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

　　我们先来看一个图：

　　上图展示了 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 测试上的一些实践。

　　一、分流

　　首先遇到的问题是如何分流的问题。对于大部分需求来说，我们希望各个版本的访问人数平均分配。解决办法有很多种，比较简单的一种即是前面提到过的，根据某一个 Cookie ID 来划分用户，前提是你的网站上每一位访客在第一次访问时要有一个不重复的 Cookie ID，比如“123.180.140.*.1267882109577.3”。然后，可以根据这个 Cookie ID 的后一位（在本例中是“3”）来划分人群，比如单数的显示 A 版本，偶数的显示 B 版本。

　　因为 Cookie ID 一般设定后不会轻易改变，基于 Cookie ID 的好处是我们能很好地对访客保持一致性，某个用户如果第一次看到的是 A 版本，那他刷新后看到的还是 A 版本，不会一会儿看到 A 版本一会儿看到 B 版本。但不足之处是如果用户浏览器不支持 Cookie 的话，分流不能正常进行了。不过，现代浏览器默认情况下都是支持 Cookie 的，如果真有用户的浏览器不支持 Cookie ，那也应该是极少数特殊情况，对结果的影响非常微小，对于这些特殊情况，我们一般可以安全地忽略掉。

　　还有一点需要注意的是，A/B 测试的页面必须有较高的 UV （Unique Visitor，独立访客数），因为分流带有一定的随机性，如果页面 UV 太小，分到每一个版本的人数更少，结果很有可能被一些偶然因素影响。而 UV 较大时，根据大数定理，我们得到的结果会接近于真实数据。像想知道一个地方的成年人的平均身高，当然是取的样本越大结论越可信。

　　二、展示

　　决定向当前访问者显示哪个版本后，怎么用前端的方法加载对应的版本呢？这需要分情况处理。

　　一般情况下，如果两个版本只有一个较小的区域不一样，我们可以同时将两个区域的 HTML 都加载到当前页面中，先用 CSS 把它们隐藏起来（也可以默认显示一个版本），等 JS 判断出该显示哪个版本后，再控制对应版本的 CSS 显示。

　　有时候，测试区域比较大，代码比较多，或者需要后台较多的计算资源，如果一开始把两个版本的 HTML 全加载到当前页面中，会需要比较大的开销（比如带宽、后台计算量）。这种情况下，我们可以先把测试区留空，之后再用 Ajax 的方式延迟加载。

　　还有的时候，测试区域非常大，几乎占了整个页面，或者完全是不同的页面，这时，用 Ajax 方式加载也不适合了，可以将不同的版本做成不同的页面，然后再用 JS 跳转。不过这样的方式并不是很好，因为前端 JS 跳转需要一定的时间，这个过程很有可能被用户感受到，并且留下不好的体验。对这个问题，似乎没有很好的解决办法，至少在前端层面很难完美解决，所以并不是非常推荐这种跳转方式，如果真的需要跳转，好是在服务器端由后端代码来操作。