AB測試實(shí)踐全總結(jié)

A/B測試實(shí)踐全總結(jié)所謂A/B測試，簡單來說，就是為同一個(gè)目標(biāo)制定兩個(gè)方案（比如兩個(gè)頁面），讓一部分用戶使用A方案，另一部分用戶使用B方案，記錄下用戶的使用情況，看哪個(gè)方案更符合設(shè)計(jì)目標(biāo)。一：基本概念網(wǎng)站設(shè)計(jì)中，我們經(jīng)常會(huì)面臨多個(gè)設(shè)計(jì)方案的選擇，比如某個(gè)按鈕是用紅色還是用藍(lán)色，是放左邊還是放右邊。傳統(tǒng)的解決方法通常是集體討論表決，或者由某位專家或領(lǐng)導(dǎo)來拍板。雖然傳統(tǒng)解決辦法多數(shù)情況下也是有效的，但A/B測試（A/BTesting）可能是解決這類問題的一個(gè)更好的方法。所謂A/B測試，簡單來說，就是為同一個(gè)目標(biāo)制定兩個(gè)方案（比如兩個(gè)頁面），讓一部分用戶使用A方案，另一部分用戶使用B方案，記錄下用戶的使用情況，看哪個(gè)方案更符合設(shè)計(jì)目標(biāo)。當(dāng)然，在實(shí)際操作過程之中還有許多需要注意的細(xì)節(jié)。A/B測試最核心的思想，即：多個(gè)方案并行測試；每個(gè)方案只有一個(gè)變量不同；以某種規(guī)則優(yōu)勝劣汰。需要特別留意的是第2點(diǎn)，它暗示了A/B測試的應(yīng)用范圍，——必須是單變量。另外，雖然A/B測試名字中只包含A、B，但并不是說它只能用于比較兩個(gè)方案的好壞，事實(shí)上，你完全可以設(shè)計(jì)多個(gè)方案進(jìn)行測試，比如ＡＢＣ測試，“A/B測試”這個(gè)名字只是一個(gè)習(xí)慣的叫法?；氐骄W(wǎng)站設(shè)計(jì)，一般來說，每個(gè)設(shè)計(jì)方案應(yīng)該大體上是相同的，只是某一個(gè)地方有所不同，比如某處排版、文案、圖片、顏色等。然后對不同的用戶展示不同的方案。要注意，不同的用戶在他的一次瀏覽過程中，看到的應(yīng)該一直是同一個(gè)方案。比如他一開始看到的是A方案，則在此次會(huì)話中應(yīng)該一直向他展示A方案，而不能一會(huì)兒讓他看A方案，一會(huì)兒讓他看B方案。同時(shí)，還需要注意控制訪問各個(gè)版本的人數(shù)，大多數(shù)情況下我們會(huì)希望將訪問者平均分配到各個(gè)不同的版本上。要做到這些很簡單，根據(jù)cookie（比如cookie會(huì)話ID的最后一位數(shù)字）決定展示哪個(gè)版本就是一個(gè)不錯(cuò)的方法。要實(shí)現(xiàn)A/B測試，我們需要做以下幾個(gè)工作：1、開發(fā)兩個(gè)（或多個(gè)）不同的版本并部署；

2、收集數(shù)據(jù)；

3、分析數(shù)據(jù)，得出結(jié)果。二：實(shí)踐方法從左到右，３條較粗的豎線代表了A/B測試中的３個(gè)關(guān)鍵角色：客戶端（Client）、服務(wù)器（Server）、數(shù)據(jù)層（Data）。從上到下代表了３種訪問形式：無A/B測試的普通訪問流程（NonABtest）基于后端分流的A/B測試訪問流程（Back-endABtest）基于前端分流的A/B測試訪問流程（Front-endABtest）。A/B測試需要將多個(gè)不同的版本展現(xiàn)給不同的用戶，即需要一個(gè)“分流”的環(huán)節(jié)。從上圖中我們可以看到，分流可以在客戶端做，也可以在服務(wù)器端做。傳統(tǒng)的A/B測試一般是在服務(wù)端分流的，即基于后端的A/B測試（Back-endABtest），當(dāng)用戶的請求到達(dá)服務(wù)器時(shí)，服務(wù)器根據(jù)一定的規(guī)則，給不同的用戶返回不同的版本，同時(shí)記錄數(shù)據(jù)的工作也在服務(wù)端完成?；诤蠖说腁/B測試技術(shù)實(shí)現(xiàn)上稍微簡單一些，不過缺點(diǎn)是收集到的數(shù)據(jù)通常是比較宏觀的PV（PageView）信息。雖然可以進(jìn)行比較復(fù)雜的宏觀行為分析，但要想知道用戶在某個(gè)版本的頁面上的具體行為往往就無能為力了?；谇岸说腁/B測試則可以比較精確地記錄下用戶在頁面上的每一個(gè)行為。它的特點(diǎn)是，利用前端JavaScript方法，在客戶端進(jìn)行分流，同時(shí)，可以用JavaScript記錄下用戶的鼠標(biāo)行為（甚至鍵盤行為，如果需要的話），直接發(fā)送到服務(wù)器記錄。下面，我將重點(diǎn)介紹一下我們在基于前端的A/B測試上的一些實(shí)踐。首先遇到的問題是如何分流的問題。對于大部分需求來說，我們希望各個(gè)版本的訪問人數(shù)平均分配?？梢愿鶕?jù)某一個(gè)CookieID來劃分用戶，比如“123.180.140.*.1267882109577.3”，可以根據(jù)這個(gè)CookieID的最后一位（在本例中是“3”）來劃分人群，比如單數(shù)的顯示A版本，偶數(shù)的顯示B版本。正確展示對應(yīng)的版本后，就要開始采集需要的數(shù)據(jù)了。當(dāng)前版本有多少PV（PageViews，訪問量），如果需要記錄這個(gè)數(shù)據(jù)的話，在正確版本加載完成之時(shí)就要發(fā)送一個(gè)打點(diǎn)信息。不過很多需求中，具體版本的PV的精確數(shù)值可能不是很重要，而且要收集這個(gè)信息需要多一次打點(diǎn)操作，所以一般情況下這個(gè)數(shù)據(jù)是可選的。必須的數(shù)據(jù)是測試區(qū)域內(nèi)用戶的點(diǎn)擊信息。當(dāng)用戶在測試區(qū)域點(diǎn)擊了鼠標(biāo)左鍵（無論這個(gè)點(diǎn)擊是點(diǎn)擊在鏈接、文字、圖片還是空白處），我們就需要發(fā)送一條對應(yīng)的打點(diǎn)信息到打點(diǎn)服務(wù)器。一般來說，這個(gè)打點(diǎn)信息至少需要包含以下數(shù)據(jù)：當(dāng)前A/B測試以及版本標(biāo)識點(diǎn)擊事件的位置點(diǎn)擊時(shí)間戳（客戶端時(shí)間）當(dāng)前點(diǎn)中的URL（如果點(diǎn)在非超鏈接區(qū)域，此項(xiàng)為空）用戶標(biāo)識（比如CookieID）用戶瀏覽器信息三：應(yīng)用例子今年，EA公司發(fā)布新版《模擬城市》（SimCity）游戲時(shí)，在網(wǎng)站做了一個(gè)A/B測試，以便試驗(yàn)轉(zhuǎn)化率在不同的布局下是否有變化。下面是兩個(gè)不同的版本：B版本與A版本的差別在于新版本刪除了Pre-Order