讓產品有效迭代，前端A/B Testing的簡單實現

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的概念，而且站在前端的角度對其進行了實現，其中方案還沒徹底落地到實際項目中，後續落地到項目中去後可能會完善此文吧

重要的事情

若是您以爲這篇博客對您哪怕有一絲絲的幫助，微博求粉博客求贊！！！