把"看视频发钱"整体下线：激励体系清退要算的四笔账
一、这不是一行配置，是一次带资产清算的迁移
有短剧产品发了一份下线金币功能的公告，计划分阶段把这套”看内容给金币、金币换小钱”的激励收掉。据公开报道，其节奏是先停新用户发放、再在一段时间后全面下线，社区里被问得最多的一句其实公告没直说：我已经攒下的那些怎么办，以及下线之后会不会转成收费。评价它的商业模式不是本文要做的事，那是别的判断；我们只把它当成一份工程材料来读——下线一个和用户资产、用户习惯绑在一起的功能，本质上是一次迁移项目，而不是把某个开关从 on 拨到 off。
差别在哪。纯功能下线的风险止于”少了一个入口”，用户点不到就点不到；一旦这个功能挂着余额、挂着签到连续性、挂着已经承诺过的兑换，下线就同时动了三样东西：一笔用户可见的资产、一条依赖它的埋点口径、一群把它当卖点的下游模块。这三样任何一样没处理干净，都会在客服工单和财报口径里反弹回来。所以我们要先把问题重述成一句可执行的话：清退要算四笔账——存量权益、生效范围与时间窗、依赖方、沟通与留痕。四笔账必须在动手前一次列全，因为它们互相咬合，晚算一笔就返工一片。
二、第一笔账：存量权益要能折算、能审计、能解释
用户已经攒下的余额是最先引爆的一笔。这里要定死三件事。
其一是折算规则。余额是继续按原价兑换、打折回收、还是到期作废，是一个业务决定；但这个决定一旦定下，就必须落成一条可复算的规则，而不是一句”以实际情况为准”。规则要回答：按什么比例折算、折算成什么（现金、代金券、还是别的权益）、有没有最低起兑门槛、门槛以下的那点余额怎么处理。最容易被漏掉的是”未领取部分”——已经产生但用户还没点的奖励，它在账上是一笔负债，下线时必须明确它归入折算还是直接停发，两者记账方式完全不同。
其二是规则变更要留审计。很多团队在迁移中途改过一次折算比例，觉得”对用户更好”就顺手改了。问题在于改一次就要留一次痕：谁改的、改前改后各是多少、对哪一批用户生效。没有这份变更审计，将来任何一次对账差异都说不清是数据错了还是规则变了。
其三是可解释性。折算结果必须能回到用户面前自证：你原来有多少、按什么规则折成多少、哪一笔是哪天产生的。这就要求底层每笔余额变动都有明细，而不只有一个汇总数字。只有汇总数没有明细的系统，在下线这一天会当场暴露它当初就没为”讲清楚”设计过。
三、第二笔账：生效范围与时间窗的三段设计
“分阶段”不是把日期往前推，而是三种人群各走各的时间线，每一段都要有明确的判定条件和对应的灰度开关，否则客户端版本更新有快有慢，同一件事会在一部分用户身上生效、在另一部分身上没生效，现场就乱了。三段一般这么切：
- 新用户停发段：判定条件是”注册或首次触发激励的时刻”落在窗口之后，开关是发放侧对满足该条件的人群直接返回不发放，但界面要同步收掉相关引导，不能继续显示”再看 3 分钟得金币”却什么都不发。
- 存量消化段：已经在账的余额继续可用一段时间，判定条件是”余额大于零”，开关是保留兑换、关闭新增，这一段的产物是一张只减不增的余额表。
- 全量停止段：入口下线、兑换通道关闭，判定条件是时间或批次到达终点，动作是关总开关并切到只读。
三段之间不允许有重叠的空档，也不允许出现”既没停发也没关兑换”的悬空态。每段都要有可回滚的灰度开关和明确的生效标记，方便出问题当天把某一段退回上一状态，而不是全站紧急回滚。
四、第三笔账：依赖方要逐项打钩
真正让下线变成项目的是依赖方清单。激励系统从来不是孤立的，它向上挂着任务和活动，向下挂着结算与发票，横向插进埋点、报表、客服话术和第三方合规申报。下面这张下线依赖检查表可以直接抄进评审文档，每个模块都要填负责人、改动时点和验证方式，空着的那格就是事故点。
| 模块 | 关键字段 | 谁负责 | 何时改 | 改完怎么验证 |
|---|---|---|---|---|
| 任务系统 | 任务类型标记、是否产出金币 | 增长/任务负责人 | 停发段开启前 | 跑一遍任务列表，确认无”产出已停激励”的活任务 |
| 活动配置 | 活动与激励的绑定关系、活动到期时间 | 运营负责人 | 停发段开启前 | 拉出所有引用该激励的活动，逐个解绑或到期 |
| 结算与发票 | 兑换流水、应付款、开票口径 | 财务 | 全量停止段前 | 对账：应付款与余额表差额归零 |
| 埋点与报表 | 事件版本标记、口径说明 | 数据负责人 | 与开关同批上线 | 新旧口径各出一版报表比对差异 |
| 客服话术 | 折算规则、截止说明、FAQ | 客服主管 | 公告发布前 | 抽检答案与后端规则文本一致 |
| 第三方与合规 | 申报口径、合作接口状态 | 法务/合规 | 全量停止段前 | 确认对外申报不再引用已停的激励数据 |
五、第四笔账：沟通与留痕，公告要能查到当时生效的版本
用户不会读你的字段表，只会读公告和客服那两句话。所以沟通这条线有两个硬要求。
公告必须写清规则和截止，而不是只写”我们将优化激励体系”。要落到：存量余额怎么处理、按什么折算、什么时候停止兑换、去哪查自己的明细。含糊的公告会把同一个问题放大成几万条工单。客服必须有统一答案，而这个答案的正确性来自它能引用”用户提问那一刻生效的规则版本”。这就倒逼留痕：每一版折算规则、每一个开关的生效时间都要存档，客服查询工具要能按用户身份和时间点还原”当时你看到的那条规则是什么”。做不到这条，用户投诉”我攒的钱凭空消失”时，你连自证的数据都对不上。
六、两个工程细节，外加 SaaS 场景的照搬
第一，埋点口径变化一定让前后指标不可比。停发之后，”人均激励成本””签到转化”这类指标的分子分母都变了，如果直接把新老数据画在一条曲线上，会被误读成”效果断崖”。做法是在指标定义里打版本标记，把”含激励阶段”和”下线阶段”当成两个口径分别维护，跨阶段对比必须显式声明换算方式。第二，全量停止后仍要保留一段只读期。不是让用户继续兑换，而是让余额明细、兑换记录在一段时间内可查，专门用来接住”我的钱呢”这类咨询，避免投诉来了却查无实据。只读期多久、什么时候彻底清理，要写进数据保留策略并指定负责人。
这套清单对做企业 SaaS 的同行同样适用，甚至更干净：把一个计费项、一个套餐或一个旧接口下线，照四笔账走即可——存量权益对应”已购未用完的额度怎么折算或退”，生效范围对应”老客户保留多久、新客户何时停售”，依赖方对应”计费引擎、发票、报表口径、开发者文档、支持工单”，沟通留痕对应”变更公告与 API 弃用版本号”。我们在洹拓内部交付时把这三条当红线：带权益的下线必配只读期、口径变更必打版本标记、公告里的每句话都要能指回某个后端字段。四笔账算齐了，下线才从一次危机变成一次可交付、可对账的迁移。