2. 客户留存指标：留存率的定义与计算

聊留存率之前，我先问你一个问题：你每天打开微信几次？

我猜至少十几次吧。但你有没有想过，为什么微信团队不关心你今天打开了几次，而是更关心「你明天还会不会打开」？

这就是留存率的本质——它不是看用户来了多少，而是看用户走了多少。

2.1 留存率的定义：别被公式骗了

留存率，说白了就是：某天来的用户，过了一段时间后还有多少人在用。

公式很简单：

留存率 = (第N天还在用的用户数) / (第0天新增的用户数) × 100%

举个例子：

• 1月1日来了100个新用户
• 1月2日（第1天）还有40人打开过App → 次日留存率 = 40%
• 1月8日（第7天）还有20人打开过 → 7日留存率 = 20%

嗯，这里要注意：「还在用」的定义很关键。我见过不少团队把「登录就算留存」改成「有核心操作才算留存」，结果留存率直接腰斩。你想想看，如果用户只是打开App看了一眼就关掉，这算留存吗？我个人习惯把「有效留存」定义为至少完成一次核心操作。

2.2 三种留存周期：日、周、月

不同产品看不同周期，我整理了一张表：

留存类型	计算周期	适用场景	我见过的典型值
日留存（D1/D7/D30）	按天计算	社交、资讯、工具类	次日40%+，7日20%+
周留存（W1/W4）	按周计算	电商、教育、低频工具	首周30%+，第4周15%+
月留存（M1/M3/M6）	按月计算	SaaS、金融、游戏	首月20%+，第6月10%+

我在做一款企业SaaS产品时踩过一个坑：只看日留存，觉得数据还行，结果月留存惨不忍睹。后来才发现，用户每周只用一次，日留存当然低。所以我的建议是：根据产品使用频率，选对留存周期。

2.3 留存曲线：一眼看出产品健康度

留存曲线，就是把不同周期的留存率连成一条线。我习惯用双对数坐标来画，因为大多数产品的留存曲线都符合幂律分布。

正常的留存曲线长这样：

• 陡降期（第1-3天）：大量用户流失，这是正常的
• 缓降期（第4-14天）：流失速度放缓，核心用户开始沉淀
• 平稳期（第15天以后）：曲线趋平，剩下的就是忠实用户

我曾经帮一个团队分析他们的留存曲线，发现第7天有个「诡异的小凸起」。排查后发现：他们的App在第7天会推送一条强提醒消息，把一部分已经流失的用户「拉」了回来。这其实是虚假留存，因为用户是被迫回来的，不是主动使用。

2.4 Cohort分析：把用户分组看

Cohort分析，说白了就是把用户按「来的时间」分组，然后对比不同组的表现。

举个例子：

• 1月第1周来的用户（Cohort A），7日留存率25%
• 1月第2周来的用户（Cohort B），7日留存率22%
• 1月第3周来的用户（Cohort C），7日留存率18%

看到这个趋势，你第一反应是什么？产品是不是越改越差了？还是渠道质量下降了？

我习惯用Cohort分析来做版本回归验证。比如我们发了一个新版本，如果新版本用户的留存率比老版本用户低，那这个版本大概率有问题。

2.5 兼容性问题如何影响留存率？

这个问题我太有发言权了。我之前负责的一款App，在Android 12发布后，次日留存率从42%直接跌到28%。一开始大家都以为是产品改坏了，查了一圈才发现：新系统下的权限模型变了，App在后台频繁崩溃。

兼容性问题对留存的影响，通常有这几个路径：

1. 直接崩溃：用户打开就闪退，留存直接归零。我见过最夸张的案例，某个国产ROM的特定版本，App启动必崩，那个渠道的次日留存是0%。
2. 功能异常：比如支付页面白屏、登录按钮点不动。用户试了两次不行，就走了。而且大概率不会再回来。
3. 性能劣化：卡顿、耗电、发热。用户可能不会立刻卸载，但使用频率会明显下降。反映在留存曲线上，就是「缓降期」变陡了。
4. UI错乱：按钮重叠、文字溢出。这种问题最隐蔽，因为不致命，但会让用户觉得「这个App很山寨」，从而降低信任感。

我总结了一个兼容性-留存影响矩阵：

兼容性问题类型	影响留存周期	影响程度	修复优先级
启动崩溃	次日留存	极高（-50%~-100%）	P0
核心功能异常	3-7日留存	高（-20%~-50%）	P1
性能劣化	7-30日留存	中（-10%~-20%）	P2
UI/UX问题	长期留存	低（-5%~-10%）	P3

2.6 知识体系总览

下面这张图，是我对本章知识结构的梳理：

这张图把本章的核心逻辑串起来了：从留存率的定义出发，到三种周期的选择，再到留存曲线的解读，最后用Cohort分析定位兼容性问题。每一步都是环环相扣的。

---

公众号:蓝海资料掘金营，微信deep3321