留存率是我们产品经理非常有用的指标，缺点是对外行人来说不够简单直观。本文适合产品经理，预计需要三分钟。

一、留存率 vs 留存天数

产品经理都知道什么是留存率，但要向外人解释什么是留存率，那就有点困难了。即使是面向业内人士，不容易说清楚。

他们通常会问：这是针对新用户还是活跃用户？为什么7日留存和周留存是不一样的？更别提这个指标对他们的工作有什么影响。

即使他们了解留存率这个概念，留存率也难以直观的反映留存的情况。你得通过一组数据，比如次日留存 + 七日留存 + 30日留存，最好有个折线图，才能反映出留存的情况。

留存天数，也就是用户生命周期（Life Time），这个概念就容易理解得多了，从字面意思就可以知道，从用户第一天使用，到最后一天使用，用户会使用你这个app多少天。

投资人一听就会明白，你的app留存天数越长，说明你的app价值越大，用户越离不开你；运营的同事一听就明白，他的工作就是尽量留住用户，延长这个留存的时间；销售的同事听了也会明白，过了这个时间段，用户就会走掉，必须在这个时间段内，尽可能的把用户转换为顾客（付费用户）。

二、如何计算留存天数？

方法一：全样本统计

用户最后一次使用的日期，减去他注册的日期，就是单个用户的留存天数。把所有用户的单用户留存天数平均一下，就是留存天数了。

这种方法的缺点是非常不灵敏。样本要足够的大，时间跨度要足够的长，才能得出真实的数据。如果你的app上线时间少于一年，得出的数据都是没有意义的。这样计算出来的数据，显然不会有什么波动。

方法二：倒推法

今天每一个活跃用户，从他们的注册时间到今天的时间差，平均一下，就得出留存天数了。

同样的方法，可以用来计算某一天的，某一周的，某个月的，某一年的。

这个方法听上去不错，用我们的薄荷 app 实际跑一遍数据，就会发现是多么不靠谱。

由于数据不方便完全公开，用上面说的全样本统计，算出来的值设为 X。用倒推法，一天算就是 X 的4.1倍，用一个月算就是 X 的2.5倍，用3个月算就是 X 的2.3倍，一年算就是 X 的1.7倍。

可以看出，时间跨度越短，误差越大。时间跨度越大，误差越小。无论选哪一个时间跨度，都与全样本统计得出的数据相差甚远。

《解析用户生命周期价值：LTV》这篇文章里提到了一个计算用户生命周期的公式：

LT：（Life Time）生命周期；指的是新增账户在首次进入游戏到最后一次参与游戏的时间天数；目前大部分取值均以自然月为准；即某个月用户生命周期之和/MAU=平均生命周期

这个方法算出来就是 X 的2.5倍，是不可靠的。

为什么会有这么大的误差呢？因为你统计到的样本，都是已经留下来的用户。那些没有留下来的用户，你都没有统计到。

这就是「幸存者偏差」，典型案例有返航的飞机和都买到火车票了吗，有兴趣的朋友可以去了解下。

方法三：经验公式

留存天数跟留存率之前是正相关的关系，留存率越高，留存天数就越长。那么，用留存率能直接算出留存天数吗？

《剖析用户生命周期和价值》这篇文章里提了一个计算公式：

用户生命周期=周期/(1-周期内新增留存率)

这个算法从逻辑上判断就是不靠谱的。

• 留存天数与留存率虽然是正相关，但不是线性相关，两者的对应关系不是靠一个简单公式就能描述得清楚的。

• 公式里的周期，用一个月为单位，用户生命周期就是 n 个月，用一周为单位，用户生命周期就变成 n 周啦？

从实际数据来看，我用薄荷 app 的数据算了下，以一个月为单位，把月留存代入公式，得出的结果大约是全样本统计结果的一半。

小结

除了全样本统计的方法，另外两种方法都是不准的。

留存率不够简单，留存天数不够灵敏，有没有一个指标既简单又灵敏呢？答案是有的。

三、月活跃天数

能兼顾简单和灵敏的指标，就是月活跃天数了。意思是，这个月的活跃用户的平均活跃天数。

这个概念就比较清晰，界定的样本范围和时间跨度都比较适中。计算方法也非常简单：

月活跃天数 = 当月每天日活的总和 / 月活

我们现在的考核指标，就是用月活 + 月活跃天数，来代替了原来的日活 + 周留存。因为这两个数据受市场推广因素的影响比较小，能更加准确的衡量产品经理的工作表现。

四、总结

留存率是我们产品经理非常有用的指标，缺点是对外行人来说不够简单直观。

留存天数，也就是用户生命周期，是很简单直观的概念。只能通过全样本统计的方式来计算，其他算法都不靠谱。这个指标很重要，但波动不大，无法反映短时间内工作的成绩。

如果要作为工作考核指标的话，建议使用月活跃天数这个指标。