多端身份统一，应先明确企业要识别的是账号、会员还是具体业务客户，再确定哪些标识能够证明同一身份。OneID的价值在于让跨来源行为能够按一致规则关联，而不是追求更高的合并数量。关联过程需要能解释、纠错，并让标签、人群和分析同步遵守身份规则。
本文提供的是通用评估方法。具体规则应结合业务账户体系、授权范围和产品实现确认，不代表某款CDP默认采用的算法或字段。
一、先分清设备、账号、会员和客户
一个人可能使用多个设备，一个设备也可能由多个人使用。账号可能由组织统一管理，会员身份则可能只在特定业务范围内有效。如果不先解释这些关系，“去重用户数”就可能使用了不同的分母。
例如，匿名访问与登录后的操作是否可以关联，要看是否存在合法且可靠的关系证据；同一设备上先后登录两个账号，也不能仅凭设备一致，就把两个账号认定为同一个人。
建议先列一张身份资产表：
联系方式不宜不加条件地作为永久唯一身份。应明确其授权用途、变更规则和可访问范围，而不是因为多个来源出现相同值，就直接完成永久合并。
二、把关联规则写成可解释的业务判断
在评估前，先说明哪些证据允许建立关系，哪些只能作为线索，以及证据冲突时由谁处理。规则至少应包含适用数据源、发生时间、可信依据、例外情况和生效范围。
可以把规则问题分成三个层次：
- 确定可以关联。 例如，在受控流程中，业务账户系统提供了明确的账号与会员关系。
- 需要进一步确认。 例如，历史数据存在重复编号、缺失时间或来源不清。
- 明确不能据此关联。 例如，仅因同一设备被不同账号使用，就推断为同一客户。
这里的例子用于说明测试边界，不是厂商默认功能。实施时需要由业务账户负责人、数据团队及相关管理角色共同确认。
企业还应分清“客户身份统一”和“业务对象关联”。车辆、门店、商品等可以与客户建立业务关系，但不应因为存在购买或到访记录，就与客户合并成同一种身份。业务对象之间的关系，需要单独定义。
三、历史关联要能解释时间
如果一条关系在今天建立，是否影响昨天的报表？如果账号关系被更正，已经导出的人群是否同步更新？这些问题决定了分析结果能否被正确解释。
至少要区分三种时间：业务事件发生时间、数据进入系统的时间，以及身份关系生效或被修正的时间。迟到数据不能只按到达顺序覆盖历史判断，具体行为应按事先约定的规则验证。
在供应商演示中，可以选择一个测试身份追问：它为什么被关联，关系来自哪里，关联前后哪些标签和统计发生变化，哪些下游结果不能自动追回。能回答这些问题，比只展示一个统一编号更有意义。
四、用合成数据覆盖正常情况与反例
不要直接拿真实客户资料做开放式测试。可以先设计不含真实身份的合成样本，并在测试前写明预期结果。
测试中既要有“应该关联”的样本，也要有“不能关联”的样本。若只准备成功案例，错误规则也可能看起来表现良好。
当需要量化结果时，必须先有人工确认的预期关系集合。否则，所谓“合并率提高”可能只是关联更多，并不能证明识别更准确。样本不充分时，应记录逐条结果，不给出代表整体准确率的结论。
五、把身份测试延伸到标签与业务使用
统一身份只是中间结果。还应检查同一测试用户的行为是否进入正确的标签、人群和分析范围，关系纠正后，相关结果是否按约定重新处理。
尤其要注意三个边界：一是标签计算采用哪个身份口径；二是群组输出给下游的是统一标识还是业务侧标识；三是外部系统能否理解这个标识，并把结果回传到相同对象。
如果身份正确，但下游无法找到业务账号，运营仍然无法执行；如果历史人群不保留快照，复盘时也可能无法解释当时对谁做了什么。标签与人群的后续验收可参阅实时标签和用户分群怎么评估。
六、选型时如何评估GrowingIO的相关能力
GrowingIO的客户数据平台产品页介绍了OneID与多源数据整合等能力。企业可以以此作为讨论起点，要求结合自己的身份资产表，说明关联规则、冲突处理与实际交付范围。
不要因为产品具备身份统一能力，就默认任何账户体系都能直接接入。数据源质量、现有账号设计和历史迁移条件，需要在方案中单独确认。若采集阶段的事件定义已经混乱，应先处理埋点规范与生命周期管理，再评估身份关联后的分析效果。
完整采购评估还应覆盖部署、标签及成本。可返回CDP平台选型与PoC清单，把OneID测试纳入同一组验收任务。
