留存是一本账:同队列、活跃定义与四个数字

一位开发者看着注册总数从 420 涨到 1,860,以为增长还在继续,直到按同队列重算才发现每周真正完成核心动作的只有 30 人。本文对照四种活跃定义的虚高幅度,给出四周队列表的读法,说明新增、W1、W4 与周活为什么不能相加,并用两种口径复算同一批用户。

注册总数只增不减,它永远不会告诉你产品正在变差。

一、每个月都在涨的注册数

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

周航做了一款面向自由职业者的报价单工具「一页报价」,上线 18 个月。后台的注册总数在 1 月是 420,3 月是 760,6 月是 1,860。他把这条曲线截图发在朋友圈,配文只有三个字:「还在涨」。

但另外三个数字朝反方向走。客服工单从每周 14 封降到 5 封,产品更新邮件的打开率从 41% 降到 19%,最近一次功能投票只有 9 个人参与。他起初觉得这是好事:没人提问,说明产品稳定了;邮件没人看,说明大家不需要帮助。

六月最后一个周五,他导出了一份名单:过去 7 天内完成过一次核心动作的用户,也就是真正生成并发出过一份报价单的人。名单上有 30 个人,其中 11 个是他认识的同行。1,860 个注册,30 个人在用,比例是 1.6%。

更让他意外的是这 1,860 的构成:其中 1,500 个来自半年前一次目录站收录带来的脉冲,那批人注册之后大多数再没回来。他的注册总数记录的是「有多少人曾经来过」,不是「有多少人还在」。

他又把 6 月的注册按来源拆了一遍:目录站 38 个、搜索 41 个、老用户推荐 9 个、直接访问 12 个。四个来源加起来 100 个,和当月新增对得上。但当他去看这四个来源各自的人在第 4 周还剩几个时,数字变成了 9、11、4、3。来源之间的差别,比总数曲线能表达的差别大得多。

注册总数是一条只增不减的曲线,它不会跌,所以它也永远不会告诉你产品正在变差。

二、先定义「活跃」,再谈留存

在算留存之前,必须先回答一个更基础的问题:什么样的人算「活跃」。这个问题没有唯一正确答案,但必须选一个、写死,否则每个月的数字都不可比。

活跃定义每 100 个注册一周内计入的人数相对最严格口径的虚高主要问题
打开应用712.7 倍通知点开、后台唤醒都算
登录542.1 倍自动登录与未过期会话都算
完成一次核心动作331.3 倍「核心」需要写到可判断
产出并保存结果261.0 倍最接近真实价值,但会漏掉部分使用者

四个定义的差别不是技术问题,而是「你愿不愿意承认没做成事的人不算用户」。打开应用和登录都可以被通知、自动登录、后台唤醒制造出来;只有核心动作和产出结果是用户主动付出时间换来的。

判断一个定义能不能用,有个简单的测试:拿这个数字去问「所以下周该改什么」。如果答案是「不知道」,说明它离价值太远。打开应用上升,可能只是推送发得勤;完成核心动作上升,至少说明有更多人做成了一件事。

「完成一次核心动作」里的核心动作,指的是产品存在的理由。报价单工具的核心动作是「生成一份可以发给客户的报价单」,不是「打开编辑器」,也不是「点了一次保存草稿」。定义写到这个粒度,才可能被观察、被改动、被复算。

本文余下部分统一使用第三种定义:完成一次核心动作。第四种作为更严格的上限参照,出现在需要讨论「真正产出」的时候。

三、队列表:一行是一周进来的人

有了定义,才能建表。队列表的第一列不是日期,而是「哪一周进来的人」。同一行的人注册时间相近,经历的产品版本、渠道和季节也相近,这样比较才有意义。

队列(周)新增W1W2W3W4
第 1 周10038312826
第 2 周10034272221
第 3 周10029241918
第 4 周1003123未到未到

读法一:横向看同一队列随时间的衰减。第 1 周进来的 100 人,第一周还有 38 人在做核心动作,第四周剩 26 人。这条线如果一直往零走,说明产品没有留住人的结构。

读法二:纵向看不同队列在同一生命周期的表现。W1 从 38 降到 29,W4 从 26 降到 18,说明最近进来的用户质量在下降,或者产品最近的改动在劝退新人。两个原因需要分开查,不能混成一句「留存变差了」。

读法三:最后一行 W4 写「未到」,不写 0。第 4 周进来的人还没过完 28 天,任何 W4 数字都是假的。队列表最常见的造假不是编数字,而是把「还没到观察期」填成 0,然后得出「留存崩了」的结论。

还有一种读法值得养成:把「新增」这一列也当成结论看。如果某一周的新增突然翻倍,后面几周的 W1、W4 大概率会下降,因为新来的人群和原来不是同一批人。渠道变化会先污染新增,再污染留存,最后才被你在总数上看见。

3.1 一行是一周,不是一天

按天分行的表看起来更细,实际上更难读:每天几十个注册,任何一天的波动都会盖过趋势。按周分行,一周 100 人左右,比例才有稳定的分母。产品有明确的周节奏时,按周也更贴近真实使用。

如果一周的新增少于 30 人,按周也不够,应该按四周或按月合并,并在表头注明「合并队列」。样本太小的比例不要写小数点后一位,写「约」并标注人数,避免把 3 个人说成 12.5%。

四、四个数字为什么不能相加

日常汇报里最常被放在一起的四个数字,其实有四种不同的量纲。把它们相加、相减,或者放进同一个饼图,得到的都不是信息。

  • 新增:一段时间内新注册的人数,是流量,单位是人/周。
  • W1:某一队列在注册后第 7 天所在自然周仍完成核心动作的比例,分母是该队列人数。
  • W4:同一队列在第 28 天所在自然周的比例,仍然是比例,而且 W4 的人必然也计入过 W1。
  • 周活:某一周内完成核心动作的去重人数,是存量快照,分母是所有还在使用的人。

不能相加的第一个原因:单位不同。人能相加,比例不能和人相加。第二个原因:分母不同。W1、W4 的分母是队列,周活的分母是全体现存用户,新增的分母是时间。

第三个原因:包含关系。W4 是 W1 的子集,把两者相加会把同一批人算两次。这也是为什么「W1 加 W4 等于留存」这类公式在任何产品上都不成立。

能做的运算只有一种:同层相除。激活除以注册、W1 人数除以队列人数、W4 人数除以队列人数。跨层只能描述,不能计算,更不能画成一条折线。

还有一条容易忽略的规则:换了活跃定义,就不能和旧数据比。 如果你 5 月用「登录」当活跃,6 月改成「完成核心动作」,6 月的数字和 5 月之间没有可比性,必须在图上断开,从下一个月重新起算。否则你会得到一个漂亮的「下降」并误以为自己找到了问题。

五、复算:同一批人,两个结论

下面用同一批人算两次。假设某产品连续 26 周、每周新增 100 人,且每个队列的衰减都相同:W1 = 30、W2 = 24、W3 = 20、W4 = 18(只取最近四周,更早的队列不再计入,这是为演示而做的简化)。

总数口径(把累计注册当分母):
  第 4 周末:累计 400,本周活跃约 30 + 24 + 20 + 18 = 92
             92 ÷ 400 = 23.0%
  第 13 周末:累计 1,300,本周活跃约 92
             92 ÷ 1,300 = 7.1%
  第 26 周末:累计 2,600,本周活跃约 92
             92 ÷ 2,600 = 3.5%

队列口径(同一批数据):
  第 1 周队列 100 人 → W4 = 18 人 → 18%
  第 2 周队列 100 人 → W4 = 18 人 → 18%
  第 3 周队列 100 人 → W4 = 18 人 → 18%

两者差在哪里:
  总数口径的分母 26 周里涨了 6.5 倍(400 → 2,600)
  队列口径的分母始终是 100 人
  总数口径从 23.0% 掉到 3.5%,是 19.5 个百分点;
  队列口径的 W4 一直是 18%,一点没动。

总数口径给出的是一条持续下滑的线。如果只看这条线,结论会是「产品越来越差,必须立刻改」。但同一段时间里,每个队列的 W4 都是 18%。

队列口径给出的结论完全不同:留存没有恶化,恶化的是分母。累计注册越滚越大,而每周活跃的人数只和最近四周的队列有关。用一个不断变大的分母去除一个基本不变的小分子,得到的必然是一条下滑曲线。

真实数据不会这么整齐。上表的 W1 从 38 降到 29、W4 从 26 降到 18,那才是需要处理的事:它说明最近进来的用户质量在下降,或者最近的改动在劝退新人。总数口径的下滑是算术,队列口径的下滑才是产品。

如果再往下追一步,还能看出一个方向:第 3 周队列的 W1 是 29,第 4 周回升到 31,但两行的 W2 分别是 24 和 23,差距在缩小。这说明最近一次的改动可能只改善了「第一次用」,没有改善「第二次回来」。队列表的价值不在于给出结论,而在于把结论缩小到某一行、某一列上。

六、行动清单与复算验收

这份清单只有五条,目标是下周就能开始记,而不是先搭一套分析系统。一张能贴进文档的表,比一个买了没配置的工具更有用。

  • 写下「核心动作」的一句话定义,写到别人能照着判断的程度。
  • 把后台的「活跃用户」改成按这个定义统计,并在图上标注口径变更日期。
  • 建一张按周分队列的表,列固定为新增、W1、W2、W3、W4。
  • 未到观察期的格子填「未到」,不填 0,也不做估算。
  • 每周只回答一个问题:最新队列的 W1 比上一周高还是低。

验收标准:把这张表交给一个没参与产品的人,他能在两分钟内说出哪一周进来的人留得最好、哪一周最差,并且不会把 W4 当成「本周活跃」。

使用边界与实操验收

本文不覆盖付费、续费与召回,也不讨论提升留存的具体交互,那些内容在第 05 到第 09 篇。本文只解决一件事:怎么把留存算对。算错的口径不会因为后面做了多少优化而变对。

所有比例都应以你自己的后台事件为准。如果产品还没有埋点,先用可核实的替代行为手工记两周,例如导出记录、交付记录、发信记录,不要用「大概」补齐。验证以同一队列的连续四周数据为准,不以某一天的数字为准。

最后提醒一句:留存是比例,不是人数。30 个人在 1,860 里是 1.6%,在 100 里是 30%,同样的 30 个人可以讲出两个完全相反的故事。写任何结论之前,先写清分母。

关键参考与核验范围

本文的四种活跃定义、队列表与两组复算均为教学演示,不构成统计分析建议。核验日期:2026-10-23。

第三方分析工具与行业基准报告在本次核验中无法访问,因此本文不引用其数值或条款原文,也不附链接。执行时以你自有后台能导出的事件为准。

系列导航

继续阅读

探索更多技术文章

浏览归档,发现更多关于系统设计、工具链和工程实践的内容。

全部文章 返回首页

「Indie」更多文章

  1. 定价复盘:价格、转化、留存与退款的一张表
  2. 低流量定价实验:样本不够时怎么测
  3. 结账页:币种、税费、失败重试与拒付