客户端 ABTest 怎么玩？支付宝 App 落地与实践

关注

转载最新推荐文章于 2025-09-07 20:58:47 发布 3.4k 阅读 AI 写同款· GEO 优化 ›

教你如何对产品做AB测试（abtest）我们经常会面临多个设计方案的选择，比如app或pc端某个界面的某个按钮是用红色还是用蓝色，是放左边还是放右边。传统的解决方法通常是集体讨论表决，或者由某位专家或领导或文青来拍板，实在决定不了时也有随机选一个上线的。虽然传统解决办法多数情况下也是有效的，但A/B 测试（A/B Testing）可能是解决这类问题的一个更好的方法。所谓 A/B 测试，简单来说，就是为同一个目标制定两个方案（比如阅读详情

点击“开发者技术前线”，选择“星标?”

13：21 在看|星标|留言, 真爱

来自：mPaas

| 导语
近年来，随着互联网的快速发展，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 测试以数据驱动为导向，可以实现灵活的流量切分，使得同一产品的不同版本能同时在线，通过记录和分析用户对不同版本产生的行为数据，得到效果对比，最大程度地保证结果的科学性和准确性，从而帮助人们进行科学的产品决策。

1. ABTest 的主要组成部分

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

整个架构包含以下部分：

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

2. 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 的智能化能力构建提供了有力的支撑。

1. 实验模型

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

流量的隔离和复用

同一批用户如果同时参与多个实验，实验场景之间如果是相关的，两个实验之间的结果就可能相互影响，导致实验结论不正确。因此我们需要让同一个用户在同一段时间只能参与一个实验，从而避免多个实验导致的影响，称之为 流量的隔离。随着线上实验的增多，流量隔离避免不了 流量不足 以及 流量饥饿 的问题，这就对 流量的复用 提出了要求。

Google 层域架构

在 Google 2010 年发布的《Overlapping Experiment Infrastructure: More, Better, Faster Experimentation》这篇文章中，主要介绍了 Google 的交叠实验架构，目的是能够提供一个 Better & More Faster 的实验平台。关于 Google 提出的交叠实验架构，其核心是层域模型：

通过上图我们可以了解层域模型的基础结构了，这类结构不仅能够兼容单层实验和多变量实验，同时更具灵活性，可以对系统参数进行多种组合划分。
因为层域之间的复杂关系，这样设计虽然增加了灵活性但是同时使得业务方使用成本也大大增高，实际业务中主要还是基于单层实验，当整个链路中，每个分支都是相互独立，而每个分支的子集划分也比较清晰，所以对域的需求并不是很强。

ABTest 的领域模型

mPaaS ABTest 的领域模型： 640?wx_fmt=png

mPaaS 上的 ABTest 通过“实验室”实现了一个分层，即每个“实验室”都拥有独立的 100% 流量。由于实际业务的一个链路并没有很多的参数并且参数间是否独立也是比较明确的，所以 ABTest 弱化了域这个概念。

实验室

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

实验

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

实验版本

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

2. ABTest 架构

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

接入层

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

客户端实验

客户端实验通常是针对客户端的样式、交互流程进行实验，从而帮助产品和研发团队进行更好的迭代和优化。实验配置通过客户端动态配置服务（ Remote Config）触达到客户端，客户端业务通过从本地 local cache 中取变量的方式，拿到分流结果对应的实验变量及值，做对应的差异化渲染，达到对不同的用户提供不同服务、体验的目地，同时动态配置（ Remote Config）服务会记录分流日志，回传服务端。 H5 容器、小程序框架集成 Remote Config，通过 Hybrid API 暴露服务给 H5、小程序，这样客户端 Native、H5、小程序大开发框架都具备了 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 导入流计算引擎，流计算引擎进行分流日志和业务转化日志的双流 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 日留存等。

简单型指标 简单型指标由单个自定义事件构成，在用户配置一个自定义事件之后，会自动生成对应的实验指标：包括 p 总数（事件触发次数），UV 总数（事件触发总用户数），UV 转化率（实验用户中触发了该自定义事件的用户占比），均值（触发总次数/进入实验方案的用户数）。
复合型指标
复合型指标是为了计算多个自定义事件组成的相关统计效果，在基础的集合运算中包含 交并差除，那么我们在复合型指标中也支持这四种运算。这里面我们以两个自定义事件 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 为每个用户曝光次数， 640?wx_fmt=jpeg