产品已迭代或停更
88VIP 会员产品
这是什么
把会员权益从一场场活动，做成后台能改规则、合作方能按标准接入的分发。
当时卡在哪
权益每次都像再办一场活动：规则写进需求，活动一结束链路就散。外部供给也一对一对接，池子扩不起来。运营被卡住的不是创意，是分发没法配置。
做了什么
- 分析手淘链路领取与核销数据，优化个性化分发与多权益池 AB 规则；搭建可配置后台。
- 联动集团内外资源做权益置换；定义接入标准与规则，提升合作效率。
业务链路（脱敏）
- 1
权益供给
内部置换或外部接入，先过标准与规则，再进入权益池。
- 2
分发配置
运营在后台配置人群、池与 AB 规则，而不是每次活动改一遍代码。
- 3
领取与核销
用户端走领取/核销；数据回写分发效果，再调规则。
结果
运营能改规则而不改代码；外部权益能按标准进池，而不是一对一对接。
- 形成可配置的权益分发体系与可扩展的权益供给开放平台。
和研发怎么对齐
会员权益后台同样按域说话：访问层是运营配置与用户领取，应用层是规则/池/单据，数据层要能对账核销，集成层对接会员身份与合作方供给，而不是重写支付。
当时的判断： 别把权益做成活动
附录
负责权益分发策略与后台、用户端体验，以及权益开放平台的标准与合作链路。
我负责的边界
- 分发策略与可配置后台：多权益池、个性化/AB 规则、领取与核销在用户端和运营端的闭环。
- 权益开放平台：外部权益接入标准、合作规则与置换链路，让供给可扩展。
明确不负责
- 会员身份与支付账务本身（分发后台消费会员身份，不替代账户/支付系统）。
协作方式
- 运营与行业：对齐权益池规则和活动节奏，把一次性投放收成可配置策略。
- 合作方：用接入标准降低一对一对接；研发实现规则引擎与后台，产品给边界与验收。
分层怎么说（不写选型）
- 访问层：管理后台或门户，按角色做权限与菜单，而不是一套界面打天下。
- 应用层：按业务域拆模块（主数据、流程、规则、单据），先定域边界再谈服务怎么拆。
- 数据层：主数据与业务单据分开，加上审计与日志，保证可追溯、可对账。
- 集成层：对接已有 ERP / MES / 生产或交易系统，而不是重写现场控制或核心账务。
独立部署时怎么估资源
分发后台与开放接入若独立部署，按运营配置并发、领取峰值和核销对账量估容量；核数内存由研发按压测定。
- 无状态应用：按管理端人数与峰值并发估实例，可水平扩；先问「同时在用的人」而不是先问机器型号。
- 数据库：按单据量、查询是否拖垮写入来决定要不要读写分离或把报表拆出去。
- 文件与日志：附件、导出、审计不宜和业务库绑死，独立存储更利于容量与合规。
- 一个可独立部署的中等管理模块，通常是「应用实例 + 库 + 必要中间件」；主路径模块和边缘模块的容量差一档。具体核数内存由研发按压测定，产品给出可用性、权限、审计和量级。