企业 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”即可免费下载完整版白皮书。
（推广）
