数据应用系列-ab测试

公众号：一个数据人的自留地
作者介绍
前网易出口大数据产品经理一枚
负责过数据采集、bi系统、ab测试、画像平台等应用层平台搭建
酷爱健身、钟爱咖啡、喜爱摩托、热爱生活

01为什么需要ab测试

大家在日常工作中是否会遇到以下问题：1）产品经理提出一个竞品没有的功能，即便感觉自己引领了行业，但老版：“这个功能竞品都没有为啥要做？”好不容易说通了老板，到了开发大佬评审时：“这功能对用户好像没用啊，要想说服开发，又要经历一轮苦口婆心，心累！
2）新功能经历灰度发版后，上线之后数据增长下跌是否是因为这次功能或策略导致，要想拆分清楚，分析师小伙伴又要经历一次抽丝剥茧3）我有两个想法，但不确定哪个对用户更有效，如何能进行验证……
我们每天的工作都要处理各种各样的决策，而人们决策的方式会偏好自己习惯或者熟悉的方式，但往往结论与其相悖，要想以实际效果来驱动业务。
这就需要一个科学、并行、可操作的方法来验证每一种策略的可能性，这种方法就是我们今天要讲的A/B测试。近几年来随着用户增长，精细化分析概念的普及，作为核心方法的ab测试也仿佛成为了互联网圈小伙伴们必须掌握的基础技能之一。
Google、facebook、linkin、快手、字节等国内外大厂都把ab测试结果作为推动业务发展的基础。但ab测试方法具有一定的使用门槛，对于业务人员需要具备统计学、平台操作等相关知识；对于平台人员需要具备统计学、平台设计、数据采集、系统搭建以及异常问题处理等相关知识，乍一听起来，好像有点难度。别慌，听我慢慢给大家逐一阐述。

02ab测试与控制变量

AB测试的定义是指为Web或App界面或流程制作两个（A/B）或多个（A/B/n）版本，在同一时间维度，分别让组成成分相同（相似）的访客群组（目标人群）随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析、评估出最好版本，正式采用。

这条定义有几个关键词，同一时间、组成成分相同，随机访问，目的是尽可能的避免其他变量对实验产生的影响。看完这条定义，不知大家是否有些似曾相识。
我们初中上物理或生物课的时候，老师介绍过一种方法——控制变量法。控制变量法是指把多因素的问题变成多个单因素的问题,只改变其中的某一个因素,从而研究这个因素对事物影响,分别加以研究,最后再综合解决的方法。
该方法最早被设计出来是在进行科学实验时把多因素问题变成单因素问题来研究对事物的影响，目的是为了减少方差。

下面我们来举个例子说明一下控制变量法和ab测试有多么的相似：例1：某兴趣小组做了个实验，研究问题是种子生长情况收到什么因素影响，提出研究假设：种子生长情况是否收到洗涤剂影响，实验设计如下图：

例2：例如某app打算优化一下签到功能，研究签到功能的点击率受什么因素影响，假设：签到点击率是否受到文案的影响，实验设计如下图：

我们从实验流程角度来看两组实验：

| 实验设计 | 相同组成成分、相同时间下：1.对照组：展示签到2.实验组1：签到改为签到有礼3.实验组2：亲到改为签到得奖 | 相同光照、相同温度、湿度下：1.实验组：正常生长2.实验组1：加入中性洗涤剂 
3.实验组2: 加入复合洗衣液 
 | | 选取研究对象 | 相同组成成分的人 | 相同大小、相同品种的种子 | | 观测实验现象/数据 | 实验组1、2点击转化率均高于对照组 | 实验组1、2 生长受到抑制对照组正常生长 | | 得出结论 | 签到功能点击转化率受到文案影响 | 种子生长受到洗涤剂影响 |

是不是操作流程、设计理念有异曲同工之妙。虽然控制变量法已经被创造了百十年，但这个“古老”的方法也是后期设计实验、设计平台以及数据分析上的一个基本依据。

03ab测试有哪些优点

那么ab测试在实际运用的过程中有哪些优点呢？1.说服力：我觉得这个优点是首当其冲的，有些时候无论是产品、运营提的想法总会被开发diss，这需求有用么？嗨！有没有用上实验，用数据说话。这套操作下来简直是无形中给我们负责提需求的小伙伴们强有力的支持，长此以往，我相信开发大佬们也会对我们“言听计从”的。

2.降低风险：ab测试强调先验性，实验确定对用户有效果才会上线，避免了传统操作需上线以后观测数据的方式，对用户影响小的多，降低了“伤害”用户的风险 

3.符合科学原理：ab实验经过了科学的实验设计、科学的用户抽样、运用科学的统计方法及数据分析得出的结论并采用逐步全量进行上线的方式 

4.口径统一：实验组和对照组同时生效、同时展示、采用同样的指标口径进行计算，避免了后期实验结果上因口径不同导致的分歧 


04ab的基础知识及作用

ab测试是一种对比分析方法，通过样本对总体的估计，来识别出哪个版本对整体效果最好。下面我们一起看一下要学会ab测试方法需要哪些基础知识。
流量层可以理解为平行时空，每层人总数是一样的，通过算法进行随机打散，让同一个人在不同层有不同的顺序和标号以便进入到不同实验，规避掉实验上多因素造成的数据偏差，之所以引入流量层的作用是为了解决实验多而流量不够的问题，每层都可以运转实验，结束后流量释放。
正交&互斥正交&互斥是存在于流量层上，即实验用户同层互斥、不同层正交，通俗来讲就是实验已经占用的用户在同层不会被其他实验占用，但该实验中的用户在其他流量层会被占用，正交&互斥原则是实验设计时基本原则，为了避免实验与实验间互相影响。

均值：表示一组数据集中趋势的量数,在一组数据中所有数据之和再除以这组数据的个数，ab实验中涉及的均值为人均值和转化率，例如人均点击次数、ctr等，在ab测试里作为一个观测指标展示
方差：是指各数据与其均值的离差平方和的平均数，反应每个数据与均值的离散型或者波动性，在ab测试中是计算临界值的一个基本数据。
假设检验：又称统计假设检验，其作用是用来判断样本与样本，样本与总体差异是由抽样误差引起的还是本质差别引起的一种方法。
例如：汽车引擎新排放标准是平均值<20ppm，现某公司抽取10台汽车样本，其引擎排放水平为 15.6 16.2 22.5 20.5 16.4 19.4 16.6 17.9 12.7 13.9，判断该公司汽车是否符合新排放标准？
若要看排放是否符合标准，首先要建立原假设：排放不符合标准；其次要构造统计量进行相关数据的对比；再次要确定这10台汽车与标准是否具有显著差异，若无差异，最后得出结论。
所以综上假设检验通常需要以下步骤：
1.提出猜想，设定原假设和备择假设2.构造统计量，根据样本计算相关数值3.确定显著性水平，进行数据检验4.得出结论

常用的假设检验的方法有：z检验、t检验、f检验、卡方检验，我们可以根据下图来确定什么检验方式适合自己：

其中t检验和z检验为ab测试所使用的检验方式。
正态分布：正态分布是描述连续型变量值分布的曲线，表现形式为中间高两边低，可根据一组数据的均值和方差求得，根据其均值、中位数和众数的大小关系有以下几种表现形式：

若均值（μ）为0（y轴），标准差（σ）为1，则该分布又称标准的正态分布，其在横轴区间（μ-σ,μ+σ）内的面积为68.268949%，横轴区间（μ-1.96σ,μ+1.96σ）内的面积为95.449974%，横轴区间（μ-2.58σ,μ+2.58σ）内的面积为99.730020%。也就是说在这三个置信区间内的概率分别是68.27%、95.45%、99.74%，该概率又成为置信水平。
置信区间：是指用样本均值估计总体均值时允许的误差范围。例如我们要统计全人类的体重，因为无法统计每一个人，但是我们根据规则随机取各个国家1万人的体重求其均值μ，假定做了100组实验，就会有95组实验包含μ，5组不包含。用数学公式标识则为P(μ−1.96nσ<< span=””>M<< span=””>μ+1.96nσ)=0.95
p值：即发生某件事情的概率，是用来判断假设检验结果的一个参数，若p值很小则证明原假设发生的概率很小。因样本是从总体中随机抽取，所以不能确定样本的表象差别是否通过抽样误差引起，故需要从统计学角度来判断此次抽样是否有统计学意义，其数据解释如下：

显著性差异是说明对比的数据不是来自于同一总体，而是来自于具有差异的两个不同总体，例如大学生和小学生的在学习能力上的对比，就是有极显著差异。
显著性水平α：是在原假设为真时拒绝原假设的概率，根据具体需求选择双侧检验还是单侧检验，详见下图：
p值和显著性水平α的关系如下：1）若P<< span=””>=α，那么拒绝原假设2）若p>α，那么不能拒绝原假设
通常情况下单侧检验取0.05或0.01为拒绝域的临界值，这表明作出接受原假设的决定时，其正确的可能性是95%或99%
统计功效：备择假设成立时，正确的拒绝原假设的概率，我们用下图来说明下什么是统计功效。
红色线是原假设下分布情况，红色区域在原假设分布下为拒绝原假设的概率，其中z值为临界值，统计功效就是该临界值在备择假设的分布下，统计量大于z的概率，即上图绿色区域，公式为1-β。
上面我们知道了以上ab测试所需要的基本概念，那如何运用到实际ab测试中呢。
我们举个例子来看下：背景：某天a公司产品部门要优化push文案策略对用户点击率的影响
产品经理小a在其公司下的ab平台创建了一个实验，分2个实验组开启实验，假设：实验版本比对照版本好
实验时间：周期21天，21天后观测效果如下：

根据上表数据，具体推演流程小伙伴们可以根据前面的知识点自己思考一下~
上面梳理了ab测试的原理、优点以及一些相关的基础概念，如果要实际操作还是需要一个平台来承接，那么一个ab平台都需要具有哪些功能呢？我对比了一下市场上的产品给大家剖析一下。

05市场工具的竞品分析

市场上提供ab测试相关功能的公司主要有：
国内：1.云眼https://www.eyeofcloud.com/）abtester（http://www.abtester.cn/）2.吆喝科技（http://www.appadhoc.com/）3.智道助手http://sjmyz.zhidzhushou.com/lp2.html?utm_source=5&utm_medium=sembaidu&utm_term=sem_baidu_data_lz&utm_campaign=bdpcdata90444.数极客https://www.shujike.com/product/abtest.html5.云测（https://www.testin.cn/）等
国外：1.Vwo（https://vwo.com/）、2.Optimizely（https://www.optimizely.com/）3.Omniturehttps://www.adobe.com/marketing-cloud.html
我分别用吆喝科技、Optimizely 进行一个简单的“竞品分析”，分别从功能框架、使用流程上来对比一下国内外ab测试产品设计上的差异情况
1）功能框架：吆喝科技应该是国内提供ab测试首屈一指的大厂，其具体功能如下：

optimizely公司是2010年创立，美国的一家资深提供ab测试服务的公司，功能丰富，自主化操作很强，对于不同场景的兼容也是别具一格，是非常值得大家学习和参考的一个产品，具体功能框架如下：

2）使用流程：页面展示：使用流程：
吆喝科技实验流程以引导式的交互方式进行，整个流程相对较“顺”，单从操作角度上而言门槛不是很高。
而Optimizely相对来说比较自由，但每一个操作配置都需要进行代码集成，操作流程较国内而言相对较多，具体如下：页面展示：
上图为截取的部分配置页面
操作流程：
如果是一次新的操作，Optimizely需要提前配置好指标、受众人群、属性、功能等，每个操作流程都会展示很多配置需要集成在sdk里，对于使用者来说初始化过程有一定成本，不过对于开发者确实比较友好，只需要复制粘贴一段段代码即可，如果有人能提前把相关信息配置好，那用Optimizely进行ab测试还是比较香的。 经过对两个产品的对比，ab测试的功能也就一目了然：

总结：AB测试是数据驱动增长的核心方法，本文的目的在于能以“通俗易懂”的方式给大家普及一些基本概念，让ab测试的使用和理解不在有“门槛“，全文分别从原理、基本概念以及相关平台建设的角度进行叙述。
但因篇幅有限，相关知识点无法更全面的为大家展开，感兴趣的童鞋可以进行留言，后续相关的文章我也会逐一为大家解答，若文章内描述有错误的也欢迎大家指正。希望大家读完后可以多多思考多多探讨，让ab测试真正能为企业增长作出贡献。
备注：1.以上功能框架是根据各产品的功能说明文档进行整理，仅供参考，若与实际有差异请于笔者联系，及时修正
2.流程图并非标准流程图，只对比了主要流程进行的流程示意图
。

上篇文章《数据应用系列（1）-ab测试》我们讲述了一些ab测试的基础概念以及对市场上一些第三方平台进行了简单的对比分析。

如有平台使用的需求，各家公司可以根据自身业务情况选择一些厂商进行ab服务的购买，但一般情况下，选择服务厂商都会存在以下问题：
1.公司数据有泄漏风险；
2.平台功能并不完全符合公司业务发展和变动，后期改造成本较大；
3.选用服务成本不低，但是收效却不尽人意等。

所以部分公司权衡后便决定组织人力着手搭建平台，那么一个ab平台究竟要如何搭建，搭建的ab平台如何在业务中应用，实验过程中出现的异常如何应对等一系列问题便会接踵而至。

下面我将从平台的前期准备，业务场景、平台建设以及异常处理四个方面来讲述一下整个搭建的过程。

01前期准备

所谓前期准备就是立项前的一个评估，评估在什么“前提”下公司可以开始投入人力搭建ab平台。

01有足够量级的用户基础

这里的用户量级不仅仅是指app本身、还包括具体功能使用的人数量级，再具体点来说就是进入实验的用户量级，ab测试之所以有科学性主要是引用了统计学的评估原理，根据z检验的公式：

可以很直观的看出：如果样本量很小，单个用户的行为表现就具有极大的影响力，极易造成两个版本的差异变大，无法客观的评估实验结论是具有统计学意义的。

02功能模块可以进行精细化控制

ab实验的原理上一章我也有所描述，整体流程类似于控制变量法，那既然是控制变量，就要通过对已知变量的控制来减少误差对实验的影响，即实验过程中只对某一变量因素进行控制，因此需要在功能切分上做到相对精细化的控制，避免引入其他影响因素造成实验结果不具备参考价值。

03能客观接受实验结果和实验结果的“代价”

ab测试前期需要投入较大的研发成本，而实验过程平均周期也需要2-3周，最终得到的结果却不一定符合预期，甚至不一定是正向表现，需要反复的进行实验探究。一次实验从开始到最终结论产出的这个煎熬过程和”损失“需要我们能理性的接受。

01
学会“三思后行”

ab测试并非是解决决策“分歧”的唯一依据，我们要以思辨的角度先去评估用户反馈的功能是否是产品的主功能或者影响了主流程的使用，毕竟在实验过程中要投入大量的人力和时间成本。

笔者在ab测试问题复盘的过程中，经常发现很多无故的放大用户需求的案例，最终的实验结果达不到最初的预期。所以在实验设计阶段或实验评审阶段大家尽量做到”三思而后行“。

上述列举的几点是笔者认为几个比较重要的因素，大家也可以结合自身业务特性进行其他角度的思考和补充。有了搭建ab平台的一些前置要素。下面我们进入第二篇内容，看一下公司中都有哪些业务场景需要进行ab测试：

02
业务场景

36Kr曾在一篇报道中写道，“头条发布一个新APP，其名字都必须打N个包放到各大应用市场进行多次A/B 测试才能决定。

张一鸣告诉同事：哪怕你有99.9%的把握那是最好的一个名字，测一下又有什么关系呢？那互联网行业中都有哪些场景需要ab测试呢？下面我简单整理了一下不同角色工作中适用ab测试的业务场景：

列表中的是否发版用以判断实验变量控制位置，需要发版一般版本id要在客户端进行版本判断，不需要发版一般可通过服务端进行判断，按需则根据具体功能实现方式来选择。

数据来源是作为实验效果评估的主要数据依据。例如客户端实验主要以sdk采集的用户行为数据为主，服务端实验若无法全面的获取用户数据，则以服务端日志为主要依据，例如push实验，用户不点击push打开，则无法统计到用户行为数据，只有服务端记录的push下发相关的数据。

03
平台建设

上面我们描述了一下平台搭建的前期准备和适用的业务场景。本章我们拆解一下平台如何进行建设，在开始这部分前，我选用上面一个流程优化的场景，通过一段”日常“对话来描述一下平台的需求都有哪些，方便大家进行理解：

业务产品经理：最近收到一批忠实用户的反馈，内容创作的入口应该从「我」中拿到主页面，我们想调整一下看不同入口位置哪种效果最好，目前已经设计了3个方案想搞个ab实验，选一个最优版本来代替当前版本上线。

平台产品经理：你们新版本大概什么时间开发好？实验需要运行多久？
业务产品经理：大概2021年1月1号能开发完，实验周期的话预计2周时间

平台产品经理：你需要提前想一下实验的名字，不然这么多实验列表里不好找你的实验。哦对了，你们这次实验大概要用多少用户？
业务产品经理：3个方案的话加上当前对照组，怎么也得用至少总体的20%的用户去验证效果

平台产品经理：那下次发版时间大概什么时候？
业务产品经理：预计过完年后，2月底了，这个版本功能比较多，所以如果数据效果好，看能不能通过平台直接全量到线上，过年大家是大家分享的黄金时间，所以来不及等下次发版功能代码开发了

平台产品经理：好滴!我们平台马上也要上线了，到时候可以直接在平台操作，不会耽误你们进度的。

从对话中我们提取几个关键词（红字标记）：

通过简单的一个场景描述，我们可以看到，一个ab系统的核心模块至少包括以下四个：

01
实验信息管理

该模块主要是记录实验业务信息方便方便解读和查询，最少需要记录以下信息：

02
实验变量管理

该模块用以确定变量版本，方便逻辑控制。同样，需要的字段和每个字段的意义我以表格形式进行了整理：

该模块下需要提供版本个数的增删操作，方便用户进行临时版本的增加和删除操作

03
实验流量管理
实验流量管理模块应该是ab平台的核心功能之一，承载着确定变量流量，保证各版本分配的用户成分相似。但在互联网行业每天可能进行众多的实验，为了解决实验流量不够的问题，现通过引入流量层的方式来解决，所以实验流量就会出现正交&互斥的特性，那我在这里再简单描述一下相关知识点：

互斥
所谓互斥是指同层同时运行多个实验，彼此占用的用户不会被其他实验所占用，详见下图：

正交
正交是指，相同的用户在不同层都会被随机打散，以便以足够离散的支持不同的实验，详见下图：

那我们如何实现的流量的控制（离散和圈定），主要有三个方面：哈希算法、哈希因子以及流量确认。

哈希算法
业界比较常用的算法是murmurhash，共有三个版本（murmurhash、murmurhash2、murmurhash3），这种算法是一种非加密型哈希函数，适用于一般的哈希检索操作，其优点如下：
1）简单（就生成的汇编指令而言）。
2）良好的分布（通过几乎所有键集和存储桶大小的卡方检验）
3）良好的雪崩行为（最大偏差为0.5％）。
4）良好的抗碰撞能力（通过了鲍勃·詹金的frog.c酷刑测试。4字节密钥不可能发生冲突，差异不大（1至7位）。
5）在Intel / AMD硬件上具有出色的性能，在哈希质量和CPU消耗之间进行了很好的权衡。

当然还可以根据设备id的尾号进行分流，常用的分流算法有 crc_32、sha_256等，但是使用场景具有一定局限性：需要用户量足够大、设备id分布足够均匀、实验组数量不宜过多。

哈希因子
所谓的哈希因子，通俗的来讲就是被哈希的对象，一般情况下设备id（deviceid）、流量层id（layerid）就够了、还有一些统一测试平台还会涉及应用key或应用id（appid）、美团的业务场景下还会引入区域的id（areaid），所以一个哈希因子就变成了appid_areaid_layerid_deviceid。

流量确认
通过哈希算法和哈希因子可以最终确定一个1-n的位置，假设是1-100，则某一层的总流量就是1-100，业务方通过平台上操作的实验版本个数和版本流量，来确定这个实验1-100的位置如何分配，就完成了一次实验的流量确认的过程，下图就展示了正交&互斥的完整流量确认的流程。

实验效果评估
通过实验信息配置、版本和流量分配、实验周期的控制，最后一步就是通过实验数据来验证版本效果好坏，那我们要关注哪些数据呢？

1）北极星指标
所谓北极星指标就是业务核心发展的重点指标，换句话说今年kpi就全靠他了，所以实验版本的效果提升，都是采用对北极星指标正向的影响

2）业务相关指标
是指业务人员关注对策略改版本身有所影响的指标以及其他辅助指标的波动情况，从时效性上可分天级、小时级、分钟级

3）统计相关信息
每个指标的p值、置信区间、统计功效
除了以上指标，还可以观测ab测试版本中功能后续使用的留存情况，进一步去评估本次实验效果是真的好，还是偶然的好

上面根据业务场景和需求讲述了ab平台搭建需要的一些基本模块，下面我们就来将这些模块开始有机的组装和流转：

页面参考：
1）创建实验

2）指标查看

除了上述页面还应该提供一些管理页面，包括：用户管理、角色管理、应用管理（如果有多app的话）、元数据管理、流量层管理、指标管理等，这些页面这里就不作样例展示了，大家可根据自身业务特性来发挥想象。以上页面展示仅为参考，为方便大家便于理解上述所描述的内容。

业务处理流程：

上图中蓝色线代表了以客户端为逻辑判断的主要流程，红色线代表以服务端为逻辑判断的主要流程，不同的逻辑判断位置即代表了业务架构的差异性也影响数据获取的方式。

除了abtestsdk请求策略层获取版本id用以app端逻辑判断或传递给服务端进行逻辑判断外，还有通过业务服务端直接请求策略层进行逻辑判断的方式，如push实验，本身特性是无论是否有用户点击app，都需要根据push平台进行策略下发。第二节业务场景中所描述的是否发版和数据获取来源直接决定了ab的接入方式和效果评估的数据来源

功能框架参考：

04
异常处理

通过前期评估、业务场景、系统流转以及平台功能的框架，基本一套完整的ab平台就已经初具雏形，下面我们就可以按照以下的操作流程开始进行ab实验，对每次策略进行效果评估：

在本文的第一章节有提及，我们要理性的接受ab测试过程中得出的结论可能无效甚至与预期相悖的，不过这些也不一定是实验本身策略的问题，那么有哪些因素会导致实验“无效”并且怎么去解决呢？

01
实验周期
很多童鞋在做实验时特别着急的想去看结果，甚至迫不及待的实验开启几天就已经开始决定要上线，这样的做法显然是不可取的，实验周期的长短影响主要有以下几个方面：

a.影响样本量的大小；样本量决定了样本的代表性和实验的可参考性；

b.用户行为习惯影响数据指标，比如节日效应，或者例如有些工具类app工作日使用会较频繁，周末会下降；

c.影响进入实验的用户情况，因每天用户活跃情况不同，若观测时期较短，可能会因一天的数据问题导致整体数据指标很大或者很小

d.科学的实验周期应该在2-4周范围内。尽量涵盖到目标样本量以及所有时间维度上（工作日、节假日）

02
辛普森悖论
辛普森悖论是指当人们尝试探究两种变量（比如新生录取率与性别）是否具有相关性的时候，会分别对之进行分组研究。然而，在分组比较中都占优势的一方，在总评中有时反而是失势的一方，我们可以通过下面的例子简单理解一下：

目标：男生的录取率高于女生
方式：各学院提高男生的招聘率

上面可以直观的看到，单看商学院和法学院都是男生录取率比较高。但是总体情况确实女生录取率（42%）是男生录取率（21%）的两倍。映射到ab实验上，实验版本和对照版本其实分别就对应的是女生和男生的录取率，辛普森现象的本质是通过加权平均引起的，而且样本量越大越容易出现这种情况。

所以如果要规避这个问题主要采用：
1）策略上线前，要尽可能的进行多维度分析，找出可能会影响的因素；
2）实验分流前尽量选取合适的样本量，避免因样本量过大造成的反结果；
3）实验方案设计时，要在相同量级的维度下进行实验。例如为了节省成本，将一个策略同时在双端进行实验，但本身android的用户量会大于ios，实验结论从整体看效果是正向的，但实际ios可能完全与其相悖

03
幸存者偏差
“幸存者偏差”是指，当信息来源，仅来自于幸存者时（因为死人不会说话），这个信息可能会存在与实际情况不同的偏差。所以大家在实验结果分析过程中，不仅仅要看用户行为数据与有版本id用户（即进入实验的用户）产生的指标情况，还应看有版本id的用户中具体触发这些用户数据的表现情况，综合来评判版本实验效果。

04
缓存问题
为了保证实验能在客户端稳定运行，避免造成实验组和对照组来回波动的情况，一般会采用缓存策略。但在实际进行ab实验时，存在对已经结束的实验进行重新开启的情况，此时这个”新实验“会受到之前实验分桶流量的影响；同时还要考虑每次启动app时请求分桶流量的时机，尽量保证实验组和对照组在没有波动的情况下获取到最新的分流策略。

05
样本量选择
样本量的大小影响显著性水平、统计功效等。样本量太小，不具代表性，得出的结论不可信；样本量太大，容易导致辛普森悖论，需要的实验周期长，同时流量有限又不能无限扩大，那多少样本量合适，我们可以根据公式进行反推，也可以用样本量测算工具（https://www.evanmiller.org/ab-testing/sample-size.html）计算。

在实际测试操作中，很多童鞋也会有这样的问题就是，既然我们统计的都是转化率这种相对指标，是不是我们实验组和对照组的样本量可以不相等，比如对照组1000人，实验组5000人，针对于这种问题，我们可以进行个假设：若实验组的流量是最小样本量，那证明对照组样本不够，极容易导致实验不可科学；

若对照组是最小样本量，那”过载“的用户样本，会导致用户数据偏移、样本数据“浪费”以及辛普森等问题。所以大家在实验过程中要尽量保证不同版本的样本量一致。

06
分流评估
业务童鞋在使用我们搭建好的平台，无论实验做的如何：可能是实验结果不符合他们预期，也可能是因业务接入问题导致实验失败，即使ab平台没问题也会先被质疑一番。
而分流是否合理便是第一个被质疑的对象，所以作为平台方我们即使用了当前最牛的分流算法，在平台功能上也要提供：分流数据实时、小时的进入流量的情况以及不同画像特征维度下实验组和对照组的数据分布情况，如果十分有必要甚至可以让业务每次实验都应该进行aab实验，用aa实验结果的准确性来保障平台的可信度。

虽然aa实验是验证ab平台数据准确性的有效手段，原则上aa实验（实验组和对照组的策略一模一样）的数据表现应该是一致的，但是有时候却发现两组指标竟然出现了差别，即使反复验证也会出现这种情况，这种情况就是aa实验的波动性。

导致这个问题的主要原因就是抽样的随机性，举个简单的例子：即使同样性别的双胞胎，经过相同条件下培训，最终答题的分数也不一定是一模一样的。所以如果要解决这个问题，可以考虑适当提升aa实验样本量的大小，在一定程度上可以抵消这种波动性。

05
总结

A/B测试作为当前互联网领域用户增长、精细化决策的核心技能，越来越多的被各家公司作为基础能力所要求。

本文我们简单总结了一下ab平台系统搭建以及大家在平台使用过程中会遇到的一些问题，如果是此时你正需要搭建一个ab平台，希望读完后能起到一定的启发作用。

如果是平台的使用方，希望可以让大家加深对ab测试的理解。通过异常处理章节中的内容我们也可以看到，想做好一个科学的ab实验并非一件容易的事，需要大家积极拆解业务，理解ab测试原理和流程，以及统计学的相关知识。

希望大家可以在工作中灵活运用这一技能，为企业带来更大的增长效益。最后提前预祝大家新年快乐，事事如意，工作牛到飞起。