竹磬网-邵珠庆の日记 生命只有一次，你可以用它来做些更多伟大的事情–Make the world a little better and easier

A/B测试：实现方法

上文介绍了 A/B 测试的基本概念 ，接下来我们继续探讨如何实现 A/B 测试。

我们先来看一个图：

（注：感谢Algo 提供本图。）

上图展示了 A/B 测试的实现原理。从左到右，四条较粗的竖线代表了 A/B 测试中的四个关键角色：客户端（Client）、服务器（Server）、数据层（Data）、数据仓库（Data Warehouse）。从上到下代表了三种访问形式：无 A/B 测试的普通访问流程（Non AB test）、基于后端的 A/B 测试访问流程（Back-end AB test）、基于前端的 A/B 测试访问流程（Front-end AB test）。

一般情况下，用户在一次浏览中，会从客户端（Client）发起一个请求，这个请求被传到了服务器（Server），服务器的后台程序根据计 算，得出要给用户返回什么内容（Data），同时向数据仓库（Data Warehouse）添加一条打点信息，记录本次访问的相关信息。这个过程也就是图上横向的流程。数据仓库收集到足够的数据之后，就可以开始进行分析 （Analytics）了，这也即是图中右上角的部分。

A/B 测试需要将多个不同的版本展现给不同的用户，即需要一个“分流”的环节。从上图中我们可以看到，分流可以在客户端做，也可以在服务器端做。传统的 A/B 测试一般是在服务端分流的，即基于后端的 A/B 测试（Back-end AB test），当用户的请求到达服务器时，服务器根据一定的规则，给不同的用户返回不同的版本，同时记录数据的工作也在服务端完成。

基于后端的 A/B 测试技术实现上稍微简单一些，不过缺点是需要技术部工程资源介入，另外收集到的数据通常是比较宏观的PV（Page View）信息，虽然可以进行比较复杂的宏观行为分析，但要想知道用户在某个版本的页面上的具体行为往往就无能为力了。

基于前端的 A/B 测试则可以解决上面的问题。它的特点是，利用前端 JavaScript 方法，在客户端进行分流，同时，可以用 JavaScript 记录下用户的鼠标行为（甚至键盘行为，如果需要的话），直接发送到对应的打点服务器记录。这样的好处是不需要技术部（如果你们和我们一样，前端工程师与后 端工程师分属不同部门的话）参与，并且可以比较精确地记录下用户在页面上的每一个行为，甚至包括后端方法难以记录到的无效点击！

A/B测试：基本概念

网站设计中，我们经常会面临多个设计方案的选择，比如某个按钮是用红色还是用蓝色，是放左边还是放右边。传统的解决方法通常是集体讨论表决，或者由 某位专家或领导来拍板，实在决定不了时也有随机选一个上线的。虽然传统解决办法多数情况下也是有效的，但A/B 测试（A/B Testing）可能是解决这类问题的一个更好的方法。

所谓 A/B 测试，简单来说，就是为同一个目标制定两个方案（比如两个页面），让一部分用户使用 A 方案，另一部分用户使用 B 方案，记录下用户的使用情况，看哪个方案更符合设计目标。当然，在实际操作过程之中还有许多需要注意的细节。

A/B 测试并不是互联网测试新发明的方法，事实上，自然界也存在着类似 A/B 测试的事件，比如下图中的达尔文雀 。

达尔文雀主要生活在太平洋东部加拉帕戈斯（Galapagos）的一个名为伊莎贝拉（Isabela）的岛上，一部分生活在岛的西部，另一部分生活在岛的东部，由于生活环境的细微不同它们进化出了不同的喙。这被认为是自然选择学说上的一个重要例证。

同样一种鸟，究竟哪一种喙更适合生存呢？自然界给出了她的解决方案，让鸟儿自己变异（多个设计方案），然后优胜劣汰。具体到达尔文雀这个例子上，不同的环境中喙也有不同的解决方案。

上面的例子虽然和网站设计无关，但包含了 A/B 测试最核心的思想，即：

1、多个方案并行测试；
2、每个方案只有一个变量（比如鸟喙）不同；
3、以某种规则优胜劣汰。

需要特别留意的是第 2 点，它暗示了 A/B 测试的应用范围，——必须是单变量 。有时我们的多个设计稿 可能会有非常大的差异，这样的情况一般不太适合做 A/B 测试，因为它们的变量太多了，变量之间会有较多的干扰，我们很难通过 A/B 测试的方法来找出各个变量对结果的影响程度。比如，土豆烧肉和豆腐鲫鱼汤都挺美味，但我们很难比较土豆和豆腐哪一个对菜的美味影响更大，而土豆烧肉和豆腐 烧肉则是不错的比较。另外，虽然 A/B 测试名字中只包含 A、B ，但并不是说它只能用于比较两个方案的好坏，事实上，你完全可以设计多个方案进行测试，“A/B 测试”这个名字只是一个习惯的叫法。

回到网站设计，一般来说，每个设计方案应该大体上是相同的，只是某一个地方有所不同，比如某处排版、文案、图片、颜色等。然后对不同的用户展示不同的方案。

要注意，不同的用户在他的一次浏览过程中，看到的应该一直是同一个方案。比如他一开始看到的是 A 方案，则在此次会话中应该一直向他展示 A 方案，而不能一会儿让他看 A 方案，一会儿让他看 B 方案。同时，还需要注意控制访问各个版本的人数，大多数情况下我们会希望将访问者平均分配到各个不同的版本上。要做到这些很简单，根据 cookie （比如 cookie 会话ID的最后一位数字）决定展示哪个版本就是一个不错的方法。

下面是 A/B 测试示意图：

可以看到，要实现 A/B 测试，我们需要做以下几个工作：

1、开发两个（或多个）不同的版本并部署；
2、收集数据；
3、分析数据，得出结果。

关于 A/B 测试的基本概念就介绍到这里，其余部分我会在后续文章中继续介绍。

为什么AB测试

很多朋友都问我怎么进行A/B测试，我一般都不直接回答他们的问题，而是首先问一句：“你的日IP是多少？”。当对方的回答是不到一百的时候，我一般都说这个没必要了解。

或许你会纳闷，为什么日IP少的站没必要了解A/B测试，原因很简单，A/B测试需要大量的IP，如果你的IP只有十几个，那么测试出来的数据很可能不是很准确，换句话说A/B测试的站日流量越大测试的结果越准确。

好了，说了这么多，还是把A/B测试跟大家谈谈吧。

举个简单的例子，当你有一个日IP过千的网站，而你的网站首页几百年没有更改了，这个时候你想启用新的网页，而你有害怕新的页面用户不一定就非常喜欢，那 么这个时候你就需要进行A/B测试了。测试的方法是将老页面定义为A页面，新页面定义为B页面。到谷歌网站优化工具申请进行A/B测试（免费的），这是时 候谷歌会给你一串代码，我们只需要将代码添加到谷歌要求的页面即可。

代码添加完毕，如果有一千个用户访问你的网站，那么会有500个用户看到A页面，500个用户看到B页面，这个时候再统计下通过A页面到达网站内页的用户 占的百分比是多少，通过B页面到达内页的用户占的百分比是多少。假设A的是6%，B的是20%那么恭喜你，这说明你新设计的页面是博得了用户的欢心。如果 你对20%的结果还不满意，那么继续修改你的页面，直到这个转化率不能够再提高为止。

A/B测试是一个科学的统计方法，这一统计的诞生，再也不用为了争吵是使用A图片好，还是使用B图片好，好不好，按照效果说算。还是邓爷爷说的好，实践是检验真理的唯一标准。停止争吵，来做个A/B测试吧。

前提是你要有上千的IP，而且还是每日。数据太小的话，往往不准确。