移动App A/B测试中的5种常见错误

A/B 测试是一个需要不断学习的技能。而任何技能都需要通过不断的磨练才能越来越好。本文列举了 5 个 A/B 测试在移动 App 中常见的错误，希望产品经理和 Growth 的同学阅读完本篇文章后，可以在以后的 A/B 测试中避免同样的错误。

1. 直接复制其他公司的 A/B 测试经验

场景描述：看到同行业另一家公司的产品正在做 A/B 测试，他们的新版本看起来不错，我们也 Copy 他们新版本的产品形式直接上线吧。

不同的公司，甚至同领域的不同公司所做的 A/B 测试的经验一般不能直接复制。这里面最经典的是人人网与 Facebook 的案例。Facebook 曾经在一个 VP 的带领下做过一个首页的产品大改版，因为产品改动巨大所以这个版本一直在做小流量的 A/B 测试（虽然是小范围测试，但是 Facebook 总体用户量巨大，所以有百万级别的用户看到过这个新版主页），并没有推送给所有用户。但是人人网并没有学习 Facebook 的 A/B 测试经验，而是在看到 Facebook 这个新版本之后直接决定 Copy 过来。结果 Facebook 的这个主页大改版其实非常不成功，最后并没有推送到所有用户，然而人人网却直接上线了这个版本，对他们用户体验的伤害其实是无法估量的。

这里面最关键的问题是，不同公司的用户群体的行为其实是很不一样的，因为产品的场景、用户群不一样，这就决定了每一个 App 都应该围绕自己的用户群体和使用场景去做 A/B 测试，而不是照搬同行的经验。

2. 不够全面、准确的优化指标

场景描述：我更改了购买按钮，并跟踪了该按钮的点击次数。经过 4 周的 A/B 测试，该按钮的点击量提升了。但是，点击该按钮和完成购买之间还有 3 个步骤。这个按钮的改变是真的提升了转化率，还是仅仅鼓励了更多的用户点击购买按钮，而没有真正完成任何购买？

另一方面，如何知道您是否已跟踪了足够多的指标？我们一般也不会想跟踪整个应用中的每一个指标：如果你看到太多的指标，很可能会出现其中一些指标会显示试验版本比原始版本好，另外一些指标会显示试验版本比原始版本差，这个时候就很难判断到底新版本好还是原始版本好了。

避免这类错误的关键是先问自己一些问题：

• 你将如何判定一个A / B测试是成功的（或失败的）？

• 为了保证A / B测试成功，你 必须 跟踪哪些指标？是一个就够了，还是要同时关注多个指标？是否需要基于多个指标做组合形成一个复合指标？

• 选择指标后，请自行检查：“如果所有这些指标都显示新版本相比原始版本具有正向的、统计显著的结果，那么你是否有足够的信心将此新版本推送给所有用户？”

这些问题可以帮助我们避免上面提到的情况，因为很多时候仅仅关注按钮点击的指标是不够的。

3. 未规划好参与试验的用户规模

场景描述：我想测试按钮文案更改对结帐流程中最后一步的影响。我的用户中有不到 1％的人看到了此步骤，但我认为将此步骤的转化率从 80％提高到 85％将大大提高我的收入。我有 3 个按钮文案的想法想进行 A/B 测试，所以我可以通过 Testin 的 A/B 测试平台（http://www.http://www.testin.cn/product/ab）运行一个有 3 个版本的 A/B 测试试验，以提高

这里的错误是，没有获取足够的用户来执行想要的 A/B 测试。一般来说，我们需要至少 1000 个用户来获得统计显著的试验结果。这似乎不那么高，但如果只有 1％的用户看到支付流程的最后一步，意味着你需要有 10 万个该 App 的用户参与到 A/B 测试试验中来才行。10 万个用户对有些 App 来说很容易，但如果你的应用程序只有 25000 个用户，你需要 4 个月才能达到统计效果显着的试验结果。简而言之，你必须保证做 A/B 测试的那个页面至少有 1000 个用户会访问才可以。

4. 过早停止 A / B 测试

场景描述：我的一个 A/B 测试试验运行了 3 天，看到了统计显著的结果，这是一个成功的 A/B 测试，于是我发布获胜的版本给所有用户。

过早地停止 A / B 测试是一个不明智的选择。如果你的测试只运行了一个较短的时间（例如仅 3 天），那么参与试验的用户几乎都是你的高频用户。如果你的高频用户喜欢这项变更，你很可能在最初几天看到正面的结果。但是如果测试运行一个月，你看的数据会包含一个更全面的用户群的视图，因为除去高频用户外，其他可能每个月只用两三次的用户行为也会慢慢展现出来，这时候的数据的结论可能跟你前 3 天看到的完全相反。

当 Airbnb 测试他们的价格滑块的变化时就经历过类似的情况。

在 Airbnb 这个 A/B 测试中[1]，他们尝试将搜索页面的价格过滤器的最大值从 300 美金提高到了 1000 美金。从试验数据来看，在试验进行到第 7 天的时候，该试验的统计数据显示新版本能将房屋预定的量提升 4%（蓝色曲线），且它的 p-value 已经小于 0.05（红色曲线），属于统计显著的效果。如果他们在那一天结束这个试验并将新版本发布给所有用户的话，他们会期望得到房屋预订量的提升；但是，好在他们当时将这个试验继续运行了 36 天的时间，以检验该变动是否真正会取得统计显著的提升。最后的结果显示，这个改版相比原版本的提升几乎为 0，而且其 p-value 值也变成了 0.4（统计不显著）。

那么我们该如何判断一个试验究竟该运行多长时间呢？一个好的经验法则是先思考你的 App 中一个典型的用户周期是多长时间，然后将你的测试运行两个用户周期。对于许多 App 来说，一个用户周期就是一个星期。但对于某些特殊应用（例如银行应用），这可能是一个月。如果你的测试运行至少 2 个用户周期，这就增加了同时捕获高频用户和一般用户的点击行为的机会。

5. 认为所有用户的行为都是一样的

场景描述：某电商 App 的商品详情页进行了改版后的 A/B 测试，发现新版本页面停留时间、加入购物车次数比原始版本都下降了，说明新版本是失败的，不应该上线。

A/B 测试通常捕获到的是用户共性的行为数据。大多数用户喜欢版本 A，但可能有一部分用户喜欢版本 B。用户选择 B 版本也有可能是随机的行为，但肯定有一个共同的特征，导致那些用户喜欢版本 B。因此找出并分析用户喜欢版本 B 的原因并在以后的试验中运用也是非常重要的。业内有句话叫“再牛的产品经理也跑不赢一半的 A/B 测试”，正是因为用户群体的不确定性导致产品经理需要使用 A/B 测试来验证自己的想法。这就是为什么需要在 A/B 测试中做用户定向试验的原因。

在 Testin 的 A/B 测试平台中，产品经理可以基于用户的设备特征（例如手机机型、操作系统版本号、手机语言等）和用户的自定义标签（例如性别、年龄、新老用户、会员等级等）进行分群，每一个 A/B 测试试验都可以选定特定的用户群进行试验。在之前的电商商品详情页的案例中，产品经理在第一次 A/B 测试之后，提出了一个假设：我们平台上老用户比较多，新用户只占 40%，如果我只给新用户做版本对比的 A/B 测试，试验结果会不会不一样呢？果然，在只对新用户进行 A/B 测试之后，他们发现新用户的行为喜好与老用户确实存在差别，为他们将来产品改版和个性化产品页面积累了很宝贵的经验。