企业 CDP 即企业客户数据平台,可以帮助企业实现全域用户数据采集和数据管理,使企业能够更加全面地洞察用户行为、深入分析用户需求,最终通过自动化营销方式为用户提供个性化体验。

 

现阶段,许多企业尝试落地 CDP,但却很难在短期内看到应有的 ROI 成效,初始投入与后期产出不对称,这严重打击了企业建设 CDP 的信心。在中国数据市场,企业 CDP 项目主要聚焦在数据治理上,致力于通过构建 CDP,打破数据割裂、上下游系统数据口径不一致、数据污染等困境,统一用户数据标识是企业 CDP 数据体系建设的关键问题。

神策数据《CDP 全域用户关联数据体系建设与实践》白皮书中提到,企业要想真正落地 CDP 项目并产生业务价值,其用户数据体系建设的终极目标是全域用户的标识唯一化,即把来自不同渠道、生态、业务系统的用户标识为同一个对象。本文将详细介绍企业如何通过全域用户关联实现用户标识唯一化,整体可概括为以下五个步骤。

关注神策数据公众号,回复关键字“CDP”即可免费下载完整版白皮书。

一、上下游业务系统数据现状盘点

如何从零开始开展 CDP 的用户数据基础建设?企业的首要任务是理清 CDP 上下游的数据情况,以用户为主体梳理数据应用场景,比如业务数据如何收集、用户数据在什么情况下输出、用户触达场景有哪些等。全域用户关联作为 CDP 系统的基础能力支撑,会对上游数据的收集以及下游业务系统造成影响,所以在方案设计之初需要尽可能对上下游相关的数据现状进行盘点。

典型的数据现状盘点流程包括:

1、数据源梳理:梳理各业务线涉及到的业务系统。

2、用户主体 ID 梳理:梳理各业务系统中用于标记用户主体和数据相关的 ID,比如设备 ID、企 微 ID、Union ID、Open ID、Cookie ID 等。

3、用户属性梳理:梳理各业务系统中用户标识 ID 对应的数据属性,业务 ID 对应的用户业务属性有卡号、身份、微信号、手机号等。

4、识别用户标识数据在源端存储的质量:例如在数据梳理的过程会发现一个手机号对应多个证件号,这时候需要对数据源产生的原因进行分析,找到异常数据产生的原因,如何在用户关联过程中处理。

5、用户 ID 应用场景梳理:梳理围绕 CDP 应用的整个业务流程中,涉及用户 ID 应用的典型场景,比如 CDP 全域数据接入场景、用户分群数据输出场景等。

二、全域用户 ID 关联方案设计

输出用户 ID 关联方案的首要步骤是明确各业务线中哪些 ID 参与用户的关联,并确定 ID 的优先级、数量、父节点等信息。

1、ID 优先级:优先级的设定是为了解决当一条数据中有多个 ID,又无法关联时,数据归属的问题。按照设定,数据会归属优先级更高的 ID 所对应的用户。

2、业务唯一 ID:系统中唯一标识一个用户的 ID 类型,其优先级最高。以电商业务为例,用户的登录 ID 由于和用户购物等行为直接产生关联且可以通过很多途径获取到,往往可以作为「业务唯一 ID」来定义。

3、数量:取决于实际业务中一个用户可以拥有单个还是多个该类型的 ID,可以用来校验关联关系是否符合规则。

4、父节点:在一些业务生态中,ID 之间存在着父子关系。父节点的定义可以用于解绑时一并解绑子节点,比如在微信生态中,Union ID 是 Open ID 的父节点,如果要将 Union ID 进行解绑,则附属的所有 Open ID 也将随之被解绑掉。

图 确定 ID 的优先级、数量、父节点

完整梳理 ID 之后,就可以针对性地采用埋点、ETL 等方式,完成用户关联的持续落地了。通俗来讲,就是明确将哪些业务系统中的哪些数据提取出来再导入 企业 CDP 系统中。业务中每一个事件对应的属性和涉及的 ID 都需要在埋点和 ETL 方案中体现,可以大大减少技术人员的理解成本。

三、用户数据关联的回溯修复

完成全域用户关联后,会在用户数据中发现历史关联错误的数据。根据新的关联结果,需要对这些错误数据进行解绑并绑定至正确的归属用户,重新完善用户全生命周期画像,从而提升 CDP 的用户数据质量。

举例来说,在用户关联过程中,基于同一个用户的唯一昵称「A」同时对应两个用户「张三 2020 年注册」「李四 2021 年注册」,由此识别为同一个用户,需要对重复关联数据进行合并。在这种情况下,可以参考最早触达用户的时间来完成用户属性的修复:「张三」2020 年注册早于「李四」2021 年注册,因此选择将数据关联至「张三」下。

同理,当历史数据中存在其他类似的「唯一用户 ID」并与当前产生冲突时,需要根据时间先后顺序,将两个「唯一用户 ID」进行合并,完成数据关联的回溯。

四、用户关联属性的冲突处理

企业在进行用户 ID 关联的过程中,会遇到用户关联同类属性冲突的情况,在进行属性合并的过程中,可以遵循以下四个规则:

第一,预置规则:特殊类型属性使用固定的预置规则来处理,比如按照访问时间先后顺序进行属性合并。

第二,缺省规则:默认以数据生成最早的时间为准,如果没有数据生成时间的相关字段就按照 ID 的优先级进行合并。

第三,设置基准规则:设置某个来源的数据为基准,例如相比 CRM 销售人员手动录入的信息数据和业务系统自动获取的订单数据,订单数据的准确性和稳定性显然更高,则选择以业务系统订单数据为基准。

第四,设置首末次规则:以最先接入数据的属性为准或者保持最末次的属性。

日常业务中会出现当前用户关联信息错误的情况,比如,用户更换手机导致设备 ID 变更等,这种情况就需要将现有的绑定关系解绑;另一方面,我们也发现,曾经认为某个 ID 和用户不相关,但后来经过人工等方式确认两者是相关的,这种情况就需要能够在自动关联未成功的情况下,以手动的方式将一个独立 ID 关联到现有用户上去。

五、全域用户关联数据校验及测试验收

以神策数据的 ID-Mapping 全域用户关联为例,数据校验及测试验收整体可以分为五个部分:

1、用户关联是否成功

完成全域用户关联的部署之后,首先应检查对应数据埋点方案的上报逻辑是否生效,比如,搜索埋点方案中设计的对应事件是否正常存在。

2、用户关联全端执行情况

确认事件上报后,可以基于数据埋点事件确认不同 SDK 类型上报的关联 ID/绑定 ID 的总次数。在前后端都调用的情况下,如果不同 SDK 间上报次数相差很多,则需要排查调用时机是否出了问题。

3、用户关联报错校验

这一步骤旨在确认事件上报的准确性,使用 ID-Mapping 可以在「神策数据治理」→「数据质量」→「埋点数据查询」过程中,查看是否有大量用户关联的报错,并确认错误数据量、错误分类、错误原因等细节信息。

4、ID 格式校验

检查业务 ID 的格式、长度等是否符合预期。一般来说,业务 ID 都会有相对固定的格式或长度,例如手机号一般都是 11 位,微信生态的 Union ID 和 Open ID 也都有固定的长度,验收人员可以使用 SQL 检查是否有不符合预期的数据。

5、ID 关联情况排查

一般可以分为三种情况:

第一,只有登录 ID 的用户:此类用户的特征是业务意义上的登录 ID 有值,其他 ID 均为空。查询只有登录 ID 用户的数量占比,如果发现此类用户占比过高,则可以推断出用户关联可能出现问题,登录用户没有与其他触点的 ID 成功关联上。

第二,只有某个特定触点相关 ID 的用户:例如只有微信生态 Union ID 或 Open ID 的用户,其他业务 ID 均为空。如果此类用户占比过高,则表示该触点可能没有与其他触点打通。

第三,只有设备 ID 的用户:例如发现用户表中存在大量只用 Android_id 的用户,则标明对应 Android 的用户关联可能没有做。

从业务逻辑上来说,一个用户肯定是先有 xxx ID 再有 yyy ID,对此类用户关联情况进行排查时,可以进行 SQL 查询,如果查询结果不符合业务逻辑,则需要进一步排查是否确实没有实现关联的用户,还是用户关联出现了问题,或者 ID 数据本身存在错误。

关注神策数据公众号,回复关键字“CDP”即可免费下载完整版白皮书。