留存率公式完整指南：客户留存、用户留存、计算步骤、实用示例、口径选择与常见错误解析

留存率公式：快速答案

其中，S 是期初符合条件的人数，E 是期末符合条件的总人数，N 是期间新增人数。示例：期初有 1,000 名客户，期末有 940 名，期间新增 140 名。来自期初且仍被保留的客户是 800 名，因此留存率为 ((940 − 140) ÷ 1,000) × 100 = 80%。

产品团队经常需要另一种相关的队列公式：原始队列中仍满足留存条件的人数 ÷ 原始队列人数 × 100。它回答“同一时间首次满足条件的用户，在第 7 天、第 4 周或其他队列年龄仍回访的比例是多少？”除非人群和事件定义完全等价，否则不要把它与总体客户留存公式混用。

如何选择正确的留存率公式

“留存率公式”可能对应多种业务问题。算术很简单，测量契约却不简单。首先要确定保留的对象、进入人群的资格、证明留存的行为，以及测量对象是持续变化的客户总体还是固定的获客队列。

如果问题是“现有客户中有多少留下来”，使用客户留存；如果问题是“注册用户中有多少在第 4 周回访”，使用队列留存；如果问题是“期初经常性收入保留了多少”，使用收入留存。一个仪表盘可以同时展示三者，但每个指标都必须拥有独立名称和定义。

计算留存率前需要准备的输入

可信的留存计算始于书面的指标定义，应在打开表格或编写 SQL 之前完成。否则，不同团队可能从同一批记录得出不同答案，而且每条查询在技术上看起来都正确。

• 分析单位：个人、账户、工作区、订阅、设备、家庭或员工。选择稳定的身份键，并记录去重规则。
• 资格条件：决定某个对象是否进入分母的事件或状态。免费试用、退款订单、内部用户和测试账户都需要明确处理。
• 起止边界：使用明确的时区以及清晰的包含或排除规则。自然月与滚动 30 天窗口不能互换。
• 留存条件：有效订阅、购买、登录、有意义的产品事件或其他可观察行为。“任意事件”可能夸大产品的持续价值。
• 迟到与删除数据：决定一个周期何时视为完整，以及身份合并、退款或数据回填后是否重算历史结果。

如何逐步计算留存率

1. 写明问题和周期

   例如：“7 月 1 日 00:00 UTC 有效的付费账户中，有多少在 7 月 31 日 23:59:59 UTC 仍然有效？”精确问题可以避免自然月、滚动窗口和队列逻辑之间悄然切换。

2. 建立期初人群

   固定 S 的名单或可复现查询。确认身份粒度，排除不符合资格的记录，并保存行数与提取时间。

3. 确定期末状态与新增

   使用相同资格规则统计期末 E。N 只统计起始边界之后首次新增的对象。恢复订阅或重新激活的账户必须有明确政策。

4. 以完整精度应用公式

   计算 ((E − N) ÷ S) × 100，只在展示时四舍五入。保留分子、分母和未舍入值，便于审核者复现。

5. 验证成员关系，而不只是总数

   在可能的情况下，将期初人群与期末留存成员直接关联。调查重复、负数、超过 100% 的留存率、缺失身份以及数据刷新后大幅变化的结果。

客户与产品用户的留存率计算示例

示例 1——月度客户留存。这是一个假设的订阅业务：4 月初有 2,400 个付费账户，4 月末有 2,310 个，其中 270 个是在 4 月首次获得的账户。留存的期初账户为 2,310 − 270 = 2,040，因此客户留存率为 2,040 ÷ 2,400 × 100 = 85%。在相同人群且结果互斥的前提下，客户流失率为 15%。

示例 2——第 7 天产品留存。一个假设队列包含 500 名在 8 月 1 日首次完成合格激活的用户。如果其中 185 名同一用户在恰好第 7 天完成定义的核心行为，则精确日留存率为 185 ÷ 500 × 100 = 37%。8 月 1 日之后新获得的用户既不进入分母，也不进入分子。如果团队统计第 7 天或之后任意时间的活动，那是滚动留存，必须使用不同标签。

留存率与流失率、收入留存的区别

相关指标揭示不同的失败模式。客户数量留存将每个账户等权处理，用户队列留存关注回访行为，收入留存按保留下来的经济价值加权，而流失率衡量损失而非存续。报告时应同时给出指标名称、单位、周期与公式。

从事件数据或数据仓库计算留存率

可重复的留存分析应保留成员名单，而不仅是最终百分比。在数据仓库中，按选定粒度建立期初人群表、带日期的状态或事件表，以及指标定义记录，再通过明确关联得出留存。这使团队能够检查谁被计入、识别身份变化并复现历史周期。

1. 创建指标契约

   记录对象粒度、进入资格、留存状态或回访事件、时区、周期边界、排除项、重新激活处理和舍入规则。定义变化时应保留版本。

2. 快照或重建资格

   使用有效起止时间戳或可靠快照。仅有当前状态字段无法重建数月前哪些对象符合资格。

3. 按稳定身份键关联

   一致处理匿名用户合并到已知用户、账户归属变化和重复设备。聚合前应检查一对多关联。

4. 按可比细分聚合

   可按套餐、获客渠道、激活路径、国家、设备或客户年龄拆分，但必须保证样本量仍有意义，并在相同队列年龄上比较。

5. 保存审核证据

   保存查询、参数、数据新鲜度、关联前后计数、排除项与结果。没有这些记录的图表在数字变化时很难解释。

对于产品留存，回访条件必须可观察。Google Analytics 将队列定义为共享某种特征的用户群，其队列探索同时要求进入条件与回访条件。该区分不只适用于 GA4，它能避免团队在没有定义“有意义回访”的情况下，把任何后续记录都称为留存。

如何解释留存率并避免错误基准

不存在适用于所有场景的“良好留存率”。杂货应用、年度企业合同、社交产品、平台卖家与员工人群具有不同的自然使用频率和资格规则。公开基准经常混合产品类型、发展阶段、国家、定价模式和留存定义，只能作为背景，不能直接作为目标。

更可靠的解释应进行同类比较：在时间上保持同一指标契约，在相同队列年龄比较，并确保细分样本量充足。百分比旁应展示分子与分母。50 名用户从 40% 提升到 44%，与 50,000 名用户的相同变化含义不同；最近的队列还可能尚未成熟。

常见留存率计算错误与局限

• 把新增客户保留在分子中：获客可能让期末总数看起来健康，却掩盖原始客户群缩小。应减去 N，或直接取期初与期末成员交集。
• 事后改变分母：看到结果后再排除休眠、试用、退款或低价值用户会产生偏差。必须预先确定资格。
• 混用精确留存与滚动留存：“第 7 天活跃”和“第 7 天或之后活跃”回答不同问题。滚动留存不能在未清楚标注的情况下放到同一曲线。
• 比较不同年龄的队列：仅存在两周的队列不可能拥有完整的第 3 月留存率。只使用已成熟单元格，或明确标记不完整数据。
• 假设留存率与流失率总和始终为 100%：只有在人群、单位、周期相同且状态互斥时才成立。重新激活、暂停、增购和收入加权都会使关系复杂化。
• 忽略幸存者偏差与观察限制：留存只描述可用数据中的已观察行为。事件缺失、追踪受阻、身份重置、季节性和过短观察期都可能造成失真。

如果没有可信的因果设计，留存率只是描述性指标。当你需要判断产品改动是否导致留存改善时，应使用实验或经过严谨设计的准实验。单纯的改动前后图表容易受到渠道结构、季节性、定价变化和外部事件影响。

留存分析结果验证清单

在发布仪表盘或决策备忘录之前，执行以下检查。留存百分比必须能够追溯到人群与原始证据，而不只是看起来合理。

• 指标名称明确是客户、用户队列、员工还是收入留存。
• 起止时间戳、时区以及精确或滚动窗口清晰可见。
• 进入事件、回访事件或留存状态、排除项与重新激活政策均有记录。
• 保留分子、分母、未舍入结果与展示舍入规则。
• 新增对象不会被误分类为留存的期初成员。
• 已检查重复身份、关联膨胀、事件缺失和迟到数据。
• 队列在相同年龄比较，不完整周期有明确标记。
• 审核者能够从保存的查询或源数据导出复现结果。

下一步可以把该指标与诊断性邻近指标连接起来：激活、功能采用、互动频率、漏斗流失与队列构成。留存告诉你某个人群是否留下或回访，而这些相关指标有助于解释体验可能在哪些环节发生变化。

留存率公式常见问题

权威来源

以下资料用于核对本文中的定义、计算方法与实施建议：

• 客户留存率计算第一方指南
• Google Analytics 队列探索文档
• 留存概览报告文档
• 产品经理数据科学指南