一个顾客被系统算成三个人，会员身份归一怎么做？

会员分析的所有结论——复购率、消费频次、RFM 分层、沉睡名单——都建立在同一个地基上：系统得认得"这是同一个人"。这个地基在餐饮行业的普遍状态是：不认得。

老王是怎么变成三个人的

一个真实又典型的场景：老王来吃饭，第一次用手机号注册了会员；第二次图方便微信扫码点单；第三次用支付宝付款。三条流水，三个身份标识——在没做身份归一的系统里，他是三个"各来过一次的新客"。

后果是连锁的：

指标	不归一时系统看到的	归一后的真实
会员数	3 个"新客"	1 个老客
复购率	三个人都没复购，被稀释	一个来了三次的忠实顾客
消费金额	拆成三份，谁也不高	集中在一个高价值顾客身上
RFM 分层	掉进"低频低价值"层	本该进重点维护名单

把这个失真放大到全量会员：你以为你有 1 万个会员，可能其实只有 7 千个真人。剩下的 3 千个"幽灵会员"，是同一个人在不同渠道留下的影子。这个比例不是吓唬人——华北某火锅连锁、以及另一家餐饮集团（均已脱敏）的会员体系，都被这个问题实打实坑过。

归一不是"手机号相同就是同一个人"

很多团队以为身份归一就是"按手机号去重"。这个做法会踩三类坑：

第一，优先级坑。同一笔消费，可能同时挂着会员标识、微信标识、支付宝标识。以谁为准？必须有固定优先级，我们的标准是：会员卡号 > 微信 > 支付宝 > 云闪付。会员卡号是顾客主动注册的身份，信度最高；支付渠道标识只是付款动作留下的痕迹。优先级不定，同一批数据归一两次能出两个人数。

第二，空值坑。"这个字段没有值"，在数据里有好几种写法：真空（NULL）、空字符串、字面量"null"四个字母——不同系统导出还会冒出别的形态。少判一种，一批顾客的身份字段就被当成"有效值"参与匹配，人就漏统、错统。这不是理论——在真实客户项目里，仅一种漏判的写法就出现过上万行。

第三，边界坑。一人多号（工作号、家庭号）、一号多人（一家老小共用一个手机号注册），都不是"手机号相同=同一人"能处理的。身份匹配要配置信度：哪些匹配是确定同一人，哪些只是疑似，要分层处理，不能一刀切。

正确的做法：身份桥，而不是改原始数据

成熟的治理做法不是在流水表上改来改去，而是建一张身份桥表：每个真实顾客一个统一标识，把他所有渠道的身份（会员卡号、微信、支付宝、云闪付）都挂到这个统一标识下。流水表不动，分析时走桥表归并。

这样做有三个好处：一是可追溯，每个数字能回溯到原始流水；二是可纠错，发现匹配错了改桥表就行，不污染原始数据；三是可扩展，接了新渠道（比如新的外卖平台），往桥表里加一行映射即可。

身份归一做完，才轮得到复购率、RFM、沉睡名单。它是所有会员分析的地基——地基不牢，上面盖的全是歪的。

给老板的自查清单

拿到任何一份会员分析报告，先问五个问题：

1. 同一个顾客在会员卡/微信/支付宝里的身份，合并了吗？
2. 合并的优先级是什么，写出来了吗？
3. 身份字段的空值，各种写法（NULL/空串/'null'……）都判全了吗？
4. 一人多号、一号多人的边界情况，怎么处理的？
5. 报告里的"会员人数"，是身份个数还是真人数？

五个问题答不上来，报告里的复购率、分层、名单都先别信。先归一，再分析——顺序反了，结论全是错的。