相关概念 | 概念介绍 |
---|---|
AB实验 | A/B实验的基本思想就是在线上流量中取出一小部分(较低风险),完全随机地分给原策略A和新策略B(排除干扰),再结合一定的统计方法,得到对于两种策略相对效果的准确估计(量化结果)。 |
实验组、对照组 | 实验组和对照组是一组相对的概念,A/B实验通常是为了验证一个新策略的效果。假设在实验中,所抽取的用户被随机地分配到A组和B组中,A组用户在产品中体验到新策略,B组用户在实验中体验的仍旧是旧策略。在这一实验过程中,A组便为实验组,B组则为对照组。 |
对比说明 | 客户端实验 | 服务端实验 |
---|---|---|
实验描述 | 指通过客户端获取实验分组信息并控制配置生效的实验。 | 指通过服务端获取实验分组信息并控制配置生效或下发的实验。 |
特点及场景 |
要求启动就要曝光的场景,比如我们要针对APP的开屏页面进行A/B实验,用户刚刚打开APP,客户端就需要向用户展现开屏界面了。这种情况下客户端可能来不及向服务端请求配置参数。 |
|
对AB实验进行实验流量分配时,需结合实验目标、实验校验灵敏度等进行估算合适的流量数据,您可使用流量计算器进行估算,详情请参见流量计算器。
以下为互斥实验、流量正交的基本概念介绍,更多应用场景和配置操作指导请参见流量层与互斥域。
互斥实验,指的是互斥组中的所有实验都不会共享用户,开在同一流量层的多个实验中,流量只能命中其中一个,即同层实验的流量之间是相互排斥的。 如果一个用户/设备命中了实验A,就不会命中该互斥组中的其他实验。
基本原则:内容相同或相关、可能会彼此影响的实验,建议将实验加入到同一个互斥组中。举例, 您要同时做按钮颜色和按钮形状的实验,就需要将两个实验加入到一个互斥组。
假如现在有4个实验要进行,每一个实验要取用30%的流量才能够得出可信的实验结果。此时为了同时运行这4个实验就需要4*30%=120%的流量,这意味着100%的流量不够同时分配给这4个实验。
那么此时我们只能选择给实验排序,让几个实验先后完成,但是这样会造成实验效率低下。
实验层技术就可以完美解决这个问题:
实验层技术是为了让多个实验能够并行不相互干扰,且都获得足够的流量而研发的流量分层技术。
我们把总体流量“复制”无数遍,形成无数个流量层,让总体流量可以被无数次复用,从而提高实验效率。各层之间的流量是正交的,可以简单理解为:在流量层选择正确的前提下,流量经过科学的分配,可以保证各实验的结果不会受到其他层实验的干扰。
互斥组=互斥层=实验层
每个独立实验为一层,一份流量穿越每层实验时,都会随机打散再重组,保证每层流量数量相同。
如何理解流量正交?
举个例子。假设我现在有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之间,就形成了流量“正交”。
流量正交有什么意义呢?
我们可以发现,因为A1组的一半流量在B1中,另一半流量在B2中,因此即使A1的策略会对实验B产生影响,那么这种影响也均匀的分布在了实验B的两个组之中;
在这种情况下,如果B1组的指标上涨了,那么就可以排除B1是受A1影响才形成上涨。这就是流量正交存在的意义。
实验时长,也叫实验周期,是指实验开启的时长,一般为了避免不同时间段(工作日与周末)的用户行为差异,建议至少观察 2 个完整的实验周期。
例如,考虑工作日与周末影响时,实验周期至少需要一周,那实验开启时长建议为14天。
确定 AB 实验的实验周期需要考虑多个因素,包括实验目的、受众行为模式、业务需求等。以下是一些常见的考虑因素:
一般来说,AB 实验的周期可以从几天到几个月不等。在确定实验周期时,可以结合以上因素进行综合考虑,并根据实际情况进行调整。同时,在实验过程中,密切监控数据和效果,以便及时做出决策并可能进行调整。
在开一个实验时,你需要通过一个标识来区分对照组和实验组,我们用参数来解决标识的问题。在A/B测试的实验中,每一个对照组和实验组可以有1个参数也可以有多个参数,每个参数都会有参数类型(目前支持String、Number、Boolean),每个参数还会有参数值。
更多实验参数的配置指导请参见如何配置实验参数。
在实验正式开启之前,通常需要先选择几名用户进入测试阶段(实验调试),观察实验是否能够正常获取想要收集的数据,或客户端是否有bug等。参与这一步的用户被称为“白名单用户”。
更多白名单用户的介绍和配置指导请参见用户测试白名单。
方差的计算公式:公式中 x̅ 为数据的平均数,N为数据的个数,s²为方差。
开设A/B实验,顾名思义,我们至少需要一个A组和一个B组,那么究竟是什么决定了哪些用户被实验命中,以及哪些用户进入A组/B组呢?就是靠A/B实验分流服务。
分流服务的任务是对用户进行随机抽样,并均匀地分配到实验组和对照组中,使其生效不同的功能。
我们先来把分流服务看作是一个“黑盒”。也就是说,抛开分流服务具体包含了什么样的流程和逻辑,先将分流服务看作是一个整体。接着,我们通过输入输出来解释它的工作原理:
以最简单、通俗的话来说:实验中,我们向分流服务发出请求(request),告诉分流服务用户是谁,随后分流服务就会告诉我们,这个用户是否被实验命中,以及用户被分到了哪个组里。
说明
分流服务在分配流量时,会先把每一层的流量平均分配为1000份,每一份被称为一个“哈希桶(bucket)”。为什么叫“哈希桶”呢?因为用户在进入实验层的时候,分流服务会通过「哈希函数」和「取模运算」,将用户分配到某个桶里。
「哈希」:Hash,一般翻译做散列、杂凑,音译为哈希。哈希函数可以把任意长度的输入,通过散列算法变换成固定长度的输出,该输出就是散列值。我们用人类的语言来解释一下这件事。在分流服务中,我们会将用户的uid/did,加上用户所在实验层的名字,组合在一起计算哈希值。比如,按照did分流的实验层上的实验,分流服务就会用“did:layer_name"做为输入值,经哈希计算后,得到一串固定长度的“数值串”。
「取模」:a Mod b,表示a除以b的余数。a除以b的余数,取值有0,1,2,3...(b-1)一共b种,因此取模函数常用来把一个数据集合分配成b份。在分流原理中我们要把流量分为1000份,因此我们对哈希函数的输出结果按1000取模,这样,已经通过哈希函数打散的uid/did就能都够随机分配到这1000个流量桶中了。
哈希和取模的目的,就是让用户能够随机、均匀地被分配到我们所分割的1000个桶里,且保障每次被分配到的是同一个桶。
经过分流服务的处理,我们把所有用户都扔进了桶里,那么这1000个桶里,每桶都有0.1%的流量。同一层上的不同实验在调用流量时,就会按照实验所需的流量的百分比,随机领取到不同数量的桶(且桶不重合)。
假设我开设的实验调用2%的流量,那么我就会领取到20个桶。如果进入实验层的用户落在了这20个桶里,那么该用户就会进入接下来的流量筛选步骤;如果不在这20个桶里,则用户不会被实验命中。
为了保证流量的大规模复用,核心思想是流量分层,把流量划分为多个实验层(互斥组),并保持如下性质:
基本概念:
常见问题——出现跳组:
了解了分流服务的输入和输出之后,我们再看看分流服务内部到底是如何运作的。
第一步:检查白名单用户
首先,分流服务会检查实验层上,是否有实验配置了白名单用户。
白名单用户:在实验正式开启之前,通常需要先选择几名用户进入测试,观察实验是否能够正常获取数据,实验配置是否正常生效,或客户端是否有bug等。参与这一步的用户被称为“测试用户”。如果实验需要测试用户,则需要先提供各组测试用户的ssid/decisionid。
如果请求参数中的ssid/decision id,在某组的测试用户列表之中,且实验处于调试状态下,那么有且只有测试用户会命中该组,获得实验配置。
第二步:流量分桶
分流服务在分配流量时,会先把每一层的流量平均分配为1000份,每一份被称为一个“哈希桶(bucket)”。为什么叫“哈希桶”呢?因为用户在进入实验层的时候,分流服务会通过「哈希函数」和「取模运算」,将用户分配到某个桶里,详情可参见上文的流量分桶章节。
第三步:检验过滤条件
在这一步里,分流服务会根据实验所配置的过滤条件(filter),再次对流量进行过滤。符合过滤条件的用户会被实验命中,不符合过滤条件的用户则没有被实验命中。
第四步:计算分组
现在,我们要对被实验命中的流量进行分组。此时我们仍旧要借助「哈希函数」的力量。在这一步当中,我们会将用户的id和实验名作为输入值(如:“did:flight_name”),来运算哈希函数,并取模,把被实验命中的用户随机地分到不同的分组之中。
以上为代码调用顺序进行下钻的,实际的用户进组流程顺序,应该是倒着的:
第一步:判断用户是否为白名单用户。
**第二步:判断用户所属实验层。**判断实验的层分流,如果没有层分流,就进行下一步去分桶。有层分流的情况下,对用户分流的 decision_id 进行hash的时候加入 layer 参数进行分桶。
**第三步:判断进组不出组逻辑。**如果开启了进组不出组,先去查客户配置的第三方进组信息存储库。有的话,就返回存储库中的分流信息。没有的话,进行下一步。
**第四步:判断目标受众。**判断用户是否满足目标受众设置的条件。满足的话,继续向下执行。
**第五步:判断用户是否命中实验对应的桶。**对用户的 decision_id 进行hash,获取到用户所在的桶编号, 判断用户会否在实验分配的桶编号列表中。
**第六步:获取实验版本号。**每个实验版本都有自己对应的桶编号列表,用户落在哪个桶里面,就是那个版本的用户。落在没有实验版本对应的桶编号,就没有命中实验。
差异细分 | 客户端实验 | 服务端实验 |
---|---|---|
进组不出组 | 客户端实验默认进组不出组 | 服务端实验默认不会进组不出组,如果要用这个特性需要根据sdk接入文档实现相关接口 |
配置下发流程图 | ||
配置生效步骤 |
|
|
实验报告中的留存率指的是“按进组时间拆分的留存率”,是根据【用户首次进实验组的时间】作为起始,用户回到App作为回访,计算用户n日留存。
统计方式如下:
规则 | 处理逻辑 |
---|---|
分组方式 | 首次进入实验组的用户 |
归因方式 | 把留存用户按照进组时间划分,分别归因到首次进组的时间 |
回访规则 | 回到APP即视为回访。 |
举个例子说明:
- 第一天实验组A的用户数为:10000,第一天base_user为10000。
- 第二天实验组A的用户数为:10400,其中9200用户是第一天便已经在A中的用户,1200用户为当天新进组用户;第二天base_user为1200,第一天的次日留存为9200/10000=92%。
- 第三天实验组A的用户数为:10200,其中8000用户为第一天便已经在A中的用户,1100用户为第二天进入A中的用户,1100为第三天进入A的用户;第三天的base_user为1100, 第一天的2日留存为8000/10000=80%, 第二天的次日留存为1100/1200=91.67%。
- 然后分别把每个进入实验日期的指标用base_user进行加权平均,得到次日留存率、第2天留存率等。
当日"已进组用户" 表示当日曝光进组的总用户数,包括之前已进组的老用户和初次到访的"新进组用户"。
置信度区间就是用来对一组实验数据的总体参数进行估计的区间范围。
举个例子,我们现在开了一个实验来优化商品页面的用户购买率,其中采用了新策略B的实验组,购买率提升均值为5%,置信区间为[-3%,13%]。
怎么理解此处的置信区间呢?
由于在A/B实验中我们采取小流量抽样的方式,样本不能完全代表总体,那么实际上策略B如果在总体流量中生效,不见得会获得5%的增长。如果我们设策略B在总体流量中推行所导致的真实增长率为μ,那么在这个案例中,μ的真实取值会在[-3%,13%]之间。
值得注意的是,μ并不是100%概率落在这一区间里,在计算置信区间的过程中,我们会先取一个置信水平,计算这一置信水平下的置信区间是多少,A/B实验中我们通常计算95%置信度下的置信区间。回到刚刚的例子,我们就可以得知,μ的真实取值有95%的可能落在[-3%,13%]之间。
“多天累计指标”是所选实验日期范围内,对应指标多天合并的累计值。
举个例子,假如现在我们要看6月1日到6月3日,用户A、B、C的用户阅读数这一指标:
6月1日 | 6月2日 | 6月3日 | 多天累计指标 | |
---|---|---|---|---|
用户A | 13 | 0 | 16 | 29 |
用户B | 5 | 3 | 4 | 12 |
用户C | 7 | 8 | 12 | 27 |
上表中的数字关系很清晰地展示了多天累计指标与单日指标之间的逻辑(即加在一起)。
在A/B实验中,如果我们所检测的指标支持多天累计指标,那么我们基本上应该以多天累计指标为准,而不要过多关注实验周期内的单日指标。
多天累积数据意味着,随着实验的进行,实验的总体样本不断增加,实验的检验灵敏度在不断提高。
A/B实验的核心统计学理论是(双样本)假设检验。假设检验,即首先做出假设,然后运用数据来检验假设是否成立。需要注意的是 ,我们在检验假设时,逻辑上采用了反证法。通过A/B实验,我们实际上要验证的是一对相互对立的假设:原假设和备择假设。
利用反证法来检验假设,意味着我们要利用现有的数据,通过一系列方法证明原假设是错误的(伪),并借此证明备择假设是正确的(真)。这一套方法在统计学上被称作原假设显著性检验 null hypothesis significance testing (NHST)。
举个例子:
我们要针对某页面的购买按钮做一个实验。我认为:将购买按钮的颜色从蓝色改为红色,可以提高购买率3%。在这个实验中,我们想通过统计学检验的“原假设”就是“购买按钮改成红色不能提升购买率”;“备择假设”就是“购买按钮改成红色能够提升购买率”。这是一对互斥的假设。也就是说,实际上我们要证明的就是“改成红色不能提升购买率”是错误的。
在统计学中,我们用显著性水平(α)来描述实验者犯第一类错误的概率。
当某个实验组的指标是显著的,说明这个实验结果大概率是可信的。这个概率是95%,也就是说,系统有95%的信心确认这个实验结果是准确的。
显著性水平存在的意义是什么?
一个按钮从蓝色改成红色,一个窗口从左边移到右边,到底用户体验会变好还是变差呢?我们并不确定,因此我们试图使用A/B实验的办法,帮助我们转化这种“不确定”——观察小流量实验中新旧策略的表现,从而确定新旧策略的优劣。
但是,这样就能完全消除不确定性了吗?答案是不能,因为存在抽样误差。
- 举个例子,假设瑞士人均收入为中国的十倍,那么随机抽三个瑞士人和三个中国人,能保证样本里这三个瑞士人的平均收入是三个中国人的十倍吗?万一这三个中国人是马云,王健林和一个小学生呢?
- 反过来想,假设在1%的流量下,组A(按钮呈红色)比组B(按钮呈现蓝色)购买率高,将流量扩大至100%,能保证策略A的表现仍旧比策略B出色吗?显然,我们还是不确定。
抽样误差带来的不确定性,使得我们在做小流量实验时,永远没法保证结论是完全正确的。幸运的是,对于抽样的不确定性,在统计学中,我们有一套方法来量化这种不确定性到底有多大,这便是显著性水平(α)存在的意义。
在统计学中,统计功效 = 1 - 第二类错误的概率,统计功效在现实中表现为:我的新策略是有效的,我有多大概率在实验中检测出来。
在实验的过程中,我们所抽取的样本流量实际上与总体流量会存在些许的差异,这些差异就决定了我们通过实验得出的结论或多或少会存在一些“误差”。
举个例子,实验中,我通过改变落地页的颜色让购买率提升了3%,但是因为样本流量并不能完全代表总体流量,有可能“我改变颜色这一策略其实没用,购买率提升3%是抽样结果导致的”。
那么发生这种“我的策略其实没用”事件的概率有多大呢?在统计学中,我们会用“显著性水平(α)”来描述发生这一事件的概率是多少。而置信度=1-α。
在「A/B 测试」产品上,根据业界标准,显著性水平α取0.05。在A/B实验中,如果发生“我的策略其实没用”这一事件的概率小于0.05,我们即称实验结论已经“统计显著/可置信”。这意味着你采取的新策略大概率(A/B实验中意味着大于95%)是有效的。相反,如果这一事件的概率大于0.05,则称实验结论“不显著/不可置信”。
显著性水平的理论依据便是中心极限定理。我们可以量化抽样误差的根基在于中心极限定理的存在。
什么是中心极限定理?
- 由于存在抽样误差,我们每次实验所得到的指标结果,都可能与我们期望得到的真正结果有误差。假设我们从总体中抽取样本,计算其指标的均值,每一次计算,样本均值都会受抽样误差影响。假如我们做无数多次实验,那么理论上,这无数多个样本均值中,总应该有一个是“真的”,不受抽样误差影响的,这个值在统计学里被称为“真值”。
- 中心极限定理定告诉我们,如果我们从总体流量里不断抽取样本,做无数次小流量实验,这无数次抽样所观测到的均值,近似呈现正态分布(就是下图这样的分布)。这个分布以真值为中心,均值越接近真值,出现的概率就越大;反之均值越偏离真值,出现的概率就越小。
PS:此处为了便于理解,放弃了阐述统计学概念,仅从A/B实验场景下出发,解释中心极限定理。
为什么样本均值越接近真值,出现的概率越大?
举个例子,如果从全中国人这个总体中,抽取很多很多次样本,计算很多很多次平均收入。
可以预见,我们会因为样本不同而得到很多个不同的平均收入值。这些数值确实有可能因为偶然抽到顶级富豪而偏高,或因为抽到极贫困的人口而偏低。但是,上述两种情况毕竟是少数(均值越偏离真值,出现的概率小)。随着抽样次数增多,我们会发现,平均收入落在大多数普通人收入范围内的次数,会显著增多(均值接近真值,出现的概率大)。并且,有了中心极限定理的帮助,我们可以知道每个均值出现的概率是多少。
假设您对某指标的预期目标提升率为1%
- 如果此时MDE=0.5%,MDE < 预期提升值,说明指标变化真的不显著,请结合业务ROI和其他维度里例如用户体验、长期战略价值等来综合判断是否值得上线;
- 如果那此时MDE=2%,MDE > 预期提升值,说明当前能检验出显著性的最小差异值是2%,由于灵敏度(也就是校验效力)不足未能检测出。这种情况下建议增大样本量,例如扩大流量、再观察一段时间积累更多进组用户,指标还有置信的可能。