-
营销中台下的策略引擎
-
营销策略引擎平台化
-
新一代流程画布
一、营销中台下的策略引擎
“中台”这个词在前两年比较热,这里我讲营销中台,一方面是从客户的架构视角出发,让营销系统能够发挥平台的价值,比如统一营销入口,提供标准 API 等;另一方面是从营销系统内部出发,基于丰富、多变的营销场景,企业对架构的解耦、业务架构和技术架构的拆分重视度提升等方面,所以我在这里再次强调了“中台”。
营销中台的功能范围覆盖以下七方面:
1.运营计划,这是目前使用较多的功能,是决定什么人在什么时间、什么场景中、以什么样的方式获取什么样的信息的营销手段,配置受众、时间和内容后就可以发送营销消息。
2.用户旅程管理,可以通过 DAG 图配置更丰富的营销策略。
3.通道触达,支持短信、App Push、微信推送、Webhook 等一系列触达方式。
4.微信运营,是一种在线营销场景,支持自动回复、菜单会话等。
5.栏位推荐,包括规则推荐和算法推荐,以及对应的策略服务和推荐服务。
6.内容管理是神策数据重点打造的功能,包括素材管理、内容编辑器、分发打通等。
7.标签与画像管理,是营销策略引擎计算使用最多的环节,可做分群与用户筛选等。
那么,数据中台和营销中台有什么区别呢?
数据中台侧重于数据标准和复用,比如提供统一的元数据管理和数据服务;而营销中台则是让冷冰冰的数据“有血有肉”地运转起来,为企业提供丰富的营销价值。
就营销策略引擎来说,它的核心功能包括四点:
1.营销自动化,营销编排功能,包括简单的营销计划和复杂的流程画布。
2.作为营销系统的中控,把其他营销系统串联起来:通过与推荐引擎对接,推送的时候用获取到物品信息来组装话术;通过与内容管理对接,提供丰富的内容素材;通过与受众引擎对接,实现统一的受众管理、查询与复用;通过与在线场景对接,满足部分交互需求;通过与标签系统对接,满足不同人群的计算与筛选。
3.支持丰富的营销触点场景,包括主动的和被动的,易扩展。
4.支持流批一体的计算引擎,比如配置过去两天消费金额,包括昨天和今天的,配置完后,窗口实时向前推进。该功能会在第三部分做详细介绍。
在神策数据内部,营销策略引擎的演化可以分为四个阶段:
第一代:功能比较丰富,可以满足营销自动化的业务需求,也涵盖第一代流程画布的功能。
第二代:以营销云 SaaS 化为建设主线,支持多租户部署,支持与私有端联动,同时开发新一版实时标签引擎,满足 SaaS 架构下的吞吐和时效的问题。
第三代:以平台化建设为主线,对系统做深度架构优化和业务拆分,通道插件化、受众引擎、在线场景融合等。
第四代:以新一代画布为主线,构建业界先进的自动化营销引擎;支持用户物品多主体,重点建设了流批一体的标签计算引擎。
二、营销策略引擎平台化
在介绍营销策略引擎平台化之前,我们先通过几个场景做初步了解。
场景一:某零售行业客户 A 有企业微信导购相关需求,对于触达通道引擎来讲只需要增加一种通道类型——企业微信触达。那么,在平台化之前,需要开发企业微信配置界面,针对企业微信进行主流程升级,完成企业微信话术拼装、发送环节的开发以及整体的联调测试等,整个周期耗时较长。
场景二:某客户 B 的营销触达场景比较丰富,经常使用 Webhook、App Push、短信以及微信等通道类型。但 Webhook(调用客户内部接口)经常出现超时现象,且其它场景的推送量级非常大。在该客户的业务需求场景中,平台化之前面临着 SLA 无法保障,互相拥塞,以及流量突增时,需要提前扩容等问题。
场景三:某客户 C 有较多在线场景的需求,SLA 要求高,同时新增了物品实时推荐的需求。在其平台化之前面临如下问题:在线场景没有实现较好的性能隔离,SLA 不高;新的在线场景开发周期长;营销自动化与物品推荐的结合不够便捷;规则推荐和智能推荐的配置方式不统一。
随着营销云的客户增多,各类的主动触达场景和在线场景的需求也在增多,为了提升迭代效率与系统稳定性,我们将引擎层与业务层做有效拆分,做系统性的架构解耦,不限于营销策略引擎本身,也包括整个营销系统内,营销引擎相关性较大的环节。
平台化之前,系统面临的突出问题有以下四点:
通道与引擎有耦合:在平台化之前,Action 动作支持插拔的能力,支持自定义 jar 包的方式,但像通道内容的配置界面、话术拼装与提取等较多方面还需要与引擎有耦合的开发;且在发送端没有较好的隔离。
受众计算较分散:业务层面来说,营销触达、个性化推荐、规则推荐、在线场景等都有受众业务上的共性需求;技术层面来看,也有统一查询和管理的需求,比如在流式、离线、在线、实时增删等场景。
在线营销场景的服务待统一:在线请求层面有弹窗、微信自动回复、推荐等在线服务需要统一抽象;对在线场景需要统一的离线的资源位管理和策略管理。
规则和个性化物品推荐规则待统一:平台化前,在推荐策略和推荐服务接口层面没有统一,SaaS 和多租户方面待完善。
今年年初,我们发起了一个平台化的项目,接下来就触达通道引擎、受众计算引擎和在线场景融合做进一步讲解。
1.触达通道引擎
触达通道引擎的目标包括:营销策略引擎与通道业务完全解耦,分别独立开发;支持通道插件热加载,也就是线上通道插件可以做单独的更新、卸载、上线和权限的管理,对引擎不会带来影响,同时,各通道插件有独立的版本,单独升级上线下线以及权限管理;支持不同通道间隔离,细颗粒度避免堵塞,吞吐能力可横向扩展。
触达通道引擎的开发原则要求,必须使用公司统一的插件平台标准,并且能够做到“前后端一体化”,这并非是指前后端代码不分离,而是指引擎基础库包含前后端基础库,也就是这个插件既包含前端,也包含后端,最后会整体打一个包,做统一的版本管理。
触达通道引擎在平台化之前,贯穿主流程,迭代效率比较低。比如说 Express-Web,用来配置营销内容,对于新类型的触点需要开发配置界面;Express-Director 是流程转化控制器,对于新类型的触点需要开发获取配置的特定逻辑,Express-Nebula 是画布驱动和事件计算引擎,设计之初就比较组件化,没有业务关联的改造;Express-Actor 需要为每类通道提取话术属性,需要有单独的开发;Express-Sender 需要为每类通道做对应的发送,有对应的开发和调试。
平台化之后,触达通道引擎的边界会更清晰,迭代效率也更高。所有的通道功能开发,包括前后端代码都统一到插件内,各模块调用插件时,可以通过热加载的插件实现本地调用,也可以通过统一的插件引擎接口来访问插件的功能。对于通道的隔离,在平台化前,只有少数队列用于做通道发送,Sender 做话术拼装经常堵塞,并且发送的资源不能做到弹性的伸缩容。
除此之外,我们对各通道做了细粒度的队列和发送的资源隔离,会深入到某一个租户的某类通道的某个第三方运营商的账户级别,同时支持资源弹性扩缩容,发送有堵塞时自动开启新的线程,也可以通过 yarn 或 k8s 申请新的资源,以满足性能需求。
2.受众计算引擎
将受众的使用统一到受众计算引擎内,并将服务抽象成受众管理、受众同步、受众查询三部分是神策数据受众计算引擎的核心。
平台化之前,受众计算比较分散,我们的运营计划使用离线标签计算与标签查询及同步;在线弹窗采用简单的受众计算;规则推荐可以直接进行数仓查询。从业务上看,他们是营销场景下的共性需求。
平台化之后,我们将这些需求统一到受众引擎,由受众引擎做统一的受众管理、调度分发、受众同步和受众查询。
目前,神策数据受众引擎支持灵活的目录方式组装受众需求;对于规则相同的结构,可以软链的形式复用;支持流式、离线、在线、实时增删等服务类型;能够做深度的计算性能优化,并引入 bitmap、bloomfilter 等方式。
3.在线场景融合
在线场景融合是平台化的一部分,但它不属于营销策略引擎。在平台化之前,我们各类在线服务场景较独立,有独立的在线、离线管理界面,和营销系统引擎对接的方式也不尽一致;在平台化之后,统一了在线服务的接入方式,提供统一的多租户流控、统一的 Cache 管理、统一鉴权、统一资源管理等。目前,SaaS 化在线服务已经接入容器服务内,支持便捷的弹性扩缩容,提供统一的资源位管理、接入统一的受众引擎,以及统一的物品推荐引擎。除此之外,物品推荐引擎也是平台化的一部分,我们针对此做了规则和算法推荐的策略服务、推荐服务的接口上的统一。
在接下来的平台化规划中,我们将从稳定与性能优化、开放生态两方面持续迭代,具体包括打造更精细的隔离策略、贴近业务的营销系统,以及营销触点的开放平台、在线场景的开放平台等。如下图所示:
三、新一代流程画布
在神策数据服务客户的过程中,我们发现,客户营销的业务复杂度在提升,客户对营销的灵活与易用性、以及客户对营销的性能与时效要求都在持续提升。因此,建立新一代流程画布的工作亟需提上日程。
接下来我们详细介绍一下神策数据新一代流程画布的建设思路:
1.以用户旅程视角来定义营销策略,支持以可视化的方式将标签(流批一体)、产品、事件、营销动作、分流(条件分流、比例分流)、时间控制等组件进行编排,实现营销策略的一体化配置。
2.支持结合 workflow(工作流)和 user journey(用户旅程)的复合编排能力。
3.支持构建母子画布,以画布间跳转的方式来满足复杂的营销场景。
4.个性化推荐策略深度融合,支持千人千面的营销场景和营销内容组装。
在下图中,画布组件之间的连线以及连线方向代表了用户的旅程,即行为路径,支持重入及批量例行调度。
首先,进入「标签(客群)」,这是驱动整个用户流转的开端。接下来,可以通过分流器做标签分流,也可以根据百分比或事件做分流。这个过程中,单节点的标签可以是实时标签、批量标签,也可以是流批一体的标签。同时,支持对事件的判断,在每个线条上可以配置时间间隔或具体时间。所以整体来看,新一代流程画布以用户旅程为主线,支持周期例行调度,一个人在一个画布中可以多次进入。
在实时标签计算引擎的技术架构中,通常会将标签规则发送给受众引擎,受众引擎将规则注册到实时标签计算引擎内,实时计算引擎对任务进行拆分和合并,同时响应离线计算、实时事件,通过 Flink 作业来实时算出对应标签。同时,标签的增减也会告知给画布引擎,推动画布引擎实时可用。
那么,实时标签和实时事件的区别是什么呢?实时标签和画布的场景关系较弱,可以让多个画布使用,是属于过去的事件;而实时事件和画布的上下游关系密切,是未来的事件。
起初,神策数据在定义画布时,遵循一个人在一个画布示例中,在同一时间只能有一个状态的规则,但是随着客户需求的增多,该原则难以满足客户的需求,我们需要增强画布重入,以及类似工作流的调度策略,批量的例行等待时间等,满足更多场景需求。
另外,有必要强调一下母子画布,这是神策数据新一代画布中比较重要的功能。以电商促销为例,母画布可以是双十一主会场,流程复杂,有主线的营销策略;子画布则是分会场,有各自的营销策略,同时也可以有自己的子画布。通过母子画布的方式,能够更好地实现灵活联动与覆盖。
最后,总结一下,神策数据新一代营销策略引擎,以平台化为技术背景,新一代画布为主线,支持流批一体的标签计算,构建业界先进的自动化营销引擎,期待在客户侧发挥更大价值。