让产品有效迭代，前端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的概念，而且站在前端的角度对其进行了实现，其中方案还没彻底落地到实际项目中，后续落地到项目中去后可能会完善此文吧

重要的事情

若是您以为这篇博客对您哪怕有一丝丝的帮助，微博求粉博客求赞！！！