做AB测试前的运营思考

本篇谈一下一个大家十分熟悉的技术：AB测试。所有有实际产品或运营经验的同学对它都不陌生，然而，在实际运用中却常常存在意识或决策上的明显错误。有四个问题常常会存在判断上的困难：

1. 到底什么要做AB测试？什么不要做？

2. AB测试时，我们应该如何判定什么数据是正确的观察对象？

3. A和B本身只是两个平级的分支，那么如果想要同时测试多个因素，尤其是互相重叠的因素（无法对等分为A、B、C、D测试组），那该怎么办？

4. AB测试的结果真的像看起来那么正确吗？

这几个问题看起来似乎很简单，然而，实际工作中我们恰恰常在这几点上做出错误决策。下面让我结合实战案例上做一些探讨。

1、什么要做AB测试？什么不要？

我最初接触AB测试这个概念时认为，如果想要精确评估一个功能带来的效果，或者衡量对比两个决策因素（或者两个设计、两个选项……）孰优孰劣如何选择，可以通过AB测试来实际看一下到底哪个更优。如果采用某个方案已经非常肯定，那么AB测试并没有太大必要。

然而，在实际工作中，我还是看到了非常多的例子，似乎已经非常肯定的事情，AB测试的结果却给出了完全相反的答案。

因此，如果条件具备的话，所有的新功能迭代都应当进行AB测试，并保持一个合理的时长，来验证预期效果是否达到，尤其值得谨慎的是，局部优化，是否在全局上反而得不偿失。

此外，还需要特别注意下面这些情况：

1. 有时一个新功能至关重要，或者来自领导层明确要求，不适合在全局只上一半。此时可以考虑进行局部AB测试，例如，把A和B分组从50:50调整成90:10（如果流量足够大，甚至可以99:1），然后用那10%的局部测试的结果数据乘以9，来和那90%进行对比，得到结论。

要特别说明的一个误区是，目前很多App是采用灰度发布的模式，慢慢把上线流量从5%提升到100%，这和AB测试是完全不同的策略。灰度发布的目的是防止未知的错误影响全局，往往先从新疆西藏等小流量地区上线，没问题再扩大到陕西湖南湖北，再没问题则延伸到江浙沪京广深等大流量区域，直至全局上线，每步推进往往只间隔几个小时，最多一天。而切分部分流量进行AB测试，则需要十分科学、均衡、对等、随机地选取流量，并进行相对更为长期的测试（至少在2～4周），以取得足够的结果样本，提高结果的正确性。

灰度发布通常是确定的策略，目的是防止未知错误影响全局，先从小流量地区往大流量地区覆盖，直到全局上线，通常只需要几小时，最多一天。AB测试则更强调对比，根据对比结果决定是否上线功能。

2. 在A和B样本选取的时候，需要对影响因素尽量保持完全对等。例如，平台的50%流量来自北京，50%流量来自上海，在做对比分组的时候，就不宜把北京作为A分组，把上海作为B分组，因为北京和上海的用户，本身很可能就存在较大的特性差异。此时最好通过系统随机抽取样本，让各种影响因素在两个样本里均匀分布（例如IP地址最后一位为奇数的为A组，偶数的为B组），通过精心设计的对等性屏蔽所有除被测因素以外的影响因子。

3. 要注意用户对新功能新用法有一个习惯培养过程。例如，当初我们把秒杀频道在首页展示的单品从纵向平铺改成横向划动，以在不加大首页长度牺牲下方栏目流量的情况下，可以在首页展示更多单品。全局的AB测试证明这是一个失败的尝试。时隔一年再次尝试，却取得了相反的结果！分析后发现，原因是在做AB测试时，有一批老用户习惯了纵向划动浏览秒杀栏目，新的交互方式这些老用户不习惯，带来了较差的预期效果，影响了整体数据。然而，对于新用户来说，横划浏览是一个非常高效的方式（注意对横划的引导设计），而老用户随着时间推移也会接受这个新交互方式，此时效果就会体现出来。因此，对于这种高度受使用习惯影响的功能，应当把测试数据集限定在不受固有习惯影响的新用户中，或把测试周期拉到足够长。

4. 战略性的新功能并不适用于AB测试。战略往往专注于未来，但AB测试只反应当前。新业务功能开发出来时，因为某些环境支持因素、用户使用习惯、或配套条件还不完全具备，数据上可能居于劣势。例如，在商详页商品图首次使用视频时，可能由于4G网络还不够普及，或者视频素材制作水平还不够规范，导致视频商详图片带来的效果并不理想。但只要相信这是正确的方向，就应该坚持下去。

5. 有时大家可能会有这样的矛盾，一个功能如果没做，是没法做AB测试的，如果做了，那么研发成本都付出了，不上线多可惜。再或者，两个方案不知道哪个好，如果不都开发出来，无法进行AB测试，如果都开发了，那么付出了双倍的成本，如何避免投入的浪费？

其实这类问题并没有标准答案。本土互联网公司讲究“试错”，讲究速度，不管对错，做了再说，总有碰对的。而亚马逊这样的国际巨头，则极其严谨，宁可不做，也不做错误的。以前我在1号店，一个迭代两周就平均上线60多个功能，看到数据变化了，也不准确地知道谁带来了多少增长或导致了多少下跌，懵懵懂懂往前狂奔。而亚马逊则十分严谨，每个功能必须做AB测试，达到了确信的提升才允许上线，一个项目上线前会不断被AB测试专家、用户体验专家、技术团队、业务团队所挑战。狂奔，有时候其实只是在兜圈子，而太谨慎，则可能输了速度，win the battle lose the war。在我看，没什么对错，要敢赌，但出手前要审慎地推敲，不打无把握的仗，事后则要想办法清晰准确地知道每件事的成败得失。

带着这个思路回看前面的问题，我的观点是，如果做了之后证明效果不佳或者平平，不上更好，止损好过进一步损失，也减少折腾用户。付出的都是沉没成本，不能舍不得它而影响未来决策（是不是觉得心有点痛，做都做了，不上好可惜～）。两个方案做哪个好，仔细分析下，做更有信心的，赌一把。如果确实差不多又是重大功能，就都做，根据AB测试取好的，因为A和B的价值差异，可能都超过成本本身。但如果这个功能不太重要，那都别做了，把时间省下来做更重要但事。半重要不重要的，抛个硬币吧。