上文介紹了 A/B 測試的基本概念，接下來我們繼續(xù)探討如何實現(xiàn) A/B 測試。

我們先來看一個圖：

（注：感謝Algo提供本圖。）

上圖展示了 A/B 測試的實現(xiàn)原理。從左到右，四條較粗的豎線代表了 A/B 測試中的四個關(guān)鍵角色：客戶端（Client）、服務(wù)器（Server）、數(shù)據(jù)層（Data）、數(shù)據(jù)倉庫（Data Warehouse）。從上到下代表了三種訪問形式：無 A/B 測試的普通訪問流程（Non AB test）、基于后端的 A/B 測試訪問流程（Back-end AB test）、基于前端的 A/B 測試訪問流程（Front-end AB test）。

一般情況下，用戶在一次瀏覽中，會從客戶端（Client）發(fā)起一個請求，這個請求被傳到了服務(wù)器（Server），服務(wù)器的后臺程序根據(jù)計算，得出要給用戶返回什么內(nèi)容（Data），同時向數(shù)據(jù)倉庫（Data Warehouse）添加一條打點信息，記錄本次訪問的相關(guān)信息。這個過程也就是圖上橫向的流程。數(shù)據(jù)倉庫收集到足夠的數(shù)據(jù)之后，就可以開始進(jìn)行分析（Analytics）了，這也即是圖中右上角的部分。

A/B 測試需要將多個不同的版本展現(xiàn)給不同的用戶，即需要一個“分流”的環(huán)節(jié)。從上圖中我們可以看到，分流可以在客戶端做，也可以在服務(wù)器端做。傳統(tǒng)的 A/B 測試一般是在服務(wù)端分流的，即基于后端的 A/B 測試（Back-end AB test），當(dāng)用戶的請求到達(dá)服務(wù)器時，服務(wù)器根據(jù)一定的規(guī)則，給不同的用戶返回不同的版本，同時記錄數(shù)據(jù)的工作也在服務(wù)端完成。

基于后端的 A/B 測試技術(shù)實現(xiàn)上稍微簡單一些，不過缺點是需要技術(shù)部工程資源介入，另外收集到的數(shù)據(jù)通常是比較宏觀的PV（Page View）信息，雖然可以進(jìn)行比較復(fù)雜的宏觀行為分析，但要想知道用戶在某個版本的頁面上的具體行為往往就無能為力了。

基于前端的 A/B 測試則可以解決上面的問題。它的特點是，利用前端 JavaScript 方法，在客戶端進(jìn)行分流，同時，可以用 JavaScript 記錄下用戶的鼠標(biāo)行為（甚至鍵盤行為，如果需要的話），直接發(fā)送到對應(yīng)的打點服務(wù)器記錄。這樣的好處是不需要技術(shù)部（如果你們和我們一樣，前端工程師與后端工程師分屬不同部門的話）參與，并且可以比較精確地記錄下用戶在頁面上的每一個行為，甚至包括后端方法難以記錄到的無效點擊！

下面，我將重點介紹一下我們在基于前端的 A/B 測試上的一些實踐。

一、分流

首先遇到的問題是如何分流的問題。對于大部分需求來說，我們希望各個版本的訪問人數(shù)平均分配。解決辦法有很多種，比較簡單的一種即是前面提到過的，根據(jù)某一個 Cookie ID 來劃分用戶，前提是你的網(wǎng)站上每一位訪客在第一次訪問時就要有一個不重復(fù)的 Cookie ID，比如“123.180.140.*.1267882109577.3”。然后，可以根據(jù)這個 Cookie ID 的最后一位（在本例中是“3”）來劃分人群，比如單數(shù)的顯示 A 版本，偶數(shù)的顯示 B 版本。

因為 Cookie ID 一般設(shè)定后不會輕易改變，基于 Cookie ID 的好處是我們能很好地對訪客保持一致性，某個用戶如果第一次看到的是 A 版本，那他刷新后看到的還是 A 版本，不會一會兒看到 A 版本一會兒看到 B 版本。但不足之處就是如果用戶瀏覽器不支持 Cookie 的話，分流就不能正常進(jìn)行了。不過，現(xiàn)代瀏覽器默認(rèn)情況下都是支持 Cookie 的，如果真有用戶的瀏覽器不支持 Cookie ，那也應(yīng)該是極少數(shù)特殊情況，對結(jié)果的影響非常微小，對于這些特殊情況，我們一般可以安全地忽略掉。

還有一點需要注意的是，A/B 測試的頁面必須有較高的 UV （Unique Visitor，獨立訪客數(shù)），因為分流帶有一定的隨機(jī)性，如果頁面 UV 太小，分到每一個版本的人數(shù)就更少，結(jié)果很有可能被一些偶然因素影響。而 UV 較大時，根據(jù)大數(shù)定理，我們得到的結(jié)果會接近于真實數(shù)據(jù)。就像想知道一個地方的成年人的平均身高，當(dāng)然是取的樣本越大結(jié)論越可信。

二、展示

決定向當(dāng)前訪問者顯示哪個版本后，怎么用前端的方法加載對應(yīng)的版本呢？這需要分情況處理。

一般情況下，如果兩個版本只有一個較小的區(qū)域不一樣，我們可以同時將兩個區(qū)域的 HTML 都加載到當(dāng)前頁面中，先用 CSS 把它們隱藏起來（也可以默認(rèn)顯示一個版本），等 JS 判斷出該顯示哪個版本后，再控制對應(yīng)版本的 CSS 顯示。

有時候，測試區(qū)域比較大，代碼比較多，或者需要后臺較多的計算資源，如果一開始就把兩個版本的 HTML 全加載到當(dāng)前頁面中，就會需要比較大的開銷（比如帶寬、后臺計算量）。這種情況下，我們可以先把測試區(qū)留空，之后再用 Ajax 的方式延遲加載。

還有的時候，測試區(qū)域非常大，幾乎占了整個頁面，或者完全就是不同的頁面，這時，用 Ajax 方式加載也不適合了，可以將不同的版本做成不同的頁面，然后再用 JS 跳轉(zhuǎn)。不過這樣的方式并不是很好，因為前端 JS 跳轉(zhuǎn)需要一定的時間，這個過程很有可能被用戶感受到，并且留下不好的體驗。對這個問題，似乎沒有很好的解決辦法，至少在前端層面很難完美解決，所以并不是非常推薦這種跳轉(zhuǎn)方式，如果真的需要跳轉(zhuǎn)，最好是在服務(wù)器端由后端代碼來操作。

三、數(shù)據(jù)采集

正確展示對應(yīng)的版本后，就要開始采集需要的數(shù)據(jù)了。有一個可選的數(shù)據(jù)，是當(dāng)前版本有多少 PV （Page Views，訪問量），如果需要記錄這個數(shù)據(jù)的話，在正確版本加載完成之時就要發(fā)送一個打點信息。不過很多需求中，具體版本的 PV 的精確數(shù)值可能不是很重要，而且要收集這個信息需要多一次打點操作，所以一般情況下這個數(shù)據(jù)是可選的。

必須的數(shù)據(jù)是測試區(qū)域內(nèi)用戶的點擊信息。當(dāng)用戶在測試區(qū)域點擊了鼠標(biāo)左鍵（無論這個點擊是點擊在鏈接、文字、圖片還是空白處），我們就需要發(fā)送一條對應(yīng)的打點信息到打點服務(wù)器。一般來說，這個打點信息至少需要包含以下數(shù)據(jù)：

當(dāng)前 A/B 測試以及版本標(biāo)識

點擊事件的位置

點擊時間戳（客戶端時間）

當(dāng)前點中的URL（如果點在非超鏈接區(qū)域，此項為空）

用戶標(biāo)識（比如 Cookie ID）

用戶瀏覽器信息

為了盡可能精確地還原用戶的點擊位置，我們的頁面對前端有比較高的要求，要求頁面在不同的瀏覽器下有基本一致的表現(xiàn)，至少在IE6、7、8以及 Fiefox 下，頁面橫向的元素要精確一致，縱向上很難做到完全一致，但也要盡可能保持統(tǒng)一。另外，這樣的測試也不太適合自適應(yīng)寬度的頁面，比較適合定寬的頁面，為了避免不同分辨率下頁面左右空白不同導(dǎo)致鼠標(biāo)點擊位置的不同，點擊位置取的應(yīng)該是相對于測試區(qū)域左上角的位置。除此之外，最好再記錄一下測試區(qū)域相對于頁面內(nèi)容左上角的位置，在后面還原點擊分布圖以及繪制熱區(qū)圖時會用到這個數(shù)據(jù)。

這一階段的流程大致如下圖所示：

數(shù)據(jù)打點該如何發(fā)送以及如何存儲呢？這要取決于你的打點服務(wù)器如何存儲信息。

四、數(shù)據(jù)存儲

我們使用了一臺專用的服務(wù)器收集打點信息，為了能支持盡可多盡可能密集的打點請求，這臺服務(wù)器的 apache 服務(wù)網(wǎng)站目錄下只有兩個靜態(tài)文件，分別是 abtest.html 和 abtest.gif ，兩者都是非常小的空白文件（空白圖片）。訪客端進(jìn)行打點時，只需要以 GET 的方式帶上相關(guān)的參數(shù)請求兩個文件中的任意一個即可。比如：

http://abtest.xxx.com/abtest.gif?abid=1-a&clickBlockX=244&clickBlockY=372&clickBlockW=392&clickBlockH=76&clickTime=1263264082137&clickRX=233&clickRY=47&clickURL=&clickBeaconID=123.180.140.*.1267882109577.3&browserType=FireFox

這個請求可以通過 Ajax 的方式發(fā)送，也可以通過 JS 在頁面上創(chuàng)建 new Image() 對象的方式完成。

對打點服務(wù)器來說，這只是一條普通的 HTTP 請求，它會在日志里留下一條普通的日志記錄，形如：

123.180.140.* – - [13/Jan/2010:15:21:15 +0800] “GET /abtest.gif?a=123&b=456&c=789 HTTP/1.1″ 304 – “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.6 (KHTML, like Gecko) Chrome/4.0.266.0 Safari/532.6″

可以看到了，除了 JS 發(fā)送給我們的信息外，Apache 還幫我們記錄了一些信息，比如訪客 IP 、服務(wù)器時間、用戶瀏覽器信息。

對于數(shù)據(jù)記錄和存儲來說，到這一步就足夠了。Apache 靜態(tài)文件 + 日志的方式足夠高效，基本不用擔(dān)心性能的問題。剩下的，就是另外一個問題，如何從 Apache 日志中讀取打點信息并加以分析，這已經(jīng)和前端無關(guān)了，并且是一個比較復(fù)雜的問題，將在后續(xù)日志中介紹。

（注：本文首發(fā)于http://oldj.net/article/AB-Testing-method/。）