ab测试实例「AB测试基础概念应用场景及入门指南」

编辑导语：AB测试这项技术最早被应用于美国的互联网市场，进入国内市场也不过6、7年时间。2000年左右，以谷歌为首的互联网企业开始采用AB测试的方法，运用数据帮助企业做决策管理，降低试错成本，促进业务增长。2010年以后，AB测试开始出现产品化的趋势，并成为企业决策的一项重要工具。

今天和大家分享一下关于AB测试的基础知识。

互联网行业变化很快，很多产品的迭代速度都是按周甚至是按天来的。无论是产品的优化方向，还是决策的制定，都需要有数据来说话。

目前，大部分产品迭代的方式，是直接将某版本发布给全部用户。一旦遇到线上BUG或者数据效果不好，就不得不紧急修复或者功能优化，有时甚至需要回滚到前一版本。

这对用户体验、项目进度影响是很大的，如何能解决这个问题呢？

AB测试能很好的避免这个问题。所谓AB测试，就是在正式发版上线前，将用户流量对应分成几组，让用户分别看到不同的方案设计，根据几组用户的真实数据反馈，进行数据效果的校验。

如果新版本数据呈现没问题，再考虑将新版本向全量放开，从而可以有效减少线上全用户发生事故的概率，提升用户体验。简单理解，其实就是初中学的对照试验。一组是对照组，一组是实验组。

哪些场景比较适合进行AB测试呢？

AB测试通常用在以下几个场景：

这是比较常见的场景。

不像功能的设计，存在着很多逻辑上的思路，经常还是可以确定哪种方案好，哪种方案不好。UI的优化，往往是很“艺术”层面的。往往看到真实数据前，谁也难以说明哪种设计能带来更好的数据效果。如下图：

上图就是一个颜色的变化，这种情况下比较适合通过AB测试完成最终方案的确定。

这个其实和UI层面的优化很类似。同一个按钮，叫【现在申请】还是【立刻申请】呢？

如何决策，还是交给AB测试吧~

页面布局，主要指的是同页面中的不同元素的排列方式。

4. 算法优化

算法优化，应该也是AB测试的一个重要场景。

上线前的算法，基本都是基于历史数据进行算法模型的训练、搭建。在本地模型效果再好，上线后也不一定有良好的表现。只有线上才是检验算法效果的决定性标准。

但谁也不能确保上线后的效果吧？那这时先用小流量做一些AB测试，是非常不错及通用的选择。

AB测试的基础概念也讲了一些，其中很重要的一个概念就是用户流量分组。实际落地时，是按照一定的规则，让用户随机访问某个版本，那具体该如何进行流量的分配呢？

关于流量分配，主要的要点有两个：同层互斥分配和分层流量正交。

每个分层都拥有全部流量。在同一个分层中，多个试验共用100%的流量，试验之间流量互斥。例如在同一分层中，试验1占用了40%流量，则试验2最多只可使用60%流量，以此类推。

有以下示意图：

当同时运行多个试验时，如果希望试验结果尽可能精确，需要确保试验之间互不干扰，则建议将试验建立在同一分层，同一个用户只会进入该分层中的一个试验。

2. 分层流量正交

分层意为复用用户流量，如果验1和试验2使用不同的分层，则试验1和试验2均可分配最多100%的流量。在此情况下，同一个用户将会同时进入试验1和试验2。

当两个试验处于不同层时，需要确保试验内容互不相关，否则将会干扰试验数据。

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

举个例子：假设我现在有2个实验，实验A（实验组标记为版本A1，对照组标记为版本A2）分布于实验层1，取用该层100%的流量；实验B（实验组标记为B1，对照组标记为B2）分布于实验层2，也取用该层100%的流量（要注意，实验层1和实验层2实际上是同一批用户，实验层2只是复用了实验层1的流量）。

如果把A1组的流量分成2半，一份放进B1组，一份放进B2组；再把A2组的流量也分成2半，一份放进B1组，一份放进B2组。那么两个实验对于流量的调用就会如下图所示。此时实验A和实验B之间，就形成了流量“正交”。

关于AB测试，今天就先分享这些。下篇文章将分享一下行业中AB测试系统的调研，看看各大厂商是如何将AB测试产品化的。

本文由 @冬至 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议。