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的概念，并且站在前端的角度對其進行了實現，其中方案還沒完全落地到實際項目中，后續落地到項目中去后可能會完善此文吧
重要的事情
如果您覺得這篇博客對您哪怕有一絲絲的幫助，微博求粉博客求贊！！！



本文轉自葉小釵博客園博客，原文鏈接http://www.cnblogs.com/yexiaochai/p/4892777.html，如需轉載請自行聯系原作者

總結

以上是生活随笔為你收集整理的让产品有效迭代，前端A/B Testing的简单实现的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。