企业 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 的优先级、数量、父节点等信息。

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

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

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

4、父节点：在一些业务生态中，ID 之间存在着父子关系。父节点的定义可以用于解绑时一并解绑子节点，比如在微信生态中，Union ID 是 Open ID 的父节点，如果要将 Union ID 进行解绑，则附属的所有 Open 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 数据本身存在错误。