神策数据：揭秘证券业数字化营销新生态背后的「坚实力量」

在 《营销策略引擎解读，以平台化构建营销新生态》 一文中，我们将营销策略引擎的核心功能总结为四点：

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

2、作为营销系统的中控，把其他营销系统串联起来；

3、支持丰富的营销触点场景，包括主动的和被动的，易扩展；

4、支持流批一体的计算引擎。

在神策数据内部，营销策略引擎的演化可以分为四个阶段：第一代以丰富功能可以满足营销自动化的业务需求为主线；第二代以营销云高性能、高可用架构升级为建设主线；第三代以平台化建设为主线； 第四代以新一代画布为主线，支持用户物品多主体，重点建设了流批一体的标签计算引擎。

一、神策数据营销策略引擎在证券行业的应用

在神策数据行业化发展战略落地过程中，证券行业经营单元从一张待描画的白纸逐渐成长为了懂证券的大数据服务与营销科技服务商。其中， 以业务场景为中心的数字化营销手段也已经成为神策数据服务证券业客户的重要优势。

接下来，我们将从几个场景了解神策数据营销策略引擎平台化在证券行业的落地与应用：

场景一：某财富管理部门助力投顾通过企业微信运营相关需求，对于触达通道引擎来讲只需要增加一种通道类型——企业微信触达。那么，在平台化之前，需要开发企业微信配置界面，针对企业微信进行主流程升级，完成企业微信话术拼装、发送环节的开发以及整体的联调测试等，整个周期耗时较长。

场景二：某网金部有较多在线场景的需求，SLA 要求高，同时新增了物品实时推荐的需求。在其平台化之前面临如下问题：在线场景没有实现较好的性能隔离，SLA 不高；新的在线场景开发周期长；营销自动化与物品推荐的结合不够便捷；规则推荐和智能推荐的配置方式不统一。

场景三：某网络金融部门，需要对线上用户在一个开户流程或者某个核心流程内每一个节点出现断点的时候都进行及时触达提醒，能够有效进行干预，采用传统的流程画布会出现用户在某一个节点出现断点时，完成该节点的目标事件后就会跳出这个流程，无法进入到下一个节点，因此该用户在下一个节点出现断点时就不会再有对应的提醒。

场景四：某网络金融部门，需要对线上用户进行投后的关怀，通过数据洞察，发现当用户的亏损达到一定程度时候，该用户就会出现沉默的迹象，因此需要在用户的账户亏损达到一定比例时，对用户进行相关干预，类似投教服务，相关资讯的通知等，在平台化之前，缺少对业务数据的即时计算能力，因此缺少这类业务状态变动情况下的策略干预能力。

场景五：某财富管理部门，需要支撑投顾人员对线下用户进行有效的精细化运营，整个运营需要通过线上数据的洞察以及用户线上的一些有效行为规律叠加投顾对客户的经验判断，通过投顾侧运营客户的触点完成用户的快速触达，在平台化之前，线上数据和线下数据割裂，投顾触达客户的手段单一，对客户的认知缺少数据支撑。

二、神策数据营销策略引擎平台化

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

接下来就触达通道引擎、受众计算引擎和在线场景融合做进一步讲解。

1、触达通道引擎

触达通道引擎的目标包括：营销策略引擎与通道业务完全解耦，分别独立开发；支持通道插件热加载，也就是线上通道插件可以做单独的更新、卸载、上线和权限的管理，对引擎不会带来影响，同时，各通道插件有独立的版本，单独升级上线下线以及权限管理；支持不同通道间隔离，细颗粒度避免堵塞，吞吐能力可横向扩展。

触达通道引擎在平台化之前，贯穿主流程，迭代效率比较低。比如说 Express-Web，用来配置营销内容，对于新类型的触点需要开发配置界面；Express-Director 是流程转化控制器，对于新类型的触点需要开发获取配置的特定逻辑，Express-Nebula 是画布驱动和事件计算引擎，设计之初就比较组件化，没有业务关联的改造；Express-Actor 需要为每类通道提取话术属性，需要有单独的开发；Express-Sender 需要为每类通道做对应的发送，有对应的开发和调试。

平台化之后，触达通道引擎的边界会更清晰，迭代效率也更高。所有的通道功能开发，包括前后端代码都统一到插件内，各模块调用插件时，可以通过热加载的插件实现本地调用，也可以通过统一的插件引擎接口来访问插件的功能。对于通道的隔离，在平台化前，只有少数队列用于做通道发送，Sender 做话术拼装经常堵塞，并且发送的资源不能做到弹性的扩缩容。

除此之外，我们对各通道做了细粒度的队列和发送的资源隔离，会深入到某一个租户的某类通道的某个第三方运营商的账户级别，同时支持资源弹性扩缩容，发送有堵塞时自动开启新的线程，也可以通过 yarn 或 k8s 申请新的资源，以满足性能需求。

2、受众计算引擎

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

平台化之前，受众计算比较分散，我们的运营计划使用离线标签计算与标签查询及同步；在线弹窗采用简单的受众计算；规则推荐可以直接进行数仓查询。从业务上看，他们是营销场景下的共性需求。

平台化之后，我们将这些需求统一到受众引擎，由受众引擎做统一的受众管理、调度分发、受众同步和受众查询。

目前，神策数据受众引擎支持灵活的目录方式组装受众需求；对于规则相同的结构，可以通过软链的形式复用；支持流式、离线、在线、实时增删等服务类型；能够做深度的计算性能优化，并引入 bitmap、bloomfilter 等方式进一步加速受众组装过程。

3、在线场景融合

在线场景融合是平台化的一部分，但它不属于营销策略引擎。在平台化之前，我们各类在线服务场景较独立，有独立的在线、离线管理界面，和营销系统引擎对接的方式也不尽一致；在平台化之后，统一了在线服务的接入方式，提供统一的多租户流控、统一的 Cache 管理、统一鉴权、统一资源管理等。目前，强大的在线服务已经接入容器服务内，支持便捷的弹性扩缩容，提供统一的资源位管理、接入统一的受众引擎，以及统一的物品推荐引擎。除此之外，物品推荐引擎也是平台化的一部分，我们针对此做了规则和算法推荐的策略服务、推荐服务的接口上的统一。

在接下来的平台化规划中，我们将从稳定与性能优化、开放生态两方面持续迭代，具体包括打造更精细的隔离策略、贴近业务的营销系统，以及营销触点的开放平台、在线场景的开放平台等。如下图所示：

三、新一代流程画布

在日常服务证券客户的过程中，我们发现，客户营销的业务复杂度在提升，对营销的灵活与易用性、以及客户对营销的性能与时效要求都在持续提升。因此，建立新一代流程画布的工作亟需提上日程。

针对此，我们梳理了神策数据新一代流程画布的建设思路：

1、以用户旅程视角来定义营销策略，支持以可视化的方式将标签（流批一体）、产品、事件、营销动作、分流（条件分流、比例分流）、时间控制等组件进行编排，实现营销策略的一体化配置。

2、支持结合 workflow（工作流）和 user journey（用户旅程）的复合编排能力。

3、支持构建母子画布，以画布间跳转的方式来满足复杂的营销场景。

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

在下图中，画布组件之间的连线以及连线方向代表了用户的旅程，即行为路径，支持重入及批量例行调度。

点击放大查看高清大图

首先，进入「标签（客群）」，这是驱动整个用户流转的开端。接下来，可以通过分流器做标签分流，也可以根据百分比或事件做分流。这个过程中，单节点的标签可以是实时标签、批量标签，也可以是流批一体的标签。同时，支持对事件的判断，在每个线条上可以配置时间间隔或具体时间。所以整体来看，新一代流程画布以用户旅程为主线，支持周期例行调度，一个人在一个画布中可以多次进入。

在实时标签计算引擎的技术架构中，通常会将标签规则发送给受众引擎，受众引擎将规则注册到实时标签计算引擎内，实时计算引擎对任务进行拆分和合并，同时响应离线计算、实时事件，通过 Flink 作业来实时算出对应标签。同时，标签的增减也会告知给画布引擎，推动画布引擎实时可用。

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

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

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

神策数据新一代营销策略引擎以平台化为技术背景，新一代画布为主线，支持流批一体的标签计算，构建业界先进的自动化营销引擎，将为更多证券客户以及其他行业的客户带来更大价值！