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

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

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

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

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

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

作为综合性电商，如何在显示面积极其有限的移动端向消费者高效率展示海量商品，是个普遍的难题。大多数情况下会根据一级分类设计类目频道，点进去是二级分类频道，再点进去是三级分类频道……这样的结果，是用户需要走很深的层级才能看见具体的商品，不但“酒香巷子深”，而且每一次跳转，都会导致流量大比例跳失。所以近年来电商产品普遍尝试的一个趋势是“做浅”。

我的团队曾经针对“做浅”做过一个产品改造，在移动端首页的所有类目频道入口直接增加展示单品，以驱动商品曝光，带来更多的商详页浏览量，并通过个性化算法向不同用户推荐不同的活动和单品，以提升转化率。如下图，

老版品类频道入口

新版品类频道入口

首页流量非常大，这样的首页商品曝光+个性化算法选品，我们认为必然能带来商详页流量的明显提升。这个项目如果是我以前负责本地电商产品时，可能会直接安排上线，因为主观预期非常明确。

但是，亚马逊有个严格的规定，所有新功能上线都必须要经过Weblab的数据验证。Weblab系统实际上就是一个AB测试的系统，可以输入观察的目标数据项，系统会用一段时间跑出结果，对比有新功能的分组（Treatment Group，简称T）和没有新功能的分组（Control Group，简称C），直接体现目标数据项的增减情况。

经过四周的Weblab测试，数据结果表明，T与C相对比，商详页流量下降了1.32%！！！

这是一个非常意外的结果，产品和BA团队随后立即进行了深入的专题数据分析。

请仔细观察上图，图中每个“Grid”对应的是首页各品类频道入口对商详页的导流数据，在Weblab测试结果中，C的数据为左边橙色柱，T的数据为右边褐色柱。从左到右的每组柱体，代表一个品类频道入口数据，在首页自上而下排序。

从图中我们可以看到，在第二、第三个栏目中（Grid-18，Grid-19），新版本带给商详页的流量确实如预期一样，超越了老版本，但从第四个栏目（Grid-20）开始出现逆转，越深的栏目，贡献给商详页的流量下跌越多，最后计算总体数据，老版本反而有更强的商详页导流能力！

产品分析的结论是，新版设计加大了单个品类频道入口高度，虽然单个品类频道的商详导流能力的确如预期的增强了，但在同样的移动端屏数里，得到曝光的品类频道入口减少。由于移动端流量随着屏数加深而迅速衰减，因此导致了向用户曝光的品类频道减少，因而在全局上商详流量出现下降。根据这个结果，最后技术团队回滚了这个功能。

这个案例表明，很多主观上看似明显更好的设计，在数据结果上往往出人意料。

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

多提一句，也许有产品同学会有疑问，做浅既然是正确的大趋势，那么这个改造为什么失败了？主要是因为这个方式考虑不够全面，如何正确地“做浅”不在本文范围，后面谈首页和频道页设计的时候我们再深入探讨。这里主要是通过这个案例说明，AB测试常常会否决想当然的推测。

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

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

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

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的价值差异，可能都超过成本本身。但如果这个功能不太重要，那都别做了，把时间省下来做更重要但事。半重要不重要的，抛个硬币吧。

本想在一篇里写完AB测试的，没想到四个点才写了一个，已经三千六百字。先在这里打住，感兴趣的同学，且听下回分解。