作者:赵泽鑫 | QE_LAB
AB 测试的本质是对照实验,最早是运用在药物测试中的。自 2000 年谷歌工程师将这一方法应用在互联网产品以来,AB 测试越来越普及,已逐渐成为衡量互联网产品运营精细度的重要体现。一般想要执行一个 AB 测试实验,在产品正式迭代发版之前,为同一个目标制定两个(或以上)可行方案,将用户流量分成几组,在保证每组流量在控制特征不同而其他特征相同的前提下,让用户分别看到不同的方案设计,根据几组用户的真实数据反馈,科学地帮助产品进行决策。
举个例子:
某付费产品想要知道购买按钮颜色是黄色的转化率高还是绿色的转化率高,可以发布产品的时候设置 AB 实验,一部分人看到的是黄色按钮,另一部分看到的是绿色按钮,分别收集黄色按钮的购买率和绿色按钮的购买率,最后得到结果。
看上去 AB 测试是一种简单的对照实验,收集数据分析数据得到更好的结果。那么 AB 测试的原理是什么呢?这样的实验难道不会被随机性影响嘛?真正合理的实验需要具备哪些条件才能让结果更加可靠呢?AB 测试是一种科学的评估手段,具备概率统计学理论的支撑。 概率论中有一个中心极限定理,意思是独立同分布的随机变量的和服从正态分布。对于 AB 测试,我们比较的是两组样本的平均表现,AB 测试保证 AB 两组某个因素不一样 (这个就是我们要验证的优化点),AB 两组其他很多未知影响因素一样 (这些因素是独立同分布的随机变量),当 AB 两组样本足够多时,这些其他因素产生的效果是满足同一正态分布的,因此可以认为对要验证的变量的作用是相互抵消的,这样待验证因素 (即我们的控制变量) 的影响就可以比较了,因此我们就可以通过实验来验证优化是否有效。
根据原理来看,执行 AB 测试的产品需要有足够多的用户,只有当样本量足够多的时候,才能满足未知因素对验证变量的作用相互取消。从而得到相对准确的结果。查看更科学更详细的原理请点击:https://zhuanlan.zhihu.com/p/458187994/ 。当然除了样本量外,实验周期也是十分重要的影响因素,在开展实验的时候存在两种情况,一种是给定流量比例判断实验周期;例如我们预计可以利用 100w 用户流量进行实验,我们就在现有的用户中按照相同规则选出 100w 用去流量去求其按天计算的标准差、均值等数字特征,在套用到公式中( https://zhuanlan.zhihu.com/p/492614164 )。求出的就是要满足一定的置信水平和功效水平所需要的实验天数。另一种是给定实验周期判断所需要的样本量:如果我们一定要在 x 天内得到可靠的实验结果,此时就是倒挤出多大样本量才能有这样的天标准差(每天样本量越大,观测指标的波动越小,实验天数需要的就越少)。
一、 算法(推荐、搜索、精准广告)
可以使用 AB 测试来验证算法是否达到预期,包括推荐算法,推荐结果是否得到更多人的点击;搜索算法,搜索结果是否更加准确,得到用户使用;广告推荐算法是否得到了更高的购买转化等;分组后,让不同组的用户使用不同的算法策略,对埋点数据分析后得到结果更好的算法进行使用。
二、 运营(验证运营策略)
AB 测试在运营中也被广泛使用,可以通过实验确定不同的运营策略产生的效果。例如,某产品上线一个营销活动,可以给用户提供价值 10 元的优惠券两张,价格是 10 元;同时还有另一种方案是价值 5 元的优惠券 4 张,价格也是 10 元。通过 AB 测试我们让不同的用户进入不同的营销策略中,通过监控两种活动的购买量来判断哪种营销方案更适合用户市场。
三、 UI 展示以及交互
UI 展示以及交互上的 AB 测试就相对来说比较容易理解,可以通过 AB 测试验证不同颜色的 UI 或者不同形状的按钮以及不同的交互逻辑,哪一种更适合用户。
业务接入主要是为了让 AB 测试系统和实际的业务系统便捷的进行组合,从而完成对业务进行 AB 测试的需求。如何接入还需要考虑到 AB 测试系统的架构问题,通常情况下采用提供 AB 测试 SDK 或者 AB 测试 Restful 接口的形式供业务方使用。业务接入模块要尽量做到高效易用且能够兼容不同的平台,app 端和 web 端,甚至要考虑不同编程语言导致的维护成本。
用户分组对于 AB 测试系统来讲是至关重要的,前面的统计学原理中有强调随机性,所以好的分组策略是要尽可能的保证用户分组随机性的同时还要考虑由于业务需求的不同而产生的分组因素,比如用户的位置信息、年龄、系统版本、应用使用时间等。
实验管理模块的目的是让运营人员或者开发人员方便快速的创建 AB 测试案例,增加新的 AB 测试分组,调整 AB 测试方案各个组的比例,让 AB 测试跑起来。同时也用于管理 AB 测试平台用户创建、权限管理,让用户具备编辑、拷贝、使用 AB 测试实验的能力,做到高效易用。
数据记录模块的主要功能是进行数据打点,当用户行为进入到了我们需要获取数据的逻辑中,就对数据进行收集,收集的数据整合成为更美观更可视化的图表。这样在实验运行的过程中就能实时或者定时获取到用户行为数据,为后续对实验结果的判定提供参考依据。
结果分析模块是用于跟踪 AB 测试的效果,根据 AB 测试效果来做出业务、运营、算法调整的决策。AB 测试要评估出 A 方案和 B 方案的好坏,这时就需要一个较好的衡量指标了,一般可以采用播放量,点击量,浏览次数,转化率等指标进行评估。具体评估指标的定义需要根据自己业务特点、产品形态、功能点等来定义,指标能够方便量化,并能够直接或者间接跟产品体验、用户增长、商业变现联系起来。定义好各类效果评估指标后,最好可以将指标计算通用化、模块化,方便实验人员快速上线 AB 实验,根据不同产品及 AB 测试案例选择合适的指标。
通常情况下会存在很多个实验在同时进行,那么当存在多个实验的时候用户流量怎么分配呢?一般情况下会分成正交和互斥两种情况。正交指的是每个独立实验为一层,一份流量穿越每层实验时,都会随机打散再重组,保证每层流量数量相同。互斥实验指的是实验在同一层拆分流量,不论如何拆分,不同组的流量是不重叠的。两个或多个实验内容相互影响则选择互斥方法分配流量,两个或多个实验内容不会相互影响则选择正交方法分配流量。
AB 测试系统是一个相对比较复杂的系统,其本质是数据驱动业务。所以它能在很多方面给我们产品的设计和假设提供科学的数据支撑。当我们对业务设计方向不一致的时候可以借助 AB 测试推动决策,因为 AB 测试是有统计学作为理论基础,并且又有工业上的实践经验作为支撑,利用 AB 测试得到的结论具备极大的说服力。任何和用户体验、用户增长相关的优化想法,也可以借助 AB 测试来进行验证,从而推动产品向着更好的方向发展。