16年四月份左右，接入美团的工作暂时告一段落，订单及商户已经全面接入美团体系。之后抽身投入活动营销项目的组建中。在这之前，我们外卖虽有做过各项目活动，但是比较缺乏营销思路，也没有成体系。这篇系列文章重点讲述之前的活动现状到整体系统的规划（下一篇会讲解对规划后的系统的可用性及稳定性的保障）。
当时业务现状
业务现状
活动上线周期长
每一次的完整活动的参与方很多，大概需要如下几个过程：
- 运营活动形式的确定；
- 产品需求确定；
- UED视觉设计；
- RD开发；
- QA测试；
- 线上灰度；
- 效果反馈。
每次活动都经过这么长的流程后，差不多也要一个月，所以当时是这个月做下个月的活动，在人力成本上投入太大，在一些活动之后的复盘的效果来看，也不尽如人意，ROI太低。
营销工具碎片化及人工化
就拿针对首购用户拉复购这个营销场景来看：
首先需要BI同学手动拉取首购用户；
其次运营人员在平台抵用券后台上传这些用户，批量发券；
然后运营人员打开push平台，给这批用户发push。
营销效果耗时费力
需要BI同学针对每个活动出具不同的数据，运营同学手动分析数据。
技术痛点
技术痛点
活动营销逻辑和订单主流程深度耦合
逻辑、代码相互耦合，活动没有单独的项目，带来的问题有很多，比如
业务理解上：错综复杂的耦合影响RD同学对业务理解；
资源上：不同的需求对同一个项目开发不可避免的会对部署环境以及QA资源产生竞争；
线上稳定性：一旦活动流量暴涨，资源竞争加剧，留给下单主流程的资源下降，导致主流程的吞吐量下降。
线上运维困难
因为没有独立的项目，且DB、redis集群，也和主流程共用。无论是活动和订单都无法准确的预估当前系统的容量。
