时间: 2021-07-30 11:42:12 人气: 36 评论: 0
如果你在一家SaaS公司工作，你可能自诩对海盗指标有很好的理解。你可能可以倒背如流——获取，激活，保留，推荐和收入。你甚至可能记得它们的出处，但是你对这些指标的理解到底有多深呢？你知道你忽视了哪个指标，或者哪个指标花费你最多成本呢？
大多数规模小、尚在成长中的SaaS公司首先都注重获取用户，并将他们带进漏斗中。然后，他们致力于保留这些用户，把他们转换成忠诚的长期用户。这很好。
但是很多公司忽略了McClure的AARRR模型中第二个A——激活的重要性。
帮助新用户达到他们的第一个顿悟时刻，并且尽早找到产品的成功之处，这些对下游具有重大的影响。为了理解如何最好地优化用户体验，你首先需要准确地理解“激活”如何影响着产品的成长。
让我们短暂地温习一下基础知识：什么是海盗指标？
海盗指标是SaaS一系列指标的戏称，它构成了SaaS增长的5步框架，最先由天使投资人兼500Startups（硅谷创投机构）创始人DavidMcClure提出。
这个框架之所以如此强大的一部分原因是因为它鼓励产品人**越一些虚荣指标：
“McClure让人们摆脱虚荣：有多少人在看我的页面，有多少人深入考虑了整个用户生命周期，最有效的分解方式什么，以及，如何优化每个部分？这改变了所有产品创始人思考业务的方式。”
— 数据分析公司 Amplitude产品营销经理Archana Madhavan
在我们的模型中，我们将海盗指标（也称作AARRR指标）定义为：
原版海盗指标的顺序类似于免费增值收入模式 — McClure参考免费增值应用程序的模式，把收入放在保留和推荐后面。
原版海盗指标
但是，免费支付收入模式正在变得越来越流行，企业用这个模式提供免费试用机**，然后将用户转化为付费用户。订阅SaaS用户经常是通过某种免费计划或者免费试用获得的。然后，当这些用户注册付费订阅计划变成付费用户的时候，现金流就来了。
在我们的模型中，我们将收入放在激活后面，来体现这个过程。
我们的模型依旧是AARRR
激活，或者用户实现产品承诺价值的那一刻，反映了你投资于获取用户所付成本的效率。
激活率越高意味着效率越高。激活也直接决定着收入，因为你需要能够向免费试用用户展示产品的价值，以此说服他们掏钱包。
简而言之，激活是衡量和优化无比重要的一个指标。
对于基于订阅的业务，百分比优化的影响是随时间复合增长的。例如，同样是提升10%的用户留存率，拥有10,000个用户，比拥有100个用户，对用户留存的影响更大。
为了证明每个海盗指标的持续影响，我们建立了一个计算模型，模拟12个月后每个指标对MRR（月度经常性收入）的影响。
我们选择计算MRR而不是ARR（年度经常性收入）是因为，对于初创公司和成长型企业，微小的改变都可以带来很大的不同，并且，MRR对于保持业务活动中一定频率的增量变化非常有用。
这是我们的计算模型：
为了模拟每个指标对MRR的影响，首先让我们计算12个月后，当每个海盗指标都处于行业基准水平时，MRR**是怎样：
然后，逐个地，我们把每个海盗指标调高25%，并计算12个月后MRR的变化。再次强调，那是：
参考基准与参考基准提升25％之后，两者的收入差异百分比。
让我们联合使用这些假设的数字，模拟这些不同的指标**如何影响你的利润。
此模型旨在让你对每个海盗指标对利润产生的直接影响形成更深刻的概念。
也就是说，我们的模型是一个假设的，规模虽小但正在增长的SaaS公司的简化表示。
在这个模型中，我们想象我们可以控制所有其他因素，并逐个隔离每个海盗指标。当然，在一家真实公司中，这些改变不**凭空产生，并且**互相影响。
同样值得注意的是，每个指标的相对重要性都**随着你的行业位置，你的产品，你的增长阶段而变化。例如，增长同样比率的保留率，拥有庞大用户基数的用户群对这一变动产生的影响**比用户基数小的用户群产生的影响更大。因为我们用百分比变化作为等权重，每个指标间的相对重要性不是绝对的。
我们强烈建议放入你自己的业务指标作为基准，去准确地计算每个指标对于 SaaS公司增长的重要程度。
让我们仔细看看这些指标，这样你就可以开始使用我们的模型了。
激活指标包括从网页浏览到销售合格潜在用户（SQLs）的所有内容。在我们的模型中，“获取”衡量着免费试用的用户数量。作为我们“获取”的参考值，假设有5000个免费试用者注册。你可以使用这个数字，如果你不知道每月免费订阅试用数量，你也可以输入自定义数字，只是作为估计而已。
根据Groove的CEO兼创始人AlexTurnbull对SaaS公司的研究，平均有8.4%的流量转化为试用者。
用我们的估计值 — 5000次免费试用注册，我们将计算一年后“获取”参数提高25%对12个月的MRR有何影响：
正如你所看到，提高获取25%，能带来25%的MRR增长。这些增长是合理且成正比的，因为获取决定着用户漏斗的大小。
因此，如果你有十倍的“获取”，你将得到十倍的MRR。这非常地无趣。但是不用担心，其他指标对MRR的影响更大。
当用户首次达到你承诺的价值时，激活就发生了。它表示已被激活的用户占总获取用户的百分比。
作为激活率的基准，我们基于移动应用程序用户登录的黯淡现实，以及我们帮助企业提升他们用户的亲身经验，我们将这个数值定为30%。
你可以用自己的数据作为参数，或者输入每月平均激活用户比率。激活对于不同产品的影响，基于产品的“顿悟时刻”是很不同的。要确保你精准定义了是什么决定着激活一个用户，那样，你就明白你该如何处理正在查看的数据！
激活是这么影响MRR的：
提升激活25%，能提升一年后34.3%的MRR。事实证明，你忽视的指标可以给你带来**额回报。
在我们的免费付费模式中，激活直接决定着你的收入。这使得激活成为一个重要的上游指标，不仅影响着你能从新用户那里获取的收入，同样也影响着你能从现有用户那里获得多少经常性收入。
请记住，在我们的简易模型中，我们没有计算每增加一个指标，对其他指标的影响。现实中，增加激活很有可能导致留存率和推荐率的上升，从而使得MRR增加更多。
每个产品的激活成因都不同。为了真正理解什么引领着用户的第一个“顿悟时刻”，你需要仔细地学习用户体验地图，与用户沟通，并围绕用户实施跟踪。
激活示例：当用户首次完成Uber或者Lyft乘车体验，当一个消费者从Instacart收到商品快递，当一个新的Gmail用户发送首封邮件时，等等。
在我们的模型中，收入代表平均合同价值，即用户每月支付的费用。
为了简单起见，我们为SMBSaaS公司模拟了一份中等规模的订阅合同，把收入设置为100美元。在你们自己的计算中，你可以用自己的平均合同价值输入收入参数中。
然后我们可以计算收入对MRR的影响：
收入增加25%，对应MRR增加25% 。
在我们的模型中，收入和获取的功能类似。两个指标都是固定值，而不像其他指标是百分比值。他们对利润有着近似的一对一影响。获取根据用户数量决定用户漏斗的大小，收入根据美元设置用户漏斗尺寸。
留存率衡量每月**持续支付产品费用的用户数量。保留通常比激活的百分比数值更大，因为要用户保留习惯比让他们开始习惯更容易。
根据TomaszTunguz（风险投资人）的观测值和ClementVouillon（风险投资人）的确认，我们将SMB公司每个月的留存率参数设置为97%。如果你有自己公司的每月消费者留存数据，你可以在计算模型中作为参数输入。
让我们来计算留存率提高25%对MRR的影响：
保留率对MRR的影响与激活对MRR的影响最接近 — 他们都是基于百分比的瓶颈。他们都可以扩大或者缩小漏斗的尺寸。
在我们的模型中，用户付费的时候就是激活发生的时候。如果是由保留群组中的用户支付的，激活对收入的影响**更小。如果你的业务使用免费付费模型，你可以使用自己的数据，看看提升激活和保留率对收入影响的相对差异。
运用同期群分析，深入研究留存率和流失率，找到发生用户流失的原因。基于你的商业模型，你可能希望能测量出每天的流失率。但是对于那些不需要每日使用的产品，月留存率和月流失率更有用。
推荐衡量的是现有用户成功将新用户带入用户漏斗的百分比。因此，推荐衡量的是：已有用户占总用户基础的百分比，而不仅仅是新用户。
我们基于推荐参数，做了一些计算，最终决定对于成功的SaaS公司，22%是一个良好的推荐率参数值。你始终可以用已有的数据代替这个参数。
让我们计算提高25%的推荐率参数所带来的影响：
正如你所看到，提升留存率25%只能带来7.4%的MRR增长。对于那些满脑子想着增长业务并坚信病毒式增长是圣杯的人来说，这个数字可能具有一定的冲击力。
在我们的模型中，25%激活提升带来的MRR增长：
在我们的简易模型中这些数值是独立于参数的。但是当比较每个海盗指标对MRR的影响的时候，激活对利润的下游影响是非常明显的。如果你仍然忽视SaaS指标，你将错失未开发的收入和增长机**。
既然你已明白这些指标的重要性，你该做些什么呢？你如何提高激活率，获得增长呢？
对于新手，你可以从另一个角度看待用户。问问自己：这些初次用户体验是否将新用户引领到他们的“顿悟时刻”。我们是否能通过更好的app内消息或者更加简化的登录流程加速他们获得“顿悟时刻”（最后一个问题的回答几乎总是“是的”）。
你可以通过这些方法，使用app内消息传递，提升海盗指标：
**越海盗指标计算模型，处理这些数字。为了实现最大提升，找到自己产品中需要改善的那一部分用户体验。然后优化它！
作者：BenWinter
链接：https://www.appcues.com/blog/pirate-metric-saas-growth
翻译：「即能」小程序，公众号：「即能学习」
本文由 @即能 翻译发布于人人都是产品经理，未经许可，禁止转载
题图来自Unsplash，基于CC0协议
