五分钟讲清楚 A/B 测试系统|测试系统|算法|调用

A/B测试是互联网行业比较热门的功能，通常是用于测试功能、页面样式、文案等的多版本优劣，并根据数据择优采纳。A/B测试是一个相对比较复杂的系统，今天我来跟大家分享一下A/B测试系统的运作方式，方便有需要的朋友作为参考。

什么是 A/B测试

A/B测试的本质是分离式组间实验，也叫分组对照实验。详细地来说，A/B测试实际上是：在产品正式迭代发版之前，为同一个目标制定两个（或以上）可行方案，将用户流量分成几组，在保证每组流量在控制特征不同而其他特征相同的前提下，让用户分别看到不同的方案设计，根据几组用户的真实数据反馈，科学地帮助产品进行决策。简单理解地话，就是高中课本也提到过的控制变量对照实验。

A/B测试通常由以下几个模块组成：

分组模块（分流模块）
实验管理模块
业务接入模块
行为记录分析模块

分组模块

分组模块，也叫分流模块，就是将流量分成多组。好的A/B分组方案可以让流量分配得更均匀随机，同时需要具备根据用户、地域、时间、版本、系统、渠道、事件等各种维度来对请求进行分组的能力，并且保证分组的均匀性和一致性。

一般来说，通用分流服务的用户唯一ID会根据不同终端采用不同的用户标识，目前通用做法为Web端(含PC以及APP端内的H5 )采用Cookieid，APP端采用设备ID (设备ID不同公司有各自生成算法，一般来说iOS会用IDFA，安卓采用Mac地址+AndroidID+IMEi )，小程序端采用openID作为唯一标识符。

如果需要做到多端联动，则需要通过用户的注册ID等其他信息进行IDMapping，建立平台真正的统一用户标识。

如果要设计分组模块，那么需要注意两个一致性：

①必须确保样本一致性：确保分配到不同实验方案的用户样本特征是一致的，在统计上控制单一变量原则，即所谓“随机均匀”；

②确保分流一致性：在分配到不同版本时应确保随机均匀分布，并且确保分流一致性（即同一客户多次进入同一个试验，访问的实验版本相同）。

实验管理模块

实验管理模块，主要就是指支持产品经理或运营等人员管理用户分组、变量、实验版本等的模块。

业务接入模块

接入模块的主要目的是方便在产品迭代优化的各个阶段整合A/B测试能力，对优化点做各种A/B测试。一般通过提供一个A/B测试SDK或者A/B测试Restful接口的形式供业务方使用。目前市面上对于业务接入模块有三种解决方案：

可行方案1：通过定制的A/BTest SDK来处理A/B测试业务

该方案需要开发A/BTest SDK，并将SDK整合到前端，A/B Test SDK会根据用户标识将用户划分到某个组，然后带着分组标识和服务端进行交互，进而完成A/B测试相关服务。

具体A/B测试服务与业务接口的交互实现方式可以是如下两种之一：

∙A/B测试服务下发两个不同的接口给A/B测试SDK，当用户请求时，根据用户的分组，分别调用不同的接口。

∙A/B测试服务下发同一个接口给A/B测试SDK，但是不同的分组对应的参数不同，当用户请求时，根据用户所在的分组，选择不同的参数来访问该接口(该接口会根据不同的参数获取不同的数据)。

可行方案2：在后端业务层增加相关组件来做A/B测试

该方案通过在后端接口层增加相关组件来处理A/B测试需求，该组件通过与A/B测试服务交互来完成A/B测试的功能，目前采用该方式的公司有Google，百度等，通过后端统一Router模块来处理A/B测试相关请求。相当于前端只需要把所有的数据传给后端，由后端的Router来统一划分组别，并根据组别去调用不同的接口服务。

这个方案的优点是模块化，Router解决所有与A/B测试相关问题，对A/B测试业务做调整不需要前端版本升级，只需要升级后端服务即可。但是Router层是整个A/B测试的核心，需要具备高并发高可用的能力，否则出现问题会影响A/B测试能力的发挥。

可行方案3：通过在算法业务层跟A/B测试服务交互来实现A/B测试能力，不需要前端和接口层做任何处理

这种方案比较适合算法类(推荐算法、搜索算法、精准投放等)相关业务做A/B测试，这里不展开细说。