详细讲解 A/B 测试关键步骤，快来检查下还有哪些疏漏的知识点

为使每个版本的样本群体具有代表性，A/B 测试平台随机让用户使用版本 A 或版本 B，或者将其排除在测试之外。测试平台须要确保用户在整个测试周期中体验一致 (总是 A 或总是 B)，并向分析平台提供额外元数据以确定对指标的影响。一旦完成指标分析并确定最佳版本，您可以通过 A/B 测试平台向所有用户逐步推广获胜版本。

譬如，您建立假设 “与应用中的标签相比， 底部导航能更好地提高用户参与度”。为此，您可以设计一个 A/B 测试来比较标签 (版本 A) 和底部导航 (版本 B)。接着，测试平台会生成一个用户基础样本，并将样本内用户随机分配使用版本 A 或版本 B， 同时保证每位用户在测试期间将一直使用被分配到的版本。在测试结束时，您可比较两个版本的用户参与度，观察版本 B 的参与度是否显著高于版本 A。若版本 B 的数值更高，这说明数据支持您选用底部导航设计，并向所有用户推广这一版本。

△ 左边 :  版本 A, 标签；右边 :  版本 B, 底部导航

关于 Google Play 管理中心中商店资讯实验的说明

Google Play 管理中心还支持对应用的商店资讯进行 A/B 测试，本文对此不加赘述。商店资讯实验能让您测试不同的图标、功能图、推广视频、简短描述和详细描述，观察应用的安装量是否随之增加。商店资讯实验侧重提高用户转换率，而本文的余下部分则着重讨论应用内 A/B 测试对安装后指标的影响，如用户存留率，用户参与度和应用内购买营收。

在这篇文章中，我将介绍应用内 A/B 测试的五个关键步骤：

1. 建立假设

2. 整合 A/B 测试平台

3. 测试假设

4. 分析并得出结论

5. 采取措施

此外，本文还会稍微谈一下您可能会用到的高级技巧。

Step 1 – 建立假设

要测试什么 (A 是什么？B 又是什么？等等)

下面的表格列举了大致场景，可以帮助您如何决定选择测试版本。以我们假设的导航实验为例：

△ “从测试中排除” 这一列表示不参与测试的用户；他们的行为不计于测试结果。详情请参照下文 “测试谁“ 板块。

根据假设测量指标的不同，可选择场景 2 或场景 3。如果测量指标仅与新功能相关，请选择场景 2 (例如，若新功能是应用内购买，那么只有新功能实现后，“应用内购买营收”这项指标才有意义)。如果假设涉及的测量项，在添加新功能之前，也具有意义，请选择场景 3 (例如，若新功能是 “最爱” 机制，而测量项是用户参与度)。

注意： 在下文到 “采取行动” 部分前，为简洁起见，我将使用情景 1 为例。 相同的方法亦适用于情景 2 和情景 3，并且我会以 “现有版本” 和 “新版本” 代替 “新 1 版本” 和 “新 2 版本”。

测试谁？

若被观察行为受到假设以外的某些因素影响 (如，已知行为根据国家不同而发生变化，而假设仅仅考虑全球收入影响)，请将该因素设定为唯一值 (单一国家) 或者使用全体人口 (所有国家) 的代表性样本。

具有代表性的控制样本大小也可设定为总人口的百分比。例如，测试样本为总人口的 10% —— 版本 A 和版本 B 各占 5% —— 剩余 90% 人口则排除在测试外。即是说，这 90% 的人或使用现有功能，或完全看不到任何新功能，且他们的行为不被计入测试指标内。

测试多久？

最长时间：用户的行为通常会随着时间发生变化，一天中的某个时段，一周中的某一天，某个月，某个季节等等。为了体现这些差异，您会想要在统计意义和业务需求之间找到某种平衡 (您的业务可能无法等到您拥有足够的数据完成统计)。如果知道某项特定指标会在短时间内发生变化 —— 例如一天或者一周中的某一天 —— 那就尝试让测试涵盖这整个时期。对于用时较长的指标，只测试几周可能会更合适一点，然后根据已知的随时间变化结果进行相应推断。

最短时间：须要测试足够长的时间，以便获取足够数据使得结果具有统计意义。这通常意味着受测用户至少达到 1000 人。不过，能否取得明显的测试结取决于从假设推导出来的指标的分布情况。那么如何在合理时间内完成测试呢？您可以通过估计有多少用户能够在所需的时间段内进行测试，然后从中选择一定比例的用户作为测试者，这样您的测试就能在这段时间内达到统计意义。一些 A/B 测试平台能自动管理这些操作，同时也可以提高您的测试采样率，让您的测试更快地达到统计意义。

Step 2 – 集成 A/B 测试平台

目前市面上已经有几种 A/B 测试平台，它们或是独立的产品，或是某更大分析平台 (如 Firebase 远程配置及分析) 的某一组件功能。通过客户端库，平台会向应用发送一组配置指令。由于应用不知道为什么要返回某个参数，因而无法获知这是测试的哪个部分，甚至不知道这是否属于测试的一部分。客户端仅仅是按照配置指令进行相应配置。此外，平台不关心返回到客户端的参数值的意义；而是由客户端自行解释。在最简单的情况下，返回的参数可以是简单的键值，对于控制是否启用给定功能，如果须要启用，则激活对应的版本。

在更复杂的情况下，如须要进行大量的远程应用配置，应用会将参数发送到 A/B 测试平台，测试平台会跟据这些参数对测试进行更为精细的调整。例如，如果假设只涉及具有 xxxhdpi 屏幕密度的设备，那么应用须要将其屏幕密度发送到 A/B 测试平台。

不要重复工作

请选择一个能够满足您 A/B 测试需求的现有平台。请注意：平台提供的 A/B 测试以及数据驱动型决策是习惯性的。

保持测试状态一致，并公平分配受测用户到多个测试并非易事。没有必要从零开始写代码。

当然，每个测试版本的代码还是必须要写的。不过，不应该由应用或某个定制服务来决定在给定时间内使用哪个版本；而是交由 A/B 测试平台处理，这样就可以应用标准方法，在同一时间对同一人群进行多项测试。只有当您确定只须进行单项测试的情况下，自己动手编写 A/B 测试机制代码才有意义。与其花大成本写两个测试的代码，不如集成一个现有的 A/B 测试平台。

整合分析工具

所以说您可以将受测群体进行自动分组，挑选一个可以直接向您现有分析平台提供详细测试状态信息的分析平台。能否紧密将两个平台整合在一起，取决于每个测试的具体配置以及直接在 A/B 测试平台和分析平台之间传递的版本。A/B 测试平台会为每个版本分配一个全局唯一引用，并将其传递给客户端和分析平台。在这种情况下，客户端只须要将该引用而不是整个版本的配置传递给分析平台。

远程配置

若应用具备远程配置功能，那么它本身就已经拥有实现 A/B 测试所需的大部分代码。基本上，A/B 测试添加了一些服务器端规则来确定向应用发送何种配置。若应用不具备远程配置功能，那么 A/B 测试平台是引入这一功能的好方法。

Step 3 – 验证假设

监控测试

我建议在测试过程中监控新版本所造成的影响，包括那些在假设中未被提及的指标。如果您发现负面影响，可能需要提早停止测试，让用户尽早恢复到之前的版本——最小化不良用户体验。某些 A/B 测试平台能提供监控功能，并在测试遇到意外负面影响时发出自动警告。否则，您须要对之前监控系统监测到的影响和现有测试进行交叉对照，以识别“不良”版本。

注意： 如果须要提早停止测试，那您应该谨慎处理收集到的数据，因为无法确保测试群体样本具有代表性。

Step 4 – 分析并得出结论

如果假设错误 —— 因为相关指标没有正面或者负面影响 —— 那么就没有理由继续保留这一版本了。不过有些情况下，新版本可能会对一个相关但意料之外的指标产生积极影响。这或许是支持新版本的正当理由，但是一般来说还是针对该指标重新设计一个测试更好一点。实际上，一个实验的结果往往会产生额外的问题和假设。

Step 5 – 采取行动

渐增发布

A/B 测试平台的常见用例之一就是转变自身角色成为渐增发布机制，将测试的获胜版本逐渐推广到所有用户，以取代旧版本。可以把它当作 A/B 设计测试，而渐增发布则是一种 Vcurr／Vnext 测试，用以确认所选的版本不会对更多用户造成负面影响。可以通过逐步提高接收新版本的用户百分比 (例如，从 0.01％提高到 0.1％，1％，3％，7.5％，25％，50％，100％) 来进行渐增发布，并观察在进入下一步之前是否有不利的结果。同时你还可以用其他方式进行分类，包括国家，设备类型，用户组等。你还可以选择仅向特定用户群体 (如内部用户) 发布新版本。

深度分组和定位

A/B 测试结果可用于分析不同分组间的差异，也可用于确定目标方法论。在这两种情况下，可能须要提高采样率或延长测试时间让每个组都具有统计意义。例如，标签 vs 底部导航假设的测试结果可能会根据国家的不同而有所不同；在另外情况下，一些国家的用户参与度可能会大幅度增长，有些则没有变化，有的略有下降。在这种情景下，A/B 测试平台可以根据国家设置不同的“默认”版本，以最大限度地提高用户总体参与度。

针对特定组可以使用同一组的数据进行测试。例如，您可以测试居住在美国的用户和之前使用过标签导航风格的用户。

A/n 测试

A/n 测试是指被测版本超过两个的测试。这可能是用几个新版本代替某一现行版本；或者是几个添加新功能的版本与无新功能的版本进行比较。在进行深度分组之后，您可能会发现不同的组表现最好的版本也各有不同。

多变量测试

多变量测试允许开发者在单次测试内，同时改变应用的多个项目，并根据每一组值设计出单独测试版本用于 A/n 测试。譬如说：

若多个相关项目会共同作用影响指标整体表现，多变量测试是不错的选择，不过可能会无法确定影响究竟来自哪一个具体项。

扩大测试规模

若在同一人群中同时进行多项测试，那么这些测试必须由同一个平台管理。有些平台可以支持千项并行测试，有些平台则只支持独立测试 (即用户一次只能进行一次测试)，而有些平台则允许共享测试群 (即用户同时进行多个测试)。前一种情况更易管理，但会迅速用完测试用户，并达到具有统计价值的并行测试数量上限。后一种情况会增加 A/B 测试平台管理难度，但是不存在并行测试数量上限，因为平台把每一个测试当作另一个测试的附加组。

自我选择

自我选择让用户获知自己正在使用某一特定测试版本。用户可以自行选择使用版本，或者让 A/B 测试平台随机给他们分配。无论哪种情况，这些用户数据都不可用于指标分析，因为他们并不是在不知情的状态下参与测试 —— 由于知道这是一个测试，因此他们的反应可能带有偏见。

• Firebase 远程配置 (FRC) 提供客户端库，允许应用向 Firebase 请求并接受配置，此外也可利用基于规则的云端机制定义用户配置。开发者可以在不发布新版本的情况下，通过远程配置更新 (或升级) 应用；
• Firebase 远程配置与分析支持通过 A/B 测试决定与跟踪版本部署；
• Firebase 分析会根据版本不同给出指标分类，并直接了解到 FRC。

请记住：在 A/B 测试中，结果分析很重要。测试和分析双管齐下才能为您提供洞见，改善应用未来的设计及开发，激发应用最优性能。