Fork me on GitHub

神策数据营销策略引擎的技术演进

导读: 本文将分享神策数据营销策略引擎的技术演进,主要包括以下内容:

  • 营销中台下的策略引擎
  • 营销策略引擎平台化
  • 新一代流程画布

分享嘉宾|关海南 神策数据 营销策略引擎技术负责人
编辑整理|苏丽萍 彩讯科技
出品平台|DataFunTalk


01 营销中台下的策略引擎

1. 神策营销中台的功能范围

营销中台有其存在的价值,一方面从客户架构视角,可让营销系统发挥平台价值,比如统一营销入口、提供标准 API 等;另一方面在营销系统内部,顺应营销场景的变化,企业重视架构解耦、业务架构和技术架构的拆分。

营销中台的功能范围包括七个方面:

  • 运营计划 :决定什么人、在什么场景、什么时间、以什么形式收到什么信息。
  • 用户旅程管理 :可以通过图形化配置更丰富的营销策略。
  • 通道触达 :可以支持短信、微信、APP Push 等触达手段。
  • 微信运营 :在线的营销场景,包括微信公众号自动回复、菜单回话、微信小程序、企微功能。
  • 栏位 推荐: 包括规则推荐和算法推荐,以及对应的策略服务。
  • 内容管理 :包括素材管理、内容编辑器、分发打通功能等。
  • 标签和画像 :营销策略引擎计算使用最多的环节,包括用户分群和筛选等功能。

2. 营销中台的策略引擎

图片

营销中台策略引擎的核心功能包括五点:

  • 营销自动化 ,营销编排功能,包括简单的营销计划和复杂的流程画布。
  • 营销系统的中控 ,把其他的营销系统串联起来。如上图右侧所示:通过与推荐引擎对接来推送,推送时可获取物品信息来组装话术;和内容管理对接,用于提供丰富的内容素材;和受众引擎的对接,实现统一的受众管理和受众查询;与在线场景对接,满足交互层面的需求;与标签系统对接,满足不同人群的计算和筛选。
  • 支持丰富的营销触点场景,易扩展。
  • 支持流批一体的计算引擎 。除了对于批量和实时的支持以外,也支持流批一体的方式。
  • 提供营销相关的指标分析 。进入营销的人数和明细,触达的人数明细,以及资源转换和营销转化的人数和明细等。

3. 营销策略引擎演化路径

图片

如上图所示,在神策数据内部,营销策略引擎的演化路径可分为 四个阶段

  • 第一代: 功能比较丰富,可以满足营销智能化的业务需求,也有第一代流程画布功能。
  • 第二代 :以营销云 SaaS 化建设为主线,支持多租户部署,支持与私有部署的联动,同时开发实时标签引擎,满足 SaaS 架构下的吞吐和时效要求。
  • 第三代 :以平台化建设为主线,对系统做深度的架构优化和业务拆分。通道引擎插件化、受众引擎、在线场景融合等。
  • 第四 :以新一代画布建设为主线,构建业界前沿的自动化营销策略引擎,重点建设了流批一体的标签计算引擎。

02 营销策略引擎平台化

1. 平台化之前的典型场景

介绍营销策略引擎平台化之前,先通过几个场景来进行初步了解。

  • 场景一:某零售行业客户 A 有企业微信导购相关需求 ,对于触达通道引擎来说是增加一种通道类型——企业微信触达。在平台化之前,需要做的工作包括:开发企业微信配置界面;针对企业微信进行主流程升级;完成企业微信话术拼装、发送环节的开发;整体的联调测试等。整个周期长。
  • 场景二:某客户 B 的营销触达场景比较丰富 ,经常使用 Webhook、App Push、短信以及微信等通道类型。但 Webhook(调用客户内部接口)经常出现超时现象,且其它场景的推送量级非常大。在平台化之前,该客户面临着 SLA 无法保障,互相拥塞;流量突增时需要提前扩容等问题。
  • 场景三:某客户 C 有较多在线场景的需求 ,SLA 要求高,同时新增物品实时推荐的需求。平台化之前,面临如下问题:几类在线场景没有较好的性能隔离,SLA 不高;新的在线场景开发周期长;营销自动化与物品推荐的结合不够便捷;规则推荐和智能推荐的配置方式不统一。

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

2. 平台化之前面临的突出问题

针对以上三个场景存在的问题进行梳理总结,在平台化之前,系统面临的突出问题有四点:

  • 通道和引擎有耦合 :在平台化之前,Action 动作有插拔能力,支持自定义包的方式但通道内容的配置界面、话术拼装与提取等还需要与引擎有耦合的开发;各通道在发送端没有较好的隔离。
  • 受众计算比较分散 :业务层面来讲,营销触达、个性化推荐、规则推荐、在线场景等都有受众业务上的共性需求;技术层面来看,有统一查询和管理的需求,比如在流式、离线、在线、实时增删等场景。
  • 在线营销场景的服务待统一 :技术上,在线请求层面有弹窗、微信自动回复、推荐等在线服务需要统一抽象;业务上,对在线场景需要统一的离线的资源位管理和策略管理。
  • 规则和个性化物品推荐待统一 :平台化前,在推荐策略和推荐服务接口层面没有统一;SaaS 和多租户方面待完善。

3. 平台化的相关项目

去年初,神策数据发起了平台化的项目,包括:受众引擎、触达通道引擎、在线场景融合。

① 触达通道引擎

图片

触达通道引擎的通用目标包括:营销策略引擎和通道业务层完全解耦,可以分别独立开发;支持通道插件热加载功能,即各通道插件有独立版本,可以单独升级上线和下线,以及权限管理;支持不同通道间的隔离,粒度尽可能细、避免拥塞,也支持横向资源性扩展。

触达通道引擎的开发原则包括:使用公司统一的插件平台标准;“前后端一体化”,并不是指前后端不分离,而是指引擎的基础库是包含前端、也包括后端的逻辑,整体打包作为版本统一管理。

图片

在平台化之前,每增加一个通道类型,需要在主流程开发很多内容,会贯穿主流程,迭代效率低。在应用配置层、流程转化控制器、通道属性获取环节以及发送环节,都需要针对通道类型做适配。

在平台化之后,把所有的通道相关功能开发,包括前端和后端的代码都统一到插件内部,各模块调用插件,可通过热加载的方式加载到本地调用,也可以远程调用插件的功能。平台化之后边界更清晰,各自迭代,迭代效率会更高,互不影响。

图片

除此之外,在平台化过程中 对整个链路进行优化

平台化之前,发送环节的资源通道隔离比较典型,有几个队列用于通道发送,发送经常阻塞,发送资源也不能做到弹性的伸缩容。

平台化之后,对各通道做细粒度资源隔离,可以细到某个租户的某类通道的某个运营商的账号级别,同时支持资源弹性的扩缩容,发送量级比较大时可开启新线程,也可以通过 Yarn 或 K8s 申请对应的新资源,以满足性能的需求。

② 受众计算引擎

图片

神策数据将受众的使用统一到受众计算引擎内,服务抽象成受众管理、受众同步、受众查询三部分。

在平台化之前,受众计算比较分散。运营计划和流程画布使用离线标签计算,标签实时查询来承载受众的场景,在线弹窗只使用离线的标签计算,规则推荐使用直接查询数仓的方式。从业务看,都是营销场景下的共性需求。

平台化之后,此类需求统一到受众引擎侧,由受众引擎做统一的受众管理、调度分发、受众的同步和受众的查询。

图片

目前,神策数据受众计算引擎的构建方式比较灵活,支持多层级的受众目录方式来提供服务,使用更灵活;受众规则相同,则以软连接方式复用;支持流式、离线、在线增删改查;底层做深度的计算性能优化,整体的性能非常高。

③ 在线场景融合

图片

在线场景融合是平台化的一部分,不属于营销策略引擎。

平台化之前,各类在线服务有独立的线上服务和独立的离线管理界面,内部对接方式也不尽一致。

平台化之后,统一了在线服务的接入方式。提供统一的多租户流控、统一的Cache 管理、统一鉴权和统一的资源管理等。目前 SaaS 在线服务已接入容器服务内,支持便捷的弹性扩缩容,提供统一的资源位管理、统一的受众接入、统一的物品推荐引擎。

4. 平台化后续规划

① 持续的做稳定性和性能的优化

  • 更精细的隔离策略
  • 更贴近业务的营销系统,比如支持不同场景有不同时效的业务需求、秒级或分钟级不同时效的营销能力。

② 分层的开放平台

  • 营销触点的开放平台
  • 在线场景的开放平台
  • 其他营销系统的开放平台

03 新一代流程画布

1. 建设背景

在服务客户的过程中发现,客户营销的业务复杂度提升、客户对营销的灵活与易用性需求提升、客户对营销的性能与时效要求提高。虽然此前神策数据在流程画布也有用户旅程的部分功能,但组件的力度和使用的灵活性上有较大提升空间,所以结合国内外先进思路和实际需求重新开发了一版流程画布。

2. 建设思路

新一版流程画布的建设思路:

首先,以用户旅程视角来定义营销策略,支持以可视化的方式将进入组件、判定组件、控制组件、营销动作组件等进行编排,实现复杂营销策略的一体化配置。

第二,支持结合工作流和用户旅程的复合编排能力。

第三,个性化推荐策略深度融合,支持千人千面的营销场景和营销内容组装。

① 用户旅程示例

图片

上方图片为用户旅程示例,画布组件之间的连线以及连线的方向代表用户的旅程,即行为路径。

首先,进入节点是驱动整个用户旅程流转的开端,接下来可通过分流器判定分流客群是否满足节点规则,也可以根据客群或比例等做分流。在此过程中,单节点的标签可以是实时标签、批量标签,也可以是流批一体的标签。还可以支持对事件的判断,在每个线条上可配置时间间隔或具体时间。

控制节点除了分流以外,还包括延时器等其他的控制节点。除了进入判定和控制节点类型以外,还有营销动作的节点,即实际触达节点,实际触达会做勿扰控制、重入等方面的限制。

整体来看,新一代流程画布是以用户旅程为主线,支持周期例行调度。

② 实时受众计算引擎

图片

实时受众计算引擎的场景比较常见。上图是典型案例,配置一个实时受众,规则是近三天消费金额大于 2000 元。按照以前的方式只能配置离线作业,现在引入了实时的受众计算,可支持流批一体的功能。

图片

在实时受众引擎的技术架构中,在画布配置周转规则并发给受众引擎,受众引擎把对应规则解析,发到实时计算引擎里做流批任务拆分,同时响应离线计算,以及实时计算需要取到的客户事件和标签变更信息,通过 Flink 作业实时计算出对应的受众。同时,受众的增减也会告知给下游的画布引擎,画布引擎用实时受众的信息做判定。

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

③ 画布场景工作流与用户旅程的复合编排能力

图片

神策数据之前定义的用户旅程,默认前提不支持分身重入,即一个用户在一个时间只有一个状态。随着用户场景增多,该规则难以满足客户的需求,神策数据开始支持多次重入并行存在的功能,支持类似工作流的调度策略,重复进入来满足更多的场景需求。

④ 用户旅程产品示例

图片

上图是用户旅程产品示例,可以比较轻易构建复杂的营销逻辑。

最后总结一下,神策数据新一代营销策略引擎,以平台化为技术背景,新一代画布为主线,具有前沿的营销编排系统,期待在客户侧发挥更大价值。

04 问答环节

Q1:个性化推荐引擎和营销引擎如何实现在业务上的深度融合?一般来说推荐和营销更像上下游关系,很难融合到一起。

A1:可以分两种场景:一种场景是通过主动推送,获取物品来做话术拼装;另一种场景可以通过营销策略,写入被动的受众方,推荐引擎可以用受众包做用户的判定。

Q2:请问流批一体目前是一套代码开发,还是只支持特定类型的标签?

A2:是一套代码开发。

Q3:运营计划和营销画布有什么区别?

A3:运营计划是比较简单的营销活动,只是简单的配置受众、选择时间做触达;画布相当于会有各种不同的连线,按用户的旅程配置,属于比较复杂或者多波次的营销策略。画布会更复杂,营销计划属于画布的一个子集。但很多场景下,简单的营销计划可以满足需求,就不需要配置更复杂的营销策略。

Q4:营销画布不能覆盖运营计划吗?

A4:可以覆盖。底层引擎的实现机制,包括指标的统计计算,还有触达手段都是一样的,营销画布可以覆盖运营计划。

Q5:资料中介绍的推荐引擎是神策平台的功能模块吗?还是指外部的其他模块,只是跟神策平台对接?

A5:指神策内部的产品,不是外部的产品。

Q6:对于推送来说,可能量会比较大,推荐引擎是只提供离线的能力还是在线调用的能力?QPS 可能短时间内会有高峰的问题怎么解决?

A6:推送和推荐引擎的结合有两类实现方式:一类是纯批的,可以提前算出来;另一类实时推送的、事件触发的,可以实时去获取。在推荐在线也做了比较深度的优化,满足高 QPS 的在线类的请求。

Q7:流批一体如何解决数据对账?

A7:数据对账主要是考虑数据准确性的问题。批的计算会更准确,实时数据可能存在上传延等问题,随着时间推移,会用昨天批的计算结果再覆盖实时的计算结果,以此来达到数据的更准确。

Q8:实时的环节选择近三天的用户信息作为条件。那么在配置策略之前的目标用户数据怎么获得?

A8:对于一个任务会做离线和实时的拆分。前三天到现在的数据,会启动一个批的计算作业,现在的时间点起一个实时的计算作业,实时的计算会等待批的计算完成,相当于过去的数据也会进行处理,数据也不会丢失。

Q9:神策平台都支持哪些触达呢?按照你们的经验,哪一种触达效果会更好?

A9:首先触达工具有一些预制的,也支持自定义,某些客户也按照各自需求开发符合自己业务场景的插件。通道类型非常多,哪种触达通道的效果会比较好?我主要负责系统建设,最终触达效果关注的不太多。个人感觉不同场景下各有优势啊,可能有些场景 Push 的效果好一些,有些是弹窗。

Q10:多个运营计划是不是也可以实现画布的能力?

A10:也可以,但会非常麻烦,需要去配置不同的时间段。在一个画布里直接是两个节点,配置等待的时间,会方便很多,同时也方便统一管理。另外,在画布里可以配统一的目标事件,在运营计划里得配多个,使用起来不方便。

Q11:请问神策的多种场景类触达是一个通用的模板吗?还是 Case By Case 开发的?

A11:相当于引擎层是通用的框架,会提供基础的库。各个不同的通道类型是基于基础的库做开发。分不同的层级,有些需要做 SDK 的开发,有些需要适配,整体上还是依赖于框架做开发。对于大的通道类型是 Case By Case,但是对于一个通道类型下的不同通道,基本上开发一套就可以,不需要再做重新的开发。

Q12:画布的流批一体,应该涉及到 Flink 任务自动翻译和提交。这里神策大概是怎么做的,可以介绍吗?

A12:Flink 作业之前已经做拆分了,Flink 相当于启动的是一个实时计算,会等待离线计算任务的到达。因为离线计算并没有在 Flink 里面去完成,实际是在标签计算层去完成,所以 Flink 本身侧重于实时本身,等待离线设完,把事件接收。

Q13:神策平台是否支持多个策略互斥,即一个用户触发了 A 策略,就不再触发 B 策略了

A13:可以。在画布里面可以支持这样配置。

今天的分享就到这里,谢谢大家。

图片

关海南

神策数据 营销策略引擎技术负责人

关海南,神策数据营销引擎技术负责人。北京邮电大学硕士,10年大数据相关工作经验,擅长数据营销及大数据平台建设。前百度大数据部研发工程师,参与开发大数据实时传输系统、日志标准化系统、离线计算引擎、交互查询引擎等。前金山云金融云大数据架构师,负责过私有云以及公有云大数据平台建设,上线多家大型客户。


本文地址:https://www.6aiq.com/article/1667879312834
本文版权归作者和AIQ共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出