推荐策略产品经理实操（五）：AB 试验

大俗大雅 2023-07-31 20:44:14

在产品做一个功能或需求时，听到最多的疑问就是：你这个功能/需求能带来的收益是什么？收益能有多大？那我们怎么去衡量一个需求带来的实际收益？这个时候，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万+是比较置信的流量，数据量过少不能输出置信的结果。