总用户涨了但老客在流失？用 Amplitude 公式排除新增，看清真实留存
排除新增客户的留存计算公式通过（期末客户减新增客户）除以期初客户，旨在剥离新客干扰以反映老客真实去留，但需明确适用边界与报告规范。
为什么需要“排除新增客户的留存计算公式”？
该公式用于识别总用户增长中由新客涌入掩盖的老客流失真相，避免管理者因数据幻觉误判产品健康度与实际留存状况。
某 SaaS 产品期末总用户数比期初多了 30%，乍看之下增长喜人。但若细查，这 30% 全是本月新注册的客户，老用户实际流失了 20%。直接对比期末与期初的总人数，会掩盖真实的客户去留状况[1]。这种数据幻觉在业务扩张期尤为常见：新客涌入像潮水一样填平了老客离开的坑，让管理者误以为产品健康度在提升。
新客涌入如何扭曲留存数据
传统做法往往忽略了一个事实：活跃用户并非跨业务天然一致的实体。登录、购买或持续付费代表不同的行为状态，单纯看总人数增长，容易把“新用户进来”和“老用户留下”混为一谈[1]。当新客规模足够大时，即便存量客户大量流失，总盘子的数字依然能维持上涨。这种计算方式无法区分用户关系的“持续”究竟指继续使用同一产品，还是仅仅指用户仍属于该组织范畴[1]。
为了解决这个问题，Amplitude 提出了一种总体客户留存计算口径：Retention Rate = (Customers at End − New Customers) / Customers at Start[1]。这个公式的核心意图非常明确：剥离期间新增的影响，只盯着那些期初就在的存量客户，看他们到底还在不在。它不关心新客带来了多少增量，只关心老客有没有走。不过，现有证据尚未验证该公式与严格队列留存、活动留存或滚动留存之间的适用边界[1]。在实际报告中，必须明确公式对应的对象、时间窗口和新增识别方式；不能因为两个指标都叫 retention，就假定它们可以直接比较。
这里有一个常被外行忽视的细节：在计算分母“期初客户”时，如果将“已流失但随后回流”的用户重新计入期初基数，会导致留存率被人为虚高。 许多团队在统计时，习惯将期初定义为“当前数据库中存在的所有非新增用户”，却未剔除那些在期初前曾离开、但在期初时刻刚刚回来的用户。这些回流用户虽然物理上存在于数据库中，但他们本质上属于“二次获取”而非“原始留存”。如果不将这部分“假期初用户”从分母中剔除，公式计算出的留存率就会包含了一次本应归因于召回策略的成功，从而模糊了真正核心老客的流失真相。因此，严谨的“期初”定义应当严格限定为“上一周期结束时仍在库且从未中断过服务关系（或按特定规则认定的连续状态）的用户”，任何中途断连后重新激活的个体，都应被视为新的流入变量，而非存量基数的自然延续。
拆解公式背后的逻辑：如何界定“活跃”与“持续”
计算留存率前必须严格定义“活跃”状态，否则不同报表中的指标将因标准混淆而失去可比性，导致无法准确衡量用户持续存在。
为什么同一个“留存率”数字，在不同报表里含义天差地别？根源在于计算前没先回答一个基础问题：什么状态才算“仍然存在”。如果不把“活跃”的定义钉死，公式算出来的只是被混淆的指标堆叠。
不同业务场景下的活跃定义
在客户场景中，“活跃”并非单一动作。它可能指窗口期内的登录行为，也可能指完成一次购买，甚至可能是订阅关系的自动延续[1]。这三者性质完全不同。登录型活跃衡量的是访问频率，购买型活跃看的是交易转化，而持续付费型活跃则更接近契约关系的存续。如果把登录次数当成购买意愿，或者用单次消费掩盖了订阅流失，数据就会失真。这三种指标可以并列报告，但绝不能在没有说明口径的情况下互相替代。
这种差异不仅存在于客户业务。员工和学生的“持续状态”也有各自独立的判定标准[1]。这意味着“活跃用户”从来不是跨业务天然一致的实体。强行套用同一套定义，就像拿尺子去量温度，结果毫无意义。
为了更清晰地看清区别，我们可以对比三种核心指标的本质差异：
| 指标类型 | 核心行为 | 衡量本质 | 适用边界 |
|---|---|---|---|
| 登录型活跃 | 打开应用/网站 | 访问行为频次 | 内容消费、工具使用类 |
| 购买型活跃 | 完成支付动作 | 交易转化结果 | 电商、一次性服务类 |
| 持续付费型 | 订阅自动续期 | 契约关系延续 | SaaS、会员制服务类 |
表格显示，不同业务对“活跃”的锚点截然不同。若不加区分，Amplitude 留存率公式会把这些不同类型的持续行为压缩成一个模糊数字。
Amplitude 进一步从概念上做了切割：Retention（留存）强调用户仍属于同一组织，而 Persistence（持久性）强调用户仍处于同一类别，哪怕已经更换了组织[1]。前者关注的是“人还在不在这个圈子里”，后者关注的是“需求还在不在”。若不先确定对象是“组织归属”还是“类别状态”，后续所有的数值分析都建立在流沙之上。
公式的适用边界：当前证据与潜在局限
现有证据尚不足以证明总体排除新增公式能完全替代严格的队列分析，其适用性受限于缺乏对特定场景的边界验证与等价性确认。
你看到 Amplitude 提出的总体排除新增客户的留存计算公式，以为能直接替代严格的队列分析？现有证据还没法证明这两者完全等价[1]。
缺乏严格边界验证的现实
这个公式的核心意图很明确：把期间新增的客户剔除，只看老客户的去留[1]。但“剔除”不等于“还原”。目前行业里还没有跨领域的通行标准，能证明这种简化算法在所有场景下都能等同于严格队列留存或滚动留存。
不同业务对“持续”的定义天差地别。登录型活跃看的是访问行为，购买型活跃看的是交易流水，订阅型活跃看的是关系延续[1]。如果混用口径，就像拿体温计去测血压，数值再精准也没意义。Amplitude 区分了 retention（仍属同一组织）和 persistence（仍处同一类别），但这只是单一供应商的观点，尚未成为通用法则[1]。若不先锁定对象，留存率会把完全不同的持续行为压缩成一个数字。
最棘手的其实是回流用户。他们算回归原始队列？还是进回流队列？亦或是独立状态？现有材料没给定论[2][3][1][4]。在规则没定下来之前，盲目套用公式极易出错。一次短暂回访被误读为生命周期恢复，数据就会失真。
为了避免这种误判，报告时必须同时保留三组数据：原始队列留存、当期回流率、当前活跃率。不要只盯着一个总指标，否则无法分辨用户是真正回来了，还是只是路过。
| 对比项 | 总体留存率公式 | 严格队列/滚动留存 | 风险点 |
|---|---|---|---|
| 计算逻辑 | (期末 - 新增) / 期初 | 追踪特定批次随时间变化 | 忽略批次差异，掩盖波动 |
| 回流处理 | 未明确归属路径 | 需预设回流归因规则 | 误将短期回访视为长期回归 |
| 活跃定义 | 依赖外部输入，非统一 | 可针对具体场景定制 | 跨场景比较时口径不一致 |
| 适用场景 | 快速概览，排除新客干扰 | 深度生命周期分析 | 复杂业务场景下精度不足 |
| 横向对比 | 不可直接与其他方法对比 | 需明确窗口与对象 | 名称相同不代表算法一致 |
不能因为两个指标都叫”retention”，就假定它们可以直接横向对比。实际报告中，必须明确公式对应的对象、时间窗口和新增客户识别方式。在规则尚未确定前，宁可多报几组数据，也别让模糊的结论误导决策。
实操指南：如何规范报告排除新增后的留存数据
在回流用户归属规则未统一前，应并行展示原始队列留存、当期回流率及当前活跃率三套指标，以防止将短暂回访误读为关系真正恢复。
回流用户该算进哪一栏？是回归原始队列、归入新的回流组，还是作为独立状态处理？现有材料并未给出统一答案 [2][3]。这种归属模糊直接导致数据不可比。在规则落地前，最稳妥的做法是并行展示三套指标：原始队列留存率、当期回流率以及当前活跃率。这样能防止将一次短暂的回访误读为生命周期关系的真正恢复。
不同业务对“活跃”的定义天然存在差异。登录行为代表访问意愿，购买行为代表交易确认，持续付费则指向订阅关系的延续 [1]。这三种状态可以并列呈现，但绝不能在没有说明口径的情况下互相替代。若强行混用，留存率就会把不同类型的持续行为压缩成一个失真的数字。
Amplitude 提出的总体公式 (期末客户 - 新增客户) / 期初客户，核心意图在于剔除期间新增的干扰 [1]。然而，该公式与严格队列留存、滚动留存之间的适用边界尚未经过广泛验证。实际报告中，必须明确界定公式对应的对象、时间窗口以及新增客户的识别标准。不能仅因两个指标都叫 retention，就默认它们可以直接横向比较。
为了让这套公式真正落地，建议在执行层面建立“新增客户白名单机制”： 不要试图用单一的“注册时间”来一刀切地定义新增，而是根据业务特性设定动态阈值。例如，对于 SaaS 企业，可以将“首次登录并产生有效会话时长超过 5 分钟”或“完成首单支付”作为新增标记的触发条件，而非仅仅依据账号创建时间。对于那些注册后从未产生实质交互的“僵尸账号”，应在计算分母（期初客户）时就予以剔除，避免稀释分母导致留存率虚高。同时，对于回流用户，建议在数据仓库中设立独立的 returning_user_flag 字段，在计算 Amplitude 公式时，将这些用户明确标记为“回流”而非“期初存量”，并在报表中单独列示其贡献值。通过这种精细化的数据打标，既能保留 Amplitude 公式的宏观视角，又能规避因定义模糊带来的计算偏差。
| 指标类型 | 计算逻辑 | 反映关系 | 潜在风险 |
|---|---|---|---|
| 原始队列留存 | 追踪初始用户群 | 长期生命周期粘性 | 忽略中途流失用户的回归 |
| 当期回流率 | 统计非活跃后复购/登录 | 短期挽回能力 | 易被单次冲动消费拉高 |
| 当前活跃率 | 统计周期内任意活跃 | 整体盘面热度 | 无法区分新老用户贡献 |
这三张表拼在一起，才能还原真实的用户状态。原始队列看的是基本盘稳不稳，回流率看的是挽回手段灵不灵，活跃率看的是当下流量热不热。只有把对象、窗口和新增识别方式说清楚，这份排除新增客户的留存计算公式才具备参考价值。
FAQ：关于留存计算的常见疑问
Q: 为什么我的总用户数在涨，但留存率却在跌？ A: 这通常是因为新客增长速度远快于老客的留存速度。总用户数是“存量 + 增量”的叠加，而留存率只关注“期初存量”的保持情况。这时候就需要用到排除新增客户的留存计算公式来剥离新客干扰，看清真实的基本盘健康状况。
Q: Amplitude 的公式适合所有业务吗？ A: 不一定。虽然它的客户留存计算口径清晰且易于执行，但它假设了“新增”和“存量”界限分明。对于高频回流、复杂订阅层级或 B2B2C 模式，可能需要结合严格队列分析来补充细节，避免误判。
Q: 如何判断“活跃”的标准是否合理？ A: 没有万能标准。关键看你的业务目标：如果是内容平台，登录即可；如果是电商，下单才算；如果是 SaaS，续费才是王道。务必在报表中明确标注你所用的 Amplitude 留存率公式是基于哪种行为定义的，否则数据就没有可比性。
参考来源
- Retention Rate: Complete Definition & Calculation Guide · https://amplitude.com/explore/growth/retention-rate（B级）
- What Is Cohort Retention? Definition and Related Resources | Amplitude · https://amplitude.com/glossary/terms/cohort-retention（B级）
- What Is Cohort Retention Analysis: Essential Metrics Guide · https://amplitude.com/explore/analytics/cohort-retention-analysis（B级）
- Cohort Retention Analysis: Reduce Churn Using Customer Data · https://amplitude.com/blog/cohorts-to-improve-your-retention（B级）