4种 удержания方式：保持率是什么样的？
留存率有很多种。衡量产品指标时，绝不应只限于一种。它有何种形式，分析师 devtodev 的维拉·卡尔坡娃（Vera Karpova）在我们系列文章“游戏效能指标”的新文章中进行了说明。
这篇文章是 App2Top.ru 和 devtodev 关于游戏指标系列文章的一部分。文章按季节分开，每季专注于某个具体主题。第二季名为“用户”。在这一季中，我们讨论反映应用在受众管理方面效能的商业指标。
维拉·卡尔坡娃
当谈到 留存率（retention） 时，通常指的是经典的指标计算公式：
留存率 N = 当天 N 登录的用户数 / N 天前安装应用的用户数 * 100%
但留存率的计算方式可以多种多样。
4 种留存类型
通常，还可以区分另外四种留存计算方法。
1) 滚动留存（rolling retention）
第 N 天的滚动留存率表示在安装后的第 N 天或更晚重返应用的用户百分比。
它考虑在第 N 天返回的用户，以及在任意其他天（N+m）登录过应用的用户。
例如，第 14 天的滚动留存率为 10%，意味着在第 14 天及之后，总共重返游戏的用户占比为 10%。
2) 完全留存（full retention）
第 N 天的完全留存率表示在第 N 天之前每一天都登录应用的用户百分比。
例如，第 5 天的完全留存率是指在安装后的第 1、2、3、4 和 5 天登录过应用的用户百分比。
3) 返回留存（return retention）
第 N 天的返回留存率表示在 N 天内至少登录过一次的用户百分比。
例如，第 21 天的返回留存率将计算在第 1 至 21 天内的所有登录用户。
4) 区间留存（bracket-dependent return retention）
第 N 天的区间留存是一种返回留存的变体。可以推测，它记录在特定时间段内至少登录一次的用户。
为了计算这种留存，需要设置额外的参数 M，以限制用户返回的时间范围。
此处的留存率计算为在 M-N 天内返回的用户百分比。
例如，14 天到 20 天的区间留存将显示在安装后的这一时间段内启动应用的用户比例。
滚动留存的特点是什么？
在上述的所有选项中，最常用的是滚动留存（rolling retention）。
其公式如下：
滚动留存 N = 当天 N 或更晚登录的用户数 / N 天前安装应用的用户数 * 100%
首先，我们通过一个例子来看看该指标是如何计算的。
假设我们有关于用户和他们会话的以下数据（绿色突出的是用户登录应用的天数，红色是自上一次登录以来没有登录的天数）：
第 N 天的滚动留存考虑那些在该天或更晚登录的用户，因此在该日的单元格为绿色或白色的用户都被包含在内。
然后，与经典留存一样，将这些用户占总用户数的比例计算出来。
如果比较这两种留存，结果如下：
滚动留存总是高于经典留存，因为它在计算时考虑了不仅在某特定日，而且在随后的日子里登录的用户。同样，这种类型的减小会比经典留存更平滑。
还有一个特点使得滚动留存与经典留存不同，使得其使用更复杂，那就是指标的计算。
实际上，这个指标需要每天重新计算，因为未登录几天并被视为流失的用户，可能在某个时刻再次使用该应用，从而影响到所有之前天数的滚动留存。
举例来说，用户在安装后的第 7 天最后一次登录应用。我们计算的 25 天的 cohort 指标中，该用户在第 7 天后不再被计入。然而他在第 26 天登录，这意味着第 8 到第 26 天的滚动留存必须重新计算，并包含该用户。
使用滚动留存的意义在于准确反映实际上并未离开项目的用户，他们只是因为某些原因未在我们测量的第 7 天登录。
我们在 devtodev 认为，这一返回指标对于不需要用户每天都使用的应用，或者在某些情况下，用户必须等待一段时间（例如，资源积累或建筑完成）才能使用的游戏尤为有用。
此外，该参数还有一个有用的特点。留存率本身被视为流失的反向指标，而滚动留存则使我们能够更精准且简便地计算这一指标。
原因很简单。特定日期的滚动留存考虑了后续日期登录的用户。如果用户未被视为重复返回，则意味着在观察期的后续日子中，他也未登录。这就意味着曲线下方的区域代表了回归用户（这正是我们指标所显示的），而曲线之上的区域则是流失用户（那些从某一天起再未登录应用的用户）。
结论
滚动留存是一个有用的指标，它表征了用户对项目的兴趣，显示他们在何时不会再返回，并能够计算流失率和用户生命周期等指标。
然而，滚动留存常常会误导开发者，让他们误以为情况良好，因为其图表呈现了更平滑的下降，且其数值往往远高于经典留存，而这对于理想上每天都应使用的应用而言可能是至关重要的。
因此，在分析用户回归时，应关注两种留存，以便做出全面的决策。
还请阅读关于其他指标的资料：
