如何在移动应用中进行A/B测试：第一部分

关于A/B测试的工作详解，由伊利亚·图门科（Ilya Tumenco），AppQuantum的出版总监，以及奥列格·谢梅诺夫（Oleg Semenov），Appbooster的市场负责人进行分享。

伊利亚·图门科和奥列格·谢梅诺夫

此材料由AppQuantum基于同名网络研讨会准备。

A/B测试：是什么，为什么需要

A/B测试（也称为分裂测试）是一种比较同一元素两个状态的方法。它们有助于提高项目的转化率和收益。评估其效果的关键指标是收入（revenue）。测试的元素可以是任何东西：订阅界面、引导流程、广告创意等。

出现的历史

A/B测试在网站兴起的时代开始流行，当时网站所有者追求提高转化率。他们开始更改页面元素，以使其对访客更具吸引力。但当时进行测试要简单得多。

过程如下：插入Google Optimize标签，然后在可视化编辑器中设置要测试的元素。接着启动实验。用户随机分为两组，一组看到元素的旧版本，另一组看到修改后的版本。

随着时间的推移，A/B测试变得越来越复杂、越来越完善。随着移动市场的发展，它们被广泛应用于应用程序的元素。然而，大多数开发者避免进行A/B测试，因为人们普遍认为进行测试既耗时又昂贵且繁琐。

让我们探讨一下拒绝进行A/B测试的开发者常见的反对意见，尽管他们尚未尝试过。

处理异议

开发者在没有测试的情况下就知道如何改善应用

这是我们最常遇到的误解。开发者认为自己在应用开发和设计方面已经有足够的经验。他们相信可以自己修复所有的弱点，然后指标就会立即上升。然而，即使依靠经验，有时也无法做出正确的结论和决策。即使在规律中，也会有例外——没有通用的解决方案。

可以简单地比较“之前”和“之后”

开发者相信可以逐个进行更改，并比较结果。然而，往往没有考虑到：更改的效果不是立即显现的，这需要时间。例如，可能需要一周。但在这期间，很多事情可能会发生变化。指标不仅受您所做的更改影响，还受到新竞争对手、投入策略等的影响。

为了确保没有任何因素影响结果的准确性，两个元素需要同时进行比较。

A/B测试—这既耗时又昂贵

这是一个合理的观点。在移动游戏中，通常测试的是深度的产品组件。仅靠一个测试是行不通的：要找到最佳解决方案，需要耐心和资金。

尽管如此，这一切都是值得的。

我们曾与一个应用程序合作，该程序的货币化部分建立在订阅上。大约六个月它都是在亏损中运行（在高峰期亏损达到30万美元）。问题出在引导流程和付费墙。我们进行了50多次测试，找到了符合我们指标的合适方案。之后，该应用程序开始盈利，收回了投资，现在每月稳定收入数十万美元。没有A/B测试，就不会有这样的结果。

因此，针对这个反对的唯一诚实回答是，测试确实需要时间和金钱：是的，确实如此。测试的费用必须在预算中从一开始就考虑进去。

制定正确的假设

有效A/B测试的准备阶段是制定正确的假设。每个假设的制定都是为了影响特定的指标。

假设我们想要提高利润，并为此着眼于留存率（retention rate）指标。我们制定假设，进行大量测试，再次制定假设，而指标却维持在同一水平。在这种情况下，通常称该指标为非弹性指标。

在团队内部形成期待：假设应当影响什么？它将改变什么？研究用户行为，了解产品特点，确定期望增长。所有这些都将有助于制定确实影响指标的假设。这将节省时间、精力和测试费用。在下一部分中，我们将介绍如何更加有效地进行低成本测试。

廉价A/B测试的秘密

1. 统计显著性

如果了解简单的窍门——使用统计显著性工具，A/B测试可以变得更便宜。

例如，我们正在测试付费墙。为此，我们仅选择到达付费墙的用户群体——其它用户对我们来说是不相关的。结果我们得到2000个用户，这些用户平均分成两个组（我们有两个测试元素）。A组有140个转化，B组有160个。

两个方案之间的差异很小。因此，不清楚我们所做的更改到底有多有效。此时，统计显著性就派上用场：它能确定有多少用户受到了更改的影响。使用专门的计算器可以帮助进行计算，下面您可以找到相关链接。

计算器将正在进行的测试数字化，让我们了解测试的进展情况。计算时，它们使用两种方法中的一种：经典频率方法和贝叶斯方法。第一种方法确定最佳测试选项，而第二种则量化其中一个选项比其他选项更好的可能性。

让我们尝试通过一种常用的Mindbox计算器来解读我们测试的结果。它依赖于经典频率方法。

在这个例子中，1000个用户的结果几乎没有差异——无法得出明确的结论。我们再通过AB Testguide计算器（采用贝叶斯方法）进行同样的输入。

我们看到它给出了明确的答案：B选项在90%的情况下比其它选项更成功。使用贝叶斯方法可以节省时间，减少测试的迭代次数，从而节省开支。重要的是，我们不会在结果上反复调用100个计算器，直到获得满足的最终结果。在这两种情况下，结果是相同的，而数据的解释却不同。

2. 激进的测试

在最低投入下达到测试的最大效率，同样可以通过激进的测试来实现，这种测试的选项与控制选项的差异尽可能大。

当产品团队刚开始建立测试工作流程时，测试通常从与当前选项最接近的选项开始。如果我们测试的报价价格是4美元，通常会测试3美元和5美元。因此这样做是不明智的。

我们认为进行测试应该更加激进。控制价是4美元？那么可以设置尽可能远离它的值——1美元和10美元。

激进A/B测试的优势

可有效比较。激进测试会产生显著的正面或负面效果，因此我们更容易评估变化的效果。即使测试不成功，我们也会了解接下来该朝哪个方向努力。犹豫的测试会给人一种找到最佳方案的错觉。5美元的选项败给了4美元的选项——这使得人们感到，既然靠近控制选项的选项已经失败了，那么更多较高的价格选项也应该不会成功。根据我们的经验，这种想法是错误的。
可以节省开支。激进测试的迭代数虽然更多，但成本更低，并且在较少的转化量上达到了所需的显著性。我们需要更少的数据就能得出可靠的结论。
降低波动性。测试选项之间越接近，偶然性发生的可能性就越高。
意外的机会。曾经我们在AppQuantum测试了非常高的报价——25美元。我们整个团队及合作开发者都坚信这太贵了，没人会以此价格购买。而竞争者提供类似内容的报价最多也才15美元。然而，我们的选项最终却获胜了。意外的好事时有发生！

3. 反向测试

验证假设的快速且便宜的方法是进行反向测试。它的本质是，与其改善元素，不如大幅度恶化它，或直接将其排除。在绝大多数情况下，这样做既简单又快速，因为开发者在制作良好解决方案时必须投入资金、时间和精力，而改善未必能提升指标。

反向测试的示例

根据用户的反馈，开发者意识到应用程序中的教程存在问题。他坚信只要修正错误，指标就会提升。如果改善能提高指标，那么降低指标是否会造成相反效果？既然如此，那么可以恶化教程并观察指标的变化。只有在开发者确认更改是有意义的之后，才可以投入精力、时间和资金来改善元素。

但是，这并不意味着这样的恶化元素一定要设计得很差。有时，中等或差的实现质量比任何实现都要差。在这种情况下，甚至反向测试也可能会提供积极的结果。

反向测试的适用领域：

叙述和本地化质量（例外：叙事驱动类型和领域）；
用户界面（例外：报价和付费墙）；
用户体验（在这种情况下，反向测试影响应用的活跃度和反馈）；
教程和引导（对此做出的变更确实会产生效果，但通常没有预期的那么显著）。

4. 测试中多次更改

一次性测试多个更改通常效果不佳。如果8个元素中的结果是显而易见的，那么测试10个元素就没有意义。然而，规则总有例外：有时可以为了节省测试时间而一次测试多个选项。

在以下情况下可以同时进行多次更改：

我们知道这些更改只有综合在一起才有效；
我们确信其中没有任何一个会产生负面效果；
一次性测试多个生产成本低的元素会比较简单。

***

我们已经搞清楚了如何进行廉价测试。现在，我们将尝试理解如何最大限度准确地计算测试结果，以缩短测试所需时间和精力。

A/B测试中的单元经济学

在寻找您产品漏斗中最有前景的位置时，建议使用单元经济学的方法。它有助于确定基于单个商品或客户收入的商业模式的盈利能力。在移动应用中，收入来自应用销售或订阅，或广告收入。

图示为一个真实应用示例：4个假设以及使用单元经济学计算的利润。我们简化了中间指标，只保留了主要指标：采购用户数、客户转化率、平均价格、每位付费用户的购买次数、用户成本和收入流的利润。

假设1

我们想提高客户的转化率。增加0.5%将带来69,477卢布的收益。

假设2

我们想增加重复购买。20个客户进行24次购买，而我们需要让这20个客户进行31次购买。聚焦于具体的指标以及清晰的任务表述有助于界定可能的假设。我们应该怎么做？也许会进行推送活动或减少玩家的生命数。

最终结果是——利润已达到75,654卢布。

假设3

增加采购：我们将采购的用户数量翻倍。结果是——37,648卢布。显然，相比于第一个以及当前的利润，这种办法收益要少得多。

假设4

在学习单元经济学的某个阶段，团队偶然想到做一些完全不可思议的事情。比如，创造一个超级功能，能提高好几个指标，并带来496,127卢布。乍一看，问题在于它的开发将花费3个月。然而，还有其他问题，接下来我们将讨论。

大型功能的MVP

MVP（最小可行产品）是具备最少功能的应用测试版本。MVP用于测试假设和验证产品的可行性。

大型功能并不是提高指标的最有效解决方案。产品可能会变得过于复杂，从而稀释其核心价值。花费时间、努力和金钱在功能的开发上，结果却可能发现应用的问题并不在于缺少这个功能。

假设我们非常想做一个大型功能。但我们需要保证它确实是必要的。要如何获得这一保证？我们来分析一下。

行动算法：

识别出最重要的奖金功能和风险功能；
回答它为什么会有效，它为什么可能会失败；
评估这项奖金是否值得承担可能的风险；
确定实现的最低要求，以获得此奖金；
在测试中形式化评估奖金和风险；
最终，不仅与控制组进行比较，还与其他替代方案进行比较。

大型功能的MVP：Doorman Story案例

以Doorman Story应用程序为例，该程序由AppQuantum发布。它是一个时间管理器，玩家在其中发展自己的酒店。酒店工作人员必须在有限的时间内为顾客服务。每个游戏机制都有计时器和操作顺序。

我们考虑：如果在其他游戏中对用户免费开放的机制，我们改为销售，结果会如何？这是一个有利的获利点：不需要制作新内容，但现在可以销售现有内容。为了测试这一假设，我们需要改变关卡的平衡，重新设计机制的获取方式，思考其开放界面的设计。

与Red Machine（Doorman Story的开发工作室）合作，我们提出了最简化的超级功能方案。创建了一种不影响整体游戏平衡，仅在一个关卡组合中出现的收费自动贩卖机的新颖游戏机制。一个机制，一个艺术——在此过程中，应用的经济未被打乱。

这个例子契合大型功能的MVP方法：明确主要的奖金和风险。奖金是我们能够销售已有的内容，而无须额外花费。风险是用户可能会因公开内容不完备，需购买部分内容而感到被拒。这可能使用户离开该产品。

我们确立了对该功能的最大和最小预期，并预计其实现将反映我们的理念。问自己：我们的工作是否具有示范性？我们能否预测效果？能否从实验中得出结论？

同时，我们可以随时调整付费墙的严格性，观察用户是否会继续游戏。若仅购买一次，我们将无法准确预测会有多少次购买。但我们可以预测付费墙的表现。

为了确保这一机制确实会被购买，我们必须将用户置于无法不买的条件中。这就是我们为何提供付费墙的原因。这帮助我们理解，出租口香糖的自动贩卖机对于玩家的价值。这种风险得到了更好的量化。如果人们在看到低价购买机会时离开，但却不进行购买——这意味着很可能他们不喜欢游戏玩法。而如果他们在付费墙时就离开——则是因为对价格的不满。

我们确定了分工具体分析的指标，以及大致的预期。制定了我们即将实施该功能的三个假设。我们构思这些功能的MVP，最多两周内完成。测试这些功能，结果出乎意料：测试中获胜的功能并非我们团队和合作伙伴中的任何一人所期望。最简化的机制最终成了赢家。事实上，最佳选项并没有被视为最佳。

如果我们仅依靠直觉而不进行测试，那么结果可能会不如预期。A/B测试使得我们在最短的时间内找到了最佳方案。

评估测试风险

进行测试时，我们必须评估可能的风险：理解每个组中可能出现的“失效”情况。

比如在用户转化增长的情况下，应用内购买数量却下降。这种情况是很多用户经过引导流程后，却在短时间内离开应用而没有付费。这表明用户对于应用的参与度较低。尽管用户数量实际上可能增加了，但我们的收入却下降了。

或者，恰恰相反，我们正在测试广告观看次数。由于每个屏幕上都有广告，用户在第二次会话中便删除应用，并且不再返回。因此，重要的是要寻找反向指标，以便在测试过程中也可以跟踪。

如果假设的判断是某种因素可能会影响用户的体验——最好的做法是关注进度和参与度的转化率。因为它直接影响我们所担心的内容。这在付费墙测试中也是适用的。

清洗测试结果

接下来是对测试结果的解释。为了对其进行客观计算，我们首先必须对受众进行细分。

细分的选项：

按人口统计（通常是国家，有时是性别+年龄。这个因素会改变流量获取渠道）；
按支付用户（如果数据足够，多个细分组）；
按新用户和老用户（如果可能，建议只测试新用户）；
按平台和来源。

重要的是要过滤掉未被更改所影响的用户。如果我们测试的元素是针对达到7级的用户，很明显，我们需要考虑未达到该水平的用户，否则将得到不准确的指标。同时，我们需要排除所有未通过漏斗的用户及任何异常数据。

移动应用程序的测试问题

在移动开发中，测试比在网页更复杂、成本更高且耗时更长。问题始于应用商店的构建验证阶段。要添加更改，必须重新上传构建——因此，审查需要花费大量时间。除此之外，还有时间和金钱成本：包括购买流量、设计、控制和处理测试。

应用程序的最新版本也是一个障碍。并非所有用户都可以拥有其更新版本——并且不是所有的用户都能参与测试。

A/B测试还有一个问题被称为“偷看问题”（peeking problem）——意思是产品团队过早得出结论并提前结束测试。

比如，开发者有一个偏爱的版本，在他看来，它应该获胜。为验证该假设，他决定使用统计显著性计算理论上的最佳选项。通过计算他看到他的首选版本确实有高获胜机率。因此，他仅基于这一信息就提前结束了测试，以缩短测试的时间和成本。尽管从技术上讲，测试并尚未结束，因为仍未所有用户通过测试元素。

这一决定往往是过于仓促的。是的，我们可以预测测试的大致结果，但并非总是能够真正有效。若开发人员将整个目标群体通过测试，则结果可能会不同。因此，虽然可以“偷看”测试结果，但必须始终等待所有用户通过测试。

还需考虑人口统计因素：不同国家可能胜出的版本不同。因此，某地区的最佳选项未必在其他地区也能获胜。

除了上述问题外，还有一个关键问题是：现实的改变。因此，曾经获胜的选项，今天未必依然会胜出。

贝叶斯多臂强盗

接下来我们介绍当前最方便、最新和快速的A/B测试：即所谓的“贝叶斯多臂强盗”。它是不断更新的测试，基于变体的效果实时优化。最有效的组会获得最大的比例。简单来说，这就是自我优化。

正如我们在图中看到的，如果A选项胜出，第二天我们就增加给该选项的用户比例。如果第三天它再次获胜，继续增加其份额。最终，赢家组的比例将达到100%。

贝叶斯多臂强盗适应时间和变化。它节省了手动识别和分析细分的时间。这有助于避免偷看问题，同时节省控制成本。最重要的是：这是自动生成的新测试，这在任何产品业务中都是昂贵和复杂的。

是的，测试需要大量的手动工作。但如果有一个机制能自动识别好的和差的选项，那么对自动测试将大有裨益。

如何判断自己是否准备好进行A/B测试

如果您具备以下条件，就表示您已准备好进行A/B测试：

在应用中嵌入了分析和跟踪功能；
经济汇总（您了解每个用户的成本，并能进行规模化）；
拥有系统性地检验假设的资源。

总结：如果知道如何执行，A/B测试可以快速、便宜且轻松地进行。而且，这一过程需要系统化。问题并不在于只进行一次测试并永远忘记它。只有通过一系列的变更，您才能获得优质的效果。