一、项目背景

某美妆集合店在同一商场里开出多个品牌专柜，涵盖护肤、彩妆、香氛三个不同定位的子品牌，每个品牌早年都各自搭了一套会员系统。顾客今天在护肤专柜办了张充值卡，明天在彩妆专柜领了张满减券，回头想用的时候发现积分不互通、等级不通用、券也不能跨柜用，体验割裂得很明显。运营侧更苦，三个品牌的会员数据躺在三套互不相通的库里，做一场联动大促只能各做各的页面、各发各的券，连带销售和复购都起不来。我们进场做调研时翻了下后台，三个系统的会员总量看着都不小，但去重之后真正能认准的人只占七成出头，剩下三成是各种重复、错号、换号留下的脏账户。

接手时最急的一件事，是把这些散落的会员资产先并到一张统一的身份底下，否则后面任何运营动作都是空打。老板当时给的硬指标也很实在：先把人认准，再谈权益怎么流动，别一上来就搞大合并。我们当时也确实有点心急，第一版方案就想全自动对齐，后来被脏数据狠狠上了一课，这个后面再说。

二、落地场景

我们采用的 XpShop 新普MALL 把多品牌会员收敛到一个统一会员中心，身份归一之后用同一套等级和积分体系承接所有品牌。落地时主要有几类场景。第一类是新客进任意专柜消费，系统自动归到统一会员档案，导购在企业微信里立刻能看到这个人在其他品牌的消费偏好。第二类是老客历史积分按预设汇率折算进统一账户，折算过程留痕，顾客随时能查自己老积分怎么变的。第三类是跨品牌发券，一张券可在参与互通的品牌间通用核销，比如护肤满赠的券能去彩妆抵现。第四类是统一触达，运营做一次活动不再分别推三个品牌的后台，而是按统一标签圈人。

这里最关键的不是功能多，而是把"人"认准，再谈权益怎么流动。导购端我们特意做了轻改造，不希望他们为了查一个会员去切三套后台，那才是最消耗一线积极性的事。

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

第一个坎是身份归一。三套老系统没有统一手机号主键，重名、换号、一人多卡的情况不少，甚至有人用座机号注册过。我们先用手机号加微信 openid 做主键对齐，匹配的自动合并；冲突的走人工复核队列，先把脏数据圈出来再合并，没敢一次性硬并。这一步我们吃过教训，第一版想全自动合并，结果重复账户刷出来一大把，合并完才发现有人被并到了陌生人的积分上，后来改成保守模式，宁可多进复核队列也不错并。

第二个坎是积分汇率。各品牌历史积分价值不一样，护肤客单价高、彩妆频次高，直接一比一合并会闹矛盾，顾客会觉得自己的积分被贬值。我们设了可配置的折算规则，老积分进"历史池"按品牌原规则消耗，新消费进统一池，两个池并存过渡，过渡期给了半年。第三个坎是权益冲突，比如同一张券在护肤能抵现、在彩妆只能换小样，我们在券模板上挂了适用品牌白名单，核销时按白名单校验，避免超范围使用。

四、效果数据

上线约两个月，统一会员身份覆盖到三个品牌约九成存量会员，去重后的可运营会员规模比改造前清晰了很多。跨品牌消费占比从改造前的不到一成升到约两成，连带销售那块提升最明显。会员复购率提升约十五个百分点，跨品牌权益核销率稳定在四成上下。导购侧反馈最实在，连带推荐的成功率比单品牌时代高了近一倍，因为他们终于能看到全貌。文中数据为项目复盘口径，已做脱敏，不对应任何单一客户真实经营数据。

五、可复用经验总结

这个项目给我最大的提醒是，会员资产统一别一上来就谈互通，先把人认准比什么都重要，我们最早就是吃了硬并脏数据的亏，合并完才看见重复账户一堆。积分汇率那种历史包袱，留个过渡池比强行归一更稳，运营和顾客都好接受，硬切只会引发投诉。权益互通的边界一定写在券模板上，别指望核销端临时判断，那是最容易出漏子的地方。说到底，会员系统难的是数据治理，不是功能堆叠，治理没做好，上面盖什么都是歪的。

回过头看，这个项目最值的经验其实是先把数据治理跑通再上功能，别被业务方一句先上线再说带节奏。我们后来把同一套思路用到另一个连锁客户，也是先花两周核对三套老系统的脏账户，再谈互通，整个过程顺得多。还有一点容易被忽略，跨品牌权益互通之后，运营要提前管住顾客预期，比如某张券其实只在单品牌有效，却因为互通让人误以为全品牌通用，这类客诉在新功能上线头一个月最集中。我们后来在券详情页强制展示适用品牌，并在顾客领取时弹一次说明，客诉立刻下来了。说到底，会员系统打通只是开始，预期管理才是长尾，技术能解决归一，治不了误会，这两件事得一起做。

案例片段（已脱敏）： 统一会员归一处的一段主键对齐配置：identity_keys:  - phone  - wechat_openid conflict_queue: manual_review merge_mode: conservative   # 冲突不自动合并积分折算规则节选：legacy_pool:  brand_a_rate: 1.0  brand_b_rate: 0.8  brand_c_rate: 0.6 unified_pool: new_consumption_only transition_days: 180一次合并后的对账日志摘要：[merge] scanned=128400, auto_merged=110200, conflict=18200, manual_queue=18200 [merge] dup_accounts_found=3100, resolved=3050, pending=50 [merge] wrong_merge_blocked=210, alerted=ops