用户账号合并后，历史UV和付费人数要重算吗？OneID怎么保留版本？
面试怎么回答
我会保留原始账号与事件键，把统一身份映射作为有证据、有版本的独立关系。账号合并后，当前重述的人数可能减少，但历史发布口径是否回改要单独约定；金额等事件事实不应因合并重复或丢失。映射需要记录来源、有效范围与规则版本，并支持错误合并后的拆分。验收覆盖身份变化前后去重、关系冲突和历史重算范围，不能把OneID当作永久不变的真相。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
昨天报表里有两个付费账号，今天确认它们属于同一位用户，历史付费人数突然从2变成1。金额没有减少，记录也没有丢，只是去重身份变了。这样的变化是否合理，取决于报表承诺展示当时口径，还是按当前身份重新解释历史。
身份合并会改变去重集合但不改变原始事件；历史原貌与当前重述要分开，并保留可回溯的映射版本。
OneID之前，先说清“一个人”的证据
账号是登录身份，设备是访问载体，会员编号是某个业务体系里的身份，它们都不天然等于自然人。
同一人可以有多个账号，多个人也可能共用设备或家庭账号。仅因在同一设备出现，就把两个账号强行合并，会把统计上的关联猜测变成身份事实。
因此统一身份规则应注明证据类型与可信度，区分明确绑定和推断关系。没有足够证据时可以保持分离，不能为了降低重复率无限扩大合并范围。
原始事件不能被统一ID替换掉
事件事实保留原始账号、来源系统和事件标识，统一ID通过映射关系获得，或者在产出中同时保留所用映射版本。
这样将来规则变更或发现误合并时，仍能重新计算，而不必从已经覆盖掉的身份字段中猜回原始归属。
映射至少需要来源身份、统一身份、业务有效时间或适用范围，以及处理版本。什么时候确认合并，与这次合并是否追溯历史，是两项不同约定。
两种历史视角，都可以成立
按当时身份统计，适合复现已发布报表：当时确认有两个账号，就保留当时口径下的去重结果。
按当前统一身份重述历史，适合重新分析用户长期价值和跨账号行为：现在确认同属一人，历史人数可能合并为一人。
两者应该有清晰名称或版本标识，不能用同一个“昨日付费人数”字段在读者不知情时切换。即使重述合理，也应解释变化来自身份规则，不是昨日业务发生变化。
一个典型场景：合并后金额也被放大了
比如映射表为同一账号保留多个历史版本，报表只按账号关联，没有加映射版本或有效范围。一条支付事件命中两条映射，金额反而翻倍。
最初以为账号合并导致多人共付，回看原支付事件只有一条。根因是身份映射的关联基数失控，不是去重人数口径本身。
旧验收只验证统一ID非空，没有检查一条事件在所选视角下应该命中几条映射。修复应选定映射版本与适用时点，再按事件键核对命中次数和金额守恒。
这个例子说明，人数允许因身份重述变化，不代表事件金额也可以随映射复制。不同指标受身份变更影响的方式，需要分别说明。
错误合并的拆分，必须能做到
如果A与B被错误合并到同一人，后续撤销合并，需要知道哪些事件原属A、哪些原属B，以及哪些下游结果使用了错误版本。
只维护一张“当前账号到OneID”覆盖表，又丢掉原始身份，恢复成本会很高。应保留关系变更记录和重算范围，让修订可追踪。
图关系的传递也要谨慎：A与B共享一次设备、B与C共享另一次设备，不代表A、B、C一定是同一人。关系类型不同，不能都当作等价关系无限传递。
发布时把口径变化说清楚
可输出映射版本、统计视角和重算批次，对比合并前后的去重人数、事件总量和金额。人数减少的对象应能追踪到具体关系，而不是只留下一个总差额。
历史聚合如果只保存人数，没有保留去重集合或可重建明细，通常无法简单做减法得到新口径。需要依据原始事件或可信中间状态重算，避免错误抵消。
测试包括明确合并、误合并后拆分、映射重叠、跨来源同号和共享设备。身份数据本身也要遵循既定访问权限，不因分析方便扩大暴露范围。
OneID的价值在于让身份关系可解释、可修订，而不是把所有ID强行变成一个永不变化的数字。