A/B Testing簡介
互聯網產品的迭代速度很快，往往一周一小發布，一月一大發布，產品提出的種種需求，哪些改動是提升產品體驗的，哪些是阻礙產品進步的，如果沒有數據可以參考，僅僅是靠拍腦袋的話，對產品成功與否來說是及其不嚴謹的，產品的成功不能只靠運氣或者可能，而是要以數據為依據，靠數據說話，A/B Testing是眾多數據中的一種。
所謂A/B Testing是可以幫產品快速檢驗變化有效的一種手段，比如PC站點的導航欄開始在左邊，一次產品迭代將它改到了右邊，如何檢測這次簡單的改動是否有效，如何判斷轉換率的提升，當然我們可以檢測上線后轉換率的變化，但是這種檢測不是最嚴謹的做法，更好的方法可能是：
將用戶平均分成兩組，一組使用舊的產品，一組使用新的產品，然后通過兩組用戶的數據對比，最終得出這次改動是不是有效的
這里的幾個特點是：
① 至少有兩個版本（一般來說兩個即可）
② 可動態控制到每個版本的流量
③ 能夠檢測到每個版本的轉換率，能收集數據
通過閱讀本文，可以了解到一個簡單的A/B Testing的前端實現方案的實現（多數A/B Testing還是基於服務器端的）
文中是我個人的一些框架&業務開發經驗，希望對各位有用，也希望各位多多支持討論，指出文中不足以及提出您的一些建議。
代碼地址：https://github.com/yexiaochai/mvc/
建議對此文有興趣的朋友先看這兩篇博客：
【移動前端開發實踐】從無到有（統計、請求、MVC、模塊化）H5開發須知
前端實現
做代碼實現的時候，首先抓住一個關鍵點：關注不同版本轉換率的變化，我們這里的轉換率便是訂單提交數據，所以這里可以得到一個結論（不同項目不一樣）
在創建訂單的時候需要記錄該次訂單來源於A方案還是B方案，這樣的話我們最終可以得到一個數據：
A方案今天創建了多少訂單，B方案今天創建了多少訂單，然后在微調不同方案的流量，這樣便能對比出這次改動是否有意義了
PS：一般來說，A/B Testing針對的是大流量頁面
本來A/B Testing可能還需要保證一個用戶進入一個頁面總是采用上次的方案，這個實現需要看你項目實際需要
根據以下需求，我得出了代碼要求：
① 有方案可以讓新老頁面同時可訪問
② 有方案控制新老頁面的訪問比例
③ 有方案得到各個頁面（方案）最終產生訂單的數據
這里我們依舊以list產品列表頁為例，我們可能還需要記錄進入不同方案的PV，這里可以使用百度統計類產品，自定義事件完成，我們這里不予關注
兩個方案同時存在
我們這里完成的第一個功能是兩個方案同時存在，這里我們做了一個事情：將原有的pages復制了一份出來，作為過去版本：
因為框架的便宜，我們可以在實例化時候做簡單操作便可以實現兩套代碼同時可訪問，比如我們這里讓url帶一個plan=b便訪問老代碼，我們這里做一個變化是將下面工具欄的位置放上去：
當然我不得不說這次改動十分傻逼，但是我們也料不到產品會如何出招啊，這里僅僅是舉個例子，我們這里只是簡單的改了下main.js的代碼：
1 (function () { 2 var project = './'; 3 var viewRoot = 'pages'; 4 5 6 //這里僅僅需要對list頁做A/B Testing 7 var viewMapping = {}; 8 var ver = 'ver/1.0.0/'; 9 var APath = 'pages/list/list'; 10 var BPath = ver + APath; 11 viewRoot = ver + viewRoot; 12 13 //默認最新方案 14 viewMapping.list = APath; 15 if (_.getUrlParam().plan && _.getUrlParam().plan == 'b') { 16 viewMapping.list = BPath; 17 project = './' + ver; 18 } 19 20 require.config({ 21 paths: { 22 //BUS相關模板根目錄 23 IndexPath: project + 'pages/index', 24 ListPath: project + 'pages/list', 25 CityPath: project + 'pages/city', 26 27 TemplatePath: project + 'templates', 28 29 BusStore: project + 'model/bus.store', 30 BusModel: project + 'model/bus.model' 31 } 32 }); 33 require(['AbstractApp', 'UIHeader'], function (APP, UIHeader) { 34 35 window.APP = new APP({ 36 //配置A/B Testing 37 viewMapping: viewMapping, 38 UIHeader: UIHeader, 39 viewRootPath: viewRoot 40 }); 41 window.APP.initApp(); 42 }); 43 })();
控制流量
我們這里要做的第二件事情是控制流量，這里如果想用戶第二次依舊保持上一次的方案，可以使用localsorage，我們這里邊簡單的使用隨機數控制吧，這里將上述代碼做了一個優化：
1 (function () { 2 var project = './'; 3 var viewRoot = 'pages'; 4 5 //這里僅僅需要對list頁做A/B Testing 6 var ver = 'ver/1.0.0/'; 7 8 //在這里設置比例參數，數字0-10，默認A方案為10，只使用最新方案 9 //a 方案所占比例為60% 10 var APlan = 6; 11 12 //產生1-10隨機數，如果條件滿足則為plan B 13 var abRandom = parseInt(Math.random() * 10); 14 if (abRandom >= APlan) { 15 project = './' + ver; 16 viewRoot = ver + viewRoot; 17 } 18 19 //如果url強制設置plan=b則使用老方案 20 if (_.getUrlParam().plan && _.getUrlParam().plan == 'b') { 21 project = './' + ver; 22 viewRoot = ver + viewRoot; 23 } 24 25 require.config({ 26 paths: { 27 //BUS相關模板根目錄 28 IndexPath: project + 'pages/index', 29 ListPath: project + 'pages/list', 30 CityPath: project + 'pages/city', 31 32 TemplatePath: project + 'templates', 33 34 BusStore: project + 'model/bus.store', 35 BusModel: project + 'model/bus.model' 36 } 37 }); 38 require(['AbstractApp', 'UIHeader'], function (APP, UIHeader) { 39 40 window.APP = new APP({ 41 UIHeader: UIHeader, 42 viewRootPath: viewRoot 43 }); 44 window.APP.initApp(); 45 }); 46 })();
於是我們做到了簡單的流量控制，這里控制60%訪問最新方案，40%訪問老方案。
數據記錄
我們這里完成的最后一步便是數據記錄了，根據之前我們的接口設計，我們完全可以在此加上一個通用的字段：
PS：這里不懂的請看此篇博客：【移動前端開發實踐】從無到有（統計、請求、MVC、模塊化）H5開發須知
head: { us: '', version: '1.0.0', plan: '' }
我們每次創建訂單的時候皆會將此參數傳給服務器端，包括版本、渠道，現在現在一個plan服務器端即可收集。
而這個plan的記錄方式有多種方案，可以釋放全局方法，或者將該參數注入給APP等方案，因為我們這里不會有接口提交，這里便略去。
結語
今天我們簡單的介紹了下A/B Testing的概念，並且站在前端的角度對其進行了實現，其中方案還沒完全落地到實際項目中，后續落地到項目中去后可能會完善此文吧
重要的事情
如果您覺得這篇博客對您哪怕有一絲絲的幫助，微博求粉博客求贊！！！
