解析营销中台产品模型
本文以狭义营销中台为讨论核心,从全局角度分析了营销中台产品模型中的表现层、触达层、规则层、奖励层。
中台化概述
最近“中台化”的概念如火如荼,这个概念由阿里而起,近年来头条系产品走红,将“中台化”推上了一个高位,于是从此前的前端产品和后端产品概念中,衍生出了中台产品。
那种中台究竟是个什么概念呢?简单描述如下:
- 中台的核心是“功能复用”,构建“大中台,小前台”来满足业务快速扩展的需求;
- 业务中台沉淀了大量的用户行为数据(包含非体系内用户),为大数据智能算法的新的商业模式奠定了基础;
- 中台作为业务服务的提供方,不需要依赖业务的稳定性,而是需要不断为新业务提供能力支持。从以上几点描述来看,中台的成熟度,可以对公司整体业务发展规模、健康情况管中窥豹。
按照上面的描述来看,中台是一个大型企业在稳定、持续发展中不可或缺的一个架构。而作为中台的产品,则需要包含几方面能力:
- 针对多业务、复杂业务场景下需求的抽象和共性需求的整合;
- 对业务、前端体验、后端架构等多方面能力的高要求;
- 对业务的深入了解,以能在常规服务基础上,提供创新性业务能力,为业务创新做指引。
营销中台简述
营销,每家公司无论大小,基本都会做。更适合作为一个公共服务层,小到领取优惠券,大到社交电商、购物返现、MGM等,均可由该服务层进行指引。而大部分类型的营销活动,均可以将共性进行抽取,并整合至营销中台,由中台数据标准化api,由前端进行定制化开发,可在较短时间内完成营销产品的上线(比如聚划算)。
甚至,足够好的营销中台(比如阿里、京东等),甚至连前端都不需要开发,完全靠运营进行页面元素拼接,就可以完成业务的最小化试验(MVP)。
全量的营销中台囊括了用户营销全量生命周期中的各个节点。并且既可以输出完整的营销服务,也可以将各个节点作为原子api输出,由业务层进行业务逻辑封装。
广义的营销中台,包含了狭义营销中台和数据中台两个方面,数据中台服务于所有业务,是大数据建设的基石,偏向技术,本身也足够庞大,后续在展开讨论。而狭义营销中台可以支撑超过80%的日常营销的支持,为本次讨论的核心,狭义营销中台主要包含以下三个方面:
- 前置层:页面快速搭建工具、数据埋点、用户前端行为、用户业务行为等;(可细化为表现及触达层)
- 规则层:活动基础规则、活动限次、场景、类型、白名单等;
- 奖励层:现金红包、卡券、积分、商品、PUSH等;
营销中台产品模型
站在上层,对营销中台进行全局考虑,通常会将狭义营销中台分为通用产品模型和定制化模型两种。
通用产品模型需要满足超过80%的营销玩法的支持,并且在业务策略进行微调时,可以在原有架构上快速支持。而针对部分一些可自成体系的营销策略,虽然在原模型上也可以支持,但是自身业务量、数据量都足够大,通常会拎出来重新进行抽象。如MGM、淘客模式、社交电商、外部渠道裂变等。
而通用营销产品模型,也可以支持最小化产品试验(MVP),方便业务进行快速试错,故他是营销中台的业务核心不为过。(这里先不涉及数据,毕竟数据才是现代化营销中台的#真核心#)
那么通用营销中台产品模型结构是怎样的呢,各个站点所描述的都比较偏框架层、比较宽泛,我这里提一下一家之见,供各位参考:
基本的架构,上图已经进行了大概的描述,针对每个部分,做一些细节性描述。
表现层
表现层主要是用户可以直接感受到的内容,可以是页面(RN/H5/Native),也可以是短信、邮件等等,在这里,用户侧的体验是首位,业务的诉求其次,还有针对复杂营销场景下高并发、限流、懒加载等多样化的技术考量。
表现层本身可以抽象出各种各样的表现层工具型产品,如淘宝的旺铺、京东通天塔以及类似的有赞微商城、微盟等等,通常叫做落地页快速搭建工具,可以满足多元化的页面快速配置、发布。
而针对部分特殊场景,无法通过模块化的形式完成页面搭建,则会考虑模板化的方式,即相对通用的展现形式固化,使得后续可以复用。
触达层
触达层主要记录与用户进行实际交互的过程,大部分情况下是可以并入表现层,这里将它抽象出来,是要强调他的重要性。
触达分为主动和被动两种,可能是用户主动进行了某个动作(比如点击、比如刷卡)参与了营销,也可能是被动的参与到某个流程中(短信、PUSH等)。最终与用户的交互动作非常重要,一把绝世好剑,满腹绝伦剑法,只有刺喉之时,才算精彩。
规则层
规则层则是营销的核心,因为它的本质是一个决策引擎,一脑子的剑法,不知道什么时候用哪一招,面对敌人也注定一败涂地。大部分中小公司的规则层做的都比较简陋,缺少统一的规划,可能仅仅包含了营销活动的有效期、类型、奖品等,实际上这些只是规则层的基础。
而规则层的核心在于规则引擎,通过触达层的用户行为,对用户、行为、场景、时间等多个维度进行综合考量后,判断用户是否满足规则,以决定执行后续的营销动作。
除此之外,在规则层中还需要包含风控策略的接入(可能自建)、多维度限次等,不展开讨论。
奖励层
奖励层本质上是一个库,可以包含营销类奖励、通知类奖励或业务类奖励。奖励层的颗粒度做到多细,是根据业务的需求来决定的,形态上会包含现金红包、优惠券、积分、商品、理财体验金等多种,底层均需要对各种类型奖励进一步抽象,如现金类、虚拟类、业务类等等。
奖励层除了对每一种奖励类型进行维护之外,还需要包含向上游(规则层)的对接,以及对下游(账务清结算)的调用。理论上奖励本身就是一个独立的体系,可以作为底层营销中台而存在。
可以设想的是,部分业务做大后,希望自己承接营销的规则,从表现层到规则层均由自己承接,那么他可能会做一套自己的业务系统。但是奖励层面,只要足够通用,因为涉及资金层面问题,大多数情况不会有人另起炉灶。这个可以理解为“内功”。
写在后面
此前也有对营销系统做过细节性描述,但是对整体的架构思考不足。近期对市面上的一些营销系统做了调研,结合此前手上的一些项目和思考,将整体的产品模型抽象出来。
对于大部分大型公司(BAT级别),应该具备一定的参考价值;对于中小型公司,或者是一些startups,可能会有一定的指导意义。
写在最后,营销是否智能化,营销中台的能力,很大部分取决于基础能力,如大数据,也就是前面说的数据中台。如果在做整体规划的情况,一定在各个节点都要考虑到数据的采集、筛选和后处理。为今后的长远发展做准备。
最后提一嘴,一些想法和关于产品、行业的理解,后面会同步在公众号,欢迎大家关注。
作者:whisperbot;公众号:灵魂为自己找一个伴侣(ID:vashresources)
本文由 @whisperbot 原创发布于人人都是产品经理。未经许可,禁止转载
题图来自Unsplash,基于CC0协议
1、hi老板,怎么理解奖励层对下游业务的调用?有没有可类比的系统去理解这个服务?
—-除了对每一种奖励类型进行维护之外,还需要包含向上游(规则层)的对接,以及对下游(账务清结算)的调用。理论上奖励本身就是一个独立的体系,可以作为底层营销中台而存在。
2、能否给些可调研的名字,比如可以登录进去体验后台的
—–近期对市面上的一些营销系统做了调研
在深圳嘛?最近看营销中台的机会嘛》
营销范围太广了,不应该抽象成规则、奖励,二是应该以能力来抽象,各项能力必然有自己的规则在运转,而不是所有能力的规则单独抽出来,反而极大的增加耦合。
作者这里我理解是属于活动主体的规则,而不泛指其他主体的规则
胡乱抽象
跟着业务场景走的,这个服务上面跑了五六个成熟业务了。
不懂可以,别乱说。
我有个问题,营销中台把活动进行抽象后,一个活动划分为规则和行为,那么这个行为怎么进行价格计算呢,中台是公司级别的,是有一个统一的价格计算中心吗,还是直接把行为这种配置信息丢给业务方去解决呢
我也有这种疑问
这个要看具体场景,如果是以电商和金融为主,我们之前是有一个决策系统来做这个事情的。
能否加个微信?
我的意思是规则层中的一部分设置信息(场景、限领、预算)与触达层信息有耦合,例如 如果触达层是push推送,那么规则层就无需设置限领次数与角色
看如何设计了,耦合的话,就不通用。通用的话,必然有冗余。
你说的这个场景,触达是Push+卡券,领取只是前置铺设的场景。
先说一下我的解读,你的意思是为了功能的高复用必然有冗余。
我的理解是营销场景和触达是紧密相关的,例如:会员生日领取优惠券,那么触达和领取限制就是由业务决定(触达是业务行为),那么把触达层单独抽离出来的意义是什么?
可能我不理解具体的使用场景,麻烦大佬结合具体场景点醒一下我
为啥场景和触达是紧密相关的?两个是松耦合的吧。
拿你说的例子来看,用户可以是在某个前端页面(比如积分商城)里面,去领取自己的生日礼品,这是一种场景上的领取。
触达的话,通常是指主动的,从外部去触达用户,可以是push、短信、邮件,甚至是一个小红点。
这两者是独立的。
我们两个人的理解有偏差,你说的触达应该只是通知吧,我理解的触达是用户领取到营销奖励或参与活动,用户点击领取、运营定推、游戏抽奖这一类是触达,短信、邮件、push仅是通知而已。你的触达层里“用户行为”、“业务行为”是触达没问题,但被动的push、短信、邮件应该只是通知,用户需要打开push自己领取营销奖励。
举例:我们推送优惠券领取的链接给用户,通知的形式是PUSH+短信,但实际触达的形式是用户主动点开push消息或者短信,点击链接主动领取,触达是用户行为
这不是转化吗
我理解你的意思了,对于业务来说,如果是非常精确的触达逻辑,例如通知push,在分发时就已经筛选过用户身份这样的情况下,确实是可以不设置规则层的逻辑的,但是我觉得中台还是需要支持通用逻辑规则的设置,也能保证最大化的能够满足到各个业务的不同场景。感觉不叫耦合吧~因为通用规则是可以由业务选择不设置的;不知道我有没有理解错误
你这个设计有一个问题,营销的触达层和规则层里的部分信息有耦合,例如一个营销场景是活动领券,那么触达层一定是用户领取,规则层里需要设置用户领取的限制条件(谁来领、预算多少、每人限领几次),规则层的信息受到了触达层的影响,如何处理上面所述的耦合问题?
点赞点赞!请教大佬
中台的券和前台用它的活动是1对多关系,怎么控制中台这个券的资源额度,监控追加吗…
这里面又可以衍生出一套东西,如果是一对多,可以增加渠道进行区分。
如果这样做,就涉及到多渠道共享一个资金池,还是分渠道管理资金池。
通常用的比较多的是共享资金池,那么为保证券核销成功率,就有生成前占用资金、冻结占用或者核销占用。
根据不同行业、不同业务场景,对应的决策是不同的。这也就是产品的价值了
营销系统是中台或者后台的,没法接触,请问如何进行调研呢
同业之间交流
Push为啥是奖励层
可以抽象成奖励包中的一种类型,跟随奖励一起下发。也可以独立和通知系统对接。看各自系统架构,取思路即可。
您好,能否详细说明一下基础营销规则和业务营销引擎之间的关系以及作用,这一块看不太懂。
抱歉,在后台没有回复你。可以加我微信
关于 基础营销规则和业务营销引擎之间的关系以及作用,也想详细请教一下,确实没太看懂
框架很正确了,下面是否会从具体的营销活动深入?
很好。
好
各位共勉。
可否加Vx聊一下