编辑导语：在进行新建活动的产品搭建时，有时会重复地耗费人力和物力资源，在时间比较紧的情况下，还无法保证产品质量。为了提升效率，很多企业便接入了中台的概念。那么营销中台要如何搭建呢？一起来看一下吧。

上一篇文章从优惠券的开头至结尾、前世至今生、内至外，全面地进行了梳理，相当于让大家看到了整个优惠券的全貌（当然，我觉得有可能还会有不足的地方，如果有什么问题，希望各位读者朋友可以在评论区进行讨论，质疑，逼迫我再进一步）。

依托优惠卡券的文章涉及系统，我来依次进行延伸会存在的各类对方系统，能更好的让各位有个抓手，形成生态。

做营销活动的产品，在处理一个营销活动产品的工作流基本如下：

1. 运营同学提出我们要在某个节日或者是临近节日做一个活动的需求
2. 产品同学拿到需求之后，深挖需求深度背后要解决的问题，并给出最优解决方案
3. 产品方案确认后同步技术同学基于原有的活动进行重构开发，开发完成后进行配置相应的信息并自测演示
4. 演示通过后交由测试同学进行测试，测试通过无误上线正式环境
5. 活动做好上线之后，如果有需要设计的前端落地页，还需要设计同学介入在设计一套适用活动的页面配置到活动中

综上所述：我们在进行新建活动的产品搭建时候会重复地耗费人力、物力资源，有时候在活动提出到上线时间比较紧急的情况下，还无法保证产品的质量。

基于此，所以很多企业都在接入了中台的概念，以此来提升效率。

一、为什么做中台

简单来说就是：“功能复用”（功能复用是中台最重要的一个点，复用的功能能够节省我们上方所说的人力、物力、财力），构建“大中台，小前台”来满足业务快速扩展的需求。

业务中台会沉淀大量的用户行为数据（包含非体系内用户），为后续我们利用大数据智能算法去拓展新的商业模式牟定基础，包括后续我们搭建的精细化运营等等。

中台作为业务服务的提供方，不需要依赖业务的稳定性（我们现在营销中台的产品基本都是依托于业务线的，抛开业务线之后就发现不能走路了），而是需要不断为新业务提供能力支持。所以说如果未来我们的中台足够成熟，那么可以对公司整体业务发展规模起到很大的支撑作用。

作为中台这款产品，需要包含以下几方面能力，也是我最近正在整理的：

• 针对多业务线、复杂业务场景下需求的抽象和共性需求的整合
• 针对业务线、前端用户体验、产品整体架构的抽取与整合（这块需要和前端、后端同学的深度碰撞，在实现上会结合大家的意见使用最优解决方案）
• 针对业务的深入了解，能在常规服务基础上，提供创新性业务能力，为业务创新做指引（这块主要体现在我们产品侧会不断地去补充营销侧的插件，走在我们运营要使用的某项活动前，产品前置）

二、营销中台的事

营销这个事情，在每家公司都会做，只不过做的营销有大有小。

营销中台是作为一个公共服务层去运转的，不受业务，不受场景的限制，极大的自由空间，小到领取优惠券，大到返现、MGM（老带新）等，均可由该服务层（营销中台）进行指引。

我们做的大部分类型的营销活动，或者是市面上能看到的营销活动，均可以将共性进行抽取，并整合至营销中台，由中台数据标准化api，由前端进行定制化开发，可在较短时间内完成营销产品的上线。

足够好的营销中台（比如阿里、腾讯等），前端都不需要介入开发，完全靠运营进行页面元素拼接，就可以完成业务的活动搭建，这也是基于背景下，我们想极力打造出来的营销中台模型。

全量的营销中台囊括了用户营销全量生命周期中的各个节点，并且既可以输出完整的营销服务，也可以将各个节点作为原子api输出，由业务层进行业务逻辑封装。

广义的营销中台，包含了狭义营销中台和数据中台两个方面，数据中台服务于所有业务，是大数据建设的基石，偏向技术，本身也足够庞大。

我们现在的数据中台也在进行整体的搭建，后续我会把我们营销中台的所有数据进行沉淀，统一汇总至大数据中台，结合大数据中台和营销中台，推出智能营销平台，延伸出更实用的产品，为业务进行赋能。

狭义营销中台主要包含以下三个方面：

1. 前置层：营销活动落地页快速搭建工具、营销数据埋点、用户前端行为、用户业务行为等（可细化为表现及触达层）
2. 规则层：活动基础规则、次数、场景、类型、风控、白名单等，以及相应的业务规则支持
3. 奖励层：现金红包、卡券、积分、商品、权益、虚拟币等

三、涉及所属中台

1. 营销中台

营销中台就不细说了，关于营销中台的前世今生都在这篇文章里面了。

2. 营销卡券

关于营销卡券，在上篇文章已经描述的很详尽了，大家可直接点击链接进行查阅http://www.woshipm.com/pd/5287512.html。

3. 数据中台

数据中台在这里有三个作用。

1）记录数据，用户数据、用户行为、用户类型、用户画像等。

比如场景：用户A参与了B活动，完成了C规则，获得了D奖励；基于此记录用户数据，id、手机号、地点、活动名称、时间、奖励、条件等。

2）数据分析，把已记录的数据通过数据挖掘、采集，建立数据模型，落地数据看板，提炼核心指标，跟踪分析产品数据，持续优化迭代。

3）数据转化，利用数据进行商业化，根据数据分析反馈，了解整体的分析数据和分析场景，依托数据反馈搭建商业化模型。

比如新的产品、新的活动等，并结合A/Btest快速迭代、快速优化，提升用户在公司整体产品的付费转化率。

4. 智能营销-延伸

智能营销是营销中台的用户数据支撑数据中台有足够的数据量，支撑数据中台进行数据建模、数据分析、提取重要数据点。

数据中台通过数据模型和数据分析反哺营销中台的活动调整、活动规则、活动发放能够基于用户的行为习惯、用户的画像定时定点，以用户最痛点的方式出现在他的面前，以此体现智能营销的价值。

当然，智能营销的作用，不止于此，拓展方向包括：用户唤醒、用户留存、用户转化等等，下次专门说智能营销。

四、营销中台模型

1. 表现层-表象

这地方所说的表现层，是产品框架5层的表现层，是用户直接感受到的内容，可以是落地的。主要是文字、图片、音视频给人感受的设计，呈现的文字不多，主要以高清大图为主，给人震撼、兴奋的感觉。

它们页面还包括一些动画，声音更能够触动人们的听觉，也使页面停留时间拉长，也可以是短信、邮件等。
在这里，体验是首位，业务诉求其次，还有针对复杂营销场景下高并发、限流、懒加载等多样化的技术考量。

表现层本身可以抽取出各种各样具象的工具型产品，比如落地页快速搭建工具（这块我也把营销工具落地页进行了组件化的拆解，使其使用者可以快速完成搭建落地页，且不需要麻烦产研团队，不断耗费人力重复开发），可以满足多元化的页面快速配置、发布。

而针对部分特殊场景，无法通过模块化的形式完成页面搭建，则会考虑模板化、模块化、组件化的方式，即相对通用的展现形式固化，使得后续可以复用。

2. 框架层-触达

框架层这层主要包括界面设计、导航设计、信息设计等，这个层面就是展示给用户看的界面了。界面设计，比如根据不同的情况使用复选框，单选框，下拉菜单或者按钮等。

框架层也是用户感知，用来记录与用户进行实际交互的过程。框架层包含很多的用户体验设计，需要符合用户体验操作行为等。

感知操作分为主动和被动两种，可能是用户主动进行了某个动作（比如点击、比如刷卡）参与了营销，也可能是被动的参与到某个流程中（短信、PUSH等）。

最终与用户的交互动作非常重要，剑虽好，不能一剑封喉，起不到好的效果。

3. 结构层-规则

结构层则是营销的核心，因为它的本质是一个决策引擎，需要进行统一的规划。前期可能仅仅包含了营销活动的有效期、类型、奖品等，这些只是规则层的基础。

随着活动的持续增加，规则的不断完善丰富，我们的规则组件将会越来越多面面俱到，做到真正的抛弃前端后端，运营直接依靠规则组件库随时随地配置自己想要的活动，或者是营销相关的一切。

而结构层的核心在于规则引擎，通过框架层的用户行为，对用户、行为、场景、时间等多个维度进行综合考量后，判断用户是否满足规则，以决定执行后续的营销动作。

除此之外，在规则层中还需要包含风控策略的接入（我们已经有风控可直接使用即可）、多维度限次等。

例如：规则组件的无限抽象。

4. 结构层-奖励

在营销卡券奖励和营销中台的规则都是结构层，规则和奖励都是功能模块间的逻辑设计，具有业务逻辑、业务权限、业务功能都是在此进行搭建的基础信息。

奖励可以包含营销类奖励、通知类奖励或业务类奖励。奖励的颗粒度做到多细，我们产品侧可以根据业务这边的需求来决定，目前现有的形态上我们已有的包含现金红包、优惠券、打车金、虚拟币、实物商品多种，后续可能还有我们在做的用户体系内：积分、成长值。

从底层产品侧会对各种类型奖励进一步抽象，如现金类、虚拟类、业务类等。

除了对每一种奖励类型进行维护之外，还需要包含向上游（规则层）的对接，以及对下游（账务清结算）的调用。

奖励本身其实就是一个独立的体系，可以作为底层营销中台而存在，比如我们现在独立出去的优惠券中台系统。

因为奖励做到足够的全面，足够通用，那么后期的其他业务线也可以接入直接使用。

奖励的设计好坏对规则和核算能够起到降本增效。

5. 数据中心

数据在现有的互联网行业被着重推举，每个公司的每个产品要想走的长久稳定，最终都将被数据支配。

数据中心在这里起到的作用不言而喻，不管是表现、触达、规则、奖励的数据，在用户操作产品的时，已经牵一发而动全身的统一入库至数据中心。

数据中心的数据会基于用户画像进行归类、拆解、筛选，已满足业务人员的基本数据分析要求，同时也为后续的智能营销、数字营销、精准营销打下基础。

根据数据分析，利用用户画像+用户行为+用户习惯+时间+地点等，对用户推送精准智能营销，以发挥数据最大值为商业化做背书。

五、产品活动流程

六、活动开发流程

1. 使用前

2. 使用时

运营、或者业务自己进行直接配置操作：

七、总结

在不同的业务线根据不同的时间节点会产生不同的运营活动的需求，随着时间的推移，如果按照活动的类型去进行建模，那我们对于活动本身一直都是在进行不断的重构重复的开发。

我们在搭建产品的时候，如果可以把要做的产品、需求，可以进行抽象化，看到这件事背后的东西就可以抓住最小颗粒度，围绕着最小颗粒度去搭建，并通过最小颗粒度的组件像拼乐高一样，拼成不一样的形状物品。

产研团队设计开发好乐高不同的组件后，到底要组合成什么样的形状物品取决运营团队想要什么样的物品。

本文由@无名 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Pexels, 基于CC0协议。