手把手教你如何衡量留存率

老雅痞
2022年9月03日11时

本文属于老雅痞原创文章，转载规矩不变，给我们打声招呼～

转载请微信联系：huangdiezi，更多DAO、Web3、NFT、元宇宙资讯，请关注公众号FastDaily

信息来源自lenny's newsletter，略有修改，作者Olga Berezovsky、Lenny Rachitsky

编译：RR

许多分析师(以及产品经理、创始人和大多数人)都被留存率所吓倒。这些图表可能很难读懂，每个产品和业务类型的定义都不同，SQL也很复杂。与此同时，在大多数公司中，留存率既是最重要的指标，也是最难理解的指标。根据我的经验，需要6个月的时间才能完成准确的留存率报告。

在这篇文章中，我将分享我多年来开发的方法、工具和策略，以帮助你计算群组留存率并理解留存率报告的细微差别。关于留存率的入门读物，请务必阅读Lenny之前关于这个话题的两篇文章：《如何提高留存率》和《什么是良好的留存率》，以便了解监测和提高留存率的重要性。

总之，留存率衡量的是你的产品在一段时间内保持用户活跃度的能力。消费者业务的留存率与企业、B2B或B2C公司的留存率含义不同：

步骤1：定义“活跃”

正如你所看到的，对于大多数产品来说，计算留存率的一个基本变量是“活跃用户”。但“活跃”的含义并不明确。

以下是各公司最常用来定义“活跃”的东西。其中每一个都有自己的缺点和局限性：

访问：太宽泛，你会过度计算用户数量，并很可能会遇到未经身份验证和未注册用户的问题。而且这只适用于网络。
对话启动：你可能会因为提取未经认证的ID而过度计算用户数。你还需要将对话长度限制在一个特定的时间范围内，该时间范围应针对你的产品使用情况而设置。如果不这样做的话，你可能会统计后台应用的刷新、通知和任何其他与用户活动无关的应用活动。
登录或应用打开：与上述相同，你需要通过某种方法排除新用户的首次应用打开，并排除未经认证的用户和重复用户。
网页浏览量或屏幕浏览量：太宽泛，很有可能将所有用户类型(包括休眠用户、流失用户和新用户)混到一起，并夸大DAU和留存率。
主要用户操作：太过狭窄，容易漏掉那些没有进行你预期的主要活动但仍在使用应用的活跃用户。

在不同的公司，我必须根据所有这些因素的变化来报告DAU和留存率，有时甚至会将其中一些混合在一起(如对话启动+应用打开)。

大多数公司使用登录或应用程序打开作为“活跃用户”定义的主要事件。但鉴于我总是以最简洁和最精确的数据报告为目标，我建议使用主要用户操作作为活跃因素，例如：

这种方法的优点：

它忽略了访问、屏幕浏览和登录等所有干扰因素，并将活跃因素调整为用户最常做的主要行为。
它为你提供了可以监视和验证他们行为的真正活跃用户的最清晰样本。
它通常可用于所有平台和数据源，因此易于报告和监测。

不管你的业务类型是什么，我的建议都是使用主要用户行为去监测留存率以及DAU、WAU、MAU和DAU/MAU比率等其他用户活跃参数。

步骤2：区分用户和客户

一旦你的团队就“活跃”对产品的意义达成一致，下一步就是将活跃用户划分为免费用户和付费用户。你的留存率对于每个群组都有不同的逻辑。

“客户”被定义为付钱给你的人/群体。用户是指使用产品的人。在订阅产品中，通常会有多个用户与单个客户关联。或者人们在成为客户之前是用户。你需要把这两件事的定义和称呼分开，以便团队清楚地采取行动。——Brian Balfour，《定义指标的常见错误》

根据你的业务模式，你的留存率输出将基于不同的参数，例如：

这些参数是你计算留存率的基准。现在你已经知道了谁是你的活跃用户或活跃客户，你可以开始计算留存率，了解他们回访的频率。

我经常看到SaaS公司犯的一个错误是报告的用户留存率是“混合”（免费用户和付费用户）的。这可能会产生误导，因为付费用户比免费用户更有可能使用产品。所以免费用户的真实活动将被隐藏起来。

步骤3：选择留存类型

计算留存率的下一步是设置时间线。作为一个团队，你必须就应该采用的留存率报告类型达成一致：

x天留存率
无限(滚动)留存率

你选择的方法会显著影响你的结果。

1. x天留存率

X-day会告诉你在特定的一天回访的用户百分比。例如，所有用户在第14天回访应用的比例是多少：

这是最保守的留存率计算方法，会得出较低的留存率。

2. 无限留存率

无限留存率会告诉你有多少用户在特定日期或之后回访。例如，在特定日期加入的所有新用户在14天后(不一定是第14天)使用该产品的用户百分比。

如果你的目标是将留存率与用户流失率相匹配，这便是可行的方法。第6个月的无限留存率将为你提供第6个月后回访的用户百分比。

那么应该使用哪种方法呢？两者都是正确的，但结果是完全不同的留存数据：

我最喜欢的计算方法是无限留存率，因为(1)我希望我的kpi是相互关联、成比例的和相关的，(2)无限留存率是流失率的反比，所以它给了我另一种验证和测试数据的方法，增加了我报告的可信度(流失率越高，留存率越低，反之亦然)。

但你应该选择最适合你分析目标和用户自然行为的方法：

如果你的用户定期使用产品(例如每天早上记录食物，记录锻炼，或每天听播客)，使用x天留存率。
如果你的kpi针对特定时间范围(如30天试用、28天活动、7天再订阅者)，那么你可能会使用x天方法只统计那些在一段时间内回访产品的用户。
如果你不指望用户每天/每周/每月都会回访，并且用户参与模式比较混乱，那就使用无限计算方法。
x日留存率更适合于衡量新用户渠道或市场营销活动等短期分析。
无限留存率对于衡量长期用户行为更有用，特别是在你想将用户分组(6M、9M、1年、2年)的情况下。

总的来说，分析的一条经验法则是，如果你的产品是SaaS，你可能会受到特定的时间限制(付费订阅长度、试用长度等)。因此，我们建议你遵循x日留存率计算法。如果你不是在SaaS领域，而是负责B2C、消费者交易或社交业务，那么你可以更灵活一些，采用无限留存法。

步骤4：BI应用程序与SQL的留存率报告

1. 通过产品分析工具获得留存率

为了计算留存率，Amplitude、Mixpanel、Kissmetrics、Google Analytics、Adobe Analytics等工具通过SDK与客户端(浏览器，应用程序，设备)集成，可以向你报告用户和应用程序活动的客户端数据。虽然这些工具中有一些可以用于报告留存率，但其他一些还没有达到这个水平。

通常情况下，为了更改订阅或购买，用户需要从应用程序转到应用商店(Apple store、Google Play、Stripe、PayPal等)来激活试用、完成支付、取消或续订等。这就是为什么支付数据可能无法用于应用(客户端)分析的原因。因此，你将无法立即在Amplitude或Mixpanel中访问这些数据。所以对于SaaS产品(基于DAPU或DAC报告留存率的产品)，你可能无法在产品分析工具中复制留存率，因为它们没有支付数据。

这是可以解决的。这里的常见解决方案是通过Segment或数据管道将支付数据从数据库加载到产品分析工具中(假设你已经从Stripe/Apple/PayPal等支付供应商那里收到了这些数据)。但如果你为一家小型初创公司工作，并处于建立报告和分析的早期阶段，情况很可能会有不同。

2. 通过SQL获得留存率

这是分析人员在SQL面试中常见的问题之一，而且往往是第一个要处理的项目。这是一个多步骤的流程，需要对业务目标的深入理解、灵活的方法和数据直觉。

通常情况下，这需要对底层表格进行一些处理，以将数据转换为适当的格式和结构。DAU、流失率、LTV等都是如此。

首先，创建对话、用户或活动表，作为以后计算KPI的基础。该表应该包含正确的用户活动时间戳、活动ID、用户ID、属性和度量值。在测试完新表后，你就可以为留存率、DAU或其他内容创建下游视图了。

当使用SQL复制留存率时，很容易失控并使方法过于复杂。请遵循以下步骤，以保持跟踪并获得正确的留存逻辑：

步骤1：获取用户的第一次（初始）操作——通常是注册或首次购买
步骤2：基于你的活跃定义获取注册或购买后的用户活动
步骤3：获取初始和连续用户操作之间的总时间
步骤4：根据需要将总时间转换为天/周/月
步骤5：根据上一步的总留存时间将用户分组
步骤6：根据用户的初始操作时间(注册或首次购买)对用户进行描述和排序

根据底层数据和表格结构的不同，可以通过简单的SELECT语句(比如SELECT * FROM ready_to_use_retention_table)或其他快速方式完成这些步骤，比如

SELECT snapshot_date,

start_date,

n_period,

COUNT(user_id) AS n_users

FROM subscriptions

GROUP BY snapshot_date, start_date, n_month

或者通过多个子查询、自连接、窗口函数或上述所有方法的组合。这就是为什么这是一个很好的面试问题——因为根据特定输入值和业务类型/案例，你的输出SQL将完全不同。

无论SQL的复杂程度如何，你输出的原始数据可能看起来像这样：

这是分组留存率的底层表结构：

下面是一个复制上述分组表的SQL样本：

WITH new_user_activity AS (

SELECT a.*

FROM activity a

JOIN signups s

ON s.user_id = a.user_id

AND s.signup_date = a.activity_date -- if initial user signup counts as activity. If not, either disregard or s.signup_date = a.activity_date

)

, active_user_count AS (

SELECT activity_date

, COUNT(DISTINCT user_id) AS users_count

FROM new_user_activity

GROUP BY activity_date

)

-- for daily retention：

SELECT n.signup_date AS signup_date,

DATEDIFF('DAU', n.signup_date, a.activity_date) AS period,

MAX(c.users_count) AS new_users,

COUNT(DISTINCT a.user_id) AS retained_users,

COUNT(DISTINCT a.user_id) / MAX(c.users_count)：：float AS retention

FROM new_user_activity n

LEFT JOIN activity a

ON n.user_id = a.user_id

AND n.signup_date < a.activity_date

AND (n.signup_date + interval '30 days') >= a.activity_date -- retention data for the next 30 days after signup

LEFT JOIN active_user_count c

ON n.signup_date = c.activity_date

GROUP BY 1, 2

第5步：留存率可视化

SQL之后，下一步就是将你的数据可视化。

有很多方法可以可视化留存率报告。我不会在这里深入探讨，因为最常见的数据可视化工具(Tableau、Power BI)需要一定专业知识，Mode和Sisence也是一样。你可以利用这些工具的群组图表，并且每种格式都可以按照(1)时间段(如每日、每月、每年)和(2)用户细分(如试用用户、再订阅用户、高级用户)进行分组，从而让你的分析变得更加强大。

在Excel中，你可以利用数据透视表复制相同的图表。在透视表编辑器中，你可以将初始活动日期拖到行中，然后将留存期间拖到列中。对于组合图表，我建议你应用一个色标(单击条件格式，选择色标，然后选择一个颜色)。如果没有色标，分组读起来会很困难。

如果你正在寻找群组留存图的快速模板，我建议你使用Christoph Janz的群组分析模板。如果你有新客户和他们的活动日期数据，你可以将其插入到他的模版中，以得到留存率的计算结果。

关于留存率可视化格式，我经常看到的是折线图或堆叠折线图。像Amplitude和Mixpanel这样的产品分析工具默认会创建类似于下面这样的折线图：

对于KPI仪表盘来说，最好有一个包含留存率数据的简单汇总表：

报告留存率的最佳做法是分组：

这张图表显示了每周有多少用户注册，以及接下来每周有多少用户留存。它只过滤了“新用户”。此外，你还可以将留存率报告细分为活跃用户、流失用户、不活跃用户和重新激活用户。这可以帮助你定位你的超级用户，并了解是什么让他们坚持下去。预计这些群组的留存率会有很大的不同。所以你应该尽可能地将用户划分为不同的行为类型。就像我所说的，你创建多个用户群组的能力与你的分析设置的好坏是线性相关的。

在拥有更先进数据栈的公司中，产品团队能够定位、测试、迭代并只面向特定用户群发布新功能。对这些群体进行清晰而精确的分组也说明了分析领域的成熟。不过，这需要时间来实现。