OneID是不是把所有ID换成一个新编号？

不应只这样理解。编号是结果表达，真正需要评估的是关系依据、适用范围、历史规则以及业务系统能否使用这些关系。

手机号相同就一定是同一个客户吗？

不能无条件作此判断。应结合业务账户与授权规则确认，尤其考虑变更、共享、历史记录和来源可信程度。本文不提供自动合并的通用判定规则。

不一定。需要同时检查误合并和漏关联。没有预期结果样本时，合并数量只能说明处理规模，不能证明准确性。

不能预设。应分别核对标签、报表、人群快照、已导出数据和已执行动作的处理边界，将不能自动回收或重算的部分写入验收记录。

多端身份统一，应先明确企业要识别的是账号、会员还是具体业务客户，再确定哪些标识能够证明同一身份。OneID的价值在于让跨来源行为能够按一致规则关联，而不是追求更高的合并数量。关联过程需要能解释、纠错，并让标签、人群和分析同步遵守身份规则。

本文提供的是通用评估方法。具体规则应结合业务账户体系、授权范围和产品实现确认，不代表某款CDP默认采用的算法或字段。

一个人可能使用多个设备，一个设备也可能由多个人使用。账号可能由组织统一管理，会员身份则可能只在特定业务范围内有效。如果不先解释这些关系，“去重用户数”就可能使用了不同的分母。

例如，匿名访问与登录后的操作是否可以关联，要看是否存在合法且可靠的关系证据；同一设备上先后登录两个账号，也不能仅凭设备一致，就把两个账号认定为同一个人。

建议先列一张身份资产表：

联系方式不宜不加条件地作为永久唯一身份。应明确其授权用途、变更规则和可访问范围，而不是因为多个来源出现相同值，就直接完成永久合并。

在评估前，先说明哪些证据允许建立关系，哪些只能作为线索，以及证据冲突时由谁处理。规则至少应包含适用数据源、发生时间、可信依据、例外情况和生效范围。

可以把规则问题分成三个层次：

这里的例子用于说明测试边界，不是厂商默认功能。实施时需要由业务账户负责人、数据团队及相关管理角色共同确认。

企业还应分清“客户身份统一”和“业务对象关联”。车辆、门店、商品等可以与客户建立业务关系，但不应因为存在购买或到访记录，就与客户合并成同一种身份。业务对象之间的关系，需要单独定义。

如果一条关系在今天建立，是否影响昨天的报表？如果账号关系被更正，已经导出的人群是否同步更新？这些问题决定了分析结果能否被正确解释。

至少要区分三种时间：业务事件发生时间、数据进入系统的时间，以及身份关系生效或被修正的时间。迟到数据不能只按到达顺序覆盖历史判断，具体行为应按事先约定的规则验证。

在供应商演示中，可以选择一个测试身份追问：它为什么被关联，关系来自哪里，关联前后哪些标签和统计发生变化，哪些下游结果不能自动追回。能回答这些问题，比只展示一个统一编号更有意义。

不要直接拿真实客户资料做开放式测试。可以先设计不含真实身份的合成样本，并在测试前写明预期结果。

测试中既要有“应该关联”的样本，也要有“不能关联”的样本。若只准备成功案例，错误规则也可能看起来表现良好。

当需要量化结果时，必须先有人工确认的预期关系集合。否则，所谓“合并率提高”可能只是关联更多，并不能证明识别更准确。样本不充分时，应记录逐条结果，不给出代表整体准确率的结论。

统一身份只是中间结果。还应检查同一测试用户的行为是否进入正确的标签、人群和分析范围，关系纠正后，相关结果是否按约定重新处理。

尤其要注意三个边界：一是标签计算采用哪个身份口径；二是群组输出给下游的是统一标识还是业务侧标识；三是外部系统能否理解这个标识，并把结果回传到相同对象。

如果身份正确，但下游无法找到业务账号，运营仍然无法执行；如果历史人群不保留快照，复盘时也可能无法解释当时对谁做了什么。标签与人群的后续验收可参阅实时标签和用户分群怎么评估。

GrowingIO的客户数据平台产品页介绍了OneID与多源数据整合等能力。企业可以以此作为讨论起点，要求结合自己的身份资产表，说明关联规则、冲突处理与实际交付范围。

不要因为产品具备身份统一能力，就默认任何账户体系都能直接接入。数据源质量、现有账号设计和历史迁移条件，需要在方案中单独确认。若采集阶段的事件定义已经混乱，应先处理埋点规范与生命周期管理，再评估身份关联后的分析效果。

完整采购评估还应覆盖部署、标签及成本。可返回CDP平台选型与PoC清单，把OneID测试纳入同一组验收任务。