流失分诊：四种流失与处理顺序

流失不是一群人，是四种人；顺序错了，努力多半白费。

一、四十个人一起消失的那个月

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

周岚一个人做「清单工坊」，一个帮小团队生成报价单的工具，月付 29 元。月初后台显示付费用户 312 个，月底只剩 272 个，一个月少了 40 个。她盯着这个数字看了很久，得出的结论是「用户不爱这个产品了」。

40 除以 312 是 12.8%。对一个月付产品来说，这个数字不算离谱；但她是第一次遇到，感觉像整栋楼塌了。情绪一起来，动作就会变形。

那几天她正好在读留存曲线的文章，知道要看同队列、要看平台段，可眼前这个数字既不是曲线也不是队列，就是一条断崖。焦虑之下，她做了一个最顺手的动作：写点什么发给用户。

那天晚上她写了两千字的信，标题叫「我们很想你」，把这 40 个人全部勾上群发。信里回顾了产品这一年做的七个功能，末尾放了一个九折续费的按钮。三天后：退订 12 个，一个用户回信说「我上个月就没在用了」，真正回来付款的只有 1 个。

她把这 40 条记录逐条翻完，发现根本不是一件事。12 个自己点了取消；9 个扣款失败，卡过期或被银行拒付；11 个连续三个月没有登录，被系统按沉默停掉；还有 8 个从注册那天起就没生成过一张报价单。

最刺眼的是那 9 个付款失败的人。账号状态写着「已过期」，但在过期前一周，其中 6 个人还登录过，有一个人的草稿里躺着一份没做完的报价单。产品并没有被抛弃，是扣款那一步掉了链子。

流失不是一种事件，是四种原因叠在同一个数字里；不分诊就发召回，等于给骨折的人贴创可贴。

二、四种流失，四种完全不同的信号

分类的依据不是「用户想不想留」，而是「离开这件事，用户到底决策过没有」。付款失败和从未激活的用户，决策从未发生，他们是被流程挤出去的；主动取消的人已经付过钱、用过、比较过，决策已经完成；沉默失效介于两者之间，多数时候没有决策，只是习惯断了。

举个具体的判法：「从未激活」不是「注册了没付钱」，而是「注册后从未完成那个核心动作」。在清单工坊里，核心动作是生成并保存一份报价单；只登录进来看看模板的人，仍然算从未激活。

四种类型的操作难度差别很大。主动取消的人要「改主意」，成本最高；付款失败的人只需要「换一张卡」，成本最低。把这两类放在同一封邮件里，等于用最高成本的动作去覆盖最低成本的机会。

优先级那一列衡量的不是重要性，是时间窗口的宽度：付款失败的窗口只有几天，宽限期一过，卡还是那张卡，人却已经习惯不用了；主动取消没有窗口，只有事后复盘的价值。

识别信号要能从后台直接取出来，否则分诊会在第一天失败。下面这几条是够用的最小集合：

• 取消时间与取消前 7 天的核心动作次数
• 最近一次扣款状态、失败代码、失败次数
• 最近一次核心动作距今天数，以及该用户的核心动作间隔中位数
• 注册到第一次核心动作之间隔了多久，是否为零
• 当前套餐与到期日，是否处于宽限期

注意「沉默失效」的阈值要按产品自己的使用周期算，不能统一写 30 天。月结型工具一个月才用一次，30 天正好把一个正常用户判成流失。

还有一层容易被忽略：同一用户可能同时满足两类。一个扣款失败两周后进入沉默失效的人，应该算付款失败，因为那是第一因。分诊规则要写「先命中先归类」，否则四类的数量会随着统计顺序漂移。

分类也不是做一次就固定的。产品改了计费方式、加了免费版、换了支付服务商，四类的比例都会变。每月打一次标，比设计一套完美的分类规则更有用。

三、处理顺序：先救本可以留下的

优先级不按人数排，按「决策是否还来得及改变」排。9 个付款失败的人里可能 6 个根本不想走，只是卡过期了；8 个从未激活的人里可能一半是注册后没找到入口。这 17 个人的流失是流程造成的，改流程就能救回来。

主动取消的 12 个人已经完成了比较，此刻发什么都像在提醒他们「你走对了」。他们值得一次真诚的原因收集，但不值得一套挽留话术。原因选项四个就够：太贵、用不上、换了工具、项目结束。

沉默失效的 11 个人要先分组：是产品没做好导致用不起来，还是本来就只有一次性需求，比如一年只报一次税。前者可以低频召回，后者不该打扰。

顺序也不是绝对的。如果某个月一次渠道活动带来 200 个注册、激活率只有 8%，那当月的第一优先级应该是从未激活，而不是付款失败——按「可挽回人数」排，不按固定表排。

处理的先后还受一件现实约束：一个人一周能做的改动有限。先做付款失败，因为它的实现是确定的——重试、通知、宽限期，做完就是做完；激活引导要靠文案和界面反复试，见效慢，但不做就永远没有数据。

把顺序写成一周的计划：周一做重试与通知，周二做降级，周三处理从未激活的引导，周四给主动取消的人发原因问卷，周五只看数据不改东西。

3.1 付款失败的最小实现

第 1 天：自动重试一次；失败就发一封只有一句话的邮件，附一个直达「更新付款方式」的链接，同时在应用内挂一条横幅。

第 3 天：第二次重试；通知里写清楚还有几天宽限期，不要写「您的账号即将被停用」这种恐吓句。

第 7 天：第三次重试；仍然失败则转入降级状态——账号能登录、能导出全部数据，但不能新建。

宽限期结束：降级到免费版，保留数据，不发最后一封「告别信」。数据还在，人就有可能回来；数据删了，就只剩一个差评。

这四个动作里只有「重试」需要写代码，通知、宽限期、降级都是配置和文案。一个人两天能做完；而写一封群发信花了一个晚上，换来 12 个退订。

如果只能做一件事，做重试。它不需要判断用户想不想留，只需要把「本来能扣到的钱」扣到。降级则决定了失败之后关系还在不在：能导出数据的账号，还有被召回的可能。

四、把四十个人算一遍

用同一份名单，按「先命中先归类」打标，再给每一类一个保守的挽回率，就能算出这 40 个人里到底有几个是「本可以留下」的。

总流失 40 = 主动取消 12 + 付款失败 9 + 沉默失效 11 + 从未激活 8
付费基数 312，流失率 = 40 / 312 ≈ 12.8%

按可挽回性排序（挽回率为教学假设）：
  付款失败 9 × 40%  ≈ 3.6 → 4 人
  从未激活 8 × 25%  = 2.0 → 2 人
  沉默失效 11 × 10% ≈ 1.1 → 1 人
  主动取消 12 × 5%  ≈ 0.6 → 1 人
可挽回合计 ≈ 8 人，占流失的 20%，占付费基数的 2.6%

把两种做法放进同一张表，差别比看单个比例更清楚。

净变化是回访减去退订。群发是负数，不是因为文案差，而是因为它同时叫醒了本来已经安静离开的人；分诊触达的绝对人数一样，但每一类收到的动作不同，退订只来自两封不必要的触达。

这张表还藏着一个成本项：群发的 40 封里有 30 封是浪费的，因为它们发给了已经做了决定的人。分诊的成本是判定的时间，大约每条记录一分钟，40 条不到一小时。

算式里的挽回率是演示值，不能拿去当基准；但结构是可复用的——换成自己的数字，先算「每类各有多少人」，再乘「这类人历史上被救回来的比例」。如果某一类从来没有被单独统计过，就先跑一个月，别急着下结论。

五、行动清单与复算验收

• 把上个月的流失名单逐条打上四类标签，允许「无法归类」，但占比不超过 5%
• 付款失败的重试节奏写死为第 1、3、7 天，三次都失败后走降级而不是停用
• 给从未激活的人单独一条引导路径，不放进召回名单
• 主动取消只收一句原因，不做挽留话术
• 下个月复盘时，四类各自的挽回率分开算，不合并成一个「召回成功率」
• 把四类数量做成一张月度小表，连续记三个月再判断趋势

验收标准：四类能分开计数，付款失败的挽回率能单独算出来，群发召回不再是默认动作。

清单不用一次做完。先做前两条，下个月就能拿到第一份分诊数据；后三条是在数据出来之后才有意义的调整。

使用边界与实操验收

本文不讨论定价、退款条款与合同文本，这些属于合同与条款 的范围；也不讨论渠道选择，那是自有渠道 的话题。四种分类只适用于订阅制或持续使用的工具；一次性买断的产品没有「续费失败」，流失定义要另写。

本文也不主张对所有流失都做挽留。有些流失是产品定位的必然结果：买错的人走了，剩下的画像才更清楚。分诊的目的不是把流失降到零，而是不让「本来会留下的人」被流程顺手清掉。

验证以自己后台的订单状态、扣款日志、登录与核心动作日志为准。判断分类是否成立有一个简单办法：抽 20 条记录，让两个人独立打标，如果同一批记录有超过 3 条被归进不同类别，说明规则定义有重叠，先改规则再统计。

如果一个月流失不到 10 个人，四类拆开每类只有两三个，比例没有意义；这时候只看绝对人数和具体记录，别急着算率。

关键参考与核验范围

本文的流失分类、挽回率与工时数字均为教学演示。核验日期：2026-10-23。

• 中华人民共和国个人信息保护法 ：从告知与撤回同意的角度看召回邮件——退订入口必须真实可用，用户拒绝后不应再以「服务通知」的名义绕过。
• 中华人民共和国电子商务法 ：从经营者义务角度看自动续费与扣款失败处理——扣款前与失败后的提示，应当让用户看得见、看得懂。

上述两条只用于说明合规取向，不构成法律意见；具体条款如何适用于自己的产品，应咨询专业人士。文中提到的「宽限期」「降级」是产品层面的做法，不等同于法律意义上的履约安排。

第三方平台文档、支付服务商说明与行业报告在本次核验中无法访问，故不引用其条款原文、不附链接；文中涉及的比例只用于演示算法结构，不代表任何外部统计。

系列导航

• 上一篇：留存曲线：找平坦段，而不是追高数字
• 下一篇：客服不是成本：工单是免费的需求样本
• 回到目录：一个人把用户留住：激活、留存与复购
• 相关阅读：自有渠道：邮件列表、更新日志与推荐 、合同与条款：服务条款、隐私政策、DPA、退款政策与试点协议