一、引子

有赞，是一个商家服务公司。我们帮助每一位重视产品和服务的商家私有化顾客资产、拓展互联网客群、提高经营效率，全面助力商家成功。而拉新、留存、促活、转化则是商家经营的关键指标。随着线上线下流量越来越贵，商家对客户精准运营诉求越来越强烈。有赞客户运营相关的业务产品也在近一年不断推陈出新。

二、早期“烟囱式”系统建设模式

早期客户运营产品的建设模式与一般企业IT系统建设模式类似：业务产品部门提出业务需求，技术部门针对需求进行分析、开发、测试、上线。但由于早期产品形态的不稳定、产品技术人员更替等因素，每一个新的业务产品都预示着一座新“烟囱”的建设，于是客户运营业务发展成如下形态。旧版架构客户运营先后共推出了兴趣人群营销、互动粉丝营销、精准人群营销、生日营销、节日营销、会员日营销等客户运营相关的业务产品，涵盖了微商城、零售等多种行业形态。

随着业务发展，产生了“场景营销”和“人群运营”两个子域。这两个子域之间有很多共性，但也出现了很多共有的问题：每个业务产品独立实现维护，拥有各自的模型，各自的实现链路。系统内部几乎没有可以复用的组件，复杂度高、链路长、维护成本高。新的业务产品功能需要重新建设，无法快速实现，迭代缓慢。

总结下来，“烟囱式”系统建设模式主要有如下弊端：

重复功能建设和维护带来的重复投资
打通“烟囱式”系统间交互的集成和协作成本高昂
不利于业务的沉淀和技术发展

三、系统整合契机

每一年的五月，有赞都会举办春季发布会，发布会上将推出全新的产品、更好用的功能等助力商家成功。而发布会上的每项功能背后，则是每个有赞人奋斗的血与泪。

本次发布会的计划功能之一就是将粉丝管理升级为全渠道运营的会员营销中心，最主要的功能就包括了“场景营销”“人群运营”的升级。如果在原有系统上进行产品迭代，无论是系统改造范围、复杂度、投入产出比、未来维护成本、后续产品建设速度，都是让技术同学极其头疼的。综合考虑后，最终选择在新的系统上完成本次需求，并对原有业务进行整合。

四、系统建设

4.1 系统目标

将场景营销、人群运营底层能力进行整合，沉淀出运营计划领域模型，统一产品逻辑，方便后续统一维护。
为了方便商家通过“有赞云”实现个性化定制，将系统功能原子化，拆成单独的组件，基于流程编排的方式建设系统。
搭建客户运营中台，将原有上层业务的场景化接口下沉，方便微商城、零售以及后续新形态业务的能力复用。
成为培育业务产品的土壤，提升产品迭代的速度。针对后续新的运营产品需求，大部分功能可以通过配置或者扩展的方式进行实现。

4.2 共性和可变性分析

首先，让我们分析出已有的六个客户运营产品之间的共性。经过对现有的六个客户运营产品进行分析，我们抽象出了运营对象、运营时间、运营行为、用户运营记录等共性。我们认为运营计划的本质可以概述为：按照一定的条件圈出一批运营对象，在合适的运营时间，执行相应的运营行为。

在抽象出共性之后，我们进行可变性分析，寻找出如下可以变化的点:
运营对象：指定等级的会员、生日的会员、公众号粉丝、浏览店铺但未消费的顾客、加购但未付款的客户
运营时间：周期性（每月、每周、每天）、用户生日（当日、当周、当月）、固定时间段、立即执行、延时执行
运营行为： 发放权益（积分、优惠券、包邮、折扣等）、发放消息通知
用户运营记录： 发放权益、发放消息、使用运营计划权益、回补运营计划权益

4.3 技术架构

新版架构

运营计划领域核心：“运营计划”核心领域模型的抽象、实现。
基础组件：与领域无关的通用组件，如task组件、流速任务处理组件、消息通知组件、期限表达式组件，方便新的业务产品及其他领域的复用。
业务产品：基于“运营计划”核心模型包装出业务产品，例如生日营销、节日营销、会员日营销、精准人群营销、兴趣人群营销、互动粉丝营销。随着业务产品的发展，也将沉淀出更多通用能力，持续反哺底层抽象，对“运营计划”模型进行补充、完善。
场景化聚合层：场景化接口的实现，目前微商城、零售的一些C端场景化接口可以复用，沉淀在这一层，方便后续其他前台产品复用。
前台：有赞不同行业形态的细分产品，如微商城、零售、零售连锁等。

4.4 运营时间

按照上述分析，“运营时间”是一个极易发生变化的点。不同业务产品均有各自的运营时间，后续新的业务产品也很有可能有自身的一套运营时间。针对于此，决定抽象出期限表达式的概念。经过调研，组内成员基于cron表达式自行扩展了一套期限表达式的转换组件。

针对周期性活动，如每周一、周三生效，则表示为“* * * * * 1,3 * 32”。
针对周期性中每天的固定时间段活动，如每天08:20 - 20:30生效，对应表示为“ 20-30 8-20 * ? 31”
针对固定期限，如2019.04.24~2019.04.25生效，则表示为“0-0 0-0 0-0 24-25 4-4 * 2019-2019 2”。

此外，还将运营时间拆分出生效时间、运营期限、执行时间三个概念。后续随着业务发展，运营计划底层将抽象出三种时间的计算接口，上层产品负责具体计算方式的接口实现，各业务产品对运营计划的核心流程进行复用。

4.5 统一接入人群系统

按照上述分析，“运营对象”也是一个极易发生变化的点。不同业务产品，运营对象均有可能不同。
考虑到现状，有赞SCRM目前已经维护了一个人群系统，但由于缺乏业务推动，目前实现还比较简单。从SCRM全局的视角出发，决定将“圈人”的规则、筛选等职责统一交由人群系统。后续随着客户运营系统的发展，将会出现更多维度的条件进行“圈人”，这也会间接的推动人群系统的发展。

4.6 统一接入权益平台系统

目前，人群运营产品（精准人群营销、兴趣人群营销、互动粉丝营销）的运营行为单一，只能够支持给用户发放优惠券来激活用户。在和产品人员进行沟通后，产品人员也希望人群运营有更多的能力吸引用户消费，产生更好的运营效果。所以，客户运营产品决定统一接入权益平台系统。权益业务现有权益系统已沉淀了包邮、折扣、积分、积分倍率、优惠券、赠品、知识付费、体验卡、成长值等十几种权益，商家自定义权益也已经在内测中。在此基础上，针对不同行业包装出了不同特性的权益行业模板。此外，伴随着权益系统的发展，权益底层已沉淀出如多版本权益组合、权益库存、周期性权益、权益发放、权益回收等基础能力。可以预见的是，未来权益系统的业务能力仍将不断得到补充。

客户运营系统接入权益平台系统，将给客户运营业务产品带来更多的“优惠”能力组合方式，更大的想象空间。客户运营系统无需关注积分、赠品、成长值、优惠券系统的发放细节，无需关注包邮、折扣的使用细节，客户运营系统只需要关注什么时间给什么用户发放权益即可。这简化了客户运营系统的模型，客户运营系统可以聚集于思考自己领域内的发展。同时，接入权益平台系统，也能给商家带来更多的运营策略，更好的运营效果。

4.7 任务处理

新系统统一基于流式处理的方式，对任务进行spilt、load、execute三个步骤的处理，提升任务处理的整体速度。为防止对下游系统产生过大压力，也可以动态调整任务处理的速度。但是，现有客户运营的流式任务处理与业务结合紧密，不能被其他业务复用。当前，团队内部已经在搭建分布式任务批处理调度系统，后续其他业务也可以接入。批处理架构图中的TSP调度系统，是有赞内部的任务调度平台，支持延时任务、定时任务调度。对于处理失败的任务，批处理系统将记录失败任务信息，系统将定期重试处理失败任务。

五、展望

新版客户运营系统充分结合了SCRM领域的现有能力进行建设，并反推SCRM依赖的子域系统的发展，其系统演进的本身也带给了我们一些思考：架构应该着重思考领域的商业价值，注重团队整体的智慧，从整体出发，综合考虑业务现状、技术现状、投入产出比、未来发展等几个角度去产出最优的决策。而不是过早的介入通用性等考虑，陷入设计陷阱。

而伴随着业务发展，客户运营系统还有很多事情可以做，如：