神策数据关海南：营销策略引擎解读，以平台化构建营销新生态

在神策 2021 数据驱动大会现场，神策营销云架构师关海南发表了题为《营销策略引擎（Express）的技术演进》的演讲。本文根据其演讲整理，核心内容如下：

• 营销中台下的策略引擎

• 营销策略引擎平台化

• 新一代流程画布

一、营销中台下的策略引擎

“中台”这个词在前两年比较热，这里我讲营销中台，一方面是从客户的架构视角出发，让营销系统能够发挥平台的价值，比如统一营销入口，提供标准 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 作业来实时算出对应标签。同时，标签的增减也会告知给画布引擎，推动画布引擎实时可用。

那么，实时标签和实时事件的区别是什么呢？实时标签和画布的场景关系较弱，可以让多个画布使用，是属于过去的事件；而实时事件和画布的上下游关系密切，是未来的事件。

起初，神策数据在定义画布时，遵循一个人在一个画布示例中，在同一时间只能有一个状态的规则，但是随着客户需求的增多，该原则难以满足客户的需求，我们需要增强画布重入，以及类似工作流的调度策略，批量的例行等待时间等，满足更多场景需求。

另外，有必要强调一下母子画布，这是神策数据新一代画布中比较重要的功能。以电商促销为例，母画布可以是双十一主会场，流程复杂，有主线的营销策略；子画布则是分会场，有各自的营销策略，同时也可以有自己的子画布。通过母子画布的方式，能够更好地实现灵活联动与覆盖。

最后，总结一下，神策数据新一代营销策略引擎，以平台化为技术背景，新一代画布为主线，支持流批一体的标签计算，构建业界先进的自动化营销引擎，期待在客户侧发挥更大价值。