周三上午，零售分析师把新看板投到会议室的大屏上。
会员数涨了，订单数也没少，复购率却从上个月开始一路往下走。
运营负责人盯着折线看了半分钟，问：“最近来的顾客，怎么都只买一次？”
分析师没有马上回答。他刚查完一位投诉顾客：订单系统里是手机号 A，小程序里是一个 OpenID，门店会员系统保留着旧手机号 B，客服系统又按设备号建过两条访客记录。三套系统摊开以后，同一个人安安静静地坐在那里，却有 5 个客户 ID。
这位顾客过去半年买了 3 次。
在人看来，她显然是复购顾客；在看板看来，可能只是 5 个互不相识的新人。
复购率变低，不一定是顾客没回来
复购率常见的一种算法，是：
购买两次及以上的客户数 ÷ 购买客户总数
公式很简单，难处藏在“客户”两个字里。
假设一位顾客买了 3 次。三笔订单都挂在同一个稳定身份下，结果是：
- 购买客户数：1；
- 复购客户数：1；
- 这位顾客对应的复购判断：是。
如果三笔订单分别落在 3 个客户 ID 下，结果会变成：
- 购买客户数：3；
- 复购客户数：0；
- 三个 ID 对应的复购判断：全都不是。
分母被撑大，分子又被压小。于是业务没有突然失去一位老顾客，数据却凭空多出了三个新客。
这也是身份碎片最麻烦的地方。它不只让客户总数偏高，还会一起影响复购率、新老客占比、获客成本、会员贡献、跨渠道转化和生命周期价值。团队若只盯着复购率公式，很容易在一个没有变化的购买行为上，解释出一段很有气势的消费趋势。
三套系统里的“人”，其实是三种业务对象
订单系统关心的是谁完成了交易。
会员系统关心的是谁注册、领券、积分和升级。
客服系统关心的是谁发起了咨询，以及下一次能不能接着服务。
它们都在记录顾客，却未必用同一种方式认识顾客。
订单可能优先保存下单手机号和收货信息；会员系统把会员号当主键；小程序依赖平台内标识；客服在未登录时只能看到设备或会话；门店导入的老会员还可能只有一张卡号。
所以，把三套表 UNION ALL 到一起并不叫客户统一。那只是把不同系统对“人”的认识，搬进了同一个仓库。
真正需要解决的问题叫实体解析，也就是在没有共同主键时，判断多条记录是否指向同一个真实对象。AWS Entity Resolution 的规则匹配会为匹配记录返回 Match ID 和命中的规则；Google Cloud 对实体解析的介绍也把它定义为：在没有公共标识时匹配不同记录。
这些工具能帮助计算，却不会替团队决定“什么证据足以说明是同一个人”。
手机号不是人，设备号也不是人
发现身份碎片以后，最诱人的动作是按手机号合并。
这比什么都不做快，也比什么都不做危险。
手机号会更换，会被重新分配；一家人可能共用一个收货电话；企业客户可能统一留前台号码；门店员工也可能替顾客下单。设备号同样会遇到多人共用、清缓存、换手机和隐私设置变化。
反过来，“手机号不同”也不能直接判定为两个人。有人下单留工作手机，会员注册用私人号码，客服咨询又从另一台设备发起。系统看到三条路，人只走了一趟。
因此，身份判断不能只看一个字段相不相等，而要看证据组合：
- 强证据：同一实名会员、同一经过验证的账号关系；
- 中等证据：手机号与姓名、收货地址等组合长期一致；
- 弱证据：相同设备、相同网络、相似地址或相似姓名。
强证据可以支持自动归并；弱证据更适合提示“可能相关”，等待更多记录或人工复核。不要因为算法能给出一个答案，就假装这个答案没有不确定性。
这里还有另一面：不能为了把复购率算得好看，把一家人、共享设备用户或接手旧手机号的人合成一个顾客。漏合会让人数偏多，错合则会把几个人的消费、偏好甚至敏感信息塞进同一份画像。
一个错误的统一身份，往往比五个碎片身份更难发现。
OneID 不是原始字段，而是一项可以追溯的判断
不少项目会新建一列 one_id，然后宣布客户统一完成。
可一列 ID 本身说明不了什么。真正重要的是：它由哪些原始记录组成，靠哪条规则合并，证据强度如何，什么时候生成，后来有没有拆分或重算。
我更愿意把 OneID 看成一张会变化的关系图。
图的一端是订单、会员、客服、活动等来源记录；另一端是暂时归到一起的客户实体。中间每条连接都要带理由：同一会员号、验证手机号一致、人工确认，或只是设备上的弱关联。
这样做有两个好处。
第一，业务追问“为什么这两条算一个人”时，分析师能顺着连接找到证据，而不是只说“模型判的”。
第二，发现错并以后可以拆。若 OneID 只是覆盖式写入的一列结果，错误常常会一路传播到标签、推荐、人群包和报表里，想回去找原始关系已经很困难。
先别重算看板，做三次小检查
身份解析项目很容易一上来就讨论平台、算法和客户 360。
我建议先做三次小检查。它们不够把 OneID 系统做完，却足以判断复购率是不是被身份碎片拖偏了。
第一，冻结当前口径，留下可比较的旧版本
先记录今天的客户去重规则、复购率分子分母、时间窗口和结果快照。
不要在同一张看板里静默替换客户 ID。否则新口径上线以后，历史曲线会整体变化，团队只看到“数字好了”，却说不清是顾客行为变了，还是身份规则变了。
旧口径不是永远保留，而是给新口径一面镜子。
第二，抽 50 个身份，画出证据关系
可以从三类样本开始：
- 订单多、客户 ID 也多的高频购买者；
- 同一手机号对应多个会员号的记录；
- 被判定为新客、却有历史地址或设备线索的人。
数字 50 不是统计标准，只是一个便于人工看完的起点。把每个来源 ID、关键标识、时间和匹配理由画在一张表或关系图上，看看问题主要来自换手机号、未登录下单、门店导入，还是系统重复建档。
样本不必完美，却要覆盖最常见的碎片来源。
第三，新旧身份双跑一个完整业务周期
新 OneID 不要直接接管正式复购率。
先同时计算：
- 原客户 ID 口径；
- 新身份规则口径；
- 两者在客户数、复购人数和复购率上的差异；
- 差异最大的渠道、门店和版本。
然后对差异最大的样本做人工核对。若新口径让客户数下降、复购率上升，也别急着宣布成功。先确认下降的是重复身份，不是被错合的一家人或共享设备用户。
双跑的目的不是证明新规则更漂亮，而是解释每一块主要差异从哪里来。
复购率看板要多写一句身份说明
一张可信的复购率看板，不只要写购买次数和时间窗口。
还应说明客户如何识别。例如：
客户按已验证会员账号优先去重；未登录订单使用手机号与订单账号关系匹配；仅设备相同不自动合并。身份规则版本为
customer_identity_v2，2026 年 7 月 1 日起生效，历史数据已按同一版本回算。
这句话不够性感，却能回答几个重要问题：
- 客户数为什么和会员系统不一样；
- 新老客为何在某天发生跳变；
- 复购率变化是行为变化还是规则变化；
- 下次修改身份规则时，哪些报表会受到影响。
如果身份规则仍在验证，也应该直说：“跨渠道未登录用户尚未完全归并，复购率可能偏低。”承认已知边界，比给一条过分精确的曲线更有用。
明天可以先做的 3 个动作
第一，找出一位“买了三次却算成三个新客”的顾客。
不用先做全量工程。把他的订单、会员、客服和设备记录按时间排开，确认身份到底在哪一步断了。
第二，把客户 ID 数和可解释的人数分开。
在看板旁增加几个诊断数：每位客户平均对应多少来源 ID、一个验证手机号对应多少客户 ID、多少订单只有弱身份。它们能提醒团队，客户数是否正在被系统建档方式推高。
第三，给身份合并留一条撤销路径。
每次合并都保存来源记录、命中规则和版本。发现共享手机号或错误关联时，能够拆开并重算，而不是在结果表上手工改一个 ID。
三件事做完，复购率未必马上变高。
但团队至少知道，它现在低在顾客没有回来，还是低在系统没有认出回来的人。
看板里的“新客”，有时只是一个老朋友换了件外套
数据分析最容易令人安心的部分，是公式。
分子、分母、窗口都写清以后，表格显得很有秩序。可如果“一个人”在三套系统里没有同一个名字，再正确的除法也会得到一个整齐的误会。
所以复购率下降时，别急着给运营写一份用户忠诚度分析。
先找一位具体顾客，看看他在订单、会员和客服系统里分别叫什么。他可能没有离开，只是换了手机号、换了入口，又被系统当成第一次见面。
人还是那个人。
数据得重新学会认出他。
我叫石头，在数据行业里摸爬滚打了十几年，见过不少趋势最后追到源头，只是系统把同一个人叫了好几个名字。这里写的，就是这些教训——我觉得值得说出来的那部分。
来源：AWS Entity Resolution：What is AWS Entity Resolution? · AWS Entity Resolution：Creating a rule-based matching workflow · Google Cloud：Introduction to the BigQuery entity resolution framework
