产品经理必知的A/B测试事儿

作为产品从业者日常工作中，却可以通过数字化的手段，将不同的方案落地对比，如果方案不好，直接扔掉恢复原方案，及时止损。这种神奇的手段就是A/B测试，A/B测试为产品经理面对各种不确定性降低决策风险提供了抓手，但A/B测试也并非万能，本篇聊聊产品经理与A/B测试的那些事。

应用场景

产品经理思考需求和功能首要考虑的便是应用场景，那么决定要不要将A/B测试作为手段，也需要考虑哪些场景需要使用。A/B测试广泛适用于产品功能/交互/UI/文案、推荐/搜索策略、运营策略。

在产品功能/交互/UI/文案场景下，产品经理日常会收到多方反馈，多方反馈有时会是矛盾的，对于一个功能，有叫好的有吐槽的，产品经理通过各种方式优化后，不确定相比之前方案是否更优，可采用A/B测试。例如之前做C端资讯客户端，详情页返回交互按钮在页面底部，而同行业经常在页面顶部，有部分用户吐槽不方便操作，从交互角度，各有优劣，为了确定最终是否需要调整，便通过A/B测试，将新老方案同时在线上跑，看关键阅读指标及操作对比数据，再做判断。

在推荐/搜索策略上，相比以上功能/交互/UI/文案场景下，最大的好处便是后端策略，不依赖客户端开发，后端调整策略后随时做A/B，自由度比较大。在推荐/搜索上，经常需要上线新策略，虽然也会做一些离线测试，但离线测试并不能代表推到线上，新策略一定比老策略表现好，通常也需要A/B测试，将新策略从0开始逐步放量，如果表现一直比较好，就可以放到全量。

在运营策略上，运营人员同样会遇到产品/策略人员一样的问题，上线新的运营策略，并不确定是否更优，或者多个运营方案哪个表现更好，也需要A/B测试线上跑，辅助决策和判断。

关键要素

产品/策略/运营应用A/B测试显然不是一句话的需求，而是需要满足做A/B测试的关键要素才行，否则可能投入不少资源，最终并不会有希望的结论。市面上有一些做A/B测试的服务商，提供的主要是工具和能力，并不能替代做A/B测试需要满足的关键要素。这些要素包含：2种及以上方案、用户选取上独立随机、单一因素变量、结果显著差异。

做A/B测试最基础需要满足的是需要有对象可测，一种方案显然不需要测试，这就需要至少有2种以上方案。例如以上案例，所有产品都采用页面顶部返回按钮，用户也没有反馈，显然不会凭空拍脑门做个底部方案，也自然不会需要做A/B测试。

做A/B测试用户选取上的独立，要求不同的方案用户不应该有交叉，并且也不应该某个方案在用户选取上只对应特定特征的用户，否则就很难客观反映不同方案实际效果。例如以上案例中，顶部返回和底部返回，我们就采用了用户ID（数字串）取模2的方式，将用户随机分成两类。

做A/B测试需要满足单一变量，很多时候不同产品团队或者不同职能团队同时给产品添砖加瓦，导致无法满足单一变量，此时得出来的结论自然也会有偏。例如以上案例中，如果衡量方案差异的关注指标包含内容消费条数，那么此时如果feed流中，推荐策略团队正巧也在做策略优化和对比实验，就可能引发“打架”，得出结论自然也是被污染的。

最后，做A/B测试需要满足方案数据指标上有显著差异，通常来讲，即便以上条件都能够满足，两个方案都一样，得出的数据也不一定相同，因此为了保证结论靠谱，需要数据指标有显著差异，才能下定论。再以以上案例举例，将返回按钮放置到顶部和底部，关注指标只有相对值1-2%差异，在随机范围之内，并不能支持新方案比老方案一定好，所有现在仍然在沿用老方案。

A/B测试局限

前两年在产品圈内，存在古典产品经理和新型产品经理的区分，大体是古典产品经理更为感性和依赖经验做产品，新型产品经理则只需要大量做A/B测试然后迭代就可以了。新型产品经理以字节跳动为甚，其中原因就是字节跳动更加强调使用A/B测试。这两年字节跳动在不同场合，在纠正圈内对新型产品经理的误解，A/B测试更多是帮助产品经理降低做细微决策的成本，而非代替决策本身。

A/B测试显然也决定不了产品或业务战略的调整，产品经理决定单条产品线或某个产品模块的走向，管理层需要解决整个公司战略方向，这些都不是A/B测试能解决的，而是需要对行业、对业务、对用户/客户有深刻的理解与洞察。

认识到A/B测试的工具性和局限性，才是用好它的基础，再反作用业务和产品进化上。