2.1 客户身份合并 - OneID策略

OneID策略核心逻辑为，通过身份匹配找到系统中的目标客户数据，再依据客户身份优先级评估不同身份冲突情况下的客户数据合并方案。

1）身份优先级：可选择指定身份作为高优先级身份，比如将“手机号”作为优先合并依据，则“手机号“作为高优先级身份。其余未作为优先合并依据，则为低优先级身份。

2）身份匹配：按照身份优先级，对新入数据与系统已有数据进行匹配，比如新入客户数据A（手机号a）在系统里已存在该身份，则视为匹配。

3）身份冲突：基于身份匹配前提下，衡量身份冲突情况（例如unionid匹配，但手机号存在冲突）并进行身份处理。

客户身份合并策略概览如下：客户身份合并策略示例：

客户身份合并策略变更后，仅面向增量数据生效，不对历史存量数据进行回溯，故需谨慎评估客户身份合并策略的变更调整。建议在项目实施过程中，由专业的交付工程师评估合理的实施方案和合并策略。

2.2 客户身份合并 - 实时数据链路

      平台提供统一的数据处理服务（ETL），对SDK/API上报的和客户相关的数据源进行实时的OneID识别与匹配，再服务ClickHouse/Mongo相关的数据查询应用。

2.3 客户身份合并 - 典型应用场景

【典型场景一】如企业存在多个前台门户，如官网（PC/H5）、App、多端小程序（微信/抖音/支付宝/百度等）；且多个前台应用统一对接同一个用户认证中心，即用户认证中心会下发唯一的用户ID，用户ID本身关联其他的用户身份，比如用户手机号。则建议将用户认证中心下发的用户ID作为高优先级身份。

【典型场景二】如企业在微信生态下建设多类应用，包括公众号、小程序、网页应用、App（微信登录）、企业微信等；且所有微信生态应用共同绑定企业创建的微信开放平台账号，微信开放平台下的用户UnionID保持唯一。其他平台同理，如抖音、支付宝、百度等平台。则建议将微信开放平台提供的UnionID作为高优先级身份。

【典型场景三】如企业需要支持跨平台应用的用户关联，如微信小程序和支付宝小程序，且不同于案例一和案例二，则建议通过共有的用户ID作为关联依据，比如用户手机号（平台认证）。则建议将用户手机号作为高优先级身份。