1 前言

最近两三年我一直从事营销和大数据相关的产品经理岗位，参与和主导了一些方案编写和功能设计，也经历了一些坑，有些坑至今也没有很好的解决办法。因此想针对营销中台这个话题做一个总结，一方面是巩固自身的知识结构，另一方面也希望借此机会分享给大家，很多粗浅的地方也希望得到专业人士指正。在文章之前有几点要提前说明一下：

1. 我一直以来做的都是传统软件，没有直接参与过大型中台建设，看过一些中台建设的书，本文结合自身对业务和架构的理解进行整理。

2. 最近看《失控》这本书，结合自身经验告诉大家，好的系统是自下而上长出来的，而不是自上而下架构出来的。别人的架构可以参考，关键是要结合自身实际情况进行应用。

3. 本文中有些内容可以涉及到老东家的产品，如有侵权，请联系我。

2 背景

当代社会，营销对于企业的重要性不言而喻，一些花里胡哨的话我这里就不说了。市场经济下我们已经处在一个商品过剩的阶段，如何让自己的产品在众多竞品中脱颖而出，让广大用户快速认识、熟悉、喜欢然后购买自己的商品是营销的价值所在。

如今我相信不管企业大小，或多或少都会有一些营销工具和能力，哪怕是小区门口的烧烤店开业放一串鞭炮本质上也是一种营销。只是不同企业的营销工具、营销方式和范围上会有不同。真正能够全渠道、多角度、系统性的进行营销的企业不多，以下将尽量从最全的角度去构建一个营销中台的方案，实际应用过程中可以选择性的进行参考。

3 概述

营销是什么？上面说到营销目的是让广大的用户快速的认识、熟悉、喜欢然后购买我们的产品或服务。对应到互联网运营常提到的拉新、促活、转化和留存四大场景。那么为了实现所描述的目标，营销应该如何去做？我总结两条关键要素：一个是触达，即营销最重要的前提是要将营销的内容让用户知道，这里面涉及到用户群、渠道、触发事件等因素；另一个是吸引，即触达给用户的内容或者活动是用户感兴趣的，否则就成了骚扰，这里面要超两个方向努力，一个尽量针对有需要的人，另一个是尽量提供最大的优惠。围绕触达和吸引两个关键要素，还有一些其他辅助要素，例如用户参与方式、效果评估等。

总结起来，营销就是：为了XX目标，在XX时间XX地点以XX的方式和XX渠道向XX用户发送XX内容，赠送XX优惠。

4 总体架构

4.1 业务架构

从业务上来说，整个营销其实是一个相对串行的过程，我们可以从流程上对其进行业务架构划分，主要可以划分为4大部分：

l 圈人：即营销活动的目标用户，可以通过客户群离线生成，也可以通过事件实时对接。

l 触达：即我们要以什么方式和渠道给用户发送什么内容，给用户提供什么样的优惠吸引。

l 用户参与：即用户以什么样的方式参与我们的活动，用户参与可以依赖于消息触达，例如直接回复短信方式参与；也可以不依赖于触达，例如口碑传播，对于不依赖于触达的参与方式有个问题就是没法准确统计活动效果，只能根据总量的变化曲线进行大致分析。

l 效果评估：即活动过程中和结束后，对活动效果进行实时或准实时的统计分析，基于效果对活动进行及时干预，例如对效果不佳的活动进行下线操作。

以下业务架构作为参考：

4.2 功能架构

基于业务架构的逻辑，我们可以进一步抽象出整个系统的功能架构。首先为了能最大程度达到中台复用的效果，可以将整个营销中台分解成几大块服务，分别是：

1. 离线圈人服务：通过用户标签等历史行为数据，筛选出营销活动的目标用户。

2. 实时事件触发服务：即营销触达的用户条件，比如当用户查看某个功能页面时，对其进行营销。

3. 营销内容管理服务：这里指营销活动的实体，即赠送给用户的优惠，可以是具体商品和服务，也可以是各种券和折扣等。

4. 多渠道触达服务：营销渠道有很多种，有短信、外呼、站内弹屏、banner位、站外资源等，这里包括了各种营销触达渠道的封装以及消息内容的管理。

5. 用户活动参与服务：用户实际参与活动的方式，即场景库管理，以及对优惠商品的核销等，不同于3营销内容管理，这里更多的是执行实例和服务的管理。

6. 活动效果评估服务：对营销活动执行的过程进行统计监控，提供一些报表等。

以下功能架构作参考：

一个优秀的系统离不开一个好的功能架构，此前我们的产品演进就卡在了系统架构无法适应产品的演进需求，又因为公司人力预算和项目交付等各种原因无法对系统进行架构重构，导致产品迭代举步艰难，当初遇到的坑主要有以下几个方面：

1. 技术架构盲目引入flink、kafka等大数据套件，又因为人才储备无法驾驭这些组件，导致项目交付故障频出，消耗大量的人力物力。同时由于这些组件都是集群部署，导致硬件成本一直降不下来。

2. 功能架构没有分层解耦，耦合成一团，离线客户群耦合在活动执行中，同时掺杂这实时数据处理，导致系统逻辑复杂，大数据处理时性能瓶颈严重。

3. 由于十多年的定制化演进，防骚扰规则类型多达十几种，分散在执行流程的各个环节，导致代码逻辑复杂，新人开发难以快速上手。

4. 业务架构上，活动参与依赖于消息触达，使得在非依赖场景上适配困难，现有架构上的不断补丁更加降低了系统的可维护性。

4.3 技术架构

基于我们要采用的营销手段和工具，采用合适的技术方案，在用户量较少的情况下，简单的java程序与oracle数据就能满足。但是在成百上千万的用户量时，情况就会变得复杂，要考虑的因素很多，包括：

l 数据量大且读写频繁时，数据库的读写将会成为瓶颈，要考虑缓存数据库，比如redis。

l 数据存储量很大，且离线计算复杂时，要考虑分布式存储，比如hadoop。

l 企业对系统稳定性、高可用有较高要求时，要考虑应用多实例部署，数据要备份。

l 有海量实时事件数据要处理的，还要考虑消息队列和实时计算，例如kafka和flink。

l 有智能营销场景，还要考虑算法计算的技术需求。

l 大型系统基本都采用分布式服务框架，例如dubbo。

以下技术架构可作为参考：

5 详细方案

5.1 数据基础

离线圈人主要实现的方式就是根据用户的历史行为数据，通过一定的组合规则筛选出目标用户群体。由于用户的历史行为数据往往非常庞大，因此需要对数据进一步加工，即加工成标签的形式。标签的加工可以根据标签类型的不同以及数据量的不同选择合适的技术和工具，一般情况下，用户离线的标签可以用hadoop或者GP等处理大数据量的数据进行离线加工。

标签的类型有很多种，大体上可以分为以下几种：

l 属性标签：即用户比较固定的身份属性，例如手机号、性别、归属地等。

l 行为标签：即用户过往发生的行为，例如购买A产品。

l 统计标签：单纯的行为标签使用场景有限，在行为标签上进行次数统计，形成统计标签，例如过去7天购买A产品的次数。

l 预测标签：通过规则或者算法，基于用户的历史行为进行预测，判断用户未来某种行为的可能性，例如“换机指数”三颗星。

5.2 离线客户群

在用户标签的基础上，可以通过不同标签的组合生产出不同的目标客户群，然后针对这些目标客户群做营销。例如可以通过标签圈出15-30岁之间，男性，过去30天购买过A产品超过30次的用户，并对其进行营销。关于离线客户群有一些注意事项：

1. 用户的标签是动态变化的，也就是说同一个规则在不同时间执行，生产出来的用户群可能不一样。而数据的处理是要耗费时间的，也就是有可能你筛选出来的用户，当触达信息发送到用户时，用户的标签已经不满足当初的条件了，例如我们筛选当前欠费的用户发送缴费提醒，但是用户收到短信之前已经缴费过了。我们应该在营销活动设计时，尽量从业务上规避这些情况。

2. 要考虑营销活动很多的情况，即有各种各样的活动每天都在跑，产生了大量的目标用户的数据，有些规则可能每天都会重复跑，要考虑这些数据的存储和清理问题。通过临时表存储是一种方式，但或许有更好的方式。

3. 当要对全量用户进行营销时，建议单独走判断逻辑，而不是把全量用户捞出来作为一个客户群，这样会导致活动期间新增用户无法参与活动。

5.3 实时事件触发

为了在更加合适的时机向用户进行营销，在圈好目标用户后，可以设置一个用户营销触发动作，即当用户做了什么事之后再恰到好处的为用户推送信息。例如当用户搜索了A商品，系统自动为用户推送A商品的优惠同款。关于实时事件触发的几个注意点：

1. 用户每天的行为数据有很多，全部都要处理的话，这是一个海量的数据，对系统的性能会造成比较大的影响。在考虑从技术上进行优化的同时，也可以考虑在业务进行处理优化。例如可以对数据来源进行分类，不同类型数据作为不同事件源，降低单一事件源的数据量。

2. 事件的处理也有不同的深度，从简单匹配命中到数量计算，再到多个事件之间的逻辑组合运算，不同计算深度对系统资源的消耗不同。例如简单匹配命中和数据计算或许通过java程序处理更加简单高效。此前我们的系统就全部怼到了flink中计算，导致flink资源成为瓶颈。

3. 实时事件触发的营销往往也需要实时进行，这与离线营销场景完全不同，导致圈人后面的执行流程也会有较大差异，之前我们是采用了两条不同的路线，系统同时支持实时营销和批量营销两种方式，某种意义上增加了系统的复杂性。其实可以通过合适的技术方案将批量的营销流程合并到实时的营销流程中，大家在实践中可以思考一下。

5.4 营销内容管理

前面概述中说到营销的第二个关键要素就是吸引，那么吸引最简单的方式就是提供优惠，那么营销内容管理其实就是优惠管理。

优惠的方式有很多种，这里在模型设计时应该考虑不同类型优惠的扩展性，包括单一折扣、组合折扣、折上折、优惠券、积分、赠品、返现、满减等各种方式。营销内容管理的模型设计上，不仅要支持灵活配置这些优惠，还要能够在用户参与活动时进行领取、发放与核销，并最终能够对活动预算进行管理。

这块功能最难的地方是在模型的扩展性设计上面，随着业务的发展，会不断的加入各种各样的优惠方式，如果模型不好扩展，就会不断增加系统复杂度，使得系统迭代越来越困难。至于如何设计模型和架构，我这里也没有很好的经验，建议在库表设计上采用基础表+扩展表的方式进行扩展。

5.5 触达渠道管理

如今企业在做营销时有很多渠道可以选择，即多渠道融合营销。例如在推销保险时可以先通过线上广撒网的方式推广，当用户感兴趣并填写个人信息时再通过电话的方式进一步营销并促成交易。在实际营销时，企业可能拥有数十种营销渠道，那么这些渠道的管理和融合将会是一个较大的问题。因此可以构建一个统一的触达渠道管理系统，面向外部统一对接和管理各个渠道，对内部统一封装触达服务，并且提供渠道融合和消息内容管理等功能。主要功能如下：

1. 渠道接入，通过API网关的方式，支持快速接入各种线上渠道，外呼、短信、弹屏、banner等，并支持渠道的管理。

2. 资源位管理，不同渠道可能拥有多个资源位，并存在容量和流量的瓶颈限制，例如坐席外呼受限于坐席人数，banner也不能无限增加。因此需要对不同渠道的资源位和资源瓶颈进行管理，当资源不足时阻断调用或者配置引用。更进一步，可以各种活动的效果数据支持资源位的效果统计，例如不同banner为的PV、转化率等数据。

3. 触达内容管理，包括短信模板和外呼话术等，在banner和弹屏中还要提供活动文案和图片等管理功能。另外，消息内容中还应该支持特定的宏变量功能，例如用户的姓名需要根据不同用户进行实例化。一般情况下，触达内容应该是跟渠道强相关的，我们此前系统就是因为将内容做成了一个独立通用功能，反而导致了在实际使用时产生了很多逻辑问题，例如外呼配置了短信的文案导致场景错乱的问题。

4. 渠道协同和融合，有些时候我们通过多种渠道向用户传递消息，不同渠道的时效快慢不同，我们希望只要有一个渠道触达了用户，其他未触达的渠道则回收消息，停止触达。类似这样的场景就需要渠道之间能进行协同。

5.6 营销评估

如果我们仅仅有了营销工具，能够进行信息触达和活动参与，但是没办法获得营销效果，这样就没有办法进行复盘和改进，达不到营销的目标。因此我们需要构建一套能够准确评估活动效果的机制。

效果评估本质是对指标的分析和统计，主要有以下几种分析方式：

1. 统计活动的直接指标，例如触达率、点击率、转化率、ROI等指标，这里面很多数据需要前期进行埋点。

2. 抽样对比分析，很多时候很难说清楚用户的行为是受营销活动影响，还是自然的行为变化，这个时候可以通过抽样比对分析。从目标受众用户中随机抽取一小部分用户作为对照组，对照组不参加活动，也不发送消息。最终通过比对对照组和非对照组的相关指标判断活动效果，例如活跃度、URPU值、在线时长等指标。

3. 在一些特殊场景，例如拉新场景下没办法通过对照组的方式进行效果评估，就可以通过与过去的数据进行比对，通过曲线的变化率来判断活动效率，例如新用户增长率。