点击“开发者技术前线”,选择“星标?”
13:21 在看|星标|留言, 真爱
来自:mPaas
| 导语近年来,随着互联网的快速发展,Growth-Hacking 已经是一个很普遍的概念。Growth-Hacking 的目的就是使用更小更灵活的成本通过数据驱动来挖掘产品增长的奥秘。同时在 AARRR 这个模型中,打造成一个不断优良循环的流程,需要从数据分析中发现产品功能、运营策略与转化之间的相关性,思考他们之间因果关系。
| 什么是 ABTest
1. ABTest 的主要组成部分
下图是一个通用的架构设计:AB 测试管理平台:实验操作门户,提供创建、修改、关闭实验等,并且提供报表查看。
配置数据库:实验配置数据,不仅仅局限于普通的关系型数据库,也可能有缓存数据库等。
分流服务:根据实验配置数据,实验具体的分流逻辑,这个一般集成在各个业务平台或者业务服务器。
SDK:提供通用的解析分流逻辑,一般集成于客户端,前端。
数据采集:分流结果日志,用户行为日志的实时采集。
数据分析:实时和离线数据分析,通过一定的数据分析算法做出科学决策。
2. ABTest 的统计学原理
小概率思想是指小概率事件(显著性水平 p < 0.05)在一次试验中基本上不会发生。
反证法是指先提出假设,再用适当的统计方法确定假设成立的可能性大小;如可能性小,则认为假设不成立。
检验假设的基础概念
原假设:又称零假设,H0,通常我们都是假设对比实验中的两组统计量的统计值一样,即实验组的均值等于对照组的均值。
备择假设:也作对立假设,即否定原假设;实验组均值不等于对照组均值。
双侧检验与单侧检验:如果备择假设没有确定的方向即"≠",则为双侧假设。如果有特定的方向,包含“>” 或 “<”的则为单侧检验。
检验统计量:在检验假设时所使用的统计量称为检验统计量,比如样本组的均值。
接受域:使原假设接受的那些样本 (X1,X2,...,Xn) 所在的区域。
否定域:使原假设被否定的样本构成的区域。
简单假设与复杂假设:不论是原假设或者备择假设,只包含一个参数则为简单假设,否则为复杂假设。
两类型错误
第 I 类错误(弃真错误):原假设为真时拒绝原假设;第 I 类错误的概率记为 α(alpha)。
第 II 类错误(取伪错误):原假设为假时未拒绝原假设。第 II 类错误的概率记为 β(Beta)。
真实情况\实际决策 | 接受 H0 | 拒绝 H0 |
H0 为真 | 正确判决 | 第一类错误 |
H1 为真 | 第二类错误 | 正确判决 |
功效函数:设 R 表示一个检验的拒绝区域,
显著性水平和统计功效
显著性水平:显著性水平是指在原假设为真时而被拒绝的概率或者风险,也就是发生类型一错误的概率 α。通常在 AB 测试中,我们设置显著性水平为 0.05,当求得的 p-value 即 p<=0.05,那么拒绝原假设;p>0.05,那么不能拒绝原假设。
统计功效:统计功效,简单说就是真理能被发现的可能性。就像胰岛素能降低血糖这事是真实存在的,但人类能发现它的概率是多少?如果统计功效是 0.8,就是说人类有 80% 的概率能发现它。它的数学定义可用一个公式来概括,统计功效=1-β。
p-value 计算
均值类指标:
UV 点击率/转化率等比率类指标:
| mPaaS ABTest
蚂蚁金服内部也有浓厚的实验文化,ABTest 实验平台已累计运行上万个实验:从支付宝客户端样式实验、交互实验到后端算法、策略实验都有着丰富的案例积累,在此过程中 ABTest 平台也得到了深度锤炼和能力积累,越来越简单易用 、成熟稳定、权威可信。 目前,ABTest 平台已完成产品化改造,并入驻到 mPaaS 产品体系中,为 mPaaS 的智能化能力构建提供了有力的支撑。1. 实验模型
在进一步介绍 ABTest 架构之前有必要讨论一下 ABTest 的实验模型:流量的隔离和复用
同一批用户如果同时参与多个实验,实验场景之间如果是相关的,两个实验之间的结果就可能相互影响,导致实验结论不正确。因此我们需要让同一个用户在同一段时间只能参与一个实验,从而避免多个实验导致的影响,称之为 流量的隔离。随着线上实验的增多,流量隔离 避免不了 流量不足 以及 流量饥饿 的问题,这就对 流量的复用 提出了要求。Google 层域架构
在 Google 2010 年发布的《Overlapping Experiment Infrastructure: More, Better, Faster Experimentation》 这篇文章中,主要介绍了 Google 的交叠实验架构,目的是能够提供一个 Better & More Faster 的实验平台。关于 Google 提出的交叠实验架构,其核心是层域模型:因为层域之间的复杂关系,这样设计虽然增加了灵活性但是同时使得业务方使用成本也大大增高,实际业务中主要还是基于单层实验,当整个链路中,每个分支都是相互独立,而每个分支的子集划分也比较清晰,所以对域的需求并不是很强。
ABTest 的领域模型
mPaaS ABTest 的领域模型: mPaaS 上的 ABTest 通过“实验室”实现了一个分层,即每个“实验室”都拥有独立的 100% 流量。由于实际业务的一个链路并没有很多的参数并且参数间是否独立也是比较明确的,所以 ABTest 弱化了 域 这个概念。实验室
实验
实验版本
2. ABTest 架构
从架构上来讲 ABTest 分为接入层、核心能力层和底层依赖层,下面重点介绍下接入层和核心能力层。接入层
接入层解决业务系统如何接入 ABTest 组件的问题,互联网业务的 ABTest 通常分为两类: 客户端实验和 服务端实验,接入层对这两类型实验都提供了支持。客户端实验
服务端实验
集成分流 SDK 有一定的开发成本,需要业务方系统接入。 在 mPaaS 平台各个流量入口组件中集成分流 SDK 提供分流服务,简化了 ABTest 的工作:
网关服务 MGS 将分流参数在请求上下文中透传到业务系统中,业务系统可以直接使用 ;
发布服务 MDS 的 H5 离线包管理平台可以直接对一个 H5 应用的不同版本做 ABTest;
智能投放 MCDP 可以支持对不同广告投放效果做 ABTest。
核心能力
关于 mPaaS ABTest 的核心能力,它已经达到了一个通用 ABTest 系统所应有的标准,主要分为两部分:实验能力
-
一次实验的生命周期包含“创建实验、功能和链路验证、正式运行、逐步放量、全量推全”五个阶段。而在实验状态转换过程中,流量的分配是否科学非常重要。
在一个实验室下,每个用户通过 Hash 算法被绑定到 0~9999 号桶上,而实验版本保存对桶号的映射
ABTest 通过将流量划分为空闲桶、回收桶、使用桶三种状态,在流量分配过程中优先使用空闲桶,其次使用回收桶。在回收桶也分配完之后,整个实验室的流量已经使用完毕,需要同实验室下其他实验推全或者下线后,使用桶被回收后才能新建实验。ABTest系统在实验生命周期流转过程中科学的分配、回收流量(即改变桶的状态)保证了流量分配的科学性,降低了对用户的打扰。
分析能力
实时计算链路 数据通过 Kafka 导入流计算引擎, 流计算引擎 进行分流日志和业务转化日志的双流 join,和实验 PUV 统计,最终将计算结果转储至 HBase,ABTest console 展现结果。
mPaaS 指标计算体系
复合型指标
复合型指标是为了计算多个自定义事件组成的相关统计效果,在基础的集合运算中包含 交并差除,那么我们在复合型指标中也支持这四种运算。这里面我们以两个自定义事件 E1,E2 为例: 并: E1+E2,表示用户只要发生了E1或者E2即认为该用户触发了(E1+E2)事件,那么事件总触发次数即为触发E1总次数+触发E2总次数,其余相关指标计算就可以看做是一个简单型指标来进行处理。 交: E1*E2,表示用户既触发了E1,也触发了E2,这个里面我们可以基于单个session来看,这样事件触发总次数就是同时触发了E1和E2的总会话数也可以默认为1(目前mPass直接认为1,即相交的计算我们主要查看uv的转化),其他相关指标计算就可以看做是一个简单性指标来进行处理。 差: E1-E2,表示用户触发了E1没有触发E2,事件总触发次数则是满足该条件的用户触发E1的总次数,其余相关指标计算就可以看做是一个简单型指标来处理。 除: E1/E2,这个我们成为转化类事件,最简单的例子就是E1事件表示某个按钮的点击,E2事件表示某个按钮的曝光,那么pv转化率就是sum(E1)/sum(E2)即pv-ctr,同样的uv转化率均值等口径也就清晰了。同样以曝光点击为例,在实际pv-ctr的方差计算时我们发现一个用户多次曝光之间其实是有相关性的,那么在计算实际方差的时候我们利用泰勒展开和E1,E2的协相关系数,对方差公式进行了优化: 假设 x1,x2,...xn 为每个用户点击次数,y1,y2,...,yn 为每个用户曝光次数,
---END---
选择”开发者技术前线 “星标?,内容一触即达。点击原文更多惊喜!
开发者技术前线 汇集技术前线快讯和关注行业趋势,大厂干货,是开发者经历和成长的优秀指南。
历史推荐
点个在看,解锁更多惊喜!