一、项目背景

某集团业务横跨零售、供应链和金融几条线，旗下有六七个业务系统各自维护客户信息：CRM、ERP、会员系统、客服坐席系统、订单中心、营销自动化平台，彼此早年没有打通，各自建号。我们进场盘点的第一周就发现，同一个客户在不同系统里有好几个 ID，有的因为早期各系统各自建号，有的因为门店和线上没打通，有的因为集团并购把被收购公司的客户库直接并入却没做去重。最离谱的一个法人主体，在会员、订单、客服三个库里分别是三个不同的档案，手机号还都不一致。集团名下累计散落着数千万条客户记录，其中到底有多少是重复的，没人说得清。结果就是营销部门群发优惠券，同一个老板收到三份；财务对账时订单归属到哪个客户全凭人工猜；会员权益更是乱，同一个人在 A 店是金卡、在 B 店查无此人。集团想做统一的客户视图，但没人说得清到底还有几个真客户没被认出来，这个项目因此在内部拖了快一年没人敢接。

二、落地场景

我们落地的是一个独立部署的客户主数据（MDM）中心，它不替代任何业务系统，只做一件事，就是认人和存准。会员注册、订单下单、客服接待这些动作，在数据落库前先调 MDM 做身份匹配，拿到全局唯一的主数据 ID，再带着这个 ID 回业务系统。这样无论客户从哪个渠道来，后端看到的都是同一个人。改资料也只改一处，中心负责把变更通过消息队列广播给所有订阅方，订阅方在自己的库里留一份轻量镜像。我们还接了客服工作台，坐席一输入手机号，立马能看到这个客户在集团内所有的历史订单、会员等级、当前在途工单，不用再问您之前在我们这买过吗。营销系统发券前也会先问 MDM 这个人是谁，避免对同一个人重复触达。整个链路对业务系统透明，调用方只多了一个轻量接口，改造量可控。

三、关键技术挑战与解决思路

难点在于判定同一性。同名不同人、同人不同名、一个人多个手机号，全得处理。我们分了三层：第一层用证件号、统一社会信用代码、手机号做确定性匹配，命中就直接归并；第二层对匹配不上的，做姓名加地址的模糊相似度计算，高于阈值先挂起到人工复核队列，绝不自动合并；第三层用规则引擎处理同一法人旗下多家子公司这种要保留多个主档但建立关联关系的情况。所有匹配规则的权重都做成配置项，业务方自己能在管控台调，不用改代码。我们还给合并动作加了可逆机制，任何自动归并都能一键回滚，避免脏数据污染主档。为了不让实时调用拖慢业务，匹配服务做成异步批处理加实时查询两种模式，注册下单走实时，历史清洗走夜间批处理，互不影响。

四、效果数据

项目上线运行约七个月，集团侧重复客户档案从约十二万条压到不足两万条，其中自动归并占七成、人工确认占三成。营销短信的重复触达率从 18% 降到 3% 以内，每月省下约三十万条无效短信。客服转人工后重复询问客户基础信息的比例下降明显，单次会话平均节省约四十秒，按日均两万通会话算，相当于每天多出约四个坐席的人力。订单归属错误引发的退单申诉，月度从高峰时一百二十多单降到个位数。会员跨店权益打通后，复购率有可见提升，集团第一次拿到了口径一致的客户总量，这件事以前谁都不敢拍板。

五、可复用经验总结

做主数据归一，技术反而是最轻松的部分，真正的坎是业务口径。我们最初想直接上算法跑全量匹配，结果业务方连什么算同一个客户都争论了两周没结论。后来改成先拉着业务把匹配规则一条条定死、写进配置，算法只管执行，进度反而快了。模糊匹配千万留人工复核这道闸，我们踩过一次把两家独立法人并成一家、月底对账对出大乱子的坑，那次之后所有自动合并都改成 T+1 二次校验才落主档。判断逻辑后来也用到了供应商主数据，但每个域的唯一性定义都得重新和业务谈，别指望一套规则吃遍天。这活儿最费的是前期和业务对齐，技术反而是后面顺的，这个顺序别搞反。

案例片段（已脱敏）： 一次夜间批处理日志出现合并告警，规则引擎将深圳市某科技有限公司与深圳某科技有限责任公司判为同一主体并自动归并。回查发现两者统一社会信用代码后九位一致但登记机关前缀不同，实为两家独立法人。我们随即将登记机关前缀差异加入排除白名单，并给自动合并加了一条 T+1 二次校验任务，未通过人工确认的合并结果不写主档、只进待定池。该规则上线后再未发生跨法人误并，待定池月均处理量从八千条降到两千条，人工复核压力明显下降。