鲸云效解读A/B测试，get这一篇就够了

鲸云效解读A/B测试，get这一篇就够了
很多人总是说A/B测试，但是真正做对的人却少之又少，为何？鲸云效总结这篇文章给你答案，精彩内容不容错过哦！

A/B测试背后的数学——假设检验
假设检验是常用的A/B测试结果分析方法。网上有许多介绍假设检验的文章，这里我再概况一下：

假设检验有原假设H0和备择假设H1。
假设检验是反证法，通过计算p值来证明备择假设H1是小概率事件（p＜α），而小概率事件很难发生，以此来接受或拒绝H1。
我们一般把要证明的假设作为H1。这样的话，如果p值落在拒绝域，说明小概率事件发生了，就有充足的理由拒绝H0，接受H1。
常见的两类错误，Type1=弃真（H0为true，被拒绝），Type2=取伪（H0为false，被接受）。在A/B测试中，我们一般更关注Type1类错误，因为Type2出错是维持现状，而Type1错误是上了不该上的版本。
Type1错误率是α，即显著性水平，实际上就是我们认为多小的概率是小概率事件。
Type2错误率是β，检验功效是1-β。检验功效指的是当H1为真时，我们有多大可能检测到H1。β与样本量负相关，即样本量越大，犯Type2错误的概率越小。

A/B测试实施步骤
在A/B测试的实施过程中，有许多细节问题需要处理，如果没处理好这些细节问题，将会降低结果可信度，甚至造成上了不该上的版本。下面我将根据A/B测试的实施步骤说说实施中的一些细节问题。A/B测试通常包含5个步骤：

定义目标：确定测试对象及其衡量指标。
开发A/B版本：开发多个版本的页面、素材、算法等元素。
划分测试流量：选择进入A/B测试的流量，确定测试时长。
分析测试数据：收集、分析测试数据。
版本选择：根据测试数据，决定线上采用哪个版本。

A/B测试step1-定义目标
在实施A/B测试时，我们首先要定义测试的对象（变量）和要达成的目标。测试对象指的是产品需要改进的地方，比如按钮大小和颜色、排序算法等与用户体验相关的因素。目标指的是我们希望通过改进测试对象达到什么效果，以及衡量效果的相关指标。在选择衡量指标时，不能只看转化率一个指标，还要关注产品的核心指标。因为我们所做的一切改进都是为了提升核心指标。例如，假设美团的产品经理要优化首页频道顺序，在选择效果衡量指标时，就不能只看一个CTR指标，而要将下单转化率、下单金额、GMV都要考虑进去。因为很有可能你CTR指标变好了，但是下单转化率、下单金额或者是GMV变差了。

A/B测试step2-开发A/B版本
开发A/B测试的多个版本时，产品经理或数据分析师要协调开发做好页面展示、事件触发的埋点工作。另外，还要标记参加测试的用户，及其对应的版本，用于检验A/B测试系统的稳定性（用户是否请求到正确的测试版本）。标记用户的流程为：当测试用户进入测试页面后，在其返回的交互数据加上特定参数，如exp_id={测试编号}、exp_bucket={用户分桶}。这样不管是在hbase一类的非关系型数据库还是传统的mysql数据库，我们都能很快的过滤出参加测试的用户，计算相应指标。

A/B测试step3-划分测试流量
我个人认为划分测试流量是A/B测试最重要的部分。A/B测试结果的正确性是建立在正确划分流量的基础上。然而，网上许多介绍A/B测试的文章，在这部分内容上，要么含糊其辞，要么压根就是错误的做法。对于是否要切分流量做A/A测试这个问题，twitter的经验是A：B流量比例2：1好于A：A：B流量比例1：1：1。划分测试流量其实有3件事要做：一是确定样本数量，二是确定测试运行时长，三是切分测试流量。

1. 确定样本数量

为了比较靠谱的计算A/B测试所需的样本量，我们要借助于GPower（http://www.gpower.hhu.de/en.html）这个免费软件，这是用来计算统计功效（t检验、z检验、F检验、卡方检验等）的软件。检验功效可以理解如果备择假设H1为真，接受H1的概率。在A/B测试中，我们关注的指标可以分为两类，一是比例数据，取值范围[0,1]，二是均值数据，取值范围[0,+∞)。对应的，我们分别基于z检验和t检验去估计这两者所需的样本量。

比例数据。填入组1、组2的比例（如转化率，CTR等），置信度水平α，检验功效1-β，组2/组1样本量比例，然后点击“calculate”即可计算出测试所需的样本量。PS，这玩意好用啊，了解个大概就能上手干活了。另外，从右边的窗口我们可以看到，检验功效随样本量增加而增加。

均值数据。我们首先根据组1组2的均值、方差计算出cohen’s d，该值表示两个均值之间的标准差异的大小。然后再输入α、1-β和两组样本量比值，就可以计算出测试所需的样本量。

2. 确定测试运行时长

确定A/B测试运行时长有三个因素要考虑，一是收集到足够的样本量，二是时间段内的用户行为有没有特殊性，三是结果的稳定性。

从样本量角度考虑，有时候我们要测试的页面流量比较小，可能一天也就1000UV，如果测试需要2000样本，那么A/B测试最少需要持续2天。如果再扣除垃圾流量，可能就需要3天。
从用户行为的特殊性考虑，如果某个事件对用户行为有较大影响，我们就需要排除这些天的数据。虽然这种情况很少发生，但是我们还是不能忽略这种可能。
从结果的稳定性方面考虑，我们不能在p值显著的情况下就立即停止测试，因为p值会波动，有可能用第二天的数据计算后就不再显著。互联网用户行为的周期性比较明显，我个人认为一个A/B测试就算在流量足够的情况下，最好也要持续7天。

3. 切分测试流量

不少产品经理或是开发认为可以通过Device ID、Cookie ID、IDFA等值的奇偶性或者末尾字符去划分。这是一个错误的做法！因为，你不知道这些值是怎么生成的，划分的结果是不是真的均匀。我们要求流量分桶算法要同时满足一致性、平衡性、随机性和独立性4个要求。一致性指参加测试的用户在测试过程中的只会访问一个版本。平衡性指的是各版本之间的流量规模一致。随机性指的是某个版本的样本选择是随机的。独立性指的是当有多个测试运行时，各个测试之间没有相关性。显然，用各类ID的奇偶去划分几乎都不符合要求。

还好，我们有各种加密算法（MD5、SHA1等）。使用加密算法，我们划分的流量可以满足上述4个要求。具体做法如下：

确定流量划分数量，比如将全站流量划分成100个不相交的子集
将用户标识和测试标识组成新的字符串，比如"10000001"+“base_bucket”=“10000001base_bucket”
得到上述字符串的MD5，然后转换成int，再取模，就得到用户的桶序号

到这里，可能很多人会有疑问，为什么是MD5算法，而不是其他加密算法？为什么用MD5加密后再取模就能平均划分流量呢？理论上来说，MD5散列结果的各个位置上的字母是服从均匀分布的，所以，使用MD5结果取模后，各桶的样本量是平衡的。在样本平衡上，MD5是相对较好的加密算法，可以参考《Practical Guide to Controlled Experiments on the Web: Listen to Your Customers not to the HiPPO》。

4. A/B测试流量分层模型

有了上面的流量划分基础，我们就可以实现流量复用，最大化利用流量。在这里，我们要了解3个概念：

域（domain）：划分出来的一部分流量。
层（layer）：产品或者系统的一个子集，是对产品的划分，每个划分包含一系列可变参数。我们可以将其理解为app里面的某些功能、频道等。例如轮播广告层、搜索结果层、秒杀频道等。
测试/实验（experiment）：一个A/B测试实例，以及参与测试的流量。
其中，域和层之间是多对多的关系，可以互相包含。分层模型的基本思想是：一个测试的参数在同一层，相互独立的参数位于不同层，不同层之间的流量划分相互独立。举个例子，下图是这样的一个流量分层模型：

流量分为两个域：首页和详情页
详情页分有两层：详情页UI和详情页商品推荐
详情页商品推荐层正在运行推荐算法的A/B测试
首页和详情页的流量是独立的，而详情页这个桶内的流量可以被多个层复用。

A/B测试step4-分析测试数据
A加粗样式/B测试的指标有比例数据和数值数据两种类型，比例数据一般是各种转化率，而数值数据通常是一些平均值（平均停留时间、平均浏览深度、平均订单价值等），我们可以分别使用z检验（转化率可以看做n-Bernoulli试验）和t检验来分析测试数据。如果显著性达到阈值α，并且维持一段时间，才能结束测试。不能一看p值小于0.05就结束测试，因为p值是会波动的。

在分析A/B测试结果时，我们要分析一系列相关指标的变动情况，而不是简单的一个点击率、转化率就可以了。例如，下图左边是京东app的详情页，页面上只有加入购物车按钮，右边是苏宁app的详情页，有立即购买和加入购物车两个按钮，究竟哪种设计更合适呢？这时候测试的指标就不能只是下单转化率了，还应该加上GMV、连带率、客单价等电商核心指标，有可能下单转化率高了，客单价、连带率就低了。

另外，除了使用假设检验比较各组指标的优劣，我们还可以从横向和纵向两个方面来分析指标：

横向对比：分析不同版本各指标和基准实验之间的差别，从而判断哪个版本更优

纵向对比：分析指定版本的效果是否稳定，效果的提升/下降是不是偶然的

最后，我们还要对实验结果进行更细致的分析，按照一定维度（如人口属性、兴趣偏好）拆解分析，找出指标上升下降的原因是什么。A/B测试的结果分析要做到“知其然，知其所以然”。

A/B测试step5-版本选择
有时候，我们无法通过指标的优劣来判断哪个版本最优。这种情况下，就需要成立专家组，让专家组决定采用哪个版本，专家组应当包括产品经理、运营、分析师等相关人员。另外，选择版本还要考虑变动对整个系统的影响，因为有些变动会显著增加技术成本（硬件、稳定性、容错性等）。