编辑导语：在做产品功能或者需求时，时常会被人问到这个功能/需求能够带来多大的收益。但其实我们对于需求所能够带来的实际收益是不明确的。这时，AB test就能够协助我们衡量需求收益。本文主要对AB试验的大致逻辑和一些重要节点和概念进行介绍，希望对你有所帮助。

在产品做一个功能或需求时，听到最多的疑问就是：你这个功能/需求能带来的收益是什么？收益能有多大？那我们怎么去衡量一个需求带来的实际收益？这个时候，AB test就是协助我们衡量需求收益的好朋友。

一、AB test是什么？

专业术语说：AB测试的本质是分离式组间试验，也叫对照试验，在科研领域中已被广泛应用（它是药物测试的最高标准）。自2000年谷歌工程师将这一方法应用在互联网产品以来，A/B测试在国外越来越普及，已逐渐成为互联网产品运营精细度的重要体现。

现实业务使用中，我认为AB test就是保证2组或多组根据条件限制划分的用户在只有1个变量条件情况下，对分组用户的各项数据指标进行汇总，对比指标变化涨幅来确定试验好坏，并且伴随数据分析去发现问题，解决问题的一个过程；

二、AB test的使用场景

产品UI变动时，AB一下新的UI是否会给用户带来更好的交互体验和视觉感受；

新增功能，想给产品增加一个新功能，AB一下新功能能带来多少收益，后期还值得公司投入多少资源去做这一块。

推荐系统中，首页推荐/搜索/推送业务都会用到AB test：推荐上用来对比一个策略、一个模型、甚至增加或减少一路召回、增加或减少一个特征、或强插一路新内容冷启动；搜索加一个推荐业务模型、上一个意图识别服务，建一个自定义纠错库；推送给用户推的频率、推的内容、推的时间等等，这些都需要AB试验去协助决策。

使用场景很多，以上只是我在工作实践中遇到的需要做AB试验的场景。凡是涉及到单一变量的数据对比，在用户进行维度打散的情况下，万物皆可AB。

三、AB test怎么用？

1. 在业务中的生效逻辑

AB试验，既可以做客户端试验，也可以做服务端试验，下面就根据客户端和推荐服务端和AB试验平台的试验流程来讲一下其中的区别和生效逻辑：

客户端试验（左图），主要是说用户请求推荐时，客户端主动带着用户信息（app版本号、渠道号、新老用户、用户onlyid）去AB试验平台上获取用户的试验配置，试验平台会根据用户的onlyid进行哈希分流（这个下面有讲到）。

然后将用户分进对应的试验组，客户端会把用户的试验信息存在本地，每次用户打开app时会再去拉取一次配置，然后带着用户配置请求推荐接口，推荐会根据用户的试验配置返回对应的推荐列表。

而服务端试验（右图），则是将客户端请求试验平台变成了服务端请求试验平台获取用户试验配置，再返回对应的推荐列表。

2种试验方式各有利弊，客户端试验不需要再经过服务端获取用户配置就能直接请求AB试验平台，逻辑上相对简单些，但是缺点是客户端依赖版本更新，版本迭代较慢，试验全量起来比较慢，不好控制。

服务端试验的缺点则是需要在逻辑上多加一层去请求AB试验平台获取用户配置，但发版较快且不受客户端版本更新限制，试验全量比较好控制。

2. 业务指标建设

通常，我们做AB试验的时候，都会根据当下试验新增几个试验指标，当然，所有的试验都会带上大盘指标。根据公司业务和规划的差异，各公司的大盘指标都会存在差异，电商类产品多关注点击率、成交率、留存以及GMV等指标。

视频类产品多关注渗透率（完播率）、转化率等，资讯类产品多关注点击率、转化率、留存等。一般都会关注的大盘指标就是留存，留存又分进组留存和活跃留存。

业务指标建设的时候，主要会根据这个试验的初衷来设置，比如，我这个试验的目的是想提升点击率，那么，点击率的指标就是我此次试验的核心指标；如果试验是为了提升转化率，那么从开始到结束的每一步转化率指标，就是我们试验的核心指标。

当然，并非所有的试验都需要大盘数据增长才是好试验，而一些代码重构，或换系统等试验，多数需要保证大盘指标数据无下降即可。

3. 用户进组设置

试验平台是怎么将用户分配到某个试验组中的？简单来说就是桶位算法。

可以理解为将用户流量分为了100个桶位（现实中会分成1000个桶位或更多），假设我们要开一个10%流量的试验，需要对用户onlyid进行哈希取余，如果余数落在前10个桶位，用户就命中这10%的流量，否则就不命中实验，用户也就不会进这个实验组。

4. 试验层流量控制

AB试验可以单层，也可以多层，通常根据产品的用户量来决定是否采取多层试验，用户量较大，业务较多时，需要做的试验也越多，就需要通过多层试验模式去进行AB，实现流量最大化利用。

（1）单层试验

单层试验上，流量100%，每个试验的流量是互斥的，举例，试验1的用户，命中试验1，就不会再进同一个试验层上的试验2或试验3，在单层试验上，用户只能进一个试验的一个组，即便是对照组流量，也是如此。

每个试验的流量至少会分成2组，也有多组试验，有试验组和对照组，每个试验中的各试验组的流量分配可以均匀分配，也可以自定义分配。

（2）多试验层——分层流量

多层试验，可以理解是多个单层试验的组合，每个试验层就是上面说的单层试验，而试验层与试验层之间的流量是正交的，也就是说，在召回层的试验1和试验2的2个用户，在召回层是互斥的，但在粗排层，很有可能在一个试验中，而在其他层，可能又会中其他的试验，业务越复杂，试验层越多。

当两个试验处于不同层时，需要保证试验内容互不相关，也就是相同的试验配置需要开在一个单层试验层上互斥，否则将会干扰试验数据。通常，用户量大一些的公司，都会采取多试验层，这样试验流量也多，且各试验之间互不干扰。

四、AB test数据控制

1. AB试验的原理是什么？如何判断数据置信？置信区间怎么计算？

AB试验的原理就是统计对照组用户和试验组用户的样本数据（主要是样本平均数和样本方差），通过正太分布公式，计算试验组总体样本数据比对照组总体样本数据提升或下降的概率。

怎么判断一个试验的结果是否置信？这里需要讲到2个概念：P值（p_value）和置信区间（可以看一些专业的相关文章）。

什么是P值？P值也叫显著性水平，可以理解P值是一个概率，是一个统计学上的衡量指标，有很多算法都可以统计出P值，通常用的比较多的是双侧双样本T检验，Z分数算出来P值（这里不做过多介绍）。

知道本质是通过进组用户样本算出检验统计量，再通过统计量算出P值就可以了。是指在原假设为真的条件下，样本数据拒绝原假设这样一个事件发生的概率。

置信区间（Confidence interval）就是用来对一个概率样本的总体参数的进行区间估计的样本均值范围。置信区间展现了这个均值范围包含总体参数的概率，这个概率称为置信水平。

（1）显著正向举例

置信区间为: [0.356269%, 3.063578%]，p-value: 0.013292

试验版本样本均值对比对照版本的变化率为1.709294%。在95%置信度下，置信区间为[0.356269%, 3.063578%]，统计显著正向说明当前的样本容量条件下已经检测出试验版本优于对照版本。

（2）显著负向举例

置信区间为: [–0.161000%, –0.043200%]，p-value: 0.000682

试验版本样本均值对比对照版本的变化率为-13.064318%。在95%置信度下，置信区间为[-0.161000%, -0.043200%]，统计显著负向说明当前的样本容量条件下已经检测出试验版本劣于对照版本

（3）不显著举例

置信区间为: [-0.999858%, 0.989777%]，p-value: 0.992076
试验版本样本均值对比对照版本的变化率为-0.005041%。在95%置信度下，置信区间为[-0.999858%, 0.989777%]，置信区间一负一正,试验结果是非统计显著的

这里可以简单的理解为试验组与对照组之间样本的总体均值之差是一个范围，如果这个范围同正，那么试验就为显著正向，如果同负，那么试验就是显著负向，如果范围一正一负，就说明试验数据不置信。

2. 单天数据和多天数据怎么计算？多天数据用户去重？

大多数试验都需要开多天，我们观察试验数据的时候，既需要观察好几天的数据，也需要对比每一天的数据，每一天的数据计算就是根据指标计算方式来计算即可，但指标的多天数据展示并不丹丹是简单的多天相加这样。

例如求用户人均时长指标的多天数据，就会将多天的用户去重进行人均时长计算，或者其他指标用用户去重求均值的方式计算多天指标，这一步主要看业务指标的定义以及需要对比的数据是什么性质。

基本上就是天级加和求平均和用户去重计算均值这2种方式。

3. 存在数据波动

我们开试验的时候，有时候会遇到一些数据波动的情况，比如大盘数据今天是显著下降的，但是第二天数据有做平了，第三天又微降了，这种时候通常是因为试验流量太小，用户量太少导致的数据波动，解决的办法主要是扩大试验流量以及长期观察（一周左右），试验中每个试验组保证单天进组用户人数在10万+是比较置信的流量，数据量过少不能输出置信的结果。

五、根据实际业务试验改编举例

之前得一篇文章介绍过负反馈功能，那这里我们就以负反馈功能的增加作为AB试验实例进行扩展，这里就是新增功能AB，因为涉及到公司业务，因此以下试验内容做了细节调整；

1. 功能开发、埋点注册

这一步在前面的文章中讲过，主要就是功能的设计和相关埋点的设计和注册，后期需要分析的数据都需要在这一步准备好，因此这一步至关重要；

2. 试验设计

（1）试验内容

• 对照组：base（基线，没有负反馈功能）
• 试验组1：负反馈1（有负反馈功能）
• 试验组2：负反馈2（有负反馈功能，且新老用户都会触发1次引导）
• 试验组3：负反馈3（有负反馈功能，且只有老用会户触发1次引导）

（2）版本限制

appversioncode>=XXX（这里主要是针对客户端版本更新做限制）

（3）试验层

可以在多层试验中单独新建一个试验层进行试验；

（4）试验流量

XX%（这里需要提前计算我们需要的试验用户量当下一共有多少量，假设我们一共需要10万用户，而我们需要的版本用户目前一共有100万用户，那么我们的试验就需要开10%的流量）

3. 试验指标设置

这个试验对比大盘数据的影响我们在开始试验之前就能大概预测到不会有太大影响，因为同比功能覆盖率都不高。

但是还是需要确保该功能不会给大盘数据带来负向影响，主要还有对首页推荐的点击、转化指标是否有影响，基本上都是讲和功能可能会造成的影响对应的数据指标设置成试验指标就可以。

4. 取数分析

试验进行到一个置信的阶段（数据显著增长或下降或者用户量够多时间够长的情况下），我们就可以下试验结论。

而下结论之前我们需要去取数分析，这里是一个功能试验，那么就需要计算一下这个功能的覆盖率（使用功能的用户占数/这个功能的日活用户数），功能的数据转化（触发功能的用户有多少使用了这个功能），以及使用这些功能的用户的用户分群数据。

例如，1万个用户触发了这个功能，有9000个用户使用了这个功能，而9000个用户中男女比例为1：3，等等，这些细化数据都需要我们后期的分析，因为试验数据没有变化，不代表功能没有意义。

可能是这个功能在某一类用户群上有正向效果，在另一类用户群上有负向效果，然后正负效果相抵消了。这些细化分析都需要在做的时候考虑到。

5. 结论、优化方向

当我们细化试验数据以后，就可以对试验下一个结论，试验是正向还是负向，在某些用户上是正向，在某些用户上是负向。

这里对用户的分群可以是根据用户app版本、用户年龄段、性别、新老用户、用户渠道等等各种维度。得出结论后，如果不能上线或数据不是正向，我们就可以知道下一步的优化方向是什么，朝着优化方向继续进行AB试验或其他的操作，直到我们不再优化或迭代，这一个功能试验才算结束。

以上就是本次AB试验的大致逻辑和一些重要节点和概念的介绍。

加油，打工人！

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

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