谈谈A/B测试
2014-09-18
A/B测试原来是用于Web前端优化效果测试的一种方法，UED设计师并没有很好的把握用户是否会喜欢新的页面，于是随机让一部分用户进入新的页面，另一部分用户进入原来的页面。这个分流对一般用户来说，是透明的。如果不是特别关注网页的底层信息，用户并不知道自己在哪个桶(bucket)里面。通过分析用户在A/B框架下的行为，比如页面停留时长、某个模块的点击率，来比较两种方案的优劣。
->
<-
最初由Google工程师提出的ABtest确实是两两均分的，随着应用的扩展和需求的增加，Abtest逐步发展成为”bucket test”（分桶测试），被比较的方案不仅仅是两个了，而且他们的流量也不一定是均分。从技术上来讲，一个系统可能比另一个系统的性能强，所以它能够支撑更多的流量，新系统往往还有很长的性能优化之路要走，甚至可能会遇上意想不到的故障；从业务来说，内容提供方不希望给大多用户带来影响和干扰，所以新方案的上线，一般并不会切入太多的流量，基于这些考虑，业界提出了一种发布方案叫“灰度发布”。于是就产生了一个问题：流量占比不同的方案之间进行ABtest，真的公平吗？
->
<-
最近我们做了几个算法，又从兄弟部门接了一个算法A。在一个app上进行ABtest，A算法接入90%的流量，我们的B算法接入10%的流量。数据报表的反馈是，A算法的效果领先我们6个百分点。于是app的负责人就来说，看来你们的算法确实比别人差不少啊。虽然不能拿流量当垫背，但我不得不说，比例不同算法对比，本身有很大的偏见。怎么说服人家呢？
首先讲个故事：我们要给全国人民推荐一种调味料，有两个算法A和B，如果恰巧分桶把A算法切到了四川省，B算法切给了除四川外的其他地区。现在两个算法给消费者推荐的都是“老干妈”，那么有“无辣不欢之称”的四川人民必然满意度比其他地区的要高，假设是80% vs 40%，难道可以说A算法优于B算法吗？实际上他们的表现是一样的。如果把A算法切流给了江浙沪，包邮人民可就不一定这么给面子了。那又能说A算法比不上B吗？
所以说，小比例和大比例数据直接对比是不公平的。最好的对比还是在相同大小流量，完全随机的条件下进行的ABtest。
然后，应该来个实验或者论证吧？可惜我还没想到，谁能教我！