神策营销数据中台建设思路

开发 中台
通常最主要的数据源有四类。第一类最典型的是线上或者线下产生的用户行为数据,来自于 APP 或小程序等;第二类是业务数据,来自各类的业务系统,比如订单系统、会员系统或是商品管理系统等;第三类是一些第三方数据,比如来自于广告平台的广告投放数据;最后一类是企业自建的数据仓库或数据湖,其中沉淀了众多业务集市数据。

一、公司介绍

神策数据是国内一家专业做大数据分析和营销科技的数据服务商。公司成立七年,现有规模 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 进行关联的。具体的计算框架,在系统中也做了许多优化将时效性和计算性能提升到最高。

责任编辑:姜华 来源: DataFunTalk
相关推荐

2023-12-29 13:48:00

数据中台

2019-05-28 23:00:45

数据中台大数据开源工具

2018-08-15 13:44:56

神策数据

2017-01-19 18:03:50

大数据

2017-01-10 17:38:37

微信小程序

2020-06-06 12:37:37

数据中台Gartner企业

2021-03-31 22:37:03

数据中台企业技术

2021-01-26 09:34:08

QPS数据中台

2020-08-19 11:21:14

数据中台数据时代Gartner

2023-11-15 13:36:00

数仓建设数据中台

2020-05-29 17:10:15

数据架构数据一切数据体系

2013-10-23 10:32:51

大数据营销 互联网

2023-08-14 07:28:02

2023-07-04 07:11:30

数据分析中台

2016-11-15 14:18:09

神策分析大数据数据分析

2019-11-07 15:31:48

中台大数据
点赞
收藏

51CTO技术栈公众号