一、公司介绍
神策数据是国内一家专业做大数据分析和营销科技的数据服务商。公司成立七年，现有规模 1200 人，七年累计服务2000 多家的客户，积累了许多行业经验，并与信通院联合发布了消费者行为分析标准。
二、营销场景的数据中台建设思路
在介绍营销数据中台的建设之前，先来讨论一下营销业务对数据的需求。我们期望帮助企业构建一个基于数据驱动的用户旅程。
比如一个企业的用户，可以通过线上或者线下途径来了解这个企业及其品牌。其中线上包括APP、网站、小程序、公众号等。用户也可能会去到线下的门店，购买商品、体验，或是成为公司的会员。对于企业来说，线上的行为数据，线下的交易数据、业务数据，共同构成了企业对用户认知的基础。
企业通过数据集成、ID关联，再加上数据分洗、标签加工等等方式，将数据打通，从而构建起用户档案，在用户档案的基础上使用例如RFM、 AIPL 等模型，即可推断出一些用户的潜在价值，或者在用户生命周期内的定位。
当我们希望去提升用户留存或用户复购的时候，在达成业务目标的通路中就可以基于数据制定一些营销策略，比如给用户发送一些定制化或者个性化的权益，通过短信、微信或电话等方式将权益通知给客户。无论采样何种方式，我们最终希望的是将所有的数据都打通，让用户得到更好的体验，并且最终沉淀成企业的数据资产。为企业长期的数字化经营提供科学依据，打造数据基础。
上图也体现了神策一直强调的 SDAF 数据营销闭环的理念（Sense 感知，Decision 决策，Action 行动，Feedback 反馈）。这个过程里，数据是贯穿始终的。
企业想要构建一个高效的数据驱动的用户旅程，一定是要建立在数据基础之上。很多企业中都已经有一些数据分析系统，或者是数据营销系统，我们期望数据中台能够起到承上启下的作用，避免烟囱式的系统建设，将数据在系统之间进行打通并可以联动。
神策的营销数据中台也是基于此目标，通过将数据集成、数据建模、数据加工和数据应用这四大关键环节能力的提升，来为企业打造个性化用户旅程和更多营销场景提供更好的数据支持。这也是我们认为营销数据中台应该解决的四个主要问题。
首先是数据集成，要接入完整的行为数据和业务数据。由于交互方式多种多样，所以需要具备灵活配置任务、可视化管理任务的能力，并提供完整的任务监控。
第二个是数据建模，要对数据进行有效的整理，企业每天的数据纷繁又庞杂，业务又灵活多变，最终数据的目标是让业务人员能够看懂数据，并且能够使用数据，这就是数据建模要集中解决的问题。
第三是数据加工，顾名思义，就是对数据做一些处理，这里主要指的是业务上的处理，比如一些客户的标签、业务指标，以及相关的一些数据分群等。
最后是数据应用部分，主要是将数据中台所持有的数据提供给分析系统、报表系统、营销系统等，并且承担多种系统之间的串联，以及数据的互联互通等职责。
接下来分别展开介绍这四部分。
1、介绍数据集成
与所有数据中台相同，我们首先要做的就是将数据接入。
通常最主要的数据源有四类。第一类最典型的是线上或者线下产生的用户行为数据，来自于 APP 或小程序等；第二类是业务数据，来自各类的业务系统，比如订单系统、会员系统或是商品管理系统等；第三类是一些第三方数据，比如来自于广告平台的广告投放数据；最后一类是企业自建的数据仓库或数据湖，其中沉淀了众多业务集市数据。
面对多种数据来源，神策的产品中做了一个数据统一的可视化的数据接收框架。针对用户行为数据，是神策相对来说最擅长的，有神策的 SDK 可以支持此部分的数据接入，其他数据的接入也提供了对应的批量或者是实时的导入工具。
在整个数据接收框架中，最新的产品中最重要的改进有两部分，一是数据对接的任务开发的成本优化，让各种数据源的数据能够轻松地接入到数据中台中。最简单的方式是数据工程师在界面上写SQL即可将数据接入，做一些简单的清洗和格式转换。稍复杂一些的是通过SeaTunnel这个框架做一些定制任务的开发，可以做一些较复杂的数据格式转换。在未来我们希望能做到对接一些行业标准的 CRM系统或ERP系统，通过一些套件做到一键接入。
在数据对接任务开发之后，后续是一些可视化的管理功能，比如任务的启停、故障和运行日志等等，主要是为了问题定位。其中比较关键的是数据血缘，意义在于当出现故障时可以及时通知下游或是做数据回溯，可以有效地降低系统故障对业务造成的影响。
2、数据建模
企业运营过程中，业务方可能会提一些营销活动的需求，要基于一些规则圈选出一些客群，通过对客群的分析，对人群做一些层次的划分，比如高频高价值、低频低价值等。再对这些不同层次的客户做一些个性化的营销策略来完成整个活动。后续还要对营销活动的效果做一些回溯，做一些复盘数据分析进行展示的。
数据部门在接收到这样的需求后，首先可能要从几百上千张表中找到对应字段，还可能需要在多张表中对其指标口径，接着做开发、测试、调试、上线，再经过几轮迭代，整个过程可能要数日甚至数月，就可能错过了营销的最佳时机。
为了提升整体的实效性，我们认为中台最终的目标不是把数据接进来就行了，而是要让业务部门能够高效、便捷地使用数据，实现业务目标。
神策提出的 EUI 模型（Event-User-Item）在用户行为分析领域发挥了非常大的价值，也帮助了非常多的客户。但随着营销业务落地场景越来越丰富，此模型也遇到了不少挑战，所以在最新的产品中对模型做了更多的扩展。在营销场景中，使用到的肯定不止是 C 端用户维度的一些数据。有的企业比如 B2C 企业既关注 B 端企业，也关注 C 端用户；零售企业关注消费者、员工、商品、供应商、门店等。这些不同实体的数据在整个营销场景中都会被不同程度的交叉使用。
因此，我们的最新产品中提供了多实体模型，除了用户以外，我们还可以将门店、员工、导购商品等所有产生数据的主体定义为实体，每个实体都可以有自己的属性标签和事件，形成自己的数据体系。在整个产品体系中，每个实体的业务能力应该是等价的。例如，用户和门店都可以有标签，通过员工事件还可以分析员工的服务质量。
在某些复杂的营销场景中，例如零售企业，在总部下发营销指令后，门店通过渠道触达自己维护的用户，并根据用户的过往习惯推荐最新上架的商品。在这样的场景中，涉及到员工、消费者、门店、商品等多个实体，以及它们之间的关联关系。对于业务来说，这些实体之间的关系比较好理解，但是对于传统的大数据系统架构来说，处理这些关联关系是比较困难的。因此，我们认为多实体是一种业务比较容易理解的数据组织方式，适用于NO SQL架构，更好地解决了大数据系统架构的问题。
另一方面，我们面临着业务数据和行为数据的打通和融合的挑战。例如订单数据，它通常具有订单ID和状态，如下单、待支付、未发货、已完成、已发货等。如果用用户行为事件来表达这些状态，那么一条数据会被拆成多条，存在大量数据冗余。此外，业务人员也难以理解其含义。因此，在我们最新的系统中，引入了明细数据类型。例如在金融场景中，有理财持仓明细等数据。每条记录包括用户ID、理财编号、当前净值、盈亏情况等。明细数据和行为数据最大的区别在于明细数据有状态，而事件数据是历史快照，不可变更。结合起来，我们才能更好地支撑营销数据体系。例如，在持仓明细中，我们可以判断用户是否有理财产品即将过期，并推荐类似理财产品，从而提升续存率。
3、数据加工与应用
在数据建模完成后，我们提供了从总体到细节的数据查看能力。系统提供了数据资产视图，可以总览数据总量、标签数量、分群数量、ID数量等信息，还可以进行不同程度的下钻，例如进入到某一分层用户列表或单个用户的360度画像。
标签和分群是营销场景中非常重要的处理方式。在这些方面，相对于以往的产品，我们做了很多增强。
首先是标签方面，神策的产品一直以来都是以行为数据为主进行建设的，包括用户行为和行为标签的建设，同时也会进行事件的聚合统计等等，如用户行为偏好等方面的标签。在引入了业务明细数据后，我们对标签规则进行了很多改进，可以将业务数据融入整个标签计算规则中，并提供函数表达式等方式，除了进行聚合计算外，还可以进行加减乘除函数等计算。除了行为标签外，还可以做一些业务标签。并且为了支持更复杂的场景，在规则方面，我们还支持插件化能力，例如企业已经有了内建的算法平台，可能会产生一些算法标签，我们也可以支持这些标签的管理工作。因此，在我们的产品中也支持插件化，将定制规则的标签纳入进来进行管理，并进行可视化配置。对于一些行业属性特别明显的企业，如银行、证券或汽车，我们也可以将一些具有行业特征的标签制作成内置的插件，提升业务人员使用的便捷度。
在分群方面，一般有两大类场景，一类是公司级的客群的大的分层，如新用户、潜在客户、活跃用户、忠诚客户等等；另一类则是对于一些临时性或者单次营销活动，进行的单次的临时分群。
我们为不同业务场景、不同角色提供了不同的数据加工能力。比如业务人员可以通过文件导入，从外部系统导入，来创建客群。另一种形式是通过我们数据中台部门维护好的标签，包括业务标签或行为标签，将标签组合起来做人群的圈选。比如广东地区，30 岁到 40 岁的男性会员作为一个客群。这两种是业务人员非常方便使用的，比如一线的业务人员可能维护200 到 2000 个客户，可以对这些人做一些临时性或是周期性的营销策略。
复杂度稍高一些的是界面规则，是一种规则模板，业务人员通过学习也可以掌握，适应更多的场景。
更为复杂的是神策最新定义EQL查询语言，即Entity Query Language。EQL与SQL具有相同能力，但是EQL对于业务人员来说更好理解、更容易掌握，它是一种更贴近自然语言的表达方式。
以上多种处理方式，可以满足从最简单、最日常的场景，到最复杂、最灵活的场景的各种需求。
最后来讲一下平台能力。作为平台来说，开放能力是很重要。所谓数据中台，是一个数据底座，需要支持各种业务系统，因此我们提供了各种Open API，可以进行很多的能力扩展。一方面，在系统中可以做更好的数据输出，另一方面也可以进行二次开发和定制开发。数据输出方面，我们支持了流式输出、订阅，也支持高并发的查询能力，从而能够更好地支持各种在线营销场景。
三、Q&A
Q1：营销平台是如何接入业务明细数据的？神策能够通过 API 直接查询业务数据库吗？这块从技术上是如何抽象和实现的？
A1：业务数据库通常是比如MySQL、Oracle 或者 PG等数据库，由于要支持业务应用因此负载也不会低，如果把大数据直接加上去是不太现实的。所以接入业务数据库的一般的方式是通过一些CDC，比如binlog 订阅的方式，将数据源表直接导入，通过replica 的方式接入，接入后对数据做一些简单的变形、做一些简单的清洗或者格式变换，比如加一些数据字典，做一些数据类型的变换，就可以放到大数据系统中来。
Q2：NO SQL 的存储如何支持多级索引的查询？比如查询门店下的导购的信息，可以支持直接关联查询吗？还是业务方使用自己的查询？
A2：是通过数据建模来做的，此部分无法做到像数据库那样的强关联，但是我们在这个数据模型里面还是做了不少的事情，本质上来说是一些 join 的计算。举个例子，比如前面提到的理财持仓数据跟客户的数据是通过客户 ID 进行关联的。具体的计算框架，在系统中也做了许多优化将时效性和计算性能提升到最高。
