所謂 A/B 測試，簡單來說，就是為同一個目標制定兩個方案（比如兩個頁面），讓一部分用戶使用 A 方案，另一部分用戶使用 B 方案，記錄下用戶的使用情況，看哪個方案更符合設(shè)計目標。

一：基本概念

網(wǎng)站設(shè)計中，我們經(jīng)常會面臨多個設(shè)計方案的選擇，比如某個按鈕是用紅色還是用藍色，是放左邊還是放右邊。傳統(tǒng)的解決方法通常是集體討論表決，或者由某位專家或領(lǐng)導(dǎo)來拍板。雖然傳統(tǒng)解決辦法多數(shù)情況下也是有效的，但A/B 測試（A/B Testing）可能是解決這類問題的一個更好的方法。

所謂 A/B 測試，簡單來說，就是為同一個目標制定兩個方案（比如兩個頁面），讓一部分用戶使用 A 方案，另一部分用戶使用 B 方案，記錄下用戶的使用情況，看哪個方案更符合設(shè)計目標。當然，在實際操作過程之中還有許多需要注意的細節(jié)。

A/B 測試最核心的思想，即：

1. 多個方案并行測試；
2. 每個方案只有一個變量不同；
3. 以某種規(guī)則優(yōu)勝劣汰。

需要特別留意的是第 2 點，它暗示了 A/B 測試的應(yīng)用范圍，——必須是單變量。

另外，雖然 A/B 測試名字中只包含 A、B ，但并不是說它只能用于比較兩個方案的好壞，事實上，你完全可以設(shè)計多個方案進行測試，比如ＡＢＣ測試，“A/B 測試”這個名字只是一個習慣的叫法。

回到網(wǎng)站設(shè)計，一般來說，每個設(shè)計方案應(yīng)該大體上是相同的，只是某一個地方有所不同，比如某處排版、文案、圖片、顏色等。然后對不同的用戶展示不同的方案。

要注意，不同的用戶在他的一次瀏覽過程中，看到的應(yīng)該一直是同一個方案。比如他一開始看到的是 A 方案，則在此次會話中應(yīng)該一直向他展示 A 方案，而不能一會兒讓他看 A 方案，一會兒讓他看 B 方案。

同時，還需要注意控制訪問各個版本的人數(shù)，大多數(shù)情況下我們會希望將訪問者平均分配到各個不同的版本上。要做到這些很簡單，根據(jù) cookie （比如 cookie 會話ID的最后一位數(shù)字）決定展示哪個版本就是一個不錯的方法。

要實現(xiàn) A/B 測試，我們需要做以下幾個工作：

1、開發(fā)兩個（或多個）不同的版本并部署；
2、收集數(shù)據(jù)；
3、分析數(shù)據(jù)，得出結(jié)果。

二：實踐方法

從左到右，３條較粗的豎線代表了 A/B 測試中的３個關(guān)鍵角色：客戶端（Client）、服務(wù)器（Server）、數(shù)據(jù)層（Data）。從上到下代表了３種訪問形式：

1. 無 A/B 測試的普通訪問流程（Non AB test）
2. 基于后端分流的 A/B 測試訪問流程（Back-end AB test）
3. 基于前端分流的 A/B 測試訪問流程（Front-end AB test）。

A/B 測試需要將多個不同的版本展現(xiàn)給不同的用戶，即需要一個“分流”的環(huán)節(jié)。從上圖中我們可以看到，分流可以在客戶端做，也可以在服務(wù)器端做。

傳統(tǒng)的 A/B 測試一般是在服務(wù)端分流的，即基于后端的 A/B 測試（Back-end AB test），當用戶的請求到達服務(wù)器時，服務(wù)器根據(jù)一定的規(guī)則，給不同的用戶返回不同的版本，同時記錄數(shù)據(jù)的工作也在服務(wù)端完成。

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

基于前端的 A/B 測試則可以比較精確地記錄下用戶在頁面上的每一個行為。它的特點是，利用前端 JavaScript 方法，在客戶端進行分流，同時，可以用 JavaScript 記錄下用戶的鼠標行為（甚至鍵盤行為，如果需要的話），直接發(fā)送到服務(wù)器記錄。

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

首先遇到的問題是如何分流的問題。對于大部分需求來說，我們希望各個版本的訪問人數(shù)平均分配。可以根據(jù)某一個 Cookie ID 來劃分用戶，比如“123.180.140.*.1267882109577.3”，可以根據(jù)這個 Cookie ID 的最后一位（在本例中是“3”）來劃分人群，比如單數(shù)的顯示 A 版本，偶數(shù)的顯示 B 版本。

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

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

• 當前 A/B 測試以及版本標識
• 點擊事件的位置
• 點擊時間戳（客戶端時間）
• 當前點中的URL（如果點在非超鏈接區(qū)域，此項為空）
• 用戶標識（比如 Cookie ID）
• 用戶瀏覽器信息

三：應(yīng)用例子

今年，EA公司發(fā)布新版《模擬城市》（SimCity）游戲時，在網(wǎng)站做了一個A/B測試，以便試驗轉(zhuǎn)化率在不同的布局下是否有變化。

下面是兩個不同的版本：

B版本與A版本的差別在于新版本刪除了Pre-Order的促銷廣告圖片，頁面更清爽一些。

結(jié)果數(shù)據(jù)顯示，A版本的轉(zhuǎn)化率為5.8%，B版本的轉(zhuǎn)化率為10.2%，提高了43.4%。

這幾乎是一個完美的A/B測試案例：有明確的測試目標，清晰的衡量標準（訂單轉(zhuǎn)化率），以及完美的結(jié)果數(shù)字。

作者：林洋，個人公眾號：產(chǎn)品時間

本文由 @林洋 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載。