Growth Hacking：移动端 ABTest 在支付宝 App 内的落地与应用

| 导语

近年来，随着互联网的快速发展，Growth-Hacking 已是一个很广泛的概念。Growth-Hacking 的目的就是使用更小更灵活的成本经过数据驱动来挖掘产品增加的奥秘。同时在 AARRR 这个模型中，打形成一个不断优良循环的流程，须要从数据分析中发现产品功能、运营策略与转化之间的相关性，思考他们之间因果关系。

One accurate measurement is worth more than a thousand expert opinions

– Admiral Grace Hopper

如何衡量思考、创新想法的正确性？数据是最好的衡量标准，这就所以要求咱们须要运用一些工具。而 AB 测试就是一个快速试错，用户影响尽量小，经过数据科学决策的工具，它是 Growth-Hacking 最基础也是最重要的工具之一。

自 2000 年谷歌工程师将 ABTest 应用在互联网产品以来，A/B 测试在国内外愈来愈普及，逐渐成为互联网数据驱动产品的重要体现，经过 A/B 测试来驱动产品设计迭代优化。

什么是 ABTest

A/B 测试以数据驱动为导向，能够实现灵活的流量切分，使得同一产品的不一样版本能同时在线，经过记录和分析用户对不一样版本产生的行为数据，获得效果对比，最大程度地保证结果的科学性和准确性，从而帮助人们进行科学的产品决策。

ABTest 的主要组成部分

下图是一个通用的架构设计：

整个架构包含如下部分：

• AB 测试管理平台：实验操做门户，提供建立、修改、关闭实验等，而且提供报表查看。
• 配置数据库：实验配置数据，不只仅局限于普通的关系型数据库，也可能有缓存数据库等。
• 分流服务：根据实验配置数据，实验具体的分流逻辑，这个通常集成在各个业务平台或者业务服务器。
• SDK：提供通用的解析分流逻辑，通常集成于客户端，前端。
• 数据采集：分流结果日志，用户行为日志的实时采集。
• 数据分析：实时和离线数据分析，经过必定的数据分析算法作出科学决策。

ABTest 的统计学原理

从 A/B 测试的试验原理来看，它是统计学上假设检验（显著性检验）的一种形式：假设检验中的参数检验是先对整体的参数提出某种假设，而后利用样本数据判断假设是否成立的过程。

逻辑上运用反证法，统计上依据小几率思想：

• 小几率思想是指小几率事件（显著性水平 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 计算

AB 测试中 p-value 的计算和区间估计的计算是相对应的，这个里面咱们就利用双样本 Z 检验，简单说明一下 p-value 的计算公式：

• 均值类指标：

• UV 点击率/转化率等比率类指标：

根据 Z 值求 p 值，其实就是求标准正态分布的积分，求(z,∞)的N(0,1)的积分*2.

mPaaS ABTest

蚂蚁金服内部也有浓厚的实验文化，ABTest 实验平台已累计运行上万个实验：从支付宝客户端样式实验、交互实验到后端算法、策略实验都有着丰富的案例积累，在此过程当中 ABTest 平台也获得了深度锤炼和能力积累，愈来愈简单易用、成熟稳定、权威可信。

目前，ABTest 平台已完成产品化改造，并入驻到 mPaaS 产品体系中，为 mPaaS 的智能化能力构建提供了有力的支撑。

实验模型

在进一步介绍 ABTest 架构以前有必要讨论一下 ABTest 的实验模型：

流量的隔离和复用

同一批用户若是同时参与多个实验，实验场景之间若是是相关的，两个实验之间的结果就可能相互影响，致使实验结论不正确。所以咱们须要让同一个用户在同一段时间只能参与一个实验，从而避免多个实验致使的影响，称之为流量的隔离。

随着线上实验的增多，流量隔离避免不了流量不足以及流量饥饿的问题，这就对流量的复用提出了要求。

Google的层域架构

在 Google 2010 年发布的《Overlapping Experiment Infrastructure: More, Better, Faster Experimentation》 这篇文章中，主要介绍了 Google 的交叠实验架构，目的是可以提供一个 Better & More Faster 的实验平台。

关于 Google 提出的交叠实验架构，其核心是层域模型：

经过上图咱们能够了解层域模型的基础结构了，这类结构不只可以兼容单层实验和多变量实验，同时更具灵活性，能够对系统参数进行多种组合划分。

由于层域之间的复杂关系，这样设计虽然增长了灵活性可是同时使得业务方使用成本也大大增高，实际业务中主要仍是基于单层实验，当整个链路中，每一个分支都是相互独立，而每一个分支的子集划分也比较清晰，因此对域的需求并非很强。

ABTest 的领域模型

mPaaS ABTest 的领域模型：

mPaaS 上的 ABTest 经过“实验室”实现了一个分层，即每一个“实验室”都拥有独立的 100% 流量。因为实际业务的一个链路并无不少的参数而且参数间是否独立也是比较明确的，因此 ABTest 弱化了域这个概念。

• 实验室

100% 的流量入口。支持设置参数的默认值兜底。业务上相互独立的每一个业务应该拥有一个独立的实验室。

• 实验

每一个实验室下能够建立多个实验，实验间的流量是互斥的，达到流量隔离的目的。同时实验级别支持圈人定向条件，支持定向实验。

• 实验版本

一个试验下能够建立多个实验版本，实验版本上绑定实验参数的实验值。每一个版本的的流量分配经过和 10000 个 bucket 间的映射关系来分配。

ABTest 架构

从架构上来说 ABTest 分为接入层、核心能力层和底层依赖层，下面重点介绍下接入层和核心能力层。

接入层

接入层解决业务系统如何接入 ABTest 组件的问题，互联网业务的 ABTest 一般分为两类：客户端实验和服务端实验，接入层对这两类型实验都提供了支持。

客户端实验

客户端实验一般是针对客户端的样式、交互流程进行实验，从而帮助产品和研发团队进行更好的迭代和优化。

实验配置经过客户端动态配置服务（Remote Config）触达到客户端，客户端业务经过从本地 local cache 中取变量的方式，拿到分流结果对应的实验变量及值，作对应的差别化渲染，达到对不一样的用户提供不一样服务、体验的目地，同时动态配置（Remote Config）服务会记录分流日志，回传服务端。

H5 容器、小程序框架集成 Remote Config，经过 Hybrid API 暴露服务给 H五、小程序，这样客户端 Native、H五、小程序三大开发框架都具有了 ABTest 的能力。

服务端实验

服务端实验一般是对服务端策略、算法作实验，是 AI 能力迭代的基础。

性能、接入难度是服务端业务系统接入 ABTest 比较关心的问题。ABTest 将分流服务抽离出独立SDK，将实验配置信息保存在内存中，集成进宿主系统后能够提供本地的分流服务，避免了网络开销。同时SDK提供了简单易用的接口，下降了使用的难度。

下图是分流SDK和ABTest Console、宿主系统之间的关系：

集成分流 SDK 有必定的开发成本，须要业务系统接入。mPaaS 平台在各个流量入口组件中预置了分流 SDK 提供分流服务，简化了 ABTest 的接入工做：

网关服务 MGS 将分流参数在请求上下文中透传到业务系统中，业务系统能够直接使用 ； 发布服务 MDS 的 H5 离线包管理平台能够直接对一个 H5 应用的不一样版本作 ABTest； 智能投放 MCDP 能够支持对不一样广告投放效果作 ABTest。

核心能力

关于 mPaaS ABTest 的核心能力，它已经达到了一个通用 ABTest 系统所应有的标准，主要分为两部分：

实验能力

实验能力主要包括实验管理、指标定义、圈人定向、分流服务、灰度推全。咱们围绕“实验生命周期 & 科学流量分隔”着重展开：

• 一次实验的生命周期包含“建立实验、功能和链路验证、正式运行、逐步放量、全量推全”五个阶段。而在实验状态转换过程当中，流量的分配是否科学很是重要。
• 在一个实验室下，每一个用户经过 Hash 算法被绑定到 0~9999 号桶上，而实验版本保存对桶号的映射
• ABTest 经过将流量划分为空闲桶、回收桶、使用桶三种状态，在流量分配过程当中优先使用空闲桶，其次使用回收桶。在回收桶也分配完以后，整个实验室的流量已经使用完毕，须要同实验室下其余实验推全或者下线后，使用桶被回收后才能新建实验。ABTest系统在实验生命周期流转过程当中科学的分配、回收流量（即改变桶的状态）保证了流量分配的科学性，下降了对用户的打扰。

分析能力

分析能力包括实时的分流 PV/UV 统计，T+1 的实验显著性报表以及多维分析和对比分析。

实验分流数据分为客户端分流埋点和服务端 ABTest SDK 分流日志两种，分别经过日志网关和 flume 收集到 HDFS 中。实验效果统计经过 mPaaS 客户端 SDK 自带的自定义事件埋点经过日志网关和 flume 回流到 HDFS。

• 实时计算链路

数据经过 Kafka 导入 Kepler，kepler 任务进行分流日志和业务转化日志的双流 join，和实验 PUV 统计，最终将计算结果转储至 HBase，ABTest Console 展示结果。

• 离线计算链路

数据经过 flume 导入 HDFS，由离线计算平台进行离线指标的计算和 ABTest 元数据和结果的同步，数据回流Hbase, ABTest console 展示结果。离线链路用于计算利己显著性报表、自定义指标已经留存等计算量较大的场景。

• 即时分析链路

离线链路还会将预处理的部分数据回流到 LDAP 系统 Explorer，ABTest Console 利用 Explorer 作更为灵活的多维分析和漏斗分析

mPaas指标计算体系

针对 mPaaS 的客户端用户行为采起自定义事件进行埋点，用户只须要经过关联特定的自定义事件便可自动产生 T+1 的实验统计效果数据。以每一个用户为独立的实验个体，这里面咱们认为两个用户之间的行为是独立的，而用户在实验期间的每次行为是有相关性的，经过实验期间全部的用户行为进行统计分析。

对于除 sum 和 count 类指标咱们都会进行区间估计(计算指标统计的置信区间，实验方案间对比的绝对差置信区间和相对差置信区间),以及基于检验假设计算 p-value 给出显著性统计结论。

• 全局指标

实验期间进入各个方案的人数(累计 UV)和次数(累计 PV)做为基础的实验分流指标；另一部分全局指标为留存类指标，以用户第一次进入实验开始，在次日活跃则记为第二天留存，依次类推，咱们能够计算 2，3，...,7 日留存等。

• 简单型指标

简单型指标由单个自定义事件构成，在用户配置一个自定义事件以后，会自动生成对应的实验指标：包括 PV 总数(事件触发次数)，UV 总数(事件触发总用户数)，UV 转化率(实验用户中触发了该自定义事件的用户占比)，均值(触发总次数/进入实验方案的用户数)。

• 复合型指标

复合型指标是为了计算多个自定义事件组成的相关统计效果，在基础的集合运算中包含交并差除，那么咱们在复合型指标中也支持这四种运算。这里面咱们以两个自定义事件 E1,E2 为例：

并（E1+E2）：表示用户只要发生了 E1 或者 E2 即认为该用户触发了(E1+E2)事件，那么事件总触发次数即为触发E1总次数+触发E2总次数，其他相关指标计算就能够看作是一个简单型指标来进行处理。

交（E1*E2）：表示用户既触发了 E1，也触发了 E2，这个里面咱们能够基于单个 session 来看，这样事件触发总次数就是同时触发了E1和E2的总会话数也能够默认为 1(目前 mPaaS 直接认为 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 为每一个用户曝光次数，则

以上，是移动端 ABTest 的具体技术架构解析以及在支付宝内如何落地实践的总结。若是对 ABTest 感兴趣，你们能够进一步关注 mPaaS 后续文章及产品迭代更新。

往期阅读

《开篇 | 蚂蚁金服 mPaaS 服务端核心组件体系概述》

《蚂蚁金服 mPaaS 服务端核心组件：亿级并发下的移动端到端网络接入架构解析》

《mPaaS 核心组件：支付宝如何为移动端产品构建舆情分析体系？》

《mPaaS 服务端核心组件：移动分析服务 MAS 架构解析》

《蚂蚁金服面对亿级并发场景的组件体系设计》

《自动化日志收集及分析在支付宝 App 内的演进》

关注咱们公众号，得到第一手 mPaaS 技术实践干货

钉钉群：经过钉钉搜索群号“23124039”

期待你的加入～