同一会员在不同小程序平台中的访客身份
Membership Operations
把分散的平台访客,变成可持续经营的会员关系
多平台会员运营体系:从身份扩展到增长与风控闭环。
身份不是终点,它让每次触达、交易与处置回到同一条会员主线。
Why Membership Matters
CRM 管理的不是一次访问,而是一段持续累积的会员关系
只有把同一会员在不同时间、平台和业务中的行为持续连接起来,运营与服务才能拥有上下文。
The Business Context
业务扩张,把同一会员拆成多个平台访客
平台从微信、支付宝扩展到内容平台、交易平台和外部数据;同一顾客会以多个平台访客身份进入系统,身份、触达、交易和来源随之断开。
Inherited Foundation
继承身份底座,在清楚的贡献边界上继续扩展
原始微信 / 支付宝模型由其他产品经理规划;我的工作从理解、吸收并扩展这套关系开始。
本人主导范围多平台接入、券主 MCU、会员触达、渠道归因和异常治理的业务建模、方案设计与上线推动;研发团队负责工程实现。
汇聚多个平台 XCU,并维护它们与 MCU 的当前归属
承载会员卡、积分、卡券、消费和等级资产
继承的不是一组缩写,而是一条需要继续尊重的会员资产边界。
Decision 02 · Business Continuity
上游没有手机号时,先让交易链路继续运行
部分外部平台订单只返回平台会员标识。系统先查找已有身份;无法找到时,再用券主 MCU 兜底。
XCU / ECU 已经找到客户主体下的会员。
使用平台会员标识,让订单、投放记录和核销继续运行。
Reusable Foundation
先沉淀会员运营基建,上层业务才能玩得很溜
这些公共服务围绕同一会员关系建设一次,再由不同营销、交易与服务模块复用。
按会员属性与业务行为定义目标范围。
统一模板、计划、执行记录和回调,避免重复建设。
把目标小程序页面转换为可触达、可携带参数的入口。
统一管理来源、渠道明细与跨模块的归因口径。
让线下点位也能绑定渠道与渠道明细。
这五项会员运营基建,决定后续模块能否低成本地找到人、触达人与记录来源。
Capability Collaboration
上层模块按需调用底层基建,组合出更多会员运营玩法
上层模块复用这些基建,找人、触达、承接与归因不再重复建设,而是从共享能力中选择需要的组合。
上层营销与业务模块
查询与圈选目标顾客
按行为触发个性化运营
邀请参与并记录来源
定向投放与活动承接
唤醒与积分运营
关联交易来源与后续触达
底层会员运营基建
基建提供的不是一条固定流程,而是一组能被不同业务自由组合的会员运营能力。
Attribution Architecture
来源写进业务数据,最上层分析才能看清渠道价值
推广渠道与线下二维码不是最终报表,而是让会员、卡券、订单和问卷数据拥有统一来源的底层能力。
最上层数据分析
中层携带来源的业务数据
下单 · 核销
记录交易对应的渠道来源访问 · 提交
记录邀请入口与渠道明细访问 · 开卡
记录会员首次与后续来源领券 · 核销
记录活动与转化来源底层来源基础设施
区分业务部、活动、门店与线上入口。
停车场、电梯、门店和具体点位进入同一归因口径。
底层来源进入中层数据,给最上层的数据分析打下基础;完整链路不等于增量因果。
Evidence of Use
用采用规模与开卡后触达覆盖,证明体系真实运行
核心能力均已正式上线
年度积分与销售数据只说明体系承载规模,不作为营销计划的增量结果。
Real-world Adversaries
增长系统进入真实业务后,身份硬规则开始被绕过
在本店制造消费,获取积分和会员等级。
用员工身份规则限制最直接的刷单。
行为转向其他门店,静态身份标签被绕过。
问题必须从“封禁某类人”升级为异常行为治理。
规则写得更多,不代表系统更懂正在变化的风险。
The Product Decision
把封禁升级为可发现、可核查、可纠错、可处置的治理闭环
按全部门店、分类、楼层、标签、业态或指定门店配置范围,识别单笔、单店累计和跨店累计异常。
系统每日计算异常会员及触发订单,记录异常原因并通知运营人员核查。
正常高频消费者进入白名单,确认风险的会员进入禁用。
禁止会员升级和积分消耗;仍允许获取积分、自然降级和领取免费券。
身份不是终点,它让每次触达、响应、交易和处置回到同一条会员业务主线。
返回项目经历