聊一聊：AB测试系统如何从应用到搭建？

增长团队有三宝：埋点、漏斗、AB测。本文给大家讲讲，AB测试系统如何从应用到搭建？

A/B 测试是一种产品优化方法；为同一个优化目标制定两个方案，让同一部分用户中的一部分用户命中 A 方案，同时另一部分用户命中 B 方案，统计并比较不同方案的点击率、转化率等数据指标，通过不同方案的数据表现，在确定数据表现通过假设检验后，决定最终方案的实验方法。

AB测试是支持数据决策最有力的工具。

以下为最基础的数据驱动流程，方案验证即为AB测试过程，实验才是检验真理的唯一标准。

两个策略是同时投入使用的，而不是AB两种策略分先后上线，这样会有其他因素影响。

两个策略对应的使用群体需要保证尽量一致。

（1）正交实验

每个独立实验为一层，一份流量穿越每层实验时，都会随机打散再重组，保证每层流量数量相同。

（2）互斥实验

实验在同一层拆分流量，不论如何拆分，不同组的流量是不重叠的。

（3）什么情况下正交、互斥分配流量？

我们刚刚就用的正交流量分配方式，导致了错误的数据结果，如果那个实验我们用互斥的流量分配方法就完美的解决了这个问题。

AB测试实验中招商会邀请函，两个或多个实验内容相互影响则选择互斥方法分配流量，两个或多个实验内容不会相互影响则选择正交方法分配流量。

（4）举个例子

在详情页面上做两个实验：

如果我们使用正交分配流量的方式会出现什么情况呢？

也就是流量同时命中实验一与实验二，最后展现在用户面前的就是如下图四种情况，这种情况我们是无法统计出准确的数据结果的，因为已经违背了单一变量原则。

这种最好使用互斥来分配流量，一部分用户命中实验一、另一部分用户命中实验二。

AB测试系统实验架构包括：应用层-实验层-策略层。

（1）应用层

应用层级别最好，应用层与应用层之间的流量是正交的。

（2）实验层

实验层是应用层子层，实验层与实验层之间的流量是互斥的。

（3）策略层

策略层是实验层子层，一个实验可以有多个策略，多个策略之间流量相互不影响。

举个例子：

创建实验时一般先设置好实验条件和统计指标

实验条件：AB测试系统可以对一些条件的用户进行限制，城市、年级、新老用户、版本号、平台（iOS、Android、h5）。这里我们完全可以直接引入用户画像系统直接进行人群定向取做AB测试实验。传送门：《用户画像如何从搭建到应用实战？》

这个功能主要是针对满足这样实验条件的用户进行分流，如不满足这些条件则不分流，直接命中默认策略。默认策略是我们在创建策略时勾选的，如果用户不满足条件命中默认策略，这些用户产生的数据是不参与计算的，也就不会影响实验结果。

（1）城市、年级、新老用户

这几个条件很好理解，就是指用户所在城市、年级、新老，但需要用户登录才能拿到这样的信息。

如果设定了实验条件，用户处于非登录态怎么办呢？

非登录态的用户我们认为他是不满足实验条件的，所以会走默认策略，这样会避免一些不满足实验条件的用户却命中实验的可能。但为了保证同一个用户在登入登出看到的页面是相同的，所以这部分人即使登录后也会走默认策略。

但不是全部未登录用户都会这样，我们判断当前时间与未登录用户刚登录的时间点的差值是否大于两天。

如果大于两天我们会让他命中实验，进行分流，这样也是为了保证每天下载的大量用户也会命中AB测试的情况，达到一个平衡的状态。

（2）适用版本

这里的版本是针对客户端的AB测试提供的功能。

比如：iOS 在1.0.1 版本，Android在1.0.2版本上线一个AB测试实验。

如果不绑定版本号会出现什么情况？

因为版本发布，除强制升级外，用户还处于老版本。对于老版本的用户也会命中实验，但是这些用户并没有看到不同的策略，就会出现，AB测试系统分给用户A策略，但是用户看到的是B策略，最终影响数据准确性。

版本号设置会向上兼容，也就是说只有此版本号，或者高于此版本的用户才能命中实验。

（3）平台

平台分为3种，分别为：iOS客户端、Android客户端、JS（H5）

分别针对不同的平台进行的AB测试。

这里不说iOS和Android同学聚会邀请词，只说一下H5，因为H5的埋点上报与客户端不一样，H5 的分流的唯一ID也与客户端不一样。客户端的分流使用的ID是设备ID，H5则是cookieID。

统计指标：

（1）对于AB两个策略上线后，我们需要跟踪两个策略的数据效果

这两个策略的效果数据来源就是页面的浏览与按钮的点击两个埋点事件来提供数据支持的。比如：客户端需要对课程详情页的报名按钮样式进行AB测试实验，数据监控的时候我们就需要统计进入详情页的人数与报名按钮点击uv进行统计。

以报名按钮uv/详情页uv此数值来统计报名按钮样式的AB两种策略效果，那么在创建实验时就需要确定统计指标，确定指标后就需要确定实验所需要哪些埋点指标统计。这里就需要详情页uv以及报名按钮uv两个埋点事件

当然还有更负责的数据指标，但都可以通过埋点数据上报来进行统计。

（2）计算方式

假设一个漏斗中包含了 A、B、C、D、E 五个步骤，选择的时间范围是 2015 年 1 月 1 日到 2015 年 1 月 3 日，窗口期是 1 天。那么，如果用户在2015年1月1日到2015年1月3日触发了步骤 A，并且在步骤 A 发生的 1 天内，依顺序依次触发了 B、C、D、E，则视作该用户完成了一次成功的漏斗转化。

在这个过程中，如果穿插了一些其它的步骤或者行为，例如在满足时间限制的情况下，用户的行为顺序是 A X B X C D X E，X 代表任意一个事件，则该用户依然视作完成了一次成功的漏斗转化。

如果该用户在这个事件限制范围内，依次触发了 A B C E，则该用户没有完成该漏斗的转化，并且会被记作步骤 C 的流失用户。

考虑一个更复杂的情况，如果一个用户在所选时段内有多个事件都符合某个转化步骤的定义，那么会优先选择更靠近最终转化目标的事件作为转化事件，并在第一次达到最终转化目标时停止转化的计算。

假设一个漏斗的步骤定义是：访问首页、选择支付方式、支付成功，那么不同用户的行为序列及实际转化步骤（标红部分）见如下例子：

分流策略：简单的理解就是哪些用户会命中策略A，哪些用户会命中策略B。

在说分流策略之前先举个例子，配合例子更好理解。

假设报名按钮颜色实验分50%流量，策略“红色”按钮分流量40%，策略“蓝色”按钮分流量60%

例如：取模10000，那报名按钮颜色实验的数字区间为0-5000；10000*50%。

策略“红色”按钮数字区间为0-2000；5000*40%。

策略“蓝色”按钮数字区间为2000-5000；2000+5000*60%。

现在我们对用户唯一id，应用id进行哈希。哈希后得到一个数字，这个数字落到哪个数字区间就将用户分到哪个策略中去。经测试10w次分流，8s，流量diff在1%以内，每个应用分到的用户正交，不相互影响。

如图：

AB测试系统和App服务端或H5服务端对接，分别有两个接口：一个是策略请求接口、一个是埋点接口。

AB测试系统将接口参数传给服务端，服务端将参数传给客户端和H5前端。

客户端或者前端遍历这些 eventids（埋点事件id）如果有用户命中这些埋点事件则上百 abtestid key及值。

例如实验是客户端报名按钮“红色”、“蓝色”。

当流量进入到客户端后， 客户端向服务端询问：我这有俩颜色的按钮，我要展示哪个颜色的按钮啊？

服务端：我暂时也不知道，我帮你问问AB测试服务。

服务端问AB测试服务：客户端来流量了，有两个颜色的按钮，需要展示哪个颜色的按钮啊？

AB测试服务：展示“红色”按钮。

服务端：我知道了，并告诉客户端：展示“红色”按钮。

客户端：我知道了，客户端展示“红色”报名按钮。

AB测试 是典型的通过样本数据估计总体数据效果的方法，所以为了避免出现小概率错误，我们需要对AB测试的结果进行假设检验。

AB测试的假设检验一般为两个总体成数的假设检验，具体可看《一文读懂假设检验怎么做》

作者：斑马，如有问题请加微信 13126701193

本文由 @斑马 于。未经许可，禁止转载

题图来自Unsplash，基于CC0协议