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

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

营销中台下的策略引擎

营销策略引擎平台化

新一代流程画布

关注神策数据公众号, 回复"2021 演讲 PPT", 即可下载完整版演讲 PPT。

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

"中台"这个词在前两年比较热, 这里我讲营销中台, 一方面是从客户的架构视角出发, 让营销系统能够发挥平台的价值, 比如统一营销入口, 提供标准 API

等; 另一方面是从营销系统内部出发, 基于丰富、多变的营销场景, 企业对架构的解耦、业务架构和技术架构的拆分重视度提升等方面, 所以我在这里再次强调了"中台"。

营销中台的功能范围覆盖以下七方面:

1.运营计划, 这是目前使用较多的功能, 是决定什么人在什么时间、什么场景中、以什么样的方式获取什么样的信息的营销手段, 配置受众、时间和内容后就可以发送营销消息。

2.用户旅程管理, 可以通过 DAG 图配置更丰富的营销策略。

3.通道触达, 支持短信、App Push、微信推送、Webhook 等一系列触达方式。

4.微信运营, 是一种在线营销场景, 支持自动回复、菜单会话等。

5.栏位推荐, 包括规则推荐和算法推荐, 以及对应的策略服务和推荐服务。

6.内容管理是神策数据重点打造的功能, 包括素材管理、内容编辑器、分发打通等。

7.标签与画像管理, 是营销策略引擎计算使用最多的环节, 可做分群与用户筛选等。

那么, 数据中台和营销中台有什么区别呢?

数据中台侧重于数据标准和复用, 比如提供统一的元数据管理和数据服务; 而营销中台则是让冷冰冰的数据"有血有肉"地运转起来, 为企业提供丰富的营销价值。

就营销策略引擎来说, 它的核心功能包括四点:

1.营销自动化, 营销编排功能, 包括简单的营销计划和复杂的流程画布。

2.作为营销系统的中控, 把其他营销系统串联起来: 通过与推荐引擎对接, 推送的时候用获取到物品信息来组装话术; 通过与内容管理对接, 提供丰富的内容素材; 通过与受众引擎对接, 实现统一的受众管理、查询与复用; 通过与在线场景对接, 满足部分交互需求; 通过与标签系统对接, 满足不同人群的计算与筛选。

3.支持丰富的营销触点场景, 包括主动的和被动的, 易扩展。

4.支持流批一体的计算引擎, 比如配置过去两天消费金额, 包括昨天和今天的, 配置完后, 窗口实时向前推进。该功能会在第三部分做详细介绍。

关注神策数据公众号, 回复"2021 演讲 PPT", 即可下载完整版演讲 PPT。

在神策数据内部, 营销策略引擎的演化可以分为四个阶段:

第一代: 功能比较丰富, 可以满足营销自动化的业务需求, 也涵盖第一代流程画布的功能。

第二代: 以营销云 SaaS 化为建设主线, 支持多租户部署, 支持与私有端联动, 同时开发新一版实时标签引擎, 满足 SaaS 架构下的吞吐和时效的问题。

第三代: 以平台化建设为主线, 对系统做深度架构优化和业务拆分, 通道插件化、受众引擎、在线场景融合等。

第四代: 以新一代画布为主线, 构建业界先进的自动化营销引擎; 支持用户物品多主体, 重点建设了流批一体的标签计算引擎。

二、营销策略引擎平台化

在介绍营销策略引擎平台化之前, 我们先通过几个场景做初步了解。

场景一: 某零售行业客户 A

有企业微信导购相关需求, 对于触达通道引擎来讲只需要增加一种通道类型 -- 企业微信触达。那么, 在平台化之前, 需要开发企业微信配置界面, 针对企业微信进行主流程升级, 完成企业微信话术拼装、发送环节的开发以及整体的联调测试等, 整个周期耗时较长。

场景二: 某客户 B 的营销触达场景比较丰富, 经常使用 Webhook、App Push、短信以及微信等通道类型。但

Webhook (调用客户内部接口) 经常出现超时现象, 且其它场景的推送量级非常大。在该客户的业务需求场景中, 平台化之前面临着 SLA

无法保障, 互相拥塞, 以及流量突增时, 需要提前扩容等问题。

场景三: 某客户 C 有较多在线场景的需求,SLA

要求高, 同时新增了物品实时推荐的需求。在其平台化之前面临如下问题: 在线场景没有实现较好的性能隔离,SLA

不高; 新的在线场景开发周期长; 营销自动化与物品推荐的结合不够便捷; 规则推荐和智能推荐的配置方式不统一。

随着营销云的客户增多, 各类的主动触达场景和在线场景的需求也在增多, 为了提升迭代效率与系统稳定性, 我们将引擎层与业务层做有效拆分, 做系统性的架构解耦, 不限于营销策略引擎本身, 也包括整个营销系统内, 营销引擎相关性较大的环节。

平台化之前, 系统面临的突出问题有以下四点:

通道与引擎有耦合: 在平台化之前,Action 动作支持插拔的能力, 支持自定义 jar 包的方式, 但像通道内容的配置界面、话术拼装与提取等较多方面还需要与引擎有耦合的开发; 且在发送端没有较好的隔离。

受众计算较分散: 业务层面来说, 营销触达、个性化推荐、规则推荐、在线场景等都有受众业务上的共性需求; 技术层面来看, 也有统一查询和管理的需求, 比如在流式、离线、在线、实时增删等场景。

在线营销场景的服务待统一: 在线请求层面有弹窗、微信自动回复、推荐等在线服务需要统一抽象; 对在线场景需要统一的离线的资源位管理和策略管理。

规则和个性化物品推荐规则待统一: 平台化前, 在推荐策略和推荐服务接口层面没有统一,SaaS 和多租户方面待完善。

今年年初, 我们发起了一个平台化的项目, 接下来就触达通道引擎、受众计算引擎和在线场景融合做进一步讲解。

关注神策数据公众号, 回复"2021 演讲 PPT", 即可下载完整版演讲 PPT。

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 作业来实时算出对应标签。同时, 标签的增减也会告知给画布引擎, 推动画布引擎实时可用。

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

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

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

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

关注神策数据公众号, 回复"2021 演讲 PPT", 即可下载完整版演讲 PPT。