first commit
This commit is contained in:
张乾
137
专栏/AB测试从0到1/00开篇词用好A_B测试，你得这么学.md
Normal file
137
专栏/AB测试从0到1/00开篇词用好A_B测试，你得这么学.md
Normal file
@@ -0,0 +1,137 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
00 开篇词 用好A_B测试，你得这么学
|
||||
你好，我是博伟。欢迎和我一起学习A/B测试。
|
||||
|
||||
可能你对我还不是很熟悉，我先来做个自我介绍。我目前呢，在美国的互联网大厂FLAG工作，是一名资深数据科学家。在过去的7年多时间里，我一直在做A/B测试、机器学习建模、大数据分析的相关工作。
|
||||
|
||||
在从事A/B测试的经历中，我参与到从设计测试、实施测试到最后分析测试结果，给出业务指导的全过程，后来逐步在团队中主导A/B测试领域的相关工作，开发与A/B测试相关的数据产品，还和工程团队合作来改进提升内部的A/B测试平台，通过持续的A/B测试为公司的新业务带来上百万用户的增长。经过多年的经验积累，现在也为数据分析、营销和产品团队提供数十场A/B测试的讲座和上百次的咨询，给他们讲解A/B测试的最佳实践以及避坑经验。
|
||||
|
||||
在我多年的数据分析实践中，我越来越觉得，A/B测试是促进业务持续增长的最实用、最有效的方式。
|
||||
|
||||
不过我也发现，在这些不同的数据分析方法中，A/B测试也是最容易用错的方法。
|
||||
|
||||
究其原因，是因为A/B测试是一种实践性很强的方法，学校的教学中往往没有相关的课程。你可能会在统计课上学到过它的理论基础——假设检验，但是还是太过理论，不知道该怎么应用。A/B测试的难点就在于，如果你只有理论基础而没有实践经验，那么实践过程由于业务场景千变万化，可能就会有各种各样潜在的陷阱在等着你。只有兼顾了理论基础和实践经验，才能得出值得信赖的测试结果。
|
||||
|
||||
也因此，我非常希望能够系统地梳理和总结下自己在硅谷成熟科技公司学到的知识经验，并分享出来。在你即将学习的这门课程中，我会先带你建立起一个做A/B测试的框架，让你在应对不同业务场景时，都能通过框架来按图索骥，灵活运用。
|
||||
|
||||
不过在讲具体的学习方法之前，我想先和你聊一聊，A/B测试到底可以帮我们解决什么问题？
|
||||
|
||||
为什么想要获得持续的业务增长，就必须学习A/B测试？
|
||||
|
||||
在大数据时代，每个公司都在说数据驱动产品和业务的快速迭代，这当然没有错。但是，有很多人都认为，数据驱动就是做几次数据分析，产生一些报表，并没有把数据放在公司的业务决策流程中。
|
||||
|
||||
这是一个非常严重的误区。
|
||||
|
||||
多年的专业经验告诉我，看一个公司或者团队是不是真正做到了数据驱动，就要看它的决策流程中有没有A/B测试这一环节。
|
||||
|
||||
为什么这么说呢，我们先来了解下决策流程，也就是产品/业务迭代的流程。
|
||||
|
||||
|
||||
|
||||
你可以看到，产品/业务迭代的流程大概分为3步：
|
||||
|
||||
|
||||
具体的业务问题催生出迭代的想法，比如出现业务问题后，团队会提出具体的迭代方案；
|
||||
团队论证方案的可行性和效果；
|
||||
论证完成后，具体实施迭代方案。
|
||||
|
||||
|
||||
很明显，只要论证环节结束了，就要开始进行迭代了。所以，做好充分而正确的论证，就是至关重要的环节。
|
||||
|
||||
这也很容易理解，你想，如果刚刚有了迭代的想法，不去论证就直接实施，就很难达到预期，甚至会产生负面效果。
|
||||
|
||||
这就好比一个刚刚研制成功的药品，不经过临床实验就直接推入市场，去治疗病人，那承担的风险是非常高的。因为这样不仅可能无法治愈病人，甚至还可能会产生严重的副作用。这么一想，你是不是就体会到论证的重要性了？
|
||||
|
||||
而A/B测试，就是保证这个关键环节不出现问题的最佳方案。因为它不仅可以让我们清楚地知道产品/迭代方案到底有没有效果，能产生多大效果，还可以在结果不如预期时，快刀斩乱麻，有理有据地放弃这个想法。
|
||||
|
||||
这样既能大大节省公司的成本，又能加快想法迭代的速度。如果在花费了大量时间和资源实施想法后，还收不到预期的效果，那就得不偿失了。
|
||||
|
||||
所以，只有在决策流程中加入A/B测试这个环节，根据值得信赖的测试结果，而不是所谓的经验来做业务和产品决策时，才是真正的数据驱动决策。
|
||||
|
||||
这其实也是所有公司都会面临一个问题：业务增长从来都不是一步到位的，那么如何保持业务的持续增长呢？A/B测试在提升业务和产品迭代上真的很管用，能持续带来营收和用户的增长。
|
||||
|
||||
无论是美国硅谷的FLAG，还是中国的BAT，每年都会进行成千上万次的线上A/B测试，参与测试的用户超百万（事实上，大部分用户是在不知情的情况下被参与的）。即使是一些初创公司，或者是像沃尔玛、美国航空这样的传统企业，也会通过小规模的A/B测试来优化提升业务。
|
||||
|
||||
以必应（Bing）搜索为例，A/B测试每个月都能帮助他们发掘数十个提升收益的方法，每个搜索的收益一年可以提升10%~25%，这些AB测试带来的改进和其他提升用户满意度的努力，是必应搜索的盈利提升，以及其美国市场份额从2009年刚成立时的8%上升到2017年的23%的主要原因。
|
||||
|
||||
讲到这里，你可能会比较好奇，这些公司用A/B测试来解决什么具体的业务问题呢？你看下面我给你总结的表格就了解啦。
|
||||
|
||||
|
||||
|
||||
正因为发现了A/B测试在产品迭代、算法优化、市场营销等领域的巨大作用，越来越多的公司开始使用A/B测试，这方面的人才的需求量也越来越大。无论是偏技术的数据科学家、数据分析师，还是偏业务和产品的市场营销分析师、产品经理以及增长黑客，都需要在工作中掌握和应用A/B测试。而且从我多年做面试官的经验来看，A/B测试也是这些职位面试中必考的一块内容，重要程度可想而知。
|
||||
|
||||
看到这里，你可能已经非常想要学习A/B测试了，先别着急。我发现，很多人对A/B测试是既熟悉又陌生。
|
||||
|
||||
说熟悉，是因为A/B测试的基本概念很好理解，它就是指科学中的控制变量实验。说陌生，是因为A/B测试涉及到千变万化的业务场景、不同的数据，以及在实施过程中的多种琐碎环节，也存在着太多的误区。
|
||||
|
||||
理解A/B测试的原理很简单，想用好却很难
|
||||
|
||||
为什么这么说呢？我们直接看几个真实的案例吧。
|
||||
|
||||
我经常和营销、产品团队一起合作A/B测试，他们一般会提出一些A/B测试的想法，比如想要提升某款App的推送效果，希望能通过改变推送中的不同因素来提升推送的点击率。
|
||||
|
||||
刚开始，他们的很多想法完全不适合A/B测试。比如说，实验组和对照组相比，他们会想到同时改变推送的标题和内容，或者同时改变推送的内容和时间，等等，这就违反了控制变量实验中实验组和对照组只能有一个因素不同的原则。因为当我们同时变化多个因素时，即使最后得到了显著的测试结果，也没有办法确定到底是哪个因素造成的。
|
||||
|
||||
这就是基础不扎实导致的。这是一个非常严重的问题，因为不清楚原理，就很容易在设计实验和分析实验结果中采取错误的方法。
|
||||
|
||||
你可能会问，那我掌握好理论基础，是不是做A/B测试就没问题啦？
|
||||
|
||||
当然不是。A/B测试是一种实践性很强的方法。你可能会在统计课上学到过它的理论基础——假设检验，但是，怎么在实际业务场景中应用呢？这就是学习A/B测试的难点。
|
||||
|
||||
理论上的东西是死的，但A/B测试的应用场景和相关的数据却是千变万化的，在实施A/B测试中会遇到各种各样的数据问题或者工程Bug，要是一不小心哪怕忽视了很小的一个点，就会有各种各样的陷阱在等着你，实验结果就会变得不准确，之前的所有功夫就白费了。
|
||||
|
||||
我再跟你分享一个小例子。
|
||||
|
||||
某个专门测试App推送的平台，有一类流程是比较发推送有没有效果。对照组不发推送，实验组发推送。
|
||||
|
||||
在正式发送前，该平台还会做一个过滤，过滤掉那些不符合推送的用户，比如用户是未成年人，或者用户手机设备太旧不支持推送，等等。但是由于只有实验组会发推送，对照组并不会发推送，所以平台只在实验组实施了过滤机制：
|
||||
|
||||
|
||||
|
||||
但是，仔细想想，这个流程会使实验组和对照组有两个不同：有无推送和有无过滤。第一个不同是在实验设计中，但是第二个不同就纯粹是流程中加进来的，是偏差，会造成实验结果的不准确。
|
||||
|
||||
正确的流程如下图。对照组即使最后不发推送，也要经过和实验组同样的过滤，这样才能保证实验的准确性：
|
||||
|
||||
|
||||
|
||||
你看，这么一个细小的问题，就可能会导致整个A/B测试失败。
|
||||
|
||||
这门课程是如何设计的？
|
||||
|
||||
所以，为了让你快速且扎实地掌握A/B测试这门手艺，我结合我的从业经验，从统计原理、基本流程和进阶实战三个层面，为你梳理出了一条学习A/B测试的最佳路径。
|
||||
|
||||
|
||||
|
||||
第一模块是“统计篇”。
|
||||
|
||||
想要做好A/B测试，统计原理的学习肯定是不能漏掉的。统计学知识纷繁复杂，但做A/B测试，其实不需要掌握全部。所以我精选了与A/B测试密切相关的统计理论，主要讲解A/B测试的理论基础-假设检验，以及A/B测试指标的统计属性这两块知识，让你有针对性地学习理论知识，真正打好做A/B测试的理论基础。
|
||||
|
||||
即使你没有很好的统计学基础，也可以在这个模块快速掌握A/B测试的统计学基础，完全不用担心。
|
||||
|
||||
第二模块是“基础篇”。
|
||||
|
||||
在这个模块，我梳理了做A/B测试的几个关键步骤，包括确定目标和假设、确定指标、选取实验单位、计算所需样本大小，以及分析测试结果。我会在讲解流程的同时，也告诉你背后的原理，帮助你在实际应用时能举一反三。
|
||||
|
||||
第三模块是“进阶篇”。
|
||||
|
||||
想要让做A/B测试的技能更上一层楼，掌握了关键流程还不够。你还需要能够识别那些在实际业务场景中潜在的坑，并且要有相应的解决方法。
|
||||
|
||||
除此之外，你应该知道A/B测试并不是万能的，所以我会专门拿出一节课来给你讲解A/B测试的适用范围及替代方法。
|
||||
|
||||
如果你是想面试A/B测试相关职位呢，也不用担心，我会花两节课带你掌握面试中的常见考点及应对方法。
|
||||
|
||||
最后，我还会通过实战，带你亲自制作一个实用的样本量计算器，来解决网上工具参差不齐、适用范围有限等问题。
|
||||
|
||||
A/B测试其实并不难，因为它并不需要你掌握非常高深的计算机算法或者高等数学，所以说理解基本的统计知识就足够了。不过想要把A/B测试做好，肯定是有难度的。它的难度就在于，如果不遵循科学化的流程，那么在实践过程中就可能会出现各种状况和问题。
|
||||
|
||||
所以我也希望你能在学习这门课程的时候，边学边实践，在实践中学习、总结前人的经验，把A/B测试慢慢变成你在工作中的一项核心竞争力。
|
||||
|
||||
最后，今天是开篇，你可以在评论区写下你对这门课的期待，或者你的学习计划，让我们一起见证彼此的成长吧！
|
||||
|
||||
|
||||
|
||||
|
||||
199
专栏/AB测试从0到1/01统计基础（上）：系统掌握指标的统计属性.md
Normal file
199
专栏/AB测试从0到1/01统计基础（上）：系统掌握指标的统计属性.md
Normal file
@@ -0,0 +1,199 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
01 统计基础（上）：系统掌握指标的统计属性
|
||||
你好，我是博伟。
|
||||
|
||||
在学习、解决技术问题的时候，我们都知道有这么一句话“知其然知其所以然”。那么，A/B测试的“所以然”是什么呢？在我看来，就是A/B测试背后的计算原理，知道A/B测试为什么要这么设计，最佳实践中为什么要选择这样的指标、那样的检验方法。
|
||||
|
||||
那说到A/B测试背后的计算原理，我们首先得知道，A/B测试的理论基础是假设检验（Hypothesis Testing）。可以说，假设检验，贯穿了A/B测试从实验设计到分析测试结果的整个流程。
|
||||
|
||||
如果要一句话解释“假设检验”的话，就是选取一种合适的检验方法，去验证在A/B测试中我们提出的假设是否正确。现在，你只要知道“假设检验”中，最重要也最核心的是“检验”就可以了，因为选取哪种检验方法，取决于指标的统计属性。
|
||||
|
||||
也就是说，理解指标的统计属性，是我们掌握假设检验和A/B测试的前提，也是“知其所以然”的第一步。
|
||||
|
||||
而至于深入理解并用好“假设检验”的任务，我们就留着下一讲去完成吧。
|
||||
|
||||
指标的统计属性，指的是什么？
|
||||
|
||||
在实际业务中，我们常用的指标其实就是两类：
|
||||
|
||||
|
||||
均值类的指标，比如用户的平均使用时长、平均购买金额、平均购买频率，等等。
|
||||
概率类的指标，比如用户点击的概率（点击率）、转化的概率（转化率）、购买的概率（购买率），等等。
|
||||
|
||||
|
||||
很明显，这些指标都是用来表征用户行为的。而用户的行为是非常随机的，这也就意味着这些指标是由一系列随机事件组成的变量，也就是统计学中的随机变量（Random Variable）。
|
||||
|
||||
“随机”就代表着可以取不同的数值。比如，一款社交App每天的使用时间，对轻度用户来说可能不到1小时，而对重度用户来说可能是4、5小时以上。那么问题来了，在统计学中，怎么表征呢？
|
||||
|
||||
没错，我们可以用概率分布（Probability Distribution），来表征随机变量取不同值的概率和范围。所以，A/B测试指标的统计属性，其实就是要看这些指标到底服从什么概率分布。
|
||||
|
||||
在这里，我可以先告诉你结论：在数量足够大时，均值类指标服从正态分布；概率类指标本质上服从二项分布，但当数量足够大时，也服从正态分布。
|
||||
|
||||
看到这两个结论你可能会有很多问题：
|
||||
|
||||
|
||||
什么是正态分布？什么是二项分布？
|
||||
“数量足够大”具体是需要多大的数量?
|
||||
概率类指标，为什么可以既服从二项分布又服从正态分布？
|
||||
|
||||
|
||||
不要着急，我这就来一一为你解答。
|
||||
|
||||
正态分布（Normal Distribution）
|
||||
|
||||
正态分布是A/B测试的指标中最主要的分布，是计算样本量大小和分析测试结果的前提。
|
||||
|
||||
在统计上，如果一个随机变量x的概率密度函数（Probability Density Function）是：
|
||||
\[-
|
||||
f(x)=\\frac{1}{\\sigma \\sqrt{2 \\pi}} e^{-\\frac{1}{2}\\left(\\frac{x-\\mu}{\\sigma}\\right)^{2}}-
|
||||
\]\[-
|
||||
\\begin{aligned}-
|
||||
\\mu &=\\frac{x\_{1}+x\_{2}+\\cdots+x\_{n}}{n} \\\\\\-
|
||||
\\sigma &=\\sqrt{\\frac{\\sum\_{i}^{n}\\left(x\_{i}-\\mu\\right)^{2}}{n}}-
|
||||
\\end{aligned}-
|
||||
\]那么，x就服从正态分布。
|
||||
|
||||
其中 ，μ为x的平均值（Mean），σ为x的标准差（Standard Deviation），n为随机变量x的个数，xi为第i个x的值。
|
||||
|
||||
随机变量x服从正态分布时的直方图（Histogram）如下：
|
||||
|
||||
|
||||
|
||||
直方图是表征随机变量分布的图表，其中横轴为x可能的取值，纵轴为每个值出现的概率。通过直方图你可以看到，距离平均值μ越近的值出现的概率越高。
|
||||
|
||||
除了平均值μ，你还能在直方图和概率密度函数中看到另一个非常重要的参数：标准差σ。σ通过计算每个随机变量的值和平均值μ的差值，来表征随机变量的离散程度（偏离平均值的程度）。
|
||||
|
||||
接下来，我们就来看看标准差σ是怎么影响随机变量的分布的。
|
||||
|
||||
为了方便理解，我们用Python做一个简单的模拟，选取服从正态分布的随机变量x，其平均值μ=0；分别把x的标准差σ设置为1.0、2.0、3.0、4.0， 然后分别做出直方图。对应的Python代码和直方图如下：
|
||||
|
||||
from scipy.stats import norm
|
||||
import numpy as np
|
||||
import matplotlib.pyplot as plt
|
||||
|
||||
## 构建图表
|
||||
fig, ax = plt.subplots()
|
||||
x = np.linspace(-10,10,100)
|
||||
sigma = [1.0, 2.0, 3.0, 4.0]
|
||||
for s in sigma:
|
||||
ax.plot(x, norm.pdf(x,scale=s), label='σ=%.1f' % s)
|
||||
|
||||
## 加图例
|
||||
ax.set_xlabel('x')
|
||||
ax.set_ylabel('Density')
|
||||
ax.set_title('Normal Distribution')
|
||||
ax.legend(loc='best', frameon=True)
|
||||
ax.set_ylim(0,0.45)
|
||||
ax.grid(True)
|
||||
|
||||
|
||||
|
||||
|
||||
通过这个直方图去看标准差σ对随机变量分布的影响，是不是就更直观了？σ越大，x偏离平均值μ的程度越大，x的取值范围越广，波动性越大，直方图越向两边分散。
|
||||
|
||||
咱们再举个生活中的例子来理解标准差。在一次期末考试中，有A和B两个班的平均分都是85分。其中，A班的成绩范围在70~100分，通过计算得到成绩的标准差是5分；B的成绩范围在50~100分，计算得到的成绩标准差是10分。你看，A班的成绩分布范围比较小，集中在85分左右，所以标准差也就更小。
|
||||
|
||||
说到标准差，你应该还会想到另一个用来表征随机变量离散程度的概念，就是方差（Variance）。其实，方差就是标准差的平方。所以，标准差σ和方差在表征离散程度上其实是可以互换的。
|
||||
|
||||
有了方差和标准差，我们就可以描述业务指标的离散程度了，但要计算出业务指标的波动范围（我会在第4讲展开具体的计算方法），我们还差一步。这一步就是z分数。
|
||||
|
||||
要解释z分数，就要引出一种特殊的正态分布，也就是标准正态分布（Standard Normal Distribution），其实就是平均值μ=0、标准差σ=1的正态分布。
|
||||
|
||||
标准正态分布的直方图如下所示：
|
||||
|
||||
|
||||
|
||||
这里的横轴就是z分数（Z Score），也叫做标准分数（Standard Score）：
|
||||
\[-
|
||||
\\mathrm{z} \\text { score }=\\frac{x-\\mu}{\\sigma}-
|
||||
\]事实上，任何一个正态分布都可以通过标准化（Standardization）变成标准正态分布。而标准化的过程，就是按照上面这个公式把随机变量x变为z分数。不同z分数的值，代表x的不同取值偏离平均值μ多少个标准差σ。比如，当z分数等于1时，说明该值偏离平均值1个标准差σ。
|
||||
|
||||
我们再用一个社交App业务指标的例子，来强化下对正态分布的理解。
|
||||
|
||||
现在有一个社交App，我们想要了解用户日均使用时间t的概率分布。根据现有的数据，1万个用户在一个月内每天使用App的时间，我们做出了一个直方图：
|
||||
|
||||
|
||||
|
||||
可以看出，这1万个用户的日均使用时间t，大约在3-5小时这个范围，而且是近似正态分布的钟形曲线，说明t的分布也可以近似为正态分布。
|
||||
|
||||
中心极限定理（Central Limit Theorem）
|
||||
|
||||
这其实是均值类变量的特性：当样本量足够大时，均值类变量会趋近于正态分布。这背后的理论基础，就是中心极限定理。
|
||||
|
||||
中心极限定理的数学证明和推理过程十分复杂，但不用害怕，我们只要能理解它的大致原理就可以了：不管随机变量的概率分布是什么，只要取样时的样本量足够大，那么这些样本的平均值的分布就会趋近于正态分布。
|
||||
|
||||
那么，这个足够大的样本量到底是多大呢？
|
||||
|
||||
统计上约定俗成的是，样本量大于30就属于足够大了。在现在的大数据时代，我们的样本量一般都能轻松超过30这个阈值，所以均值类指标可以近似为正态分布。
|
||||
|
||||
到这里，“数量足够大”具体是需要多大的数量，以及什么是正态分布，这两个问题我们就都明白了。接下来，我们再学习下什么是二项分布，之后我们就可以理解为什么概率类指标可以既服从二项分布又服从正态分布了。
|
||||
|
||||
二项分布（Binomial Distribution）
|
||||
|
||||
业务中的概率类指标，具体到用户行为时，结果只有两种：要么发生，要么不发生。比如点击率，就是用来表征用户在线上点击特定内容的概率，一个用户要么点击，要么不点击，不会有第三种结果发生。
|
||||
|
||||
这种只有两种结果的事件叫做二元事件（Binary Event）。二元事件在生活中很常见，比如掷硬币时只会出现正面或者反面这两种结果，所以统计学中有专门有一个描述二元事件概率分布的术语，也就是二项分布（Binomial Distribution）。
|
||||
|
||||
这里我们还是结合着社交App的例子，来学习下二元分布。
|
||||
|
||||
这款社交App在网上投放了广告，来吸引人们点击广告从而下载App。现在我们想通过数据看看App下载率的分布情况：
|
||||
|
||||
下载率 = 通过广告下载App的用户数量 / 看到广告的用户数量。
|
||||
|
||||
因为单个二元事件的结果，只能是发生或者不发生，发生的概率要么是100%要么是0%，所以我们要分析下载率就必须把数据进行一定程度的聚合。这里，我们就以分钟为单位来举例，先计算每分钟的下载率，再看它们的概率分布。
|
||||
|
||||
我们有一个月的用户及下载数据，一个月一共有43200分钟（60*24*30），因为我们关注的是每分钟的下载率，所以一共有43200个数据点。通过数据分析发现，每分钟平均有10个人会看到广告，下载率集中分布在0-30%之间。
|
||||
|
||||
下图是每分钟下载率的概率分布：
|
||||
|
||||
|
||||
|
||||
你可能会说，概率在某种程度上也是平均值，可以把这里的下载率理解为“看到广告的用户的平均下载量”，那我们已经有43200个数据点了，样本量远远大于30，但为什么下载率的分布没有像中心极限定理说的那样趋近于正态分布呢？
|
||||
|
||||
这是因为在二项分布中，中心极限定理说的样本量，指的是计算概率的样本量。在社交App的例子中，概率的样本量是10，因为平均每分钟有10人看到广告，还没有达到中心极限定理中说的30这个阈值。所以，我们现在要提高这个样本量，才能使下载率的分布趋近正态分布。
|
||||
|
||||
提高样本量的方法也很简单，可以计算每小时的下载率。因为每小时平均有600人看到广告，这样我们的样本量就从10提高到了600。下图是每小时下载率的概率分布：
|
||||
|
||||
|
||||
|
||||
现在再看这张直方图，每小时下载率的分布是不是就趋近于正态分布了！图中下载率的平均值大约为10%。
|
||||
|
||||
在二项分布中，有一个从实践中总结出的经验公式：min(np,n(1-p)) >= 5。其中，n为样本大小，p为概率的平均值。
|
||||
|
||||
这个公式的意思是说，np或者n(1-p)中相对较小的一方大于等于5，只有二项分布符合这个公式时，才可以近似于正态分布。这是中心极限定理在二项分布中的变体。
|
||||
|
||||
在我们的例子中，计算每分钟下载率的概率分布时，np=10*10%=1，小于5，所以不能近似成正态分布；计算每小时下载率的概率分布时，np=600*10%=60，大于等于5，所以可以近似成正态分布。
|
||||
|
||||
我们可以利用这个公式来快速判断概率类指标是不是可以近似成正态分布。不过你也可以想象在实践中的A/B测试，由于样本量比较大，一般都会符合以上公式的。
|
||||
|
||||
小结
|
||||
|
||||
今天这节课，我们主要学习了A/B测试和假设检验的前提，也就是指标的统计属性。我给你总结成了一个定理、两个分布和三个概念：
|
||||
|
||||
|
||||
一个定理：中心极限定理。
|
||||
两个分布：正态分布和二项分布。
|
||||
三个概念：方差，标准差和z分数。
|
||||
|
||||
|
||||
生活中随机变量的分布有很多种，今天我重点给你介绍了正态分布和二项分布，它们分别对应的是最普遍的两类业务指标：均值类和概率类。
|
||||
|
||||
而且你要知道，有了中心极限定理，我们就可以把业务中的大部分指标都近似成正态分布了。这一点非常重要，因为A/B测试中的很多重要步骤，比如计算样本量大小和分析测试结果，都是以指标为正态分布为前提的。
|
||||
|
||||
同时，你还可以用通过方差和标准差来了解业务指标的离散程度，再结合z分数就可以计算出业务指标的波动范围了。只有理解了指标的波动范围，才能够帮助我们得到更加准确的测试结果。
|
||||
|
||||
在下节课中，我们继续学习A/B测试的统计基础，也就是假设检验及其相关的统计概念。
|
||||
|
||||
思考题
|
||||
|
||||
我在刚开始接触概率类指标的二项分布时对于其如何能近似成正态分布很迷惑，大家可以在这里聊一聊在学习A/B测试的统计过程中有什么难理解的地方，以及是如何解决的？
|
||||
|
||||
欢迎在留言区写下你的思考和想法，我们可以一起交流讨论。如果你觉得有所收获，欢迎你把课程分享给你的同事或朋友，一起共同进步！
|
||||
|
||||
|
||||
|
||||
|
||||
235
专栏/AB测试从0到1/02统计基础（下）：深入理解A_B测试中的假设检验.md
Normal file
235
专栏/AB测试从0到1/02统计基础（下）：深入理解A_B测试中的假设检验.md
Normal file
@@ -0,0 +1,235 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
02 统计基础（下）：深入理解A_B测试中的假设检验
|
||||
你好，我是博伟。
|
||||
|
||||
在上节课学习A/B测试指标的统计属性时，我用一句话给你简单解释了下假设检验：选取一种合适的检验方法，去验证在A/B测试中我们提出的假设是否正确。
|
||||
|
||||
这句话其实很抽象，所以今天这一讲，我们就具体展开下，看看假设检验是什么，以及如何利用假设检验来做出推断。
|
||||
|
||||
假设检验(Hypothesis Testing)是什么？
|
||||
|
||||
假设检验，顾名思义，就是要检验我们提出的假设是不是正确的，在事实上能否成立。
|
||||
|
||||
在统计中，我们很难获取总体数据（Population）。不过，我们可以取得样本数据（Sample），然后根据样本数据的情况产生对总体数据的假设。所以，我们所说的假设检验，其实就是检测通过样本数据产生的假设在总体数据（即事实）上是否成立。
|
||||
|
||||
在A/B测试的语境中，假设一般是指关于实验组和对照组指标的大小的推断。
|
||||
|
||||
为了更加形象地帮你理解假设检验，这节课我就从一个推荐系统的案例出发，从中抽象出假设检验的基本原理和相关概念，让你在实践中学习理论，同时把理论应用到实践中去。
|
||||
|
||||
新闻App中的推荐系统是重要的组成部分，可以根据用户过往的浏览记录来推荐用户喜欢的内容。最近，工程团队改进了推荐系统的算法，就想通过A/B测试来验证改进的效果。
|
||||
|
||||
实验组中使用新算法，对照组中使用旧算法，然后通过点击率来表征算法的效果：推荐效果越好，点击率越高。那么，我们提出的假设就是：实验组（新算法）的点击率比对照组（旧算法）的点击率高。
|
||||
|
||||
你可能会有些疑惑，我们提出的“假设”，和假设检验中的“假设”是相同的吗？
|
||||
|
||||
其实不完全相同。
|
||||
|
||||
假设检验中的“假设”是什么？
|
||||
|
||||
为什么这么说呢？因为在假设检验中的“假设”是一对：零假设（Null Hypothesis）和备择假设（Alternative Hypothesis），它们是完全相反的。在A/B测试的语境下，零假设指的是实验组和对照组的指标是相同的，备择假设指的是实验组和对照组的指标是不同的。
|
||||
|
||||
为了更好地理解零假设和备择假设，我们可以回到推荐系统的案例中，把最开始提出的假设转化成假设检验中的零假设和备择假设：
|
||||
|
||||
|
||||
零假设是，实验组和对照组的点击率是相同的。
|
||||
备择假设是，实验组和对照组的点击率是不同的。
|
||||
|
||||
|
||||
你可能会问，我们最开始提出的假设不是“实验组的点击率比对照组的点击率高”吗？为什么备择假设中仅仅说两组的点击率不同，却没说谁大谁小呢？
|
||||
|
||||
要回答这个问题，我们就得先了解单尾检验（One-tailed Test）和双尾检验（Two-tailed Test）这两个概念。
|
||||
|
||||
|
||||
单尾检验又叫单边检验（One-sided Test），它不仅在假设中说明了两个比较对象不同，并且还明确了谁大谁小，比如实验组的指标比对照组的指标大。
|
||||
双尾检验又叫双边检验（Two-sided Test），指的是仅仅在假设中说明了两个比较对象不同，但是并没有明确谁大谁小。
|
||||
|
||||
|
||||
回到推荐系统案例中的最初假设，我们已经明确了实验组的点击率比对照组的高，那就应该选用单尾检验。但是，我们的备择假设却变成了两组的点击率不同，这是双尾检验的假设，为什么呢？
|
||||
|
||||
这就是理论和实践的不同之处，也是为什么我们觉得A/B测试的理论好掌握，但实践总出问题的原因。这里，我先告诉你结论，再给你说明为什么。结论是：在A/B测试的实践中，更推荐使用双尾检验。
|
||||
|
||||
更推荐你使用双尾检验的原因，主要有两个。
|
||||
|
||||
第一个原因是，双尾检验可以让数据自身在决策中发挥更大的作用。
|
||||
|
||||
我们在实践中使用A/B测试，就是希望能够通过数据来驱动决策。我们要尽量减少在使用数据前产生的任何主观想法来干扰数据发挥作用。所以，双尾检验这种不需要我们明确谁大谁小的检验，更能发挥数据的作用。
|
||||
|
||||
第二个原因是，双尾检验可以帮助我们全面考虑变化带来的正、负面结果。
|
||||
|
||||
在实践中，我们期望改变可以使指标朝着好的方向变化，但是万一指标实际的变化与期望的正好相反呢？这就可以体现双尾检验的优势了。双尾检验可以同时照顾到正面和负面的结果，更接近多变的现实情况。但是单尾检验只会适用于其中一种，而且通常是我们期望的正面效果。
|
||||
|
||||
所以正因为我们选择双尾测试，在备择假设中我们才只说了两组不同，并没有说谁大谁小。
|
||||
|
||||
假设检验中的“检验”都有哪些，该怎么选取？
|
||||
|
||||
现在，我们知道了假设检验中的“假设”包括零假设和备择假设两种，那么“检验”都包括什么呢？
|
||||
|
||||
其实，检验有很多种，单尾检验和双尾检验，是从“假设”的角度来分类的。除此之外，常见的“检验”还可以根据比较样本的个数进行分类，包括单样本检验（One-Sample Test）、 双样本检验（Two-Sample Test）和配对检验（Paired Test）。那么问题来了，在测试中到底该选择哪种检验方法呢？
|
||||
|
||||
答案是：在A/B测试中，使用双样本检验。
|
||||
|
||||
其中的原因其实很简单，我给你解释下它们各自的适用范围，你就知道了。
|
||||
|
||||
|
||||
当两组样本数据进行比较时，就用双样本检验。比如A/B测试中实验组和对照组的比较。
|
||||
当一组样本数据和一个具体数值进行比较时，就用单样本检验。比如，我想比较极客时间用户的日均使用时间有没有达到15分钟，这个时候，我就可以把一组样本数据（抽样所得的极客时间用户的每日使用时间）和一个具体数值（15）来进行比较。
|
||||
当比较同一组样本数据发生变化前和发生变化后时，就用配对检验。比如，我现在随机抽取1000个极客时间的用户，给他们“全场专栏一律1折”这个优惠，然后在这1000个人中，我们会比较他们在收到优惠前一个月的日均使用时间，和收到优惠后一个月的日均使用时间。
|
||||
|
||||
|
||||
看到这里，你可能会问，我还听说过T检验（T Test）和Z检验（Z Test），那这两个检验在A/B测试中该怎么选择呢？
|
||||
|
||||
选择T检验还是Z检验，主要看样本量的大小和是否知道总体方差（Population Variance）：
|
||||
|
||||
|
||||
当我们不知道总体方差时，使用T检验。
|
||||
当我们已知总体方差，且样本量大于30时，使用Z检验。
|
||||
|
||||
|
||||
我还给你画了张图，你一看就明白了。
|
||||
|
||||
|
||||
|
||||
那么这些理论具体到A/B测试实践中，一个经验就是：均值类指标一般用T检验，概率类指标一般用Z检验（比例检验）。
|
||||
|
||||
为什么会有这样的经验呢？
|
||||
|
||||
因为上节课我讲了，样本量大的情况下均值类指标是正态分布，正态分布的总体方差的计算需要知道总体中各个数据的值，这在现实中几乎做不到，因为我们能获取的只是样本数据。所以总体方差不可知，选用T检验。
|
||||
|
||||
而概率类指标是二项分布，二项分布的总体方差的计算不需要知道总体中各个数据的值，可以通过样本数据求得总体方差。而且现实中A/B测试的样本量一般都远大于30，所以选用Z检验。这里的比例检验（Proportion Test)是，专指用于检验概率类指标的Z检验。
|
||||
|
||||
讲了这么多检验，我现在来总结一下：对于A/B测试来说，要选用双尾、双样本的比例检验（概率类指标）或T检验（均值类指标）。
|
||||
|
||||
再次回到我们的案例中来，由于点击率为概率类指标，所以这里选用双尾、双样本的比例检验。
|
||||
|
||||
如何利用假设检验做出推断？
|
||||
|
||||
选取了正确的假设和检验方法，接下来就要检验我们的假设是不是正确了，这在A/B测试中就是分析测试结果这一步啦。
|
||||
|
||||
A/B测试可能出现的结果
|
||||
|
||||
假设检验会推断出两种结果：
|
||||
|
||||
|
||||
接受零假设，拒绝备择假设，也就是说实验组和对照组的指标是相同的。
|
||||
|
||||
接受备择假设，拒绝零假设，也就是说实验组和对照组的指标是不同的。
|
||||
|
||||
|
||||
但是请注意，这两个结果只是假设检验根据样本数据，通过一系列统计计算推断出的结果，并不代表事实情况（总体数据情况）。如果考虑到事实情况的话，结合假设检验的推断结果会有四种可能：
|
||||
|
||||
|
||||
|
||||
可以看出，只有当假设检验推断的情况和事实完全相符时，推断才正确，否则就会出现两类错误。
|
||||
|
||||
第一类错误（Type I Error)：统计上的定义是拒绝了事实上是正确的零假设。在A/B测试中，零假设是两组的指标是相同的，当假设检验推断出两组指标不同，但事实上两组指标相同时，就是第一类错误。我们把两组指标不同称作阳性（Positive）。所以，第一类错误又叫假阳性（False Positive）。
|
||||
|
||||
发生第一类错误的概率用α表示，也被称为显著水平（Significance Level）。“显著”是指错误发生的概率大，统计上把发生率小于5%的事件称为小概率事件，代表这类事件不容易发生。因此显著水平一般也为5%。
|
||||
|
||||
第二类错误（Type II Error)：统计上的定义是接受了事实上是错误的零假设。在A/B测试中，当假设检验推断出两组指标相同，但事实上两组指标是不同时，就是第二类错误。我们把两组指标相同称作阴性（Negative），所以第二类错误又叫假阴性（False Negative）。发生第二类错误的概率用β表示，统计上一般定义为20%。
|
||||
|
||||
这两种错误的概念读起来可能比较拗口，也不太容易理解，那么我就举一个新冠病毒核酸检测的例子来给你具体解释一下。
|
||||
|
||||
我们在这里的零假设是：被测试者是健康的，没有携带新冠病毒。
|
||||
|
||||
把携带新冠病毒作为阳性，没有携带作为阴性。如果一个健康的人去检测，结果检测结果说此人携带新冠病毒，这就犯了第一类错误，拒绝了事实上正确的零假设，是假阳性。如果一个新冠肺炎患者去检测，结果检测结果说此人没有携带新冠病毒，这就犯了第二类错误，接受了事实上错误的零假设，是假阴性。
|
||||
|
||||
现在我们了解了假设检验推断的可能结果，那么，如何通过假设检验得到测试结果呢？
|
||||
|
||||
实践中常用的有两种方法：P值（P Value）法和置信区间（Confidence Interval）法。
|
||||
|
||||
P值法
|
||||
|
||||
在统计上，P值就是当零假设成立时，我们所观测到的样本数据出现的概率。在A/B测试的语境下，P值就是当对照组和实验组指标事实上是相同时，在A/B测试中用样本数据所观测到的“实验组和对照组指标不同”出现的概率。
|
||||
|
||||
如果我们在A/B测试中观测到“实验组和对照组指标不同”的概率（P值）很小，比如小于5%，是个小概率事件，虽然这在零假设成立时不太可能发生，但是确实被我们观测到了，所以肯定是我们的零假设出了问题。那么，这个时候就应该拒绝零假设，接受备择假设，即两组指标是不同的。
|
||||
|
||||
与此相反的是，当我们在A/B测试中观测到“实验组和对照组指标不同”的概率（P值）很大，比如70%，那么在零假设成立时，我们观测到这个事件还是很有可能的。所以这个时候我们接受零假设，拒绝备择假设，即两组指标是相同的。
|
||||
|
||||
在统计中，我们会用P值和显著水平α进行比较，又因为α一般取5%，所以就用P值和5%进行比较，就可以得出假设检验的结果了：
|
||||
|
||||
|
||||
当P值小于5%时，我们拒绝零假设，接受备择假设，得出两组指标是不同的结论，又叫做结果显著。
|
||||
当P值大于5%时，我们接受零假设，拒绝备择假设，得出两组指标是相同的结论，又叫做结果不显著。
|
||||
|
||||
|
||||
至于P值具体的计算，我推荐你用工具来完成，比如Python或者R：
|
||||
|
||||
|
||||
比例检验，可以用Python的proportions_ztest函数、R的prop.test函数。
|
||||
T检验，可以用Python的ttest_ind函数、R的t.test函数。
|
||||
|
||||
|
||||
置信区间法
|
||||
|
||||
置信区间是一个范围，一般前面会跟着一个百分数，最常见的是95%的置信区间。这是什么意思呢？在统计上，对于一个随机变量来说，有95%的概率包含总体平均值（Population mean）的范围，就叫做95%的置信区间。
|
||||
|
||||
置信区间的统计定义其实不是特别好懂，其实你可以直接把它理解为随机变量的波动范围，95%的置信区间就是包含了整个波动范围的95%的区间。
|
||||
|
||||
A/B测试本质上就是要判断对照组和实验组的指标是否相等，那怎么判断呢？答案就是计算实验组和对照组指标的差值δ。因为指标是随机变量，所以它们的差值δ也会是随机变量，具有一定的波动性。
|
||||
|
||||
这就意味着，我们就要计算出δ的置信区间，然后看看这个置信区间是否包括0。如果包括0的话，则说明δ有可能为0，意味着两组指标有可能相同；如果不包括0，则说明两组指标不同。
|
||||
|
||||
至于置信区间的具体的计算，我也推荐你使用Python或者R等工具完成：
|
||||
|
||||
|
||||
比例检验，可以使用Python的proportion_confint函数、R的prop.test函数。
|
||||
T检验，可以使用Python的tconfint_diff函数、R的t.test函数。
|
||||
|
||||
|
||||
现在回到推荐系统的案例中，我会分别用P值法和置信区间法来根据A/B测试的结果进行判断。
|
||||
|
||||
|
||||
实验组（新推荐算法）：样本量为43578，其中有2440个点击，点击率为5.6%。
|
||||
对照组（旧推荐算法）：样本量为43524，其中有2089个点击，点击率为4.8%。
|
||||
|
||||
|
||||
这时候，我用R中的比例检验函数prop.test来计算P值和置信区间。
|
||||
|
||||
prop.test(x = c(2440, 2089), n = c(43578, 43524), alternative = "two.sided", conf.level = 0.95)
|
||||
|
||||
|
||||
得到了如下结果：
|
||||
|
||||
|
||||
|
||||
可以得出P值=\(1.167 e^{-7}\)， 远远小于5%且接近于0，所以我们拒绝零假设，接受备择假设，并且推断出实验组和对照组指标显著不同。
|
||||
|
||||
同时，我们也可以得出两组指标差值δ的95%置信区间为[0.005,0.011]，不包含0，也可以推断出两组指标显著不同。
|
||||
|
||||
小结
|
||||
|
||||
今天这节课，我们针对A/B测试的理论基础—假设检验，学习了假设、检验，以及相关的统计概念。你只要记住以下两个知识点就可以了。
|
||||
|
||||
第一，对于A/B测试来说，要选用双尾、双样本的比例检验（概率类指标）或T检验（均值类指标）。这决定了你在计算分析A/B测试结果时如何选取检验的参数，所以很重要。
|
||||
|
||||
第二，在A/B测试实践中，计算样本量大小、指标波动性和分析测试结果的时候，会用到这些统计概念。
|
||||
|
||||
|
||||
计算样本量大小时，会用到： 第一类/第二类错误及其概率α和β。
|
||||
计算指标波动性时，会用到：方差和置信区间。
|
||||
分析A/B测试结果时，会用到：各类检验、置信区间、P值。
|
||||
|
||||
|
||||
本节课中的关于假设检验的概念和知识点比较琐碎，为了方便你日后理解记忆，我也给你准备了下面的导图：
|
||||
|
||||
|
||||
|
||||
到这里我们的统计篇就告一段落了，现在你应该已经掌握了A/B测试所需的基本统计知识啦。其实，前两节的内容比较偏理论，会不太好理解。不过，理论知识的学习，如果只是填鸭式地讲，效果可能并不好。那该怎么掌握这些理论知识呢？在我这些年做A/B测试的实践中发现，要想真正把理论知识理解透，化为己用，还是需要自己多思考，多实践。等你有了一些实战后，自然就能自己体悟到理论学习的好处了。而且这时候再回过头来看理论，就会非常容易看懂。
|
||||
|
||||
所以，在今天的内容中，如果有哪些地方你还不能理解，那也没关系，不要给自己设置心理障碍，可以先放一放。之后的课程中，我都会运用今天讲到的理论，去解决在A/B测试中遇到的问题。你可以在学习的过程中不断回顾这些理论，或者发挥主观能动性，多查阅一些资料。等你学完整个课程，再回头看这两节理论知识，一定会发现理论原来如此简单。
|
||||
|
||||
那么接下来，我们就进入“基础篇”模块，去详细学习A/B测试的主要流程吧！
|
||||
|
||||
思考题
|
||||
|
||||
这节课涉及的统计概念都是虽然经常听到，但是难理解的，你们在学习统计中有没有对这些概念的理解有独特的心得？可以拿出来分享给大家。
|
||||
|
||||
欢迎在留言区写下你的思考和想法，我们可以一起交流讨论。如果你觉得有所收获，欢迎你把课程分享给你的同事或朋友，一起共同进步！
|
||||
|
||||
|
||||
|
||||
|
||||
224
专栏/AB测试从0到1/04确定指标：指标这么多，到底如何来选择？.md
Normal file
224
专栏/AB测试从0到1/04确定指标：指标这么多，到底如何来选择？.md
Normal file
@@ -0,0 +1,224 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
04 确定指标：指标这么多，到底如何来选择？
|
||||
你好，我是博伟。
|
||||
|
||||
上节课，我们学习了确定评价指标的几种方法，包括量化产品/业务不同阶段的目标，采取定量+定性的方法，或者借鉴行业内其他公司的经验等。你也发现了，这些方法的局限性在于只能选出单个评价指标，而且也没有考虑到评价指标的波动性对结果准确度的影响。
|
||||
|
||||
今天我们会更进一步，去看看在实际的复杂业务场景中，确定评价指标的方法，以及计算指标的波动性的方法。然后，我们再看看为了确保A/B测试结果的可靠性，应该如何去确定护栏指标。
|
||||
|
||||
综合多个指标，建立总体评价标准
|
||||
|
||||
在实际的业务需求中，有时会出现多个目标，同一目标也可能有多个都很重要的评价指标，需要我们把它们都综合起来考虑。对于单个指标，我们可以用上一讲的方法来确定；但如果要综合考虑多个指标时，又要如何考虑呢？
|
||||
|
||||
我们先看一个例子。
|
||||
|
||||
亚马逊和用户沟通的一个重要渠道就是电子邮件，它有一个专门给用户发送电子邮件的平台，通过两种方式来精准定位用户：
|
||||
|
||||
|
||||
基于用户的历史购买数据来构建用户的个人喜好，通过推荐算法来发邮件给用户做推荐；
|
||||
亚马逊的编辑团队会人工精选出推荐产品，通过电子邮件发送给用户。
|
||||
|
||||
|
||||
确定了精准用户以后，亚马逊还面临一个问题：要用什么指标来衡量电子邮件的效果呢？
|
||||
|
||||
你可能会想到，给用户发送邮件是为了让他们购买，所以邮件产生的收入可以作为评价指标。
|
||||
|
||||
实际上，亚马逊最初就是这么做的：他们确定的假设是通过多发电子邮件来增加额外的收入，评价指标就是邮件产生的收入。
|
||||
|
||||
那么这个时候，一个假想的A/B测试就被设计了出来。
|
||||
|
||||
|
||||
在实验组，我们给用户发邮件。
|
||||
在对照组，我们不给用户发邮件。
|
||||
|
||||
|
||||
结果可想而知。对照组没有收到任何邮件，也就不会有邮件产生的收入。而在实验组的用户，由于收到很多邮件，所以产生了不少收入。
|
||||
|
||||
出现这个结果的根本原因是，这个指标本身是单调递增的。也就是说，发的电子邮件越多，点击的用户也会越多，从邮件中获得的收入也会越多。所以，想要有更多的收入，就要发更多的邮件。
|
||||
|
||||
但现实情况是，用户收到的邮件多到一定程度后，他们就会觉得是垃圾邮件，被骚扰了，结果就是影响了用户体验，用户选择退订（Unsubscribe）邮件。而用户一旦退订，以后就再也接收不到来自亚马逊的邮件了。
|
||||
|
||||
把邮件产生的收入作为评价指标，可以说只是用来优化短期的收入，并没有考虑到长期的用户价值。用户一旦因为被骚扰而退订，亚马逊就失去了在未来给他们发邮件做营销的机会了。所以，邮件产生的收入并不适合作为评价指标，我们需要综合考虑发邮件所带来的好处和潜在的损失，结合多个指标，构建一个总体评价标准 （Overall Evaluation Criteria，简称OEC）。
|
||||
|
||||
那具体怎么做呢？我们可以给每个实验/对照组计算OEC：
|
||||
\[-
|
||||
\\mathrm{OEC}=\\frac{\\left(\\Sigma\_{i}{ Revenue-S\*Unsubscribe\\\_lifetime\\\_loss}\\right)} {n}-
|
||||
\]我来具体解释下这个公式。
|
||||
|
||||
|
||||
i，代表每一个用户。
|
||||
S，代表每组退订的人数。
|
||||
Unsubscribe_lifetime_loss ，代表用户退订邮件带来的预计的损失。
|
||||
n，代表每组的样本大小。
|
||||
|
||||
|
||||
当亚马逊实施了这个OEC之后，惊讶地发现有一半以上电子邮件的OEC都是负的，这就说明多发邮件并不总是能带来正的收益。
|
||||
|
||||
当亚马逊发现退订会造成这么大的长期损失以后，就改进了它的退订页面：从退订所有的亚马逊邮件到退订某一个类别的邮件。比如可以选择只退订亚马逊图书，从而避免了全部退订，也减少了长期的潜在损失。
|
||||
|
||||
通过刚刚的分析，我们可以看到，当要考察的事物包含多个方面时，只有综合各方面的指标，才能把握总体的好坏。这也是使用OEC最明显的一个好处。最常见的一类OEC，就是亚马逊的这种结合变化带来的潜在收益和损失的OEC。需要注意的是，这里的“损失”还有可能是护栏指标，也就是说OEC有可能会包含护栏指标。
|
||||
|
||||
另外，使用OEC的另一个好处就是可以避免多重检验问题（Multiple Testing Problem）。如果我们不把不同的指标加权结合起来分析，而是单独比较它们，就会出现多重检验的问题，导致A/B测试的结果不准确。多重检验问题是A/B测试中一个非常常见的误区，我在进阶篇中会具体讲解。
|
||||
|
||||
解决了单一评价指标不能应对复杂A/B测试的场景的问题后，我们继续学习评价指标的最后一个要点：波动性。在实际业务场景中，评价指标的值会因各种因素的影响而发生波动。如果忽视了这一点，就很有可能得出错误的测试结论。
|
||||
|
||||
如何衡量评价指标的波动性？
|
||||
|
||||
还记得我们上节课所学的音乐App要“增加自动播放功能”的例子吗？
|
||||
|
||||
假如，这个音乐App没有自动播放功能之前，每个月的用户续订率的波动范围是[65%-70%]。我们在A/B测试中发现，实验组（有自动播放功能）的续订率69%，确实比对照组（没有自动播放功能）的续订率66%要高。
|
||||
|
||||
那么，这个结果是可信的吗？达到A/B测试的目的了吗？答案显然是否定的。
|
||||
|
||||
虽然实验组的数据要比对照组的好，但是这些数据都在正常的波动范围内。所以，增加自动播放功能和提升续订率之间的因果关系，在这次实验中就没有被建立起来，因为这两组指标的差异也可能只是正常的波动而已。但是，如果我们事先不知道评价指标的波动性和正常波动范围，就很有可能建立错误的因果关系。
|
||||
|
||||
那么，如何才能知道评价指标的这个正常波动范围呢？
|
||||
|
||||
在统计学里面，指标的波动性通常用其平均值和平均值的标准差来表示，一个指标平均值的标准差越大，说明其波动性越大。这里面要注意，变量平均值的标准差又叫做标准误差*（*Standard Error****）。关于标准差的概念，你可以再回顾下第1节课的统计学基础。
|
||||
|
||||
评价指标的正常波动范围，就是置信区间。那具体该怎么计算呢？
|
||||
|
||||
在实践中，计算波动范围一般有统计公式和实践经验两类方法。
|
||||
|
||||
第一，根据统计公式来计算。
|
||||
|
||||
在统计学中，一般是用以下公式构建置信区间的：
|
||||
|
||||
置信区间 = 样本均值（Sample Mean） ± Z分数*标准误差
|
||||
|
||||
根据中心极限定理，当样本量足够大时，大部分情况下数据服从正态分布，所以这里选用z分数。在一般情况下我们选用95%的置信区间，对应的z分数为1.96。
|
||||
|
||||
为了给你形象地展示置信区间，我们在这里假设指标的样本均值为50、标准误差为0.1，服从正态分布，那么，该指标的95%的置信区间为 [50-1.96*0.1， 50+1.96*0.1] = [49.8, 50.2]。
|
||||
|
||||
你可能注意到了，我在用上面这个公式计算置信区间，假设了一个标准误差。但实际情况上，标准误差是需要我们来计算的。而且，计算标准误差是非常关键的一步。
|
||||
|
||||
对于简单的指标，主要是概率类和均值类，我们可以用统计公式来计算标准误差。
|
||||
|
||||
概率类的指标，常见的有用户点击的概率（点击率）、转化的概率（转化率）、购买的概率（购买率），等等。
|
||||
|
||||
这类指标在统计上通常服从二项分布，在样本量足够大的情况下，也可以近似为正态分布（关于二项分布和正态分布，你可以回顾下第1节课的相关内容）。
|
||||
|
||||
所以，概率指标的标准误差，我们可以通过下面这个公式计算：-
|
||||
$\(-
|
||||
\\text { Standard Error }=\\sqrt{\\frac{p(1-p)}{n}}-
|
||||
\)$
|
||||
|
||||
其中，p代表事件发生的概率。
|
||||
|
||||
均值类的指标，常见的有用户的平均使用时长、平均购买金额、平均购买频率，等等。根据中心极限定理，这类指标通常也是正态分布。
|
||||
|
||||
所以，均值类指标的标准误差，我们可以这样计算：
|
||||
\[-
|
||||
\\text {Standard Error}=\\sqrt{\\frac{s^{2}}{\\mathrm{n}}}=\\sqrt{\\frac{\\sum\_{i}^{n}\\left(x\_{i}-\\bar{x}\\right)^{2}}{n(n-1)}}-
|
||||
\]其中，s代表样本的标准差，
|
||||
|
||||
n=样本大小，
|
||||
|
||||
\(x\_{i}\)=第i个用户的使用时长或者购买金额等，
|
||||
|
||||
\(\\bar{x}\)= 用户的平均使用时长或者购买金额等。
|
||||
|
||||
第二，根据实践经验来确定。
|
||||
|
||||
在实际应用中，有些复杂的指标可能不符合正态分布，或者我们根本不知道它们是什么分布，就很难甚至是没办法找到相应的统计公式去计算了。这时候，要得到评价指标的波动范围，我们需要结合实践经验来估算。
|
||||
|
||||
1.A/A测试
|
||||
|
||||
我们可以跑多个不同样本大小的A/A测试，然后分别计算每个样本的指标大小，计算出来后，再把这些指标从小到大排列起来，并且去除最小2.5% 和最大2.5%的值，剩下的就是95%的置信区间。
|
||||
|
||||
2.Bootstrapping算法
|
||||
|
||||
我们可以先跑一个样本很大的A/A测试，然后在这个大样本中进行随机可置换抽样（Random Sample with Replacement）， 抽取不同大小的样本来分别计算指标。然后采用和A/A测试一样的流程：把这些指标从小到大排列起来，并且去除最小2.5% 和最大2.5%的值，得到95%的置信区间。
|
||||
|
||||
在实际应用中，Bootstrapping会更流行些，因为只需要跑一次A/A测试，既节省时间也节省资源。
|
||||
|
||||
不过要注意的是，即使对于那些简单的、符合正态分布的、可以用统计方法直接计算方差的指标，如果有条件、有时间的话，我也推荐你同时用统计公式和Bootstrapping两种方法分别计算方差。如果两者的结果差距较大，就需要再去跑更多的A/A测试，所以从两方面验证得到的结果会更保险。
|
||||
|
||||
到这里，评价指标的选取方法，以及波动性这个易错点，我们就都学习完了。接下来，我们进入到选取指标的最后一部分内容，如何选取护栏指标，为A/B测试提供质量保障。
|
||||
|
||||
护栏指标
|
||||
|
||||
A/B测试往往改变的是业务中的某一部分指标（评价指标），所以我们很容易只关注短期的改变，却失去了对业务的大局观（比如长期的盈利能力/用户体验）的掌控或者统计上合理性的检查。因此在实践中，我会推荐每个A/B测试都要有相应的护栏指标。
|
||||
|
||||
接下来，我们就从业务品质和统计品质这两个维度，来学习如何选取护栏指标。这里我先用一张图，帮你总结下：
|
||||
|
||||
|
||||
|
||||
业务品质层面
|
||||
|
||||
在业务层面的护栏指标，是在保证用户体验的同时，兼顾盈利能力和用户的参与度。所以，我们通常会用到的护栏指标主要是三个：网络延迟（Latency）、闪退率（Crash Rate）和人均指标。
|
||||
|
||||
|
||||
网络延迟
|
||||
|
||||
|
||||
网页加载时间、App响应时间等，都是表征网络延迟的护栏指标。增加产品功能可能会增加网页或App的响应时间，而且用户可以敏感地察觉出来。这个时候，就需要在A/B测试中加入表征网络延迟的护栏指标，确保在增加产品功能的同时，尽可能减少对用户体验的影响 （一般是通过优化底层代码）。
|
||||
|
||||
|
||||
闪退率
|
||||
|
||||
|
||||
对于不同的应用程序App来说，不管是在个人电脑端，还是在移动端，都有可能因为CPU、内存或者其他原因出现闪退，导致程序突然关闭。
|
||||
|
||||
说到这儿，我想和你分享一件趣事。我在用MS Word写这节课的内容时，就出现了软件闪退。关键是我当时还没有保存，心想几个小时的努力不就白费了嘛，特别心灰意冷。万幸的是，MS Word有自动保存功能。
|
||||
|
||||
你看，闪退发生的概率虽然不大，但是会严重影响用户体验。所以，在测试应用程序的新功能时，尤其是针对一些大的改动，闪退率就是一个比较好的护栏指标。
|
||||
|
||||
|
||||
人均指标
|
||||
|
||||
|
||||
人均指标可以从两个角度来考虑：
|
||||
|
||||
|
||||
收入角度，比如人均花费、人均利润等。
|
||||
用户参与度，比如人均使用时长、人均使用频率等。
|
||||
|
||||
|
||||
这两个角度一般都是实际业务中追求的目标，收入角度代表了产品的盈利能力，用户参与度代表了用户的满意程度。但是，在具体的A/B测试中，我们往往会只关注产品的被测试部分的功能，忽视了对大局的把握。
|
||||
|
||||
举个例子。应用商店优化了推荐算法后，推荐的内容更贴近用户的喜好，提高了用户对推荐内容的点击率。我们关注的评价指标点击率提高了，是不是皆大欢喜呢？不是的，因为我们分析后发现，这个新算法推荐内容中的免费App的比例增加了，使得人均花费降低了，进而影响到了应用商店的总体收入。
|
||||
|
||||
这个时候，我们可以把人均收入作为护栏指标，去继续优化推荐算法。
|
||||
|
||||
统计品质层面
|
||||
|
||||
统计方面主要是尽可能多地消除偏差，使实验组和对照组尽可能相似，比如检测两组样本量的比例，以及检测两组中特征的分布是否相似。
|
||||
|
||||
造成偏差的原因有很多，可能是随机分组的算法出现了Bug，也可能是样本不够大，还有可能是触发实验条件的数据出现了延迟，不过更多的是具体实施中的工程问题造成的。这些偏差都会影响我们获得准确的实验结果，而护栏指标就是我们发现这些偏差的利器！
|
||||
|
||||
1.实验/对照组样本大小的比例
|
||||
|
||||
在设计A/B测试的时候，我们就会预先分配好实验组和对照组，通常是把样本等分。也就是说，实验组和对照组样本大小的比例，预期是1:1=1。但有的时候，当实验结束后却发现两者的比例并不等于1，甚至也没有很接近1。这就说明这个实验在具体实施的过程中出现了问题，导致实验组和对照组出现了偏差。
|
||||
|
||||
2.实验/对照组中特征的分布
|
||||
|
||||
A/B 测试中一般采取随机分组，来保证两组实验对象是相似的，从而达到控制其他变量、只变化我们关心的唯一变量（即A/B测试中的原因）的目的。
|
||||
|
||||
比如说，如果以用户作为实验单位的话，那么，在试验结束后去分析两组数据时，两组中用户的年龄、性别、地点等基本信息的分布应该是大体一致的，这样才能消除偏差。否则，实验本身就是有问题的，得出的结果也不是可信赖的。
|
||||
|
||||
小结
|
||||
|
||||
今天，我们学习了复杂业务场景下如何选取评价指标、评价指标的波动性这个易错点，以及如何选取护栏指标。
|
||||
|
||||
|
||||
有多个指标出现的情况下，我们可以把它们结合在一起，建立总体评价标准，也就是OEC。这里面需要注意的一点是，不同指标的单位、大小可能不在一个尺度上，需要先要对各个指标进行归一化（Normalization）处理，使它们的取值都在一定的范围内，比如[0,1]， 之后再进行结合，从而剔除指标单位/大小的影响。
|
||||
|
||||
评价指标的正常波动范围，就是置信区间。计算置信区间是一个重点，对于分布比较复杂的指标我推荐用bootstrapping来计算，对于概率类或者均值类的这些符合二项分布或者正态分布的指标，建议同时用统计公式和Bootstrapping两种方法来计算。
|
||||
|
||||
在实践中选取护栏指标的时候，我们主要是从业务品质和统计品质这两个维度来考虑。可以选择的护栏指标有，网络延迟、闪退率、人均指标、实验/对照组样本大小的比例和实验/对照组中特征的分布等。
|
||||
|
||||
|
||||
思考题
|
||||
|
||||
你之前在工作中接触过的A/B测试，都会有相应的护栏指标吗？如果有的话，是什么具体的指标呢？这些护栏指标的作用又是什么呢？
|
||||
|
||||
欢迎在留言区写下你的思考和想法，我们可以一起交流讨论。如果你觉得有所收获，欢迎你把课程分享给你的同事或朋友，一起共同进步！
|
||||
|
||||
|
||||
|
||||
|
||||
164
专栏/AB测试从0到1/05选取实验单位：什么样的实验单位是合适的？.md
Normal file
164
专栏/AB测试从0到1/05选取实验单位：什么样的实验单位是合适的？.md
Normal file
@@ -0,0 +1,164 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
05 选取实验单位：什么样的实验单位是合适的？
|
||||
你好，我是博伟。
|
||||
|
||||
上节课我们确定了实验的目标、假设以及各类指标，那么今天我们就来讲一讲A/B测试的第三步：如何选取合适的实验单位。
|
||||
|
||||
前面我提到，A/B测试的本质就是控制变量实验。既然是实验，那就要有实验单位。毕竟，只有确定了实验单位，我们才能在这个单位层面进行合理的样本分配（Assignment），从而决定哪些样本在实验组（Treatment/Test Group），哪些样本在对照组（Control Group）。
|
||||
|
||||
谈到实验单位，你可能会问，这有什么难理解的，实验单位不就是用户吗？
|
||||
|
||||
其实，这是一个非常常见的认知误区。除了测试系统的表现外，在绝大部分情况下，准确地说，实验单位都是用户的行为。因为我们在产品、营销、业务上所做的调整，本质上都是为了观察用户的行为是否会有相应的变化。
|
||||
|
||||
那么问题就来了，很多单位都可以表征用户的行为。那到底是以用户为单位，以用户的每次浏览、访问为单位，还是以用户浏览的每个页面为单位呢？
|
||||
|
||||
这节课，我们就来学习下常用的实验单位有哪些，以及实践中选择实验单位的三大原则。
|
||||
|
||||
实验单位有哪些？
|
||||
|
||||
虽然可以表征用户行为的实验单位有很多，但综合来看，我们可以从用户层面、访问层面和页面层面这三个维度来分别学习。
|
||||
|
||||
用户层面（User Level）
|
||||
|
||||
用户层面是指，把单个的用户作为最小单位，也就是以用户为单位来划分实验组和对照组。
|
||||
|
||||
那么，具体到数据中，用户层面都包括什么呢？其实，主要是4种ID。
|
||||
|
||||
第一种ID是用户ID，也就是用户注册、登录时的用户名、手机号、电子邮箱，等等。
|
||||
|
||||
这类ID包含个人信息，它的特点就是稳定，不会随着操作系统和平台的变化而变化。用户ID和真实的用户一般是一一对应的关系，也是代表用户的最准确的ID。
|
||||
|
||||
第二种ID是匿名ID，一般是用户浏览网页时的Cookies。
|
||||
|
||||
Cookies是用户浏览网页时随机生成的，并不需要用户注册、登录。需要注意的是，用户使用的iOS和安卓操作系统也会随机生成Cookies，但是这些Cookies仅限于该操作系统内部，和用户浏览时使用的设备或者浏览器有很大关系。所以，综合来看，Cookies一般不包含个人信息，而且可以被抹除，因此准确度不如用户ID高。
|
||||
|
||||
第三种ID是设备ID。它是和设备绑定的，一旦出厂就不可改变。设备ID虽然不会被抹除，但是如果用户和家人、朋友共享上网设备的话，它就不能区分用户了。所以，设备ID的准确度也低于用户ID。
|
||||
|
||||
第四种ID是IP地址，它和实际的地理位置以及使用的网络都有关系。
|
||||
|
||||
同一个用户，即使用同一个设备，在不同的地方上网，IP地址也是不同的。同时，在一些大的互联网提供商中，很多用户往往共享一个IP地址。所以，IP地址的准确度是最差的，一般只有在用户ID、匿名ID和设备ID都得不到的情况下，才考虑使用IP地址。
|
||||
|
||||
这就是用户层面的4个实验单位，它们的准确度从高到低的顺序是：
|
||||
|
||||
用户ID > 匿名ID（Cookies）/设备ID > IP地址。
|
||||
|
||||
为什么我要强调这4种ID类型的准确度呢？这是因为，实验单位的准确度越高，A/B测试结果的准确度才会越高。
|
||||
|
||||
因此，当我们确定了选择用户层面的实验单位时，如果数据中有用户ID，就优先选择用户ID；如果数据中没有用户ID，比如用户出于对隐私的考虑没有注册和登录，或者是测试网页的功能无需用户注册和登录，那么就可以选用匿名ID或者设备ID；当这些ID都没有时，再选择准确度最低的IP地址。
|
||||
|
||||
访问层面（Visit/Session Level）
|
||||
|
||||
访问层面是指把用户的每次访问作为一个最小单位。
|
||||
|
||||
当我们访问网站或者App的时候，都会有后台系统来记录我们的每次访问动作。那么，我们怎么定义一次访问的开始和结束呢？
|
||||
|
||||
访问的开始很好理解，就是进入到这个网站或者App的那一瞬间。但难点就在于怎么定义一次访问的结束。在一次访问中，我们可能会点开不同的页面，上下左右滑动一番，然后退出；也有可能只是访问了一下没有啥操作，甚至都没有退出，就进入了其他的页面或者App。
|
||||
|
||||
因此，考虑到用户访问的复杂性，通常情况下，如果用户在某个网站、App连续30分钟之内没有任何动作，系统就认定这次访问已经结束了。
|
||||
|
||||
如果一个用户经常访问的话，就会有很多个不同的访问ID。那在进行A/B测试的时候，如果以访问层面作为实验单位，就可能会出现一个用户既在实验组又在对照组的问题。
|
||||
|
||||
比如，我今天和昨天都访问了极客时间App，相当于我有两个访问ID，如果以访问ID作为实验单位的话，我就有可能同时出现在对照组和实验组当中。
|
||||
|
||||
页面层面（Page Level）
|
||||
|
||||
页面层面指的是把每一个新的页面浏览（Pageview）作为最小单位。
|
||||
|
||||
这里有一个关键词“新的”，它指的是即使是相同的页面，如果它们被相同的人在不同的时间浏览，也会被算作不同的页面。举个例子，我先浏览了极客时间的首页，然后点进一个专栏，最后又回到了首页。那么如果以页面浏览ID作为实验单位的话，这两个首页的页面浏览ID就有可能一个被分配到实验组，一个被分配到对照组。
|
||||
|
||||
到这里，我们就可以对比着理解下这三个层面了。
|
||||
|
||||
|
||||
访问层面和页面层面的单位，比较适合变化不易被用户察觉的A/B测试，比如测试算法的改进、不同广告的效果等等；如果变化是容易被用户察觉的，那么建议你选择用户层面的单位。
|
||||
从用户层面到访问层面再到页面层面，实验单位颗粒度越来越细，相应地可以从中获得更多的样本量。原因也很简单，一个用户可以有多个访问，而一个访问又可以包含多个页面浏览。
|
||||
|
||||
|
||||
看到这儿，你可能觉得信息量有些大，这么多单位，具体操作时到底怎么选呢？不用担心，下面我就通过一个“视频App增加产品功能来提升用户留存率”的具体案例，来带你一步步地选出合适的实验单位。
|
||||
|
||||
一个案例：如何选择实验单位？
|
||||
|
||||
某视频App最近收到了不少用户反馈，其中很大一部分用户希望在没有网络或者网络不好的情况下也能看视频。于是，产品经理希望增加“离线下载”的功能，来提高用户的留存率。
|
||||
|
||||
现在，产品经理要通过A/B测试，来看看增加“离线下载”的功能是否真的能提升留存。那应该怎么选取实验单位呢？
|
||||
|
||||
如果把用户层面的ID作为实验单位的话（即把每个用户作为最小单位来分组），由于收集样本的时间比较紧迫，可能收集到的样本量就不够。因此，我们要去寻找颗粒度更细的实验单位，来产生更大的样本量。所以，我们可以选择访问层面或者页面层面作为实验单位。
|
||||
|
||||
数据分析师通过查看发现数据中有访问ID，但没有pageview ID，所以这里选择访问层面，把每一次访问作为最小单位来分组，因为一个用户可以产生多次访问。
|
||||
|
||||
这样一来样本量是足够了，但是我们分析计算实验结果之后发现，实验组的用户的留存率不仅没有上升，反而低于对照组。
|
||||
|
||||
这就很奇怪了，难道是因为“离线下载”功能导致用户体验变差了吗？这不是和之前用户反馈的结果相反了吗？
|
||||
|
||||
于是，我们再次对这些用户进行采访调研，得到的结论确实是用户体验确实变差了，但并不是因为用户不喜欢新增加的功能。那么问题究竟出在哪儿了呢？
|
||||
|
||||
其实，这里的问题就在于选择了不恰当的实验单位。在刚才的实验中，我们把每一次访问作为最小单位来分实验组和对照组，就造成了同一个用户因为有多个访问而被分到了不同的组。
|
||||
|
||||
所以，用户在实验组时可以使用新功能，但是被分到对照组时就会发现没有新功能，让用户很困惑。就好比，昨天你还在用一个很好用的功能今天突然消失了，是不是很沮丧呢？
|
||||
|
||||
所以，当业务的变化是用户可以察觉的时候，我建议你一定要选择用户层面作为实验单位。
|
||||
|
||||
在这种情况下，如果样本量不足，那就要和业务去沟通，明确样本量不足，需要更多的时间做测试，而不是选取颗粒度更小的单位。如果不能说服业务方增加测试时间的话，我们就要通过其他方法来弥补样本量不足会给实验造成的影响，比如增加这次A/B测试使用的流量在总流量中的比例，选用波动性（方差）更小的评价指标等方法（我会在第9节课和你讲这些方法）。
|
||||
|
||||
回过头我们再看看这个案例，是不是可以提炼些选取实验单位的经验和坑点呢？没错儿，我将其归纳为了三个原则：
|
||||
|
||||
|
||||
保证用户体验的连贯性。
|
||||
实验单位应与评价指标的单位保持一致。
|
||||
样本数量要尽可能多。
|
||||
|
||||
|
||||
掌握了这三条原则，你就能根据实际情况去选择最佳的实验单位啦！
|
||||
|
||||
确定实验单位的三大原则
|
||||
|
||||
1.保证用户体验的连贯性
|
||||
|
||||
保证用户获得最好的体验几乎是所有产品的目标之一，用户体验的连贯性尤其重要，视频App的例子告诉我们：如果A/B测试中的变化是用户可以察觉到的，那么实验单位就要选择用户层面。
|
||||
|
||||
否则，同一个用户同时出现在实验组和对照组，就会体验到不同的功能、得到不同的体验。这种体验的不连贯性，就会给用户带来困惑和沮丧，很容易导致用户流失。
|
||||
|
||||
2.实验单位要和评价指标的单位保持一致
|
||||
|
||||
为什么这么说呢？我们还得从统计学上入手去理解。
|
||||
|
||||
A/B测试的一个前提是实验单位相互独立且分布相同的（Independent and identically distributed），简称IID。如果两个单位不一致，就会违反相互独立这一前提，破坏了A/B测试的理论基础，从而导致实验结果不准确。
|
||||
|
||||
举个例子。如果用A/B测试来检测音乐App推送新专辑的效果，评价指标为用户的新专辑收听率（收听新专辑的用户数量/收到推送的用户数量），这里评价指标是建立在用户层面上的，那么实验单位一般也要为用户。
|
||||
|
||||
假如我们把实验单位变为新专辑页面层面，由于每个用户可以多次浏览该页面，所以对于同一个用户的多次页面浏览，每次页面浏览其实并不是独立的，IID的假设前提就被破坏了，那么实验结果也就变得不准确了。
|
||||
|
||||
所以，在选择实验单位时，你一定要记住：A/B测试中的实验单位应与评价指标的单位保持一致。
|
||||
|
||||
3.样本数量要尽可能多
|
||||
|
||||
在A/B测试中，样本数量越多，实验结果就越准确。但增加样本量的方法有很多，我们绝对不能因为要获得更多的样本量，就选择颗粒度更细的实验单位，而不考虑前面两个原则。
|
||||
|
||||
所以我们选取实验单位的第三个原则就是：在保证用户体验连贯性、实验单位和评价指标的单位一致的前提下，可以尽可能地选择颗粒度更细的实验单位来增加样本量。
|
||||
|
||||
那么现在三个原则就讲完啦，我来给你总结下：前两个原则是一定要考虑和满足的，第三个原则则是锦上添花，有条件的情况下可以考虑。
|
||||
|
||||
小结
|
||||
|
||||
这节课，我详细讲解了实践中常用的实验单位及其适用范围，也结合我的实际经验，给你总结了选取不同单位时需要考量的主要因素，让你真正理解并掌握背后的逻辑，从而帮助你在将来的实践中做出正确的判断。
|
||||
|
||||
我还给你总结了一个简化版的决策图，便于你回顾和记忆：
|
||||
|
||||
|
||||
|
||||
在实践中，我们要考虑的最重要的两点就是：用户体验的连贯性、实验单位和评价指标单位的一致性。毕竟用户是上帝，维持好的用户体验适用于所有的业务/产品。所以，针对用户可见的变化（比如UI的改进），大部分的实验都是把用户作为最小的实验单位（用户ID/匿名ID/设备ID），同时也把用户作为评价指标的单位。
|
||||
|
||||
如果你想要更多的样本量，同时A/B测试的变化是用户不易察觉到的（比如推荐算法的提升），可以用比用户颗粒度更细的访问或者页面作为实验单位。与此同时，也要让评价指标与实验单位保持一致。
|
||||
|
||||
思考题
|
||||
|
||||
你平时做A/B测试时，是不是都以用户为单位的？学完了这节课以后，你可以再回想一下，有些A/B测试是不是可以用其他单位？为什么？
|
||||
|
||||
欢迎在留言区写下你的思考和想法，我们一起交流讨论。如果你有所收获，也欢迎你把今天的内容分享给你的朋友，一起共同进步！
|
||||
|
||||
|
||||
|
||||
|
||||
232
专栏/AB测试从0到1/06选择实验样本量：样本量越多越好吗？.md
Normal file
232
专栏/AB测试从0到1/06选择实验样本量：样本量越多越好吗？.md
Normal file
@@ -0,0 +1,232 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
06 选择实验样本量：样本量越多越好吗？
|
||||
你好，我是博伟。
|
||||
|
||||
前面聊了很多A/B测试的准备工作，我们确定了目标和指标，也选取了实验单位，那么，现在可以正式开始测试了吗?
|
||||
|
||||
先别着急，我们还需要解决正式测试前的最后一个问题：到底多少样本量是合适的呢？
|
||||
|
||||
打破误区：样本量并不是越多越好
|
||||
|
||||
如果我问你，做A/B测试时多少样本量合适，你的第一反应肯定是，那当然是越多越好啊。样本量越多，实验结果才会越准确嘛！
|
||||
|
||||
从统计理论上来说，确实是这样。因为样本量越大，样本所具有的代表性才越强。但在实际业务中，样本量其实是越少越好。
|
||||
|
||||
为什么会这样说呢？我来带你分析一下。
|
||||
|
||||
要弄明白这个问题，你首先要知道A/B需要做多长时间，我给你一个公式：A/B测试所需的时间 = 总样本量 / 每天可以得到的样本量。
|
||||
|
||||
你看，从公式就能看出来，样本量越小，意味着实验所进行的时间越短。在实际业务场景中，时间往往是最宝贵的资源，毕竟，快速迭代贵在一个“快”字。
|
||||
|
||||
另外，我们做A/B测试的目的，就是为了验证某种改变是否可以提升产品、业务，当然也可能出现某种改变会对产品、业务造成损害的情况，所以这就有一定的试错成本。那么，实验范围越小，样本量越小，试错成本就会越低。
|
||||
|
||||
你看，实践和理论上对样本量的需求，其实是一对矛盾。所以，我们就要在统计理论和实际业务场景这两者中间做一个平衡：在A/B测试中，既要保证样本量足够大，又要把实验控制在尽可能短的时间内。
|
||||
|
||||
那么，样本量到底该怎么确定呢？
|
||||
|
||||
你可能会说，网上有很多计算样本量的网站，我用这些网站来计算出合适的样本量，难道不可以吗？这当然也是一种方法，但你有没有想过，这些网上的计算器真的适用于所有的A/B测试吗？如果不适用的话，应该怎么计算呢？
|
||||
|
||||
事实上，我们只有掌握了样本量计算背后的原理，才能正确地计算出样本量。
|
||||
|
||||
所以，这节课，我会先带你熟悉统计学上的理论基础，再带你进行实际的计算，让你学会计算不同评价指标类型所需的样本量大小。最后，我再通过一个案例来给你串讲下，帮助你掌握今天的内容。
|
||||
|
||||
样本量计算背后的原理
|
||||
|
||||
这里咱们开门见山，我先把样本量的计算公式贴出来，然后再来详细讲解：
|
||||
\[-
|
||||
\\mathrm{n}=\\frac{\\left(Z\_{1-\\frac{\\alpha}{2}}+Z\_{1-\\beta}\\right)^{2}}{\\left(\\frac{\\delta}{\\sigma\_{\\text {pooled}}}\\right)^{2}}=\\frac{\\left(Z\_{1-\\frac{\\alpha}{2}}+Z\_{\\text {power}}\\right)^{2}}{\\left(\\frac{\\delta}{\\sigma\_{\\text {pooled}}}\\right)^{2}}-
|
||||
\]其中：
|
||||
|
||||
\(Z\_{1-\\frac{\\alpha}{2}}\) 为 \(\\left(1-\\frac{\\alpha}{2}\\right)\) 对应的 \(Z\) Score。 \(Z\_{\\text {Power}}\) 为 Power 对应的 Z Score。-
|
||||
\(\\delta\) 为实验组和对照组评价指标的差值。-
|
||||
\(\\sigma\_{\\text {pooled}}^{2}\) 为实验组和对照组的综合方差（Pooled Variance）。
|
||||
|
||||
从公式中，我们可以看出来，样本量主要由α、Power、δ和\(\\sigma\_{\\text {pooled}}^{2}\)决定。我们要调整样本量的大小就靠这4个因素了，下面我们就来具体聊聊每个因素怎样影响样本量n的。
|
||||
|
||||
这四个因素里，α、δ和 \(\\sigma\_{\\text {pooled}}^{2}\)我在前几节课已经讲过了，所以在聊每个因素是如何影响样本量n这个问题之前，我先来给你介绍下Power到底是什么。
|
||||
|
||||
如何理解Power?
|
||||
|
||||
Power，又被称作Statistical Power。在第二节讲统计基础时，我讲解过第二类错误率β（Type II Error）。在统计理论中，Power = 1–β。
|
||||
|
||||
Power的本质是概率，在A/B测试中，如果实验组和对照组的指标事实上是不同的，Power指的就是通过A/B测试探测到两者不同的概率。
|
||||
|
||||
可能这么说还是有些抽象，不过没关系，Power确实是比较难理解的统计概念，我刚开始接触时也是一头雾水。所以，我再举个例子来帮助你理解Power。
|
||||
|
||||
某社交App的用户注册率偏低，产品经理想要通过优化用户注册流程来提高用户注册率。用户注册率在这里的定义是：完成注册的用户的总数 / 开始注册的用户的总数 * 100%
|
||||
|
||||
那么，现在我们就可以用A/B测试来验证这种优化是否真的能提高用户注册率。
|
||||
|
||||
我们先把用户分为对照组和实验组，其中：
|
||||
|
||||
|
||||
对照组是正常的用户注册流程，输入个人基本信息——短信/邮箱验证——注册成功。
|
||||
实验组是，在正常的用户注册流程中，还加入了微信、微博等第三方账号登录的功能，用户可以通过第三方账号一键注册登录。
|
||||
|
||||
|
||||
相信不用我说，你也能猜到，实验组用户的注册率肯定比对照组的要高，因为实验组帮用户省去了繁琐的注册操作。这就说明，在事实上这两组用户的注册率是不同的。
|
||||
|
||||
那么，现在如果A/B测试有80%的Power，就意味着这个A/B测试有80%的概率可以准确地检测到这两组用户注册率的不同，得出统计显著的结果。换句话说，这个A/B测试有20%的概率会错误地认为这两组用户的注册率是相同的。
|
||||
|
||||
可见，Power越大，说明A/B测试越能够准确地检测出实验组与对照组的不同（如果两组事实上是不同的）。
|
||||
|
||||
我再给你打个比方。你可以把A/B测试看作是探测空中飞行物的雷达。那么专门探测小型无人机的雷达的灵敏度，就要比专门探测大型客机的雷达的灵敏度高。因为探测物越小，就越需要灵敏度更高的雷达。在这里，雷达的灵敏度就相当于A/B测试的Power，Power越大，就越能探测到两组的不同。
|
||||
|
||||
所以啊，你把Power看成A/B测试的灵敏度就可以了。
|
||||
|
||||
四个因素和样本量n的关系
|
||||
|
||||
认识完Power，那现在就让我们来看下α、Power、δ和\(\\sigma\_{\\text {pooled}}^{2}\)这四个因素和样本量n的关系。
|
||||
|
||||
1.显著水平（Significance Level）α
|
||||
|
||||
显著水平和样本量成反比：显著水平越小，样本量就越大。这个也不难理解。因为显著水平又被称为第一类错误率（Type I Error）α，想要第一类错误率越小，结果越精确，就需要更大的样本量。
|
||||
|
||||
2.Power （1 – β）
|
||||
|
||||
Power和样本量成正比：Power越大，样本量就越大。Power越大，就说明第二类错误率（Type II Error）β越小。和第一类错误类似，想要第二类错误率越小，结果越精确，就需要更大的样本量。
|
||||
|
||||
3.实验组和对照组的综合方差\(\\sigma\_{\\text {pooled}}^{2}\)
|
||||
|
||||
方差和样本量成正比：方差越大，样本量就越大。
|
||||
|
||||
前面讲过，方差是用来表征评价指标的波动性的，方差越大，说明评价指标的波动范围越大，也越不稳定，那就更需要更多的样本来进行实验，从而得到准确的结果。
|
||||
|
||||
4.实验组和对照组评价指标的差值δ
|
||||
|
||||
差值和样本量成反比：差值越小，样本量就越大。因为实验组和对照组评价指标的差值越小，越不容易被A/B测试检测到，所以我们需要提高Power，也就是说需要更多的样本量来保证准确度。
|
||||
|
||||
实践中该怎么计算样本量？
|
||||
|
||||
在实践中，绝大部分的A/B测试都会遵循统计中的惯例：把显著水平设置为默认的5%，把Power设置为默认的80%。这样的话我们就确定了公式中的Z分数，而且四个因素也确定了两个（α、Power）。那么，样本量大小就主要取决于剩下的两个因素：实验组和对照组的综合方差\(\\sigma\_{\\text {pooled}}^{2}\)，以及两组评价指标的差值δ。因此样本量计算的公式可以简化为：-
|
||||
$\(-
|
||||
\\mathrm{n} \\approx \\frac{8 \\sigma\_{p o o l e d}^{2}}{\\delta^{2}}-
|
||||
\)$
|
||||
|
||||
现在，我们就可以用这个简化版的公式来估算样本量大小了。
|
||||
|
||||
其中，方差是数据本身的属性（代表了数据的波动性），而两组间评价指标的差值则和A/B测试中的变量，以及变量对评价指标的影响有关。
|
||||
|
||||
以上公式其实是在两组评价指标的综合方差为 \(\\sigma\_{\\text {pooled}}^{2}\)，两组评价指标的差值为δ的情况下，要使A/B测试结果达到统计显著性的最小样本量。
|
||||
|
||||
注意，这里重点强调“最小”二字。理论上样本量越大越好，上不封顶，但实践中样本量越小越好，那我们就需要在这两者间找一个平衡。所以由公式计算得到的样本量，其实是平衡二者后的最优样本量。
|
||||
|
||||
样本量计算出来了，接下来就要分对照组和实验组了，那这里就涉及到一个问题，实验组和对照组的样本量应该如何分配？在这个问题中，其实存在一个很常见的误解。那么接下来，我就带你来好好分析一下样本量分配这个问题。
|
||||
|
||||
实验组和对照组的样本量应保持相等
|
||||
|
||||
如果A/B测试的实验组和对照组样本量相等，即为50%/50%均分，那么我们的总样本量（实验组样本量和对照组样本量之和）为：-
|
||||
|
||||
|
||||
你可能会问，实验组和对照组的样本量必须要相等吗？
|
||||
|
||||
虽然两组的样本量不相等在理论上是可行的，实践中也可以如此操作，但是我强烈不建议你这样做。下面听我来仔细分析。
|
||||
|
||||
一个常见的误解是，如果实验组的样本量大一些，对照组的样本量小一些（比如按照80%/20%分配），就能更快地获得统计上显著的结果。其实现实正好相反：两组不均分的话反而会延长测试的时间。
|
||||
|
||||
为什么会这样呢？因为我们计算的达到统计显著性的最小样本量，是以每组为单位的，并不是以总体为单位。也就是说，在非均分的情况下，只有相对较小组的样本量达到最小样本量，实验结果才有可能显著，并不是说实验组越大越好，因为瓶颈是在样本量较小的对照组上。
|
||||
|
||||
相对于50%/50%的均分，非均分会出现两种结果，这两种结果均对业务不利。
|
||||
|
||||
|
||||
准确度降低。如果保持相同的测试时间不变，那么对照组样本量就会变小，测试的Power也会变小，测试结果的准确度就会降低；
|
||||
延长测试时间。如果保持对照组的样本量不变，那么就需要通过延长测试时间来收集更多的样本。
|
||||
|
||||
|
||||
所以只有两组均分，才能使两组的样本量均达到最大，并且使总样本量发挥最大使用效率，从而保证A/B测试更快更准确地进行。
|
||||
|
||||
你可能会问，这个样本量的估算是在A/B测试前进行的，但我还没有做这个实验，怎么知道两组间评价指标的差值δ呢？
|
||||
|
||||
估算实验组和对照组评价指标的差值δ
|
||||
|
||||
这里呢，我们当然不会事先知道实验结束后的结果，不过可以通过下面的两种方法估算出两组评价指标的差值δ。
|
||||
|
||||
第一种方法是从收益和成本的角度进行估算。
|
||||
|
||||
业务/产品上的任何变化都会产生相应的成本，包括但不限于人力成本、时间成本、维护成本、机会成本，那么变化带来的总收益能否抵消掉成本，达到净收益为正呢？
|
||||
|
||||
举个例子，我们现在想要通过优化注册流程来增加某App的用户注册率。假设优化流程的成本大约是3万元（主要是人力和时间成本），优化前的注册率为60%，每天开始注册的人数为100人，每个新用户平均花费10元。如果优化后的注册率提升为70%，这样一年下来就多了3.65万元（（70%-60%）*100*10*365）的收入，这样的话一年之内的净收益就为正的，这就说明此次优化流程不仅回本，而且还带来了利润，也就证明10%的差值是一个理想的提升。
|
||||
|
||||
当然，我们进行相应的改变肯定是希望获得净收益，所以一般我们会算出当收支平衡时差值为 \(\\delta\_{\\text {收支平衡}}\)，我们希望差值\(\\delta \\geq \\delta\_{\\text {收支平衡 }}\)。在这个例子中， \(\\delta\_{\\text {收支平衡}}\)= 8.2% (30000/10/100/365)，所以我们希望的差值δ至少为8.2%。
|
||||
|
||||
第二种方法是，如果收益和成本不好估算的话，我们可以从历史数据中寻找蛛丝马迹，根据我在第4节课介绍的计算指标波动性的方法，算出这些评价指标的平均值和波动范围，从而估算一个大概的差值。
|
||||
|
||||
比如说我们的评价指标是点击率，通过历史数据算出点击率的平均值为5%，波动范围是[3.5%, 6.5%]，那么我们对实验组评价指标的期望值就是至少要大于这个波动范围，比如7%，那么这时δ就等于2%（7%–5%）。
|
||||
|
||||
计算实验组和对照组的综合方差\(\\sigma\_{\\text {pooled}}^{2}\)
|
||||
|
||||
至于两组综合方差\(\\sigma\_{\\text {pooled}}^{2}\)的计算，主要是选取历史数据，根据不同的评价指标的类型，来选择相应的统计方法进行计算。评价指标的类型主要分为概率类和均值类这两种。
|
||||
|
||||
概率类指标在统计上通常是二项分布，综合方差为：-
|
||||
$\(-
|
||||
\\sigma\_{\\text {pooled}}^{2}=p\_{\\text {test}}\\left(1-p\_{\\text {test}}\\right)+p\_{\\text {control}}\\left(1-p\_{\\text {control}}\\right)-
|
||||
\)$
|
||||
|
||||
其中，\(p\_{\\text {control}}\)为对照组中事件发生的概率，也就是没有A/B测试变化的情况，一般可以通过历史数据计算得出；\(p\_{\\text {test}}=p\_{\\text {control}}+\\delta\)，得出的是期望的实验组中事件发生的概率。
|
||||
|
||||
均值类指标通常是正态分布，在样本量大的情况下，根据中心极限定理，综合方差为：-
|
||||
$\(-
|
||||
\\sigma\_{p o o l e d}^{2}=\\frac{2 \* \\sum\_{i}^{n}\\left(x\_{i}-\\bar{x}\\right)^{2}}{n-1}-
|
||||
\)$-
|
||||
其中：
|
||||
|
||||
|
||||
n为所取历史数据样本的大小。
|
||||
\(x\_{i}\)为所取历史数据样本中第i个用户的使用时长/购买金额等。
|
||||
\(\\bar{x}\)为所取历史数据样本中用户的平均使用时长/购买金额等。
|
||||
|
||||
|
||||
好了，到这里，这节课的核心内容就全部讲完了。不过为了帮助你更好地掌握这些公式原理和计算方式，现在我就用优化注册流程来增加用户注册率的这个例子，来给你串一下该怎么计算样本大小。
|
||||
|
||||
案例串讲
|
||||
|
||||
我们可以根据前面介绍总样本量的公式来计算样本量：
|
||||
|
||||
|
||||
|
||||
首先，我们来计算实验组和对照组之间评价指标的差值δ。在前面某App优化用户注册率的案例中，可以看到，我们从成本和收益的角度估算出\(\\delta\_{\\text {收支平衡}}\)=8.2%。
|
||||
|
||||
其次，我们来计算\(\\sigma\_{\\text {pooled}}^{2}\)。根据历史数据我们算出注册率大约为60%（\(p\_{\\text {control}}\)），结合前面算出的\(\\delta\_{\\text {收支平衡}}\)=8.2%，这时就可以把流程改变后的注册率定为68.2%， 然后再根据概率类指标的计算公式求出\(\\sigma\_{\\text {pooled}}^{2}\) = 60%*(1-60%) + 68.2%*(1-68.2%)=0.46。
|
||||
|
||||
最后，我们在A/B测试中把实验组和对照组进行50%/50%均分，利用公式最终求得样本总量为：
|
||||
|
||||
|
||||
|
||||
这样我们就求得每组样本量至少要有548，完成了样本量的计算。
|
||||
|
||||
还记得开头我提到的网上各种各样的A/B测试的样本量计算器吗？比如这款。如果你仔细研究这些计算器，就会发现这些计算器几乎全部是让你输入以下4个参数：
|
||||
|
||||
|
||||
原始转化率 \(p\_{\\text {control}}\)（Baseline Conversion Rate）。
|
||||
最小可检测提升δ（Minimum Detectable Lift）或者优化版本转化率\(p\_{\\text {test}}\) 。
|
||||
置信水平 (1-α）（Confident Level）或者显著水平α（Significance Level）。
|
||||
Statistical Power（1-β）。
|
||||
|
||||
|
||||
细心的你可能已经发现：上面这些参数都是计算概率类指标要用的参数，所以现在网上的这些样本量计算器只能计算概率类的指标，并不能计算均值类的指标，所以我们在使用时一定要注意要求输入的参数是什么，才能根据不同类型的指标选择正确的计算方法。对于均值类指标，现在网上还没有比较好的样本量计算器，在这种情况下我建议你通过公式来计算。
|
||||
|
||||
为了方便大家日后计算A/B测试中各类指标的样本量，我会在专栏的最后一节课，教大家用R做一个既可以计算概率类指标，还可以计算均值类指标的线上样本量计算器，敬请期待！
|
||||
|
||||
小结
|
||||
|
||||
这节课我们主要学习了怎么确定A/B测试所需的样本量大小，了解了背后的理论基础，我给你总结了影响样本量的四个因素，其中，向上箭头表示增大，向下箭头表示减小。
|
||||
|
||||
|
||||
|
||||
这里我想要再强调一下，这节课介绍的计算A/B测试样本量的方法，是测试前对样本量的估计值，是为了让A/B测试结果达到统计显著性的最小样本量，所以，只要最终的实际样本量大于最小样本量就行。当然如果业务条件允许的话，样本量自然是越多越好。
|
||||
|
||||
最后我想说的是，当我们用网上的A/B测试样本量计算器时，要注意输入的参数是什么，因为绝大部分的计算器都是让用户输入转化率，只能计算概率类的指标，所以当计算概率类指标时我们可以用网上的计算器，但如果是其他类的指标（如均值类）的话不能用网上的计算器，还是得靠你自己利用公式计算测试所需的最小样本量，或者跟着我在专栏的最后，一起做一个既包含概率类指标，又包含均值类指标的线上样本量计算器。
|
||||
|
||||
思考题
|
||||
|
||||
你有用过网上的A/B测试样本量计算器吗？有没有想过为什么网上大部分的样本量计算器只能算概率类的指标而不能计算均值类指标呢？
|
||||
|
||||
欢迎在评论区留言、讨论，也欢迎点击“请朋友读”，把今天的内容分享给你的同事、好友，和他一起学习、成长。好，感谢你的收听，我们下节课再见。
|
||||
|
||||
|
||||
|
||||
|
||||
224
专栏/AB测试从0到1/07分析测试结果：你得到的测试结果真的靠谱吗？.md
Normal file
224
专栏/AB测试从0到1/07分析测试结果：你得到的测试结果真的靠谱吗？.md
Normal file
@@ -0,0 +1,224 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
07 分析测试结果：你得到的测试结果真的靠谱吗？
|
||||
你好，我是博伟。
|
||||
|
||||
经过前面的确定目标和假设、确定指标、选取实验单位、计算所需样本大小后，我们终于来到了A/B测试的最后一站：分析测试结果。
|
||||
|
||||
在正式开始之前，我想先问你一个问题：拿到测试结果之后，就可以马上进行分析了吗？肯定不行。因为只有确定测试结果值得信赖之后，才可以进行分析。其实，分析A/B测试结果并不难，难的是如何得出值得信赖的结果，从而给业务以正确的指导。
|
||||
|
||||
为什么这么说呢？接下来，我就通过一个音乐App要提高用户升级率的例子，和你先拆解下导致测试结果不可靠的因素有哪些，然后再看看具体该怎么分析。
|
||||
|
||||
案例导入
|
||||
|
||||
通常情况下，音乐App有两种盈利模式，一种是提供免费音乐，但是会在App中加广告，通过广告赚钱；一种是让用户付费订阅App，享受高品质的免广告音乐。
|
||||
|
||||
我们的这款音乐App是两种盈利模式都有，但是从长期盈利效果和用户体验来看，采用用户付费订阅的模式会更胜一筹。因此，我们计划在双十一前后，针对App里的免费用户做一次促销，吸引他们付费。
|
||||
|
||||
现在有这么两条广告语，为了通过A/B测试验证哪条更有效，将其分别放到实验组和对照组：
|
||||
|
||||
|
||||
对照组广告语：千万曲库免广告无限畅听，用户升级，免费试用半年！
|
||||
实验组广告语：即日起到11月15日，用户升级，免费试用半年！
|
||||
|
||||
|
||||
现在，我们来完成A/B测试的整体设计方案。
|
||||
|
||||
|
||||
确定目标：使更多的免费用户升级成为付费用户。
|
||||
提出假设：通过在广告语中加入倒计时这种增加紧迫感的信息，能够提升免费用户的升级率。
|
||||
确定实验单位：免费用户的用户ID。
|
||||
实验组/对照组：随机分配，50%/50%。
|
||||
评价指标：用户升级率 = 点击广告升级的用户数 / 看到广告的用户数。
|
||||
评价指标的波动范围：[1.86%，2.14%]。
|
||||
|
||||
|
||||
设计好了A/B测试的框架，实施了A/B测试后，我们就可以等待分析测试结果了。那什么时候可以查看测试结果，停止A/B测试呢？这是保证测试结果可信赖要解决的第一个问题。
|
||||
|
||||
什么时候可以查看测试结果？
|
||||
|
||||
还记得我们上节课，在计算测试要达到显著性结果所需的最小样本量时，用到的一个公式吗？
|
||||
|
||||
A/B测试所需的时间 = 总样本量 / 每天可以得到的样本量。
|
||||
|
||||
结合这个公式，再根据App中每天免费用户的流量，我们可以计算出这个测试在理论上需要跑10天。
|
||||
|
||||
其实，这个公式只是理论上推导，具体到A/B测试的实践中，我们要确定测试时间，除了考虑样本量的大小外，还要考虑指标周期性变化的因素。
|
||||
|
||||
如果指标具有强烈的周期性变化，比如周中和周末的变化很大，那么这时候的测试时间要包含至少一个周期的时间，以排除指标周期性变化的影响。
|
||||
|
||||
在音乐App这个案例中，我们通过历史数据发现，在周末升级的用户要比周中多。这就说明用户升级率这个评价指标，会以每周为单位形成周期性的变化，所以我们的测试至少要跑7天。而我们通过最小样本量已经算出了本次测试需要跑10天，包含了一个周期，所以我们可以放心地把测试时间定为10天。
|
||||
|
||||
我再多补充一句，如果计算出的测试时间小于一个周期的时间，那么最好也按照一个周期来算，这样做更为保险。
|
||||
|
||||
不过啊，在测试实际进行的过程中，有可能出现这样一种情况：在预计时间之前，评价指标出现了显著不同。这时候你就要小心了，如果提前结束测试，就会前功尽弃。我来给你具体解释下。
|
||||
|
||||
假设负责这个测试的数据分析师是第一次做A/B测试，所以特别激动兴奋，每天都在观测实验，计算测试结果。在实验进行到第6天的时候（样本量还没有达到预期），他发现实验组和对照组的评价指标出现了显著的不同。这位数据分析师就在想，测试结果在预计时间之前达到了统计显著，这个实验是不是提前成功了呢？
|
||||
|
||||
答案当然是否定的。
|
||||
|
||||
一方面，因为样本量是不断变化的，所以每次观测到的测试其实都可以算作新的实验。根据统计上的惯例，A/B测试一般有5%的第一类错误率α，也就是说每重复测试100次，平均就会得到5次错误的统计显著性的结果。
|
||||
|
||||
这就意味着如果我们观测的次数变多的话，那么观测到错误的统计显著结果的概率就会大大提升，这是多重检验问题（Multiple Testing Issue）的一种体现。关于多重检验问题，我会在第9节课中详细讲解。
|
||||
|
||||
另一方面，提前观测到统计显著的结果，这就意味着样本量并没有达到事先估算的最小样本量，那么这个所谓的“统计显著的结果”就极有可能是错误的假阳性（False Positive）。“假阳性”是指，两组事实上是相同的，而测试结果错误地认为两组显著不同。
|
||||
|
||||
因此这位数据分析师还不能提前结束这次测试，仍然需要继续观测实验。
|
||||
|
||||
但如果测试已经跑到了第10天，样本量也达到了之前计算的量，那是不是就可以开始分析A/B测试的结果了呢？
|
||||
|
||||
答案依旧是不行。
|
||||
|
||||
俗话说心急吃不了热豆腐，为了确保实验在具体实施过程中按照我们预先设计的进行，保证中途不出现Bug，那么在正式分析实验结果前，我们还要进行测试的合理性检验（Sanity Check），从而保证实验结果的准确性。
|
||||
|
||||
在第3和第4节课我们学过，为了确保在具体实施过程中不会出现破坏统计合理性的Bug，我们可以用护栏指标来保证统计品质。这时，我们可以使用实验/对照组样本大小的比例和实验/对照组中特征的分布这两个护栏指标。这是保证测试结果可信赖，我们要关注的第二个问题。
|
||||
|
||||
保障统计品质的合理性检验
|
||||
|
||||
检验实验/对照组样本量的比例
|
||||
|
||||
我们预设的是，实验组和对照组的样本量各占总样本量的50%，现在我们来看看实验过程中有没有发生什么变化。
|
||||
|
||||
各组样本量占总样本量的比例也是概率，也是符合二项分布的，所以具体的操作方法（参见第4节课指标波动性的相关内容）是：
|
||||
|
||||
|
||||
首先根据二项分布的公式\(\\sqrt{\\frac{p(1-p)}{n}}\)算出标准误差。
|
||||
然后，以0.5（50%）为中心构建95%的置信区间。
|
||||
最后，确认实际的两组样本量的比例是否在置信区间内。
|
||||
|
||||
|
||||
如果总的比例在置信区间内的话，就说明即使总的比例不完全等于50%/50%，也是非常接近，属于正常波动，两组样本量大小就符合预期。否则，就说明实验有问题。那该如何确认和解决潜在问题呢？
|
||||
|
||||
回到我们的A/B测试上来，我们实验组的样本量315256，对照组的样本量为315174。通过公式我们求得标准误差为：-
|
||||
计算出来的结果是0.06%，我们构建了95%的置信区间[50%-1.96*0.06%, 50%+1.96*0.06%] = [49.88%,50.12%]，也就是两组占比的波动范围，然后算出总体的实验组/对照组的样本量比例=50.01%/49.99%。
|
||||
|
||||
可以看到，两组占比均在置信区间内，属于正常波动。也就是说，两组样本量符合均分的预期，成功通过了实验/对照组样本量的比例这个合理性检验。那我们接下来就可以进行实验/对照组中特征的分布这个合理性检验了。
|
||||
|
||||
检验实验/对照组中特征的分布
|
||||
|
||||
A/B测试中实验组和对照组的数据要相似才具有可比性。这里的相似，我们可以通过比较两组的特征分布来判断。
|
||||
|
||||
常用的特征包括用户的年龄、性别、地点等基本信息，或者可能影响评价指标的特征。比如在音乐App这个案例中，我们还可以查看用户平时的活跃程度。如果这些特征在两组中分布比例相差较大，则说明实验有问题。
|
||||
|
||||
一旦从合理性检验中发现了问题，就不要急着分析实验结果了，实验结果大概率是不准确的。我们要做的就是找到出现问题的原因，解决问题，并重新实施改进后的A/B测试。
|
||||
|
||||
找原因的方法主要有以下两种：
|
||||
|
||||
|
||||
和工程师一起从实施的流程方面进行检查，看看是不是具体实施层面上两组有偏差或者bug。
|
||||
从不同的维度来分析现有的数据，看看是不是某一个特定维度存在偏差。常用的维度有时间（天）、操作系统、设备类型等。比如从操作系统维度，去看两组中iOS和Android的用户的比例是否存在偏差，如果是的话那说明原因和操作系统有关。
|
||||
|
||||
|
||||
通过数据分析发现这两组数据中重要特征的分布基本一致，说明两组数据是相似的。这就意味着我们已经通过了合理性检验，接下来我们就可以分析A/B测试的结果了。
|
||||
|
||||
最后，我还想跟你强调一下，这两个合理性检验是都要进行的，这是保障实验质量的关键。这两种检验如果没有通过的话都会使实验结果不准确，具体来说，实验/对照组样本量的比例和实验设计不相同时会出现样本比例不匹配问题（Sample Ratio Mismatch），实验/对照组的特征分布不相似则会导致辛普森悖论问题（Simpson Paradox），这两类问题我们会在第11节课中重点讲解。
|
||||
|
||||
如何分析A/B测试的结果？
|
||||
|
||||
其实，分析A/B测试的结果，主要就是对比实验组和对照的评价指标是否有显著不同。那怎么理解“显著”呢？其实，“显著”就是要排除偶然随机性的因素，通过统计的方法来证明两者的不同是事实存在的，而不是由于波动性造成的巧合。
|
||||
|
||||
那具体怎么做呢？
|
||||
|
||||
首先我们可以用统计中的假设检验（Hypothesis Testing）计算出相关的统计量，然后再来分析测试的结果。最常用的统计量是用P值（P value）和置信区间(Confidence Interval)这两种统计量。
|
||||
|
||||
你可能会说，假设检验中有各种各样的检验（Test），我应该选取什么检验来计算P值和置信区间呢？这里我们不需要理解这些检验的复杂理论解释，只要熟悉实践中常用的3种检验方法的使用场景就可以了：
|
||||
|
||||
|
||||
Z检验（Z Test）
|
||||
|
||||
|
||||
当评价指标为概率类指标时（比如转化率，注册率等等），一般选用Z检验（在A/B测试中有时又被称为比例检验（Proportion Test））来计算出相应的P值和置信区间。
|
||||
|
||||
|
||||
T检验（T Test）
|
||||
|
||||
|
||||
当评价指标为均值类指标时（比如人均使用时间，人均使用频率等等），且在大样本量下可以近似成正态分布时，一般选用T 检验来计算相应的P值和置信区间。
|
||||
|
||||
|
||||
Bootstrapping
|
||||
|
||||
|
||||
当评价指标的分布比较复杂，在大样本量下也不能近似成正态分布时（比如70%用户的使用时间，OEC等），一般采用Bootstrapping的方法，从P值或者置信区间的定义来计算P值和置信区间（具体方法请参见第三节课指标波动性的相关内容）。
|
||||
|
||||
现在我们已经拿到了如下的测试结果：
|
||||
|
||||
|
||||
实验组：样本量为315256，升级的用户为7566，升级率为2.4%。
|
||||
对照组：样本量为315174，升级的用户为6303，升级率为2.0%。
|
||||
|
||||
|
||||
因为评价指标的波动范围是[1.86%,2.14%]，所以我们可以得出实验组的升级率2.4%并不属于正常范围，很有可能显著不同于对照组。
|
||||
|
||||
接下来，我们就可以通过P值法和置信区间法来分析这个测试结果，验证我们的假设是否正确。
|
||||
|
||||
P值法
|
||||
|
||||
首先我们可以采取P值法，借助一些计算工具，常见有Python、R，还有网上的一些在线工具（比如这个网站），都可以计算P值。具体选择哪个工具，根据自己的喜好来就可以。我个人比较喜欢选用R来计算：
|
||||
|
||||
results <- prop.test(x = c(7566, 6303), n = c(315256, 315174))
|
||||
|
||||
|
||||
因为用户升级率这个评价指标属于概率类指标，所以我们选择了专门针对概率类指标的函数prop.test。
|
||||
|
||||
通过计算，我们可以得到P值 < \(2.2 e^{-16}\)：
|
||||
|
||||
|
||||
|
||||
根据统计惯例，一般我们会把测试的显著水平（Significance Level）α定为5%（统计上的约定俗成），再把计算出来的P值和5%相比。当P值小于5%时，说明两组指标具有显著的不同。当P值大于5%时，说明两组指标没有显著的不同。如果你对这块概念还不是很清楚，可以回顾下第二节课中假设检验的内容。
|
||||
|
||||
从上面的结果可以看出，P值远远小于5%且接近于0，说明两组指标具有显著的不同，这就意味着实验组的广告语确实能提升免费用户的升级率。
|
||||
|
||||
置信区间法
|
||||
|
||||
在第三节课介绍指标时，我们学习了该怎样构建置信区间。现在我们要比较实验组和对照组的评价指标是否显著不同，也就是看两者的差值是不是为0。这时候，我们就要构建两组指标差值\(\\left(p\_{\\text {test}}-p\_{\\text {control}}\\right)\)的置信区间了。
|
||||
|
||||
置信区间的具体计算我们也可以借助Python和R等软件，当然你也可以使用我在第二讲时介绍过的具体函数，这里我们还是用R的prop.test这个函数。
|
||||
|
||||
其实当我们在上面用这个函数计算P值时，R也顺便把95%的置信区间算出来了：-
|
||||
|
||||
|
||||
由图可见，95%的置信区间为[0.0033, 0.0047]。
|
||||
|
||||
接下来，我们需要比较一下两组指标是否有统计显著的不同，也就是要看看这个置信区间是否包括0。
|
||||
|
||||
我们知道数值在置信区间内均为正常波动，如果置信区间包括0的话，就说明两组指标的差值也有可能为0，两组指标是相等的。而如果置信区间不包括0的话，就说明两组指标的差值不为0，两组指标是显著不同的。
|
||||
|
||||
显然，[0.0033, 0.0047]这个置信区间是不包括0的，也就是说我们的测试结果是统计显著的。那对应到业务上，与对照组的广告语（千万曲库免广告无限畅听，用户升级，免费试用半年！）相比，带有紧迫感的实验组广告语（实验组广告语即日起到11月15日，用户升级，免费试用半年！）能吸引更多用户升级，也就验证了我们最开始的假设是成立的。
|
||||
|
||||
学到这里，我们发现无论是P值法还是置信区间法，都可以用来分析A/B测试结果是否具有统计显著性。那么，在实际应用中该如何选择呢？两者有什么差别吗？
|
||||
|
||||
其实，在大部分情况下这两种方法是通用的，只要选择一种就可以。但如果需要考虑实施变化后的收益和成本的关系时，我们就要选择置信区间法了。
|
||||
|
||||
因为要考虑收益和成本的关系时，除了满足结果在统计上是显著的（两组指标不相同，差值的置信区间不包括0）还不够，更要让结果在业务上也是显著的（两组指标不仅要不相等，而且其差值δ >= \(\\delta\_{\\text {收支平衡}}\)，并且差值的置信区间的范围都要比\(\\delta\_{\\text {收支平衡}}\)大）。
|
||||
|
||||
小结
|
||||
|
||||
这节课我们主要讲解了A/B测试中如何分析结果，根据实践经验我给你总结了3个要点：
|
||||
|
||||
|
||||
切莫心急，一定要等到达到足够样本量时再分析测试结果。
|
||||
分析结果前一定要做合理性检验来确保测试的质量，否则一旦实施过程中出现Bug，就会功亏一篑。
|
||||
一定要根据指标和数据的特点，选择正确的分析方法来得出可以驱动业务的结论。
|
||||
|
||||
|
||||
数据领域有一句名言：“Garbage in, garbage out”，意思就是“放进去的是垃圾，产出的还是垃圾”。这句话放在A/B测试中同样适用：如果A/B测试没有设置好，或者虽然计划得很好，但要是在实施过程中出现了问题，也会得到错误的结果和结论，从而给业务带来难以估量的损失。
|
||||
|
||||
所以，前面我们用4节课来讲怎么设置实验，今天又花了很多篇幅来介绍确保结果是可信赖的，都是在给“分析测试结果”做铺垫。
|
||||
|
||||
好了，今天这个音乐App的测试得到了显著的结果，皆大欢喜。但是如果结果不显著，又该怎么办呢？
|
||||
|
||||
关于这个问题，我们在第9节课再来好好讨论！
|
||||
|
||||
思考题
|
||||
|
||||
你觉得分析结果前的合理性检验还可以参考哪些护栏指标呢？为什么？
|
||||
|
||||
欢迎在留言区写下你的思考和答案，我们一起交流讨论。如果你觉得有所收获，欢迎你把这一讲分享给你的朋友，邀请他一起学习。
|
||||
|
||||
|
||||
|
||||
|
||||
158
专栏/AB测试从0到1/08案例串讲：从0开始，搭建一个规范的A_B测试框架.md
Normal file
158
专栏/AB测试从0到1/08案例串讲：从0开始，搭建一个规范的A_B测试框架.md
Normal file
@@ -0,0 +1,158 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
08 案例串讲：从0开始，搭建一个规范的A_B测试框架
|
||||
你好，我是博伟。
|
||||
|
||||
经过前面几节课的学习，相信你不仅掌握了做A/B测试的统计原理，还知道了一个规范的A/B测试的流程是什么样的，以及关键步骤中有哪些需要注意的地方。
|
||||
|
||||
今天这节课的内容，整体来说不会太难，主要是用一个音乐App提升留存率的案例，来串讲一下我们学过的统计知识，以及做A/B测试的几个核心步骤。
|
||||
|
||||
在学习这节课的过程中，一方面，如果你还有一些没有完全搞懂的内容，可以再针对性地复习下，查漏补缺；另一方面，之前几节课的内容容量都比较大，今天的案例串讲相当于帮助你理清思路，清空大脑，然后再有效地去吸收进阶篇的知识。
|
||||
|
||||
好了，那我就通过下面音乐App这个案例，来带你走一遍流程。
|
||||
|
||||
从业务问题出发，确定A/B测试的目标和假设
|
||||
|
||||
咱们今天案例里的产品是一款音乐App，用户只要每月付费就可以免广告畅听千万首音乐。当然，除了最基本的播放音乐功能，产品经理还给这款App设计了很多便利的功能，比如用户可以把喜欢的音乐加入收藏夹，可以创建不同的歌单，还可以离线下载以便随时随地畅听自己喜欢的音乐，等等。
|
||||
|
||||
数据科学家通过数据分析也发现，使用这些便利功能的用户往往有着高于平均水平的续订率，说明这些便利功能确实有助于提升用户留存。但是也有一个问题一直困扰着团队：这些功能虽然方便实用，有助于优化用户的听歌体验，但是使用率却一直不高。使用率不高，从长期来看，势必会影响用户留存。
|
||||
|
||||
团队通过用户调研才发现其中的原因。
|
||||
|
||||
由于App的页面设计崇尚简洁，这些功能一般就存放在每首歌曲的功能列表中，而用户往往需要点击两次才能使用：第一次先点击功能列表，第二次再点击具体的产品功能。一方面，很多用户，尤其是新用户，并没有发现这些功能。另一方面，点击两次才能使用，用户体验并不好，慢慢地也就退订了。
|
||||
|
||||
那么，我们现在的目标就非常明确了：增加用户对产品功能的使用率。
|
||||
|
||||
如何增加这个使用率呢？你可能会说，把每个功能都直接显示出来，让用户一目了然，不就可以提高它们的使用率了嘛！产品经理刚开始就想到了这一点，但是后来发现功能太多，全部直接显示出来，会让歌曲界面看起来非常杂乱，会让用户体验更糟糕。
|
||||
|
||||
既然产品交互界面的改动被否定了，那么我们可不可以主动告知用户这些功能怎么使用呢？
|
||||
|
||||
比如说，在新用户刚注册登录后就告知他们每个功能的用法。不过这个想法很快也被产品经理否定了，毕竟新用户刚登录时并不会用到所有功能。这很好理解，因为没有需求嘛，新用户在看到这些功能时肯定也没有什么反应，所以新用户在第一次登录时一般都会跳过产品功能介绍。
|
||||
|
||||
之前的A/B测试也验证了这一点。只有在用户有使用这个功能的需求时，再告知他们，才最有效果。
|
||||
|
||||
于是团队的假设就是：在用户有需求时，通过弹窗的形式告知用户相关使用功能，以此提升相关功能的使用率。这样的话，既能避免对每一个新用户的打扰，又能满足有需求的用户，两全其美。
|
||||
|
||||
确定A/B测试的评价指标
|
||||
|
||||
确定了目标和假设之后，就可以开始定义评价指标了。
|
||||
|
||||
团队准备先拿“把喜欢的音乐加入收藏夹”这个功能来做一个A/B测试，验证以上的假设是否成立。
|
||||
|
||||
因为要在用户有需求的时候再告知用户，所以我们就需要一个条件来触发这个告知。那么，我们的首要任务就是确定触发条件：只有当用户从来没有用过这个功能（如果用户知道这个功能的话我们就没有必要告知了），并且播放同一首歌曲达到x次时（以此来判断用户对某首歌曲的喜爱程度），我们才会给用户发送弹窗通知。
|
||||
|
||||
经过数据科学家的数据分析，最终确定了x的最优值为4，所以该功能的弹窗的最终触发条件为：
|
||||
|
||||
|
||||
该用户从来没用过“把喜欢的音乐加入收藏夹”这个功能。
|
||||
该用户已经对某首歌听了4次，当播放第5次时触发弹窗。
|
||||
|
||||
|
||||
需要说明的是，因为弹窗是为了要告知用户，不需要重复提醒，所以每个符合触发条件的用户也只能收到一次，不能多次触发。
|
||||
|
||||
|
||||
|
||||
在这个A/B测试中把用户随机分为实验组和对照组，每组50%。
|
||||
|
||||
|
||||
在实验组中，如果用户满足了触发条件，系统就会发送弹窗提醒（如上图）。
|
||||
在对照组中，用户不会收到弹窗提醒，不管是否符合触发条件。
|
||||
|
||||
|
||||
确定了目标和假设，现在我们来具体定义下评价指标：
|
||||
|
||||
“把喜欢的音乐加入收藏夹”功能的使用率 = 使用了“把喜欢的音乐加入收藏夹”的用户总数 / 实验中的用户总数。
|
||||
|
||||
很明显，这是一个概率类的指标，也就是说在实验中的这些用户，使用了“把喜欢的音乐加入收藏夹”这个功能的概率有多少。不过，为了使我们的评价指标更加具体，也方便之后的计算，所以这里我们要搞清楚两个问题。
|
||||
|
||||
第一个问题，如何定义“实验中的用户”？
|
||||
|
||||
鉴于用户只有满足了条件才会触发弹窗，并不是所有在实验中的人都会受到影响，所以测试时不能用所有被分配在实验中的用户，因为这样就会引入没有受到影响的用户（那些被分配在实验中但是却没有满足触发条件的用户），从而降低测试的准确性。所以一定要注意，这里的“实验中的用户”应该是符合触发条件的用户（下图中虚线部分）。
|
||||
|
||||
在实验组中就是触发弹窗的用户，在对照组中则为符合触发条件的用户（因为对照组中的用户不管符合不符合触发条件都不会触发弹窗）。-
|
||||
-
|
||||
第二个问题，如何确定用户从触发弹窗开始到最终使用功能的时间窗口期呢？
|
||||
|
||||
因为本次A/B测试是要检测弹窗是否会对相关功能的使用率有所提升，而且每个用户触发弹窗的时间不同，所以需要事先规定一个统一的时间窗口期来衡量，比如触发后x天之内的使用率，这样统一化是为了使指标更加清晰准确。
|
||||
|
||||
因为弹窗告知在这里具有及时性，及时性也就是说在用户有需求时，所以如果用户是受到弹窗的影响才使用相关功能时，肯定会在看到弹窗不久后就使用了。我们这里就把x设为1，即触发后1天内的使用率。
|
||||
|
||||
搞清楚了这两个问题，我们就可以把评价指标最终定义为：-
|
||||
“把喜欢的音乐加入收藏夹”功能的使用率 = 在符合触发条件后1天之内使用了“把喜欢的音乐加入收藏夹”的用户总数 / 实验中的符合触发条件的用户总数
|
||||
|
||||
光确定评价指标的具体定义还不够，为了更了解咱们的评价指标，得出准确的实验结果，我们还要从统计的角度来看下这个指标的波动性如何。
|
||||
|
||||
通过对历史数据的回溯性分析，得到了用户在符合触发条件后一天之内使用相关功能的平均概率为2.0%，通过统计公式最后求得该指标95%的置信区间为[1.82%，2.18%]。这就说明如果测试结束后两组评价指标的值均落入这个波动范围内，则说明两组无显著不同，属于正常波动范围。
|
||||
|
||||
选取实验对象的单位
|
||||
|
||||
确定了A/B测试的评价指标后，接下来我们要确定下实验对象的单位了。
|
||||
|
||||
因为本次实验的弹窗是用户可见的变化，而且评价指标是以用户为单位，所以我们选择用户作为最小实验对象单位，具体来说，可以选用用户ID，因为这些用户必须登录后才能享受音乐服务。
|
||||
|
||||
计算所需的样本大小和实验所需时间
|
||||
|
||||
我们继续往下走，就该计算实验所需的样本量了。这里，我们需要先确定4个统计量：
|
||||
|
||||
|
||||
显著水平（Significance Level）α。
|
||||
Power （1 – β）。
|
||||
实验组和对照组的综合方差 \(\\sigma\_{\\text {pooled}}^{2}\)。
|
||||
实验组和对照组评价指标的差值δ。
|
||||
|
||||
|
||||
一般A/B测试中显著水平默认为5%，Power默认为80%， 我们的案例也遵循这样的原则。至于两组评价指标之间的差值，根据我们之前算出的波动性，两者的差值要在0.18%以上，才算是统计显著的变化，那么我们就取0.2%。至于综合方差，因为是概率类的指标，我们就可以用统计公式直接算出。
|
||||
|
||||
确定了这些统计量后，我们算出实验组和对照组各需要至少8.07万个符合触发条件的用户，一共需要16.14万用户。而数据分析显示每天符合触发条件的新用户大约为1.7万人，所以本次实验大约需要10天时间完成。
|
||||
|
||||
那么当我们完成了对整个A/B测试的设计工作后，现在就让测试跑起来，收集数据，等到样本量达到预期时就开始分析测试结果。
|
||||
|
||||
分析测试结果
|
||||
|
||||
经过了一周多的等待，我们的样本量终于达标，可以来分析最终的结果啦。不过在分析结果前，我们还要确保A/B测试在具体实施过程中符合我们最初的设计，保证测试的质量品质，这时候就要做合理性检验。
|
||||
|
||||
我们用最常见的护栏指标来做检验。
|
||||
|
||||
|
||||
实验/对照组样本大小的比例是否为50%/50%。
|
||||
实验/对照组中特征的分布是否相似。
|
||||
|
||||
|
||||
经过分析发现，本次A/B测试完全通过了这两项护栏指标的合理性检验，说明试验实施的正如预期。
|
||||
|
||||
那么，现在我们就开始正式分析实验结果了。
|
||||
|
||||
|
||||
实验组：样本量为80723，符合触发条件一天之内使用功能的用户为3124，使用率为3.87%。
|
||||
对照组：样本量为80689，符合触发条件一天之内使用功能的用户为1598，使用率为1.98%。-
|
||||
|
||||
|
||||
|
||||
根据结果我们得到的P值接近于0而且远远小于5%，同时我们计算出两组评价指标差值的95%的置信区间为[1.72%，2.05%]，不包括0，说明这两组的使用率显著不同，事实上实验组的使用率几乎等于对照组的两倍，证明了在用户需要时的弹窗提醒确实有效果！
|
||||
|
||||
得到这个振奋人心的结果后，团队决定把“把喜欢的音乐加入收藏夹”功能的弹窗提醒推广到所有符合触发条件的用户，同时也计划对其他功能的弹窗做类似的A/B测试，来验证它们的效果。如果一切进行顺利的话，就将这些弹窗全部推广，长期来看肯定会增加用户的留存率！
|
||||
|
||||
小结
|
||||
|
||||
通过这个案例串讲，你肯定对做A/B测试的关键步骤有了更具体、更深层次的认识了。
|
||||
|
||||
|
||||
|
||||
那么基础篇的内容到这里也就结束了。接下来我们就会进入到进阶篇的学习。
|
||||
|
||||
在进阶篇，我会给你讲解更多偏经验和方法论的知识。针对做A/B测试时经常出现的一些问题，我会给你讲解它们的成因，给出解决办法。针对面试中常出现的一些考点，我会结合我做面试官的经验，来给你一些解题思路。
|
||||
|
||||
最后我还想强调一下，学习这件事本来就是反复和持续的。进阶篇的内容会和基础篇有不少联系。所以在学习进阶篇的课程时，我也希望你能够不断温习、思考之前学过的知识。待课程结束，再回头看基础篇这些内容，相信你会有一种“蓦然回首，原来A/B测试如此简单”的畅快感和收获感。
|
||||
|
||||
思考题
|
||||
|
||||
回忆你之前做过或者经历过的A/B测试，它们是否有这些基本的流程步骤？如果缺少的话，是缺少哪些步骤，为什么？如果还有其他步骤，也和我分享一下吧。
|
||||
|
||||
如果你学完今天的案例串讲，对A/B测试的流程、步骤有了更清晰的认识，欢迎你点击“请朋友读”，把今天的内容分享给你的同事、好友，大家一起学习、成长。好，感谢你的收听，我们进阶篇的课程再见。
|
||||
|
||||
|
||||
|
||||
|
||||
202
专栏/AB测试从0到1/09测试结果不显著，要怎么改善？.md
Normal file
202
专栏/AB测试从0到1/09测试结果不显著，要怎么改善？.md
Normal file
@@ -0,0 +1,202 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
09 测试结果不显著，要怎么改善？
|
||||
你好，我是博伟。
|
||||
|
||||
通过“基础篇”的学习，你已经掌握了A/B测试的整体流程，那就可以参照这些流程设计一次A/B测试了。不过在具体实施的过程中，你会因为业务的复杂性、没有严格遵守规范的流程，或者数据本身的属性等，不可避免地遇到一些问题。
|
||||
|
||||
没错儿，这就是我在开篇词中和你说的，A/B测试的实践性非常强，你需要能够识别那些潜在的坑，并找到相应的解决方法。所以在接下来的三节课里，我会带你去看看我积累的经验，曾经踩过的坑，让你在实践时能提前规避，少出错。
|
||||
|
||||
今天，我们就先从一个很痛的问题开始吧。在第7节课我们学习如何得到可信赖的测试结果，以及如何分析测试结果时，非常顺利地得出了对照组和实验组指标显著不同的结果。不知道你脑海中会不会一直萦绕着这么一个问题：我也是按照这个流程来设计A/B测试的啊，为什么我的实验结果不显著呢，我应该据此得出“两组指标事实上是相同的”结论吗？
|
||||
|
||||
今天这节课，我们就来深入剖析“测试结果如何不显著怎么办”这个大家经常遇到的问题。
|
||||
|
||||
为什么会出现“实验结果不显著”？
|
||||
|
||||
首先我们要搞清楚，为什么会出现“实验结果不显著”？有两方面原因。
|
||||
|
||||
|
||||
A/B测试中的变化确实没有效果，所以两组的指标在事实上是相同的。
|
||||
A/B测试中的变化有效果，所以两组的指标在事实上是不同的。但是由于变化的程度很小，测试的灵敏度，也就是Power不足，所以并没有检测到两组指标的不同。
|
||||
|
||||
|
||||
如果是第一种原因，就证明这个变化对产品/业务优化没有效果。那我们要考虑放弃这个变化，或者去测试新的变化。
|
||||
|
||||
如果是第二种原因，那我们可以从A/B测试的角度进行一些优化和调整。具体来说就是，通过提高Power来提高A/B测试检测到实验结果不同的概率。在第6节课我讲过了，Power越大，越能够准确地检测出实验组与对照组的不同。所以当我们提高了Power之后，如果仍然发现测试结果不显著，这样才能得出“两组指标事实上是相同的”的结论。
|
||||
|
||||
有什么方法可以提高Power呢？
|
||||
|
||||
我们再来回顾下第6节课讲到的样本量估算公式：-
|
||||
\(\\mathrm{n}=\\frac{\\left(Z\_{1-\\frac{\\alpha}{2}}+Z\_{1-\\beta}\\right)^{2}}{\\left(\\frac{\\delta}{\\sigma\_{\\text {pooled}}}\\right)^{2}}=\\frac{\\left(Z\_{1-\\frac{\\alpha}{2}}+Z\_{\\text {power}}\\right)^{2}}{\\left(\\frac{\\delta}{\\sigma\_{\\text {pooled}}}\\right)^{2}}\)-
|
||||
其中:-
|
||||
\(Z\_{1-\\frac{\\alpha}{2}}\) 为 \(\\left(1-\\frac{\\alpha}{2}\\right)\) 对应的 \(Z\) Score。-
|
||||
\(Z\_{\\text {Power}}\) 为 Power 对应的 \(Z\) Score。-
|
||||
\(\\delta\) 为实验组和对照组评价指标的差值。-
|
||||
\(\\sigma\_{\\text {pooled}}^{2}\) 为实验组和对照组的综合方差 (Pooled Variance)。
|
||||
|
||||
在公式里，我们找出影响Power的因素，也就是样本量和方差。其中：
|
||||
|
||||
|
||||
样本量和Power成正比。即通过增大样本量就可以提高Power。
|
||||
方差和Power成反比。即通过减小方差就可以提高Power。
|
||||
|
||||
|
||||
具体来说，实践中，在有条件获得更大样本量的情况下，可以选择增大样本量的方法来提高Power，相对简单易操作。如果受流量或时间限制，没有条件获得更多的样本量，此时可以通过减小方差来提高Power。
|
||||
|
||||
接下来，我就分别从增大样本量和减小方差这两个维度，来讲解6种提高Power的具体方法。
|
||||
|
||||
如何通过增加样本量来提高Power？
|
||||
|
||||
实践中，用来增加样本量的方法主要有三种：延长测试时间，增加测试使用流量在总流量中的占比，以及多个测试共用同一个对照组。
|
||||
|
||||
延长测试时间
|
||||
|
||||
对于延长测试时间，你肯定不陌生，我在第6节课讲样本量估算时就讲过。每天产生的可以测试的流量是固定的，那么测试时间越长，样本量也就越大。所以在条件允许的情况下，可以延长测试的时间。
|
||||
|
||||
增加测试使用流量在总流量中的占比
|
||||
|
||||
假设某个产品每天有1万流量，如果我要做A/B测试，并不会用100%的流量，一般会用总流量的一部分，比如10%，也就是测试使用流量在总流量中的占比。
|
||||
|
||||
为什么不使用全部流量呢？
|
||||
|
||||
一方面，A/B测试有试错成本，虽然出现的概率较低，但是我们在测试中做出的任何改变都有可能对业务造成损害。所以，使用的流量越少，试错成本越低，也就越保险。
|
||||
|
||||
另一方面，在大数据时代，对于互联网巨头来说，由于本身就拥有巨大的流量，那么产品本身做出的任何比较明显的改变，都有可能成为新闻。
|
||||
|
||||
比如要测试是否要增加一个新功能时，公司并不想在测试阶段就把这个新功能泄露给用户，以免给用户造成困扰。所以它们一般会先使用很小比例的流量来做A/B测试（比如1%），确定得到显著结果后再把A/B测试中的变化慢慢推广到100%的流量。
|
||||
|
||||
所以，在保持测试时间不变的情况下，还可以通过增加测试使用流量在总流量中的占比，来达到增加样本量的目的。
|
||||
|
||||
多个测试共用同一个对照组
|
||||
|
||||
有时我们会在同一个产品上同时跑多个A/B测试，比如我们想要提升推送的点击率，就会在原推送的基础上改变推送的标题、推送的内容、推送的时间、推送的受众，等等。
|
||||
|
||||
对于这四个不同的影响因素，事实上，改变每一个因素都是一个独立的A/B测试。那理论上我们就需要设计4个实验，需要有4个实验组和4个对照组。
|
||||
|
||||
假设我们现在的可用流量一共是8万，那么每组就有1万流量。但是你会发现这样流量的利用率太低了，因为每个实验的对照组其实都是一样的（原推送）。但如果我们把4个对照组合并成一个，这样的话就变成了4个实验组和1个对照组，每组就有1.6万流量。
|
||||
|
||||
你看，在同一个基础上想同时验证多个变化，也就是跑多个A/B测试有相同的对照组的时候，我们可以把对照组合并，减少分组数量，这样每组的样本量也会增加。这种测试又叫做A/B/n测试。
|
||||
|
||||
总结来说，在实践中：
|
||||
|
||||
|
||||
如果时间允许，最常用的是延长测试时间的方法，因为操作起来最简单。
|
||||
如果时间不充足的，可以优先选择增加测试使用流量在总流量中的占比，因为可以节省时间。
|
||||
当有多个测试同时进行，而且对照组又相同的情况下，就可以把多个对照组合并成一个。
|
||||
|
||||
|
||||
通过增加样本量来提高Power，是实践中最常见的方法，但是业务场景千变万化，虽然不常见，但有时候确实没有办法获得更多的样本，比如时间紧迫，同时已经使用了100%的总流量，结果还是不显著，那这个时候就要通过减少方差来提高Power了。
|
||||
|
||||
如何通过减小方差来提高Power？
|
||||
|
||||
实践中常用的减少方差的方法也有三种：减小指标的方差，倾向评分匹配，以及在触发阶段计算指标。
|
||||
|
||||
减小指标的方差
|
||||
|
||||
减小指标的方差有两种方式。
|
||||
|
||||
第一种方式：保持原指标不变，通过剔除离群值（Outlier）的方法来减小方差。
|
||||
|
||||
如果我们通过指标的直方图，发现实验的指标分布中有很明显的离群值，就可以通过设定封顶阈值（Capping Threshold）的方法把离群值剔除掉。
|
||||
|
||||
比如可以根据指标的分布，只选取95%的取值范围，然后把剩下的5%的离群值剔除掉。常见的指标，比如电商中的人均花费，或者音乐App中的人均收听时间，由于会有些极少热衷于线上购物的用户花费居多，或者音乐发烧友一直在听歌，那么这些极少部分的用户就可能变成离群值，从而增加方差。
|
||||
|
||||
第二种方式：选用方差较小的指标。
|
||||
|
||||
取值范围窄的指标比取值范围广的指标方差要小。比如点击者量比点击量的方差小（因为一个点击者可以产生多个点击，点击比点击者多，取值范围广）；购买率比人均花费的方差小（因为购买率是表征买或不买的二元事件，只有两个取值，人均花费则可以是任何数量的金钱，理论上有无限的取值范围）；收听率比人均收听时间的方差小；等等。
|
||||
|
||||
可以看到，对于表征类似的行为（比如买买买，听音乐，看视频，等等），概率类指标要比均值类指标的方差小。所以在满足业务需求的情况下，如果我们想要减少方差，就可以把均值类的指标转化成表征相似行为的概率类指标，也就是修改原定指标，选用取值范围窄的指标。
|
||||
|
||||
倾向评分匹配（Propensity Score Matching）
|
||||
|
||||
倾向评分匹配，简称PSM，是因果推断的一种方法，目的是解决实验组和对照组分布不均匀的问题。
|
||||
|
||||
你一定还记得我们在第7节课中，学习过分析结果前要进行合理性检验，那么它和PSM是什么关系呢？
|
||||
|
||||
我来总结下。如果说合理性检验是帮我们确定两组分布是否相似的方法，那么PSM，就是帮我们找出两组中相似部分的回溯性分析方法。简单来说，两组的各个特征越相似，就说明两组的方差越小。
|
||||
|
||||
PSM的基本原理，就是把一组中的数据点，找到在另一组和它们相似的数据点，进行一对一的匹配，这个相似性是通过比较每个数据点的倾向评分（Propensity Score）得到的。如果不理解倾向评分也没关系，你只需要知道这一点就够了：倾向评分越接近，说明两个数据点越相似。这里的一个数据点，指的就是A/B测试中的一个实验单位。
|
||||
|
||||
PSM的具体做法如下。
|
||||
|
||||
|
||||
首先，把我们要匹配的两组中每个数据点的各个特征（比如用户的性别，年龄，地理位置，使用产品/服务的特征等）放进一个逻辑回归（Logistics Regression）中。
|
||||
然后，算出每个数据点的倾向评分，然后再用诸如最邻近（Nearest Neighbor）等方法进行匹配。
|
||||
最后我们只需要比较匹配后的两组相似的部分即可。
|
||||
|
||||
|
||||
PSM的原理有些复杂，我放了一些资料链接，你可以查看。不过幸运的是，在主要的编程语言Python和R中都有相应的库，比如Python中的pymatch和R中的Matching，让我们的实施变得相对容易些。
|
||||
|
||||
在倾向评分匹配这个部分，你只需要记住一个结论就可以了，那就是：PSM能够有效地减少两组的方差。通过比较倾向评分匹配后的两组的相似部分，我们可以来查看结果是否显著。
|
||||
|
||||
在触发阶段计算指标
|
||||
|
||||
在A/B测试中我们把实验单位进行随机分组的这个过程叫做分配（Assignment）， 同时你要知道，在有些A/B测试中，比如在第8节课的案例中，我们要测试的变化是需要满足一定条件才能触发的。
|
||||
|
||||
所以从分配和触发的关系来看，A/B测试可以分为两种。
|
||||
|
||||
|
||||
变化不需要条件触发。所有用户在被分配到实验组后，就都可以体验到A/B测试中的变化。
|
||||
|
||||
变化需要条件触发。在被分配到实验组的所有用户中，只有满足一定条件的用户才会触发A/B测试中的变化。
|
||||
|
||||
|
||||
|
||||
|
||||
实践中大部分的A/B测试都属于第一种，而且也比较好理解。
|
||||
|
||||
但是要注意了，我们这里讲的减小方差的方法只适用于第二种A/B测试，简单来说，就是在计算指标时只考虑每组符合触发条件（黄圆圈）的用户，而不是考虑每组中的所有用户（绿圆圈）。这个不是很好理解，我来举例说明下。
|
||||
|
||||
还记得第8节课中我们讲到可以利用弹窗的形式来告知用户“把喜欢的音乐加入收藏夹”新功能的A/B测试吗？在A/B测试的设计中，并不是在实验组的所有用户都会收到弹窗提醒的。
|
||||
|
||||
所以为了避免打扰到不相关的用户，把弹窗发送给需要这个功能的用户，我们事先规定了触发弹窗的规则：
|
||||
|
||||
|
||||
该用户从来没用过“把喜欢的音乐加入收藏夹”这个功能。
|
||||
该用户已经对某首歌听了4次，当播放第5次时触发弹窗。
|
||||
|
||||
|
||||
那么当我们计算案例中的评价指标时，各组中“把喜欢的音乐加入收藏夹”功能的使用率 = 各组中使用了“把喜欢的音乐加入收藏夹”的用户总数 / 实验中各组的用户总数。
|
||||
|
||||
这里的分母“实验中各组的用户总数”就只算满足弹窗触发规则的用户，而不是算所有被分配到实验中各组的用户，这就是在触发阶段计算指标。
|
||||
|
||||
这里要注意的是，在对照组也会有用户满足弹窗触发规则的，只不过因为他们在对照组，所以即使他们满足了弹窗触发规则，我们也不会给这些用户发弹窗，我们还是要统计这些人因为要用他们做分母来计算评价指标。
|
||||
|
||||
这里对数据埋点熟悉的小伙伴可能要问了：这些符合弹窗触发规则的对照组用户并没有触发弹窗，在数据中并没有相关的记录，我怎么在数据中去记录他们呢？
|
||||
|
||||
在工程实现上其实是有一个小技巧的：对于对照组的用户，如果他们符合触发规则，我们就给他们发送一个只有一个像素点的看不见的隐形弹窗，这样的话我们在数据中会有相关记录，方便之后的指标计算，同时又保证了对照组不会受到弹窗的影响。
|
||||
|
||||
通过把评价指标的分母变为满足弹窗触发规则的用户，在计算指标时就会排除掉数据中的噪音（那些被分配到实验中但是没有触发弹窗的用户），从而减小方差。
|
||||
|
||||
这种需要触发的A/B测试多出现在有固定的用户使用路径的业务中，比如电商。在电商中，用户一般有较明确的多层级的使用路径：进入网站/App —> 浏览商品列表 —> 查看具体商品 —> 加入购物车 —> 购买。
|
||||
|
||||
在电商的A/B测试中，一般是在用户进入网站/App时就被分配到实验组或者对照组，如果我们测试之后的环节，比如在“购物车”页面测试新功能，这时候只有进入到“购物车”页面的用户才能触发A/B测试中的变化。
|
||||
|
||||
总体而言，通过减少方差来提高Power的情况不多（常见的是通过增加样本量来提高Power）。如果真的遇到这种情况，那么比较简单快速的方法就是减小指标的方差。当然如果有条件的话我还是推荐更加科学的倾向评分匹配（PSM）。那么对于在A/B测试中的变化存在触发的情况下，就一定要在触发阶段计算指标。
|
||||
|
||||
小结
|
||||
|
||||
为了解决A/B测试结果不显著的问题，这节课我们主要讲解了提高A/B测试Power的6种方法，我把它们从原理上分成了两大类：
|
||||
|
||||
|
||||
|
||||
你可以根据我对每种方法的介绍，以及在什么情况下选用哪种方法，灵活应用。
|
||||
|
||||
如果在尝试过这些方法后，重新跑实验得出的测试结果还不显著，那就说明两组的指标事实上是相同的，我们就要放弃这个A/B测试中的变化，用其他的变化来优化业务和产品。
|
||||
|
||||
最后再强调一下，做出一个能真正提升业务的改变并不容易。从美国FLAG这些大厂披露出来的实验数据来看，A/B测试得到真正显著的结果并最终实施变化的概率，还不到三分之一。
|
||||
|
||||
所以也不要气馁，虽然不是每次实验都会有显著的结果，但是你可以从每次实验中学到新的知识（比如变化到底对业务有没有效果），沉淀新的方法论，还能从中发现业务、数据或者工程上潜在的一些问题。这些个人技能上的成长、业务流程上的完善，都是非常宝贵的。
|
||||
|
||||
思考题
|
||||
|
||||
在某次A/B测试中，你是不是也遇到过没能得到显著结果的情况？你当时是怎么处理的，有没有从实验中获得一些宝贵的经验？
|
||||
|
||||
欢迎在评论区留言、讨论，也欢迎点击“请朋友读”，把今天的内容分享给你的同事、好友，和他一起学习、成长。好，感谢你的收听，我们下节课再见。
|
||||
|
||||
|
||||
|
||||
|
||||
171
专栏/AB测试从0到1/10常见误区及解决方法（上）：多重检验问题和学习效应.md
Normal file
171
专栏/AB测试从0到1/10常见误区及解决方法（上）：多重检验问题和学习效应.md
Normal file
@@ -0,0 +1,171 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
10 常见误区及解决方法（上）：多重检验问题和学习效应
|
||||
你好，我是博伟。
|
||||
|
||||
上节课，我们讲了一个在做A/B测试时普遍存在的一个问题，那么接下来，我就根据自己这些年做A/B测试的经验，精选了一些在实际业务中会经常遭遇的误区，主要是多重检验问题、学习效应、辛普森悖论和实验/对照组的独立性这四大误区。
|
||||
|
||||
这四个误区，其实也可以被看作在实际业务中经常出现的几个问题。不过我在题目中之所以强调说这是误区，是因为你很可能会在这些问题的理解上产生一些偏差。
|
||||
|
||||
所以接下来我在讲这两节课时，会按照“问题阐述—问题解析—总结引申—课后思考”的范式来给你讲。也就是说，我会先带你深入剖析问题的成因，然后再举例分析这些问题在实践中的表现形式，最后给出对应的解决方法。
|
||||
|
||||
毕竟，在搞清楚问题原理的前提下，再学习问题的表现形式和解决方法，不仅你的学习效果会事半功倍，而且在实际应用时，你也能根据变化多端的业务场景，随机应变，灵活运用。
|
||||
|
||||
多重检验问题（Multiple Testing Problem）
|
||||
|
||||
多重检验问题，又叫多重测试问题或多重比较问题（Multiple Comparison Problem），指的是当同时比较多个检验时，第一类错误率α就会增大，而结果的准确性就会受到影响这个问题。我在基础篇讲A/B测试流程时就多次提到过它，比如第4节课讲OEC的好处时，还有第7节课讲什么时间才能查看测试结果时。
|
||||
|
||||
多重检验为什么会是一个问题？
|
||||
|
||||
要搞清楚多重检验为什么会是一个问题，我们还得先从第一类错误率α（又叫假阳性率，显著水平，是测试前的预设值，一般为5%）说起。我在第2节课也讲过，第一类错误率指的就是当事实上两组指标是相同的时候，假设检验推断出两组指标不同的概率，或者说由于偶然得到显著结果的概率。而且，它在统计上的约定俗成是5%。
|
||||
|
||||
5%看上去是个小概率事件，但是如果我们同时比较20个检验（测试）呢？你可以先思考一下，如果每个检验出现第一类错误的概率是5%，那么在这20个检验中至少出现一个第一类错误的概率是多少呢？
|
||||
|
||||
要直接求出这个事件的概率不太容易，我们可以先求出这个事件发生情况的反面，也就是在这20个检验中完全没有出现第一类错误的概率，然后再用100%减去这个反面事件的概率。
|
||||
|
||||
这里我们用P（A）来表示出现事件A的概率。P（每个检验出现第一类错误）=5%，那么P（每个检验不出现第一类错误） = （1-5%）=95%，所以P（20个检验中完全没有第一类错误）= 95%的20次方。
|
||||
|
||||
这样我们就可以求得这个概率：-
|
||||
-
|
||||
这里的 P（至少出现一个第一类错误）的概率又叫做 FWER （Family-wise Error Rate）。-
|
||||
通过计算得出来的概率是64%。这就意味着当同时比较20个检验时，在这20个结果中，至少出现一个第一类错误的概率是64%。看看，这是不是个很大的概率了呢？事实上，随着检验次数的增加，这个概率会越来越大，你看看下面这个图就明白了。
|
||||
|
||||
|
||||
|
||||
图中的蓝线和橙线分别表示当α=5%和1%时，FWER的变化情况。根据这个图我们可以得出两个结论：
|
||||
|
||||
|
||||
随着检验次数的增加，FWER，也就是出现第一类错误的概率会显著升高。
|
||||
|
||||
当α越小时，FWER会越小，上升的速度也越慢。
|
||||
|
||||
|
||||
第一个结论讲的就是多重检验带来的问题。第二个结论其实为我们提供了一种潜在的解决方法：降低α。
|
||||
|
||||
这就意味着，当我们同时比较多个检验时，就增加了得到第一类错误的概率（FWER），这就变成了一个潜在的多重检验问题。
|
||||
|
||||
什么时候会遇到多重检验问题？
|
||||
|
||||
你可能会说我平时都是一个测试一个测试去跑，不会同时跑多个测试，是不是就不会遇到这个问题了呢？其实不是的，实践中出现多重检验问题比你想象的要普遍得多，它在实践中主要以4种形式出现。
|
||||
|
||||
第一种形式，当A/B测试有不止一个实验组时。
|
||||
|
||||
当我们想要改变不止一个变量且样本量充足时，我们可以不必等测试完一个变量后再去测试下一个，而是可以同时测试这些变量，把它们分在不同的实验组当中。
|
||||
|
||||
每个实验组只变化一个变量，在分析结果时分别用每个实验组和共同的对照组进行比较，这种测试方法也叫做A/B/n测试。比如我想要改变广告来提升其效果，那么想要改变的变量包括内容、背景颜色、字体大小等等，这个时候我就要有相对应的3个实验组，然后把它们分别和对照组进行比较。
|
||||
|
||||
这就相当于同时进行了3个检验，就会出现多重检验问题。
|
||||
|
||||
第二种形式，当A/B测试有不止一个评价指标时。
|
||||
|
||||
这个很好理解，因为我们分析测试结果，其实就是比较实验组和对照组的评价指标。如果有多个评价指标的话，就会进行多次检验，产生多重检验问题。
|
||||
|
||||
第三种形式，当你在分析A/B测试结果，按照不同的维度去做细分分析（Segmentation Analysis）时。
|
||||
|
||||
当我们分析测试结果时，根据业务需求，有时我们并不满足于只把实验组和对照组进行总体比较。
|
||||
|
||||
比如对于一个跨国公司来说，很多A/B测试会在全球多个国家同时进行，这时候如果我们想要看A/B测试中的变化对于各个国家的具体影响时，就会以国家为维度来做细分的分析，会分别比较单个国家中的两组指标大小，那么此时分析每个国家的测试结果就是一个检验，多个国家则是多个检验。
|
||||
|
||||
第四种形式，当A/B测试在进行过程中，你不断去查看实验结果时。
|
||||
|
||||
这种情况我在第7节课中提到过，因为当测试还在进行中，所以每次查看的测试都和上一次的不一样，每查看一次结果都算是一次检验，这样也会产生多重检验问题。
|
||||
|
||||
了解了多重检验问题在实践中的表现形式，那么在实践中该如何解决它呢？
|
||||
|
||||
如何解决多重检验问题？
|
||||
|
||||
首先我要提前说明的是，接下来我介绍的解决方法，只适用于前3种表现形式。对于第4种表现形式的解决办法，我已经在第7节课介绍了，那就是不要在A/B测试还在进行时就过早地去查看结果，一定要等样本量达到要求后再去计算结果，所以这里就不再赘述。
|
||||
|
||||
鉴于多重检验问题的普遍性，在统计上有很多学者提出了自己的解决方法，大致分为两类：
|
||||
|
||||
|
||||
保持每个检验的P值不变，调整α。
|
||||
|
||||
保持α不变，调整每个检验的P值。
|
||||
|
||||
|
||||
为什么会做这两种调整呢？
|
||||
|
||||
在第2节课，我们介绍了用P值来判断假设检验的结果是否显著时，是用检验中计算出的P值和α进行比较的。当P值<α时，我们才说结果显著。
|
||||
|
||||
所以，我们要么调整α，要么调整P值。前面我也说了，降低α是一种解决办法，最常用的调整α的方法是Bonferroni校正（Bonferroni Correction），其实很简单，就是把α变成α/n。
|
||||
|
||||
其中n是检验的个数。比如α=5%，那当我们比较20个检验时，校正之后的α=5%/20 = 0.25%，此时的FWER =\(1-(1-0.25 \\%)^{20}\) = 4.88% ，和我们最初设定的α=5%差不多。
|
||||
|
||||
Bonferroni校正由于操作简单，在A/B测试的实践中十分流行，但是这种方法只是调整了α，对于不同的P值都采取了一刀切的办法，所以显得有些保守，检测次数较少时还可以适用。
|
||||
|
||||
根据实践经验，在检测次数较大时（比如上百次，这种情况在A/B测试中出现的情况一般是做不同维度的细分分析时，比如对于跨国公司来说，有时会有上百个markets）， Bonferroni校正会显著增加第二类错误率β，这时候一个比较好的解决办法就是去调整P值，常用的方法就是通过控制FDR（False Discovery Rate）来实现。
|
||||
|
||||
控制FDR的原理比较复杂，我就不展开讲了，你只需要记住它指的是一类方法，其中最常用的是BH法（Benjamini-Hochberg Procedure）就行了。BH法会考虑到每个P值的大小，然后做不同程度的调整。大致的调整方法就是把各个检验计算出的P值从小到大排序，然后根据排序来分别调整不同的P值，最后再用调整后的P值和α进行比较。
|
||||
|
||||
实践中，我们一般会借助像Python这样的工具来计算，Python中的multipletests函数很强大，里面有各种校正多重检验的方法，其中就包括我们今天讲的Bonferroni校正和BH法，我们使用时只需要把不同的P值输入，选取校正方法，这个函数就会给我们输出校正后的P值。
|
||||
|
||||
这里我总结一下，虽然Bonferroni校正十分简单，但由于过于严格和保守，所以在实践中我会更推荐使用BH法来矫正P值。
|
||||
|
||||
聊完了多重检验问题，我们再聊一下A/B测试中另一个常见问题——学习效应。
|
||||
|
||||
学习效应(Learning Effect)
|
||||
|
||||
当我们想通过A/B测试检验非常明显的变化时，比如改变网站或者产品的交互界面和功能，那些网站或者产品的老客户往往适应了之前的交互界面和功能，而新的交互界面和功能对他们来说需要一段时间来适应和学习。所以往往老用户在学习适应阶段的行为会跟平时有些不同，这就是学习效应。
|
||||
|
||||
学习效应在实践中有哪些表现形式？
|
||||
|
||||
根据不同的改变，老用户在学习适应期的反应也不同，一般分为两种。
|
||||
|
||||
第一种是积极的反应，一般也叫做新奇效应（Novelty Effect），指的是老用户对于变化有很强的好奇心，愿意去尝试。
|
||||
|
||||
比如把点击按钮的颜色，由之前的冷色调变成了非常艳丽的大红色，在短期内可能会使诸如点击率之类的指标提升，但是当用户适应了新的大红色后，长期的指标也可能回归到之前的水平。
|
||||
|
||||
第二种是消极的反应，一般也叫做改变厌恶（Change Aversion）。指的是老用户对于变化比较困惑，甚至产生抵触心理。
|
||||
|
||||
比如你经常光顾的电商网站，之前的加入购物车功能是在屏幕的左上方，但是交互界面改变后加入购物车的位置变到了屏幕的右下方，这个时候你可能就需要在屏幕上找一阵子才能找到，甚至找了一圈没找到，因为烦躁就关掉了页面，那么这时候短期的指标就会下降。
|
||||
|
||||
可以想象，这些在学习适应期的不同反应一般是短期的，长期来看这些短期反应也是会慢慢消退的。但是要注意的是，这些短期的学习效应确实会给A/B测试的结果带来干扰，使结果变得过于好或者过于差。那么我们如何来及时发现学习效应，从而剔除学习效应带来的干扰呢？
|
||||
|
||||
学习效应该如何检测？
|
||||
|
||||
在实践中，主要有两种方法可以用来检测学习效应。
|
||||
|
||||
第一种方法是表征实验组的指标随着时间（以天为单位）的变化情况。
|
||||
|
||||
在没有学习效应的情况下，实验组的指标随着时间的变化是相对稳定的。
|
||||
|
||||
但是当有学习效应时，因为学习效应是短期的，长期来看慢慢会消退，那么实验组（有变化的组）的指标就会有一个随着时间慢慢变化的过程，直到稳定。
|
||||
|
||||
|
||||
如果是新奇效应，实验组的指标可能会由刚开始的迅速提升，到随着时间慢慢降低。
|
||||
如果是改变厌恶，实验组的指标可能会由刚开始的迅速降低，到随着时间慢慢回升。
|
||||
|
||||
|
||||
当然我们在使用这个方法时需要注意：随着时间表征实验组的指标变化，但并不是让你每天去比较实验组和对照组的大小。如果每天都去比较，就会出现我们刚才讲的多重检验的问题。一定要记住，只有达到样本量之后才可以去比较两组大小，分析测试结果。
|
||||
|
||||
第二种方法是只比较实验组和对照组中的新用户。
|
||||
|
||||
学习效应是老用户为了学习适应新的变化产生的，所以对于新用户，也就是在实验期间才第一次登录的用户来说，并不存在“学习适应新的变化”这个问题，那么我们可以先在两组找出新用户（如果是随机分组的话，两组中新用户的比例应该是相似的），然后只在两组的新用户中分别计算我们的指标，最后再比较这两个指标。
|
||||
|
||||
如果我们在新用户的比较中没有得出显著结果（在新用户样本量充足的情况下），但是在总体的比较中得出了显著结果，那就说明这个变化对于新用户没有影响，但是对于老用户有影响，那么大概率是出现了学习效应。
|
||||
|
||||
在实践中我们可以用以上方法检测出学习效应，不过要想真正排除学习效应的影响，得到准确的实验结果，还是要延长测试时间，等到实验组的学习效应消退再来比较两组的结果。
|
||||
|
||||
小结
|
||||
|
||||
今天这节课我们重点讲解了A/B测试中两个常见的实验误区：多重检验问题和学习效应。我把这两个问题出现的原理、在实践中的多种表现形式，以及相应的解决方法，都给你详细讲解了。
|
||||
|
||||
不过我还想特别强调一下多重检验问题。多重检验问题的表现形式多种多样，所以在A/B测试中尤为常见。我在刚接触A/B测试时就已经知道了这个问题的存在，不过当时了解到的是它会在A/B/n测试中出现，但后来才发现，原来在做细分分析时也会出现多重检验的问题。
|
||||
|
||||
幸好这个问题发现得及时，才没有让整个测试功亏一篑。现在再去复盘，主要还是因为当时只知道多重检验问题的存在，了解其中一两个表现形式。但对于为什么会出现多重检验问题，什么时候可能会出现多重检验问题，我都不清楚，所以在问题出现新的表现形式时就没有及时识别出来。
|
||||
|
||||
这也是我想要跟你强调的，知道为什么会出现这个问题，并且发现问题，和解决问题同样重要。
|
||||
|
||||
思考题
|
||||
|
||||
结合自己的经验，想一想过去有没有在A/B测试中遇到多重检验问题和学习效应？以及当时是如何处理的呢？
|
||||
|
||||
欢迎在评论区写下你学习本节课的收获和深度思考，如果今天的内容能帮你解答了一些困惑问题，也欢迎点击“请朋友读”，和他一起学习、成长。感谢你的收听，我们下节课再见。
|
||||
|
||||
|
||||
|
||||
|
||||
161
专栏/AB测试从0到1/11常见误区及解决方法（下）：辛普森悖论和实验组_对照组的独立性.md
Normal file
161
专栏/AB测试从0到1/11常见误区及解决方法（下）：辛普森悖论和实验组_对照组的独立性.md
Normal file
@@ -0,0 +1,161 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
11 常见误区及解决方法（下）：辛普森悖论和实验组_对照组的独立性
|
||||
你好，我是博伟。这节课，我们继续来学习A/B测试中的常见误区和解决方法。
|
||||
|
||||
今天我们要解决的问题，是辛普森悖论和实验/对照组的独立性。这两个问题在A/B测试的实践中也是常客。
|
||||
|
||||
对于辛普森悖论呢，由于遇到的次数太多，以至于我每次做A/B测试结果的细分分析时，都要先检查该细分领域在两组的比例是否符合两组整体的比例，来确保实验结果的准确。
|
||||
|
||||
对于实验/对照组独立性被破坏这个问题，我在早期做营销预算固定的A/B测试时也经常遇到，但是它的表现形式其实非常多变，各个业务类型中都有它的身影，所以就需要有针对性地进行分析。
|
||||
|
||||
听了我的经历，你可能还是不太明白这两个问题到底是什么，它们对A/B测试有什么影响，不用担心，今天我就会为你深度剖析，带你在实践中去识别它们，并解决它们！
|
||||
|
||||
辛普森悖论
|
||||
|
||||
听到“辛普森悖论”这个概念，你可能会有点迷茫，不知道它具体说的是什么问题。所以我还是先用音乐App来举个例子，告诉你辛普森悖论是什么，以及它在A/B测试中到底指的是什么。
|
||||
|
||||
一款音乐App优化了新用户的注册流程，并且希望通过A/B测试在北京、上海这两个主要的市场来验证优化注册后的转化率是否有所提升。
|
||||
|
||||
|
||||
实验组：使用优化后的注册流程。
|
||||
对照组：使用原有的注册流程。
|
||||
|
||||
|
||||
在设计好了实验之后，实验组和对照组的样本量均分。等跑完实验，获得了足够的实验样本之后，结果得到实验组的转化率为1.44%， 对照组的转化率为2.02%。
|
||||
|
||||
这就很让人意外了，为什么实验组（使用优化后的注册流程）的转化率，反而比对照组（使用原有的注册流程）的转化率要低呢？
|
||||
|
||||
而且更让人意外的是，当你在分别分析北京和上海这两个市场时，会发现它们的实验组转化率都比对照组的要高。
|
||||
|
||||
|
||||
|
||||
在确认了数据和计算没有错误后，你的本能反应可能会是：同样的数据，我在进行总体分析和细分分析时得出的结果却完全相反，这怎么可能呢！
|
||||
|
||||
这就是在数学理论中很有名的辛普森悖论，它是指当多组数据内部组成分布不均匀时，从总体上比较多组数据和分别在每个细分领域中比较多组数据可能会得出相反的结论。在数学上，它的形式要更加抽象：即使 \(\\frac{a}{b}<\\frac{A}{B}, \\frac{c}{d}<\\frac{C}{D}\)，那么\(\\frac{a+c}{b+d}>\\frac{A+C}{B+D}\)也是可能成立的。
|
||||
|
||||
真是奇怪了，这个有些反直觉的现象，在数学上竟然是完全可以成立的。而这种不可思议的现象，也出现在了A/B测试中。
|
||||
|
||||
究其原因，在这个例子当中，其实是因为实验组和对照组虽然在总体上实现了我们在设计实验时要求的样本量均分。但是在北京和上海这两个细分市场中却分布不均匀，没有实现样本量均分。-
|
||||
-
|
||||
关于细分分析，我也再补充一下。在A/B测试的实践中，我们一般根据市场（不同的城市、国家等），设备类型（手机、桌面、平板等），用户的互动或者花费程度（轻度、中度、重度等）来进行细分分析。
|
||||
|
||||
好了，还是回到我们的案例当中。如果你对基础篇的内容掌握得足够扎实，就会发现我们在第7节课中讲分析结果前的合理性检验时，其中有一项就是检验实验/对照组中特征的分布，意思是说要检验两组中的特征分布是否相似，是否符合实验设计要求的比例分布。
|
||||
|
||||
所以，咱们今天讲的辛普森悖论，实际上就是由于实验中两组在不同细分领域中的分布不均造成的。
|
||||
|
||||
当然，在音乐App这个例子中只有两个细分领域。如果是多个细分领域，比如要在全国几十个大城市进行A/B测试，那么只要是实验组和对照组在任何一个细分领域的分布与实验设计的不相符时，都有可能出现辛普森悖论。
|
||||
|
||||
所以，既然辛普森悖论是我们做A/B测试时需要规避的问题/现象，那有没有合适的解决方案呢？
|
||||
|
||||
其实，解决一个问题的最好方法就是减少或者避免它的产生。就像我刚才说的，辛普森悖论是两组在不同细分领域中的分布不均造成的。想想看，如果我们在分析测试结果前做好了合理性检验，那出现辛普森悖论的几率就会大大减小。
|
||||
|
||||
不过，如果在分析结果前我们没有做好合理性检验，那还有别的办法可以解决吗？
|
||||
|
||||
当然有，不过会比较麻烦。如果我们在进行总体分析和细分分析时发现了辛普森悖论，最好的解决办法就是重新跑实验，看看两组在不同细分领域的分布不均会不会消失。
|
||||
|
||||
如果分布不均的情况还是没有消失，那就说明这很可能不是偶然事件。这个时候就要检查看看是不是工程或者实施层面出现了问题，由此造成了分布的不均匀。如果是工程层面出现了问题，那就要有针对性地去解决。
|
||||
|
||||
当然如果时间比较紧迫，没有时间重新跑实验和检查问题的原因，那么就以细分领域的结果为准，因为总体结果出现了辛普森悖论会变得不准确。不过这里因为是比较细分领域，会出现多重检验问题，要用我们上节课讲的方式做相应的处理。
|
||||
|
||||
好啦，现在你对辛普森悖论的理解肯定比之前更深刻了，那么我们接下来聊聊实验组和对照组的独立性这个问题。
|
||||
|
||||
实验组和对照组要相互独立
|
||||
|
||||
首先要说明的是，A/B测试有一个前提：*实验组和对照组的实验单位是要相互独立的，意思是说测试中各组实验单位的行为仅受本组体验的影响，不能受其他组的影响*。这个前提又叫做Stable Unit Treatment Value Assumption （SUTVA）。
|
||||
|
||||
针对实验组与对照组保持独立的问题，可能很多人都会觉得：这有什么好说的，都分成两个组了，肯定是各自独立的啊！在实践中还真不是这样的。我们在做A/B测试时，经常会在不知不觉中，因为实践中碰到了一些业务场景，导致检验两组的独立性被破坏了，而这就会破坏实验结果的准确性。
|
||||
|
||||
这还是因为A/B测试的本质是因果推断，所以只有在实验组和对照组相互独立，互不干扰的情况下，如果测试结果有显著的不同，那么才能把这个显著不同归因成实验组相对于对照组的变化，否则就很难建立准确的因果关系。
|
||||
|
||||
这么说你可能理解得还不够深刻，下面我就结合具体的业务场景，来看下在A/B测试中，两组实验单位的独立性都是如何被破坏的。
|
||||
|
||||
破坏两组独立性的表现形式有哪些？
|
||||
|
||||
在A/B测试中，两组的独立性被破坏主要表现在社交网络/通讯，共享经济以及共享资源这三类业务上，下面就让我来为你一一讲解。
|
||||
|
||||
第一类业务是社交网络/通讯类业务。
|
||||
|
||||
这类业务主要是用户之间的交流和信息交换，典型代表包括微信、微博、领英（Linkedin）、语音/视频通讯、电子邮件，等等。
|
||||
|
||||
在这类业务中，会存在网络效应。网络效应也就是网络中相邻的各个节点会相互影响。如果节点A在实验组，而它相邻的节点B在对照组，这时候两者就不是独立的。
|
||||
|
||||
我举个例子来帮助你理解。某社交App改进了信息流的推荐算法，通过推荐给用户更相关的内容来增加用户的互动，现在呢，我们想通过A/B测试来检测算法改进的效果。
|
||||
|
||||
|
||||
对照组：使用旧算法。
|
||||
实验组：使用改进后的新算法。
|
||||
评价指标：用户的平均使用时间。
|
||||
|
||||
|
||||
这样我们就可以做个假设：实验组的用户A体验到了改进后的新算法，看到了更多喜欢的内容，就花了更多的时间在这个App上，同时也在App中分享了更多有趣的内容，和朋友有了更多的互动。而他的好友用户B恰巧在对照组，那么当B看到A分享的内容和互动后，可能也会花更多的时间在App中浏览，并且参与到和A的互动当中，即使B并没有体验到改进后的算法。
|
||||
|
||||
这就是一个典型的A/B测试中网络效应的例子。在实验组的用户A会因为A/B测试中的变化而改变使用行为，并且这个行为上的改变会通过网络效应传递给在对照组的好友B，从而改变了用户B的使用行为，这就使得对照组也间接受到了实验组中新算法的影响。
|
||||
|
||||
这显然违背了我们在对照组给用户旧算法体验的实验设计，所以测试结果很可能是两组的指标都升高，造成结果不准确。
|
||||
|
||||
第二类业务是共享经济类业务。
|
||||
|
||||
共享经济类业务一般是双边市场（Two-Sided Market），即公司只提供交易平台，供给方和需求方均是用户。典型代表包括淘宝、滴滴、Uber、共享单车、共享租赁、爱彼迎(Airbnb)，等等。在这类业务中，由于供需关系是动态平衡的，一方的变化必然会引起另一方的变化，从而造成实验中两组相互影响。
|
||||
|
||||
比如说，我们在用A/B测试验证不同的优化是否有效时，往往只能一次验证一个优化。如果我们用A/B测试检验一个需求侧的优化，就要在需求侧分成实验组和对照组，这样实验组由于受到了优化，就会导致需求增加。那么在供给一定的情况下，更多的供给流向了实验组，就会造成对照组的供给减少，对照组的用户体验会变得更差，从而进一步打击对照组的需求。
|
||||
|
||||
我给你举个例子，假设某共享打车服务优化了用户在App中的打车流程，现在我们要通过A/B测试来验证这个优化是否有效果。
|
||||
|
||||
这里，实验组依然是使用优化流程，对照组则使用旧流程。实验组的用户因为流程的优化，打车更加方便，吸引了更多的司机。而由于司机的数量是稳定的，这就会导致可供对照组选择的司机减少，对照组的用户更难打到车，用户体验变差，那么通过A/B测试得出的流程优化的效果相比较对照组就会被高估。
|
||||
|
||||
第三类业务是共享资源类业务。
|
||||
|
||||
有些共享资源类业务有固定的资源或者预算，最常见的就是广告营销了。
|
||||
|
||||
在营销预算固定的情况下，我们用A/B测试来验证不同广告的效果。如果发现我们在实验组改进后的广告效果更好，点击率更高，那么这就会造成对照组的广告预算减少，从而影响到对照组的广告效果。因为线上的广告大部分是按点击次数付费的，所以这时候实验组广告花的钱就越多，在营销预算固定的情况下就会抢占对照组的预算。以此来看，通过A/B测试得出的实验组的广告效果就会被高估。
|
||||
|
||||
如何避免破坏两组的独立性？
|
||||
|
||||
那么，从我刚才讲的三类业务中你也能看出来，在实际业务场景中，由于违反两组实验单位独立性的表现形式和原因有很多，所以也会有不同的方法来解决，不过总的原则就是通过不同形式的分离来排除两组之间的干扰。具体而言，主要有以下4种分离方法：
|
||||
|
||||
第一种方法是从地理上进行分离。
|
||||
|
||||
这类方法主要适用于受到地理位置影响的线下服务，比如共享出行和共享租赁，这种本地化的服务一般不同的地域之间不会有干扰，这时候就可以按照不同的市场来分类。
|
||||
|
||||
最常用的是从城市这个维度进行分类。比如把北京的用户作为实验组，把上海的用户作为对照组，这样就可以排除两组间的干扰。需要注意的是，这里选取的不同市场要尽量相似，具有可比较性。我所说的相似，包括但不限于：该项业务在当地的发展情况，当地的经济状况，人口分布情况等等。
|
||||
|
||||
第二种方法是从资源上进行分离。
|
||||
|
||||
这类方法主要适用于由于共享资源造成的两组之间的干扰。具体操作就是A/B测试中每组的资源分配比例要和每组样本量的比例一致。比如在做广告营销中，如果通过A/B测试比较不同组的广告的效果，那么每组分配的广告预算的比例要和每组的样本量比例相等，比如两组样本量均分时，广告预算也要均分，这样两组之间的广告预算才能互不干扰。
|
||||
|
||||
第三种方法是从时间上进行分离。
|
||||
|
||||
这类方法主要适用于不易被用户察觉的变化上，比如算法的改进。这类方法的原理就是实验组和对照组都是同一组用户，在一段时间内实施变化，给他们实验组的体验，然后在另一段时间内不实施变化，给他们对照组的体验。
|
||||
|
||||
需要注意的是，这个时间段的单位可以是分钟、小时或者天，这样的话因为在同一时间内所有的实验单位都属于同一组，也就不存在不同组之间的干扰了。不过用这种方法时要特别注意用户的行为可能会在每天的不同时段，或者周中/周末有所波动。如果有周期性波动的话，就要在比较时尽量在不同周期的同一个阶段进行比较，比如只把周中和周中比较，周末和周末比较，但是不能把周中和周末比较。
|
||||
|
||||
第四种方法是通过聚类（Clustering）的方法进行分离。
|
||||
|
||||
这种方法主要适应于社交网络类业务。社交网络中用户之间的连接其实也不是均匀的，有远近亲疏，那就可以通过模型的方法，根据不同用户之间交流的程度来分离出不同集群cluster，每个cluster都会有不同的联系很紧密的用户，我们可以把每个cluster作为实验单位随机分组，这样就能从一定程度上减少不同组之间的干扰。
|
||||
|
||||
这种方法比较复杂，实施难度大，需要数据模型和工程团队的支持，有兴趣的话可以参考Google和Linkedin的经验。
|
||||
|
||||
小结
|
||||
|
||||
在这节课，我具体讲解了辛普森悖论和实验/对照组的独立性这两个常见的实验误区，以及在实践中的常用解决办法。相信通过这节课的学习，你能够在实践中及时发现并解决它们。
|
||||
|
||||
另外啊，我把这两节误区系列的内容呢也总结成了一张图，放在了文稿里，你可以保存下来，方便之后的复习与巩固。-
|
||||
|
||||
|
||||
到这里，我们的常见实验误区系列就告一段落了，通过这两节课的学习，你也体会到了我在讲课时不断说的，真实业务场景的复杂多变，潜在的各种各样的坑，这些误区和问题其实都是通过一次次A/B测试去积累试错得出的，所以就更加体现出了实践在A/B测试中的重要性。
|
||||
|
||||
如果你能在A/B测试中及时识别和解决这些常见的潜在的误区，不仅能为公司挽回潜在的损失，获得持续的增长，也是区别你和A/B测试新手的重要标志。
|
||||
|
||||
思考题
|
||||
|
||||
结合自己的经验，想一想过去有没有在A/B测试中遇到辛普森悖论和实验/对照组的独立性被破坏的情况？以及当时是如何处理的呢？
|
||||
|
||||
欢迎把你的思考和收获分享在留言区，我们一起学习、讨论。如果这两节的误区系列帮你解答了一些疑难问题，也欢迎你把课程分享给你的同事、好友。我们下节课再见。
|
||||
|
||||
|
||||
|
||||
|
||||
132
专栏/AB测试从0到1/12什么情况下不适合做A_B测试？.md
Normal file
132
专栏/AB测试从0到1/12什么情况下不适合做A_B测试？.md
Normal file
@@ -0,0 +1,132 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
12 什么情况下不适合做A_B测试？
|
||||
你好，我是博伟。
|
||||
|
||||
我们知道，A/B测试是帮助公司实现持续增长的利器。然而，没有任何一种方法能解决所有的问题，让我们一劳永逸。A/B测试也是如此。
|
||||
|
||||
A/B测试可以解决大部分因果推断的问题。但在有些因果推断的业务场景下，A/B测试就不适用了。这个时候我们就需要另辟蹊径，换一种思路和方法来解决问题。
|
||||
|
||||
所以今天这节课，我们就来学习A/B测试在什么情况下不适用，如果不适用的话，有哪些相应的解决方法。
|
||||
|
||||
A/B测试在什么情况下不适用？
|
||||
|
||||
在实践中主要有3种情况下A/B测试不适用：
|
||||
|
||||
当没有办法控制想要测试的变量时
|
||||
|
||||
A/B测试是控制变量实验，它的一个前提就是我们必须可以控制想要测试的变量的变化，这样才能人为地给实验组和对照组的实验单位不同的用户体验。但是在有些情况下，我们就没有办法控制变量的变化。
|
||||
|
||||
你可能会有疑问，有这样的变量吗？
|
||||
|
||||
当然是有的，主要是用户个人的选择。我们能够控制的变量其实都是在产品和业务端，但是对于用户个人的选择，我们其实是没有办法、也不可能去控制的。毕竟用户都是有自由意志的，所以我们所有的营销方法都是努力去说服用户，但最终选择权还是在用户手里。
|
||||
|
||||
比如我们想要了解用户从QQ音乐换到网易云音乐后使用情况的变化，那更换音乐App就是我们想要测试的变量。需要注意的是，我们无法帮助用户决定是否要更换音乐App的行为，因此我们也没有办法做到真正的随机分组。
|
||||
|
||||
你可能会说，我们可以通过营销，给用户优惠甚至付费让用户去更换音乐App，这在实践上是可行的，但是在实验中就会产生新的偏差。因为对于外界激励，不同的用户会有不同的反应，我们可能只研究了对外界激励有反应的用户，而忽略了对外界激励没有反应的用户。这样得到的实验结果是不准确的。
|
||||
|
||||
当有重大事件发布时
|
||||
|
||||
重大事件的发布，主要指的是新产品/业务的发布，或者涉及产品形象的一些改变，比如商标/代言人的改变，我们往往是不能进行A/B测试的。因为凡是重大事件的发布会，都想要让尽可能多的用户知道，并且也花了大量营销的钱。在当下这个信息流通极度发达的互联网时代，不存在我公开发布了一个新品，只有一小部分用户知道这种情况，即使是中小企业也是如此。
|
||||
|
||||
比如苹果公司每年的新品发布会，并不会、也不可能事先去做大规模的用户A/B测试来看看新品的效果如何，然后再决定是否要发布。
|
||||
|
||||
再比如，一个公司如果想要改变自己的商标，就不能事先把用户进行分组，让实验组的用户接触新商标，对照组的用户接触旧商标。因为商标是一个公司或者产品的形象，你想想看，如果把用户进行分组，就会出现同一个产品同时有多个商标在市场流通的情况，那就会对用户造成困惑，而且也不利于产品形象的打造。
|
||||
|
||||
当用户数量很少时
|
||||
|
||||
这个其实很好理解，如果我们没有一定的流量能让我们在短时间内达到所需要的样本量的情况下，那么A/B测试也就不再适用了，不过这种情况其实在大数据的互联网行业中比较少见，这里我们就不展开讲解了。
|
||||
|
||||
当A/B测试不适用时有哪些替代方法？
|
||||
|
||||
当A/B测试不适用时，我们通常会选用非实验的因果推断方法和用户研究两类方法来替代，让你在想做因果推断却又不能进行A/B测试时，有新的思路和方法。
|
||||
|
||||
倾向评分匹配（Propensity Score Matching）
|
||||
|
||||
非实验的因果推断方法，又叫观察性研究，这其中最常用的就是倾向评分匹配（Propensity Score Matching），简称PSM。我在第9节课已经介绍了PSM，它的本质就是在历史数据中，通过模型的方法，人为地（而不是像实验那样随机地）构建出相似的实验组和对照组，最后再对两组进行比较。
|
||||
|
||||
这里我会通过一个音乐App的案例，来详细讲解下用PSM替代A/B测试时，是怎么在因果推断中应用的。
|
||||
|
||||
这款音乐App是付费订阅模式，有两种订阅方式：
|
||||
|
||||
|
||||
个人订阅每月10块钱，只能供一个人使用。
|
||||
家庭订阅每月20块钱，最多可以5人同时使用。
|
||||
|
||||
|
||||
此外，不管是个人订阅，还是家庭订阅，只要是新用户，都会有3个月的免费试用期。
|
||||
|
||||
数据分析师通过大量的数据分析发现，家庭订阅比个人订阅用户的长期留存率（即续订率）更高。仔细想想其实也很好理解，家庭订阅可以和他人分享，所以每个订阅中的用户会更多一些，一般不止一个。而订阅中的用户越多，就越不容易取消这个订阅，所以长期留存率会越高。
|
||||
|
||||
于是这位数据分析师就根据这个分析发现，向营销经理推荐：可以向个人订阅的用户发广告，宣传家庭订阅的好处，鼓励他们升级到家庭订阅。
|
||||
|
||||
不过营销经理却提出了不同的意见：选择家庭订阅的用户和选择个人订阅的用户，在本质上就是不同的。比如他们的用户画像、使用行为等，都存在很大差异。也就是说，并不是升级本身导致了用户留存的提高，而是由于他们本来就是不同的用户，所以留存才不同。
|
||||
|
||||
为了验证营销经理的想法，数据分析师详细地分析了两种订阅方式的用户画像和使用行为，发现果然如营销经理所说，从个人订阅升级到家庭订阅的用户和没有升级的用户差别很大，比如升级的用户平均年龄更大，使用的时间更长等等。-
|
||||
|
||||
|
||||
看到这里，你大概已经知道了，个人订阅升级到家庭订阅是否会提升用户留存率，其实是一个因果推断的问题。
|
||||
|
||||
数据分析师的观点是“从个人订阅升级到家庭订阅”这个原因，可以导致“用户留存提升”这个结果。
|
||||
|
||||
但是营销经理的意见是影响用户留存的因素有很多，在用户升级这个情境下并不能排除其他因素，因为升级是用户自己的选择，那么很有可能升级和不升级的用户本来就是两类不同的人，所以在其他因素不相似的情况下就不能只比较升级这一个因素。
|
||||
|
||||
两者的观点看起来都很合理，那我们该通过什么方法来验证谁对谁错呢？
|
||||
|
||||
验证因果推断的最好方法当然是做A/B测试了！但是在这个业务情景下，由于是否升级这个变化因素是用户的自主选择，我们并不能控制，所以就并不能做随机分配的实验。那么这个时候，非实验的因果推断方法PSM就可以派上用场啦。具体方法如下。
|
||||
|
||||
首先，我们从历史数据中选取在同一个时间范围内开始个人订阅的试用期用户。
|
||||
|
||||
在三个月试用期结束后还在付费的用户中，有的依旧是个人订阅，有的则升级成了家庭订阅。而在这自然形成的两类用户中，我们通过PSM的方法对用户的画像和使用行为等因素进行匹配，在没有升级的用户中选出和升级用户相似的用户，然后在这些相似用户中比较长期的用户留存：-
|
||||
-
|
||||
接着，进行完PSM后呢，我们再来比较下个人订阅和家庭订阅各自的用户画像和使用行为。-
|
||||
-
|
||||
从数据中我们可以发现，经过PSM处理后的没有升级的用户和升级的用户，在各个特征上都已经非常相似了，那么这个时候我们就可以进行比较了。当我们比较时，因为已经控制了其他特征相似，两组只有“是否升级”这一项不同，所以如果用户留存有变化，那就说明是升级这个变化因素造成的。
|
||||
|
||||
最后，我们来看一下最终的比较结果。下图中的纵轴是用户留存率，横轴是从试用期开始时的月份，因为试用期是3个月，且试用期内不存在续费问题，所以留存率就是100%， 那我们就从第4个月开始算用户留存率。-
|
||||
-
|
||||
从图中可以看到，如果我们不做PSM的话，就像最开始数据分析师发现的那样，个人订阅升级到家庭订阅能够使一年的留存率提升28%， 但这是在没有剔除其他因素的情况下，所以28%这个结果就不够准确（营销经理的观点）。
|
||||
|
||||
那么经过PSM处理后，我们得到了和升级用户相似的非升级用户，结果发现升级确实能提升用户留存，不过只能提高13%，那就说明只有13%的用户留存率的提升可以归因于用户升级。
|
||||
|
||||
这里我们通过PSM，在剔除了其他因素的影响之后，模拟出了一个控制变量实验，从而确定了个人订阅升级到家庭订阅对用户留存所带来的准确影响。
|
||||
|
||||
用户研究
|
||||
|
||||
用户研究适用于A/B测试无法进行时，比如新产品/业务发布前的测评，我们就可以通过直接或间接的方式，和用户交流沟通来获取信息，从而判断相应的变化会对用户产生什么影响。
|
||||
|
||||
用户研究的方法有很多种，我们今天主要来聊一聊常用的几种：深度用户体验研究（Deep User Experience Research），焦点小组（Focus Group）和调查问卷（Survey）。
|
||||
|
||||
深度用户体验研究，指的是通过选取几个潜在用户进行深度的信息提取，比如通过用户眼球的运动来追踪用户的选择过程的眼动研究，或者用户自己记录的日记研究。
|
||||
|
||||
|
||||
眼动研究能让我们了解到用户的正常使用流程是什么样的，在哪些阶段会有卡顿或者退出。
|
||||
日记研究通过用户自己记录的使用情况和意向，来了解他们的反馈。
|
||||
|
||||
|
||||
焦点小组是有引导的小组讨论，由主持人把潜在的用户组织起来，引导大家讨论不同的话题，然后根据大家在讨论中发表的不同意见，综合得出反馈意见。从小组讨论这个形式就可以看出，每次焦点小组能够组织的用户一般要比深度用户体验研究的用户数量要多，但是比调查问卷的用户数量要少。
|
||||
|
||||
调查问卷就是通过事先设计好想要了解的问题，可以是选择题或者开放式的问题，比如对新品/新业务的想法和感受。然后把这些问题做成问卷发放给潜在的用户。交流方式可以是面对面、线上或者是电话等等，然后根据不同用户的回答结果，统计出大致的反馈结果。-
|
||||
-
|
||||
从图中可以看出，从深度的用户体验研究，到焦点小组，再到调查问卷，虽然参与的用户越来越多，但是团队从每个用户身上获得的信息深度会越来越浅，所以选择何种方法也取决于你能招募到多少潜在用户，有没有相应的条件与设备（比如眼动研究需要眼动仪来完成），还有想要得到的信息深度。
|
||||
|
||||
小结
|
||||
|
||||
今天这节课我们讲解了A/B测试的局限性，通过案例介绍了非实验的因果推断方法-倾向评分匹配（PSM），也带你简单了解了用户研究的相关方法。实践中出现较多的还是我们没有办法控制的用户选择这种变量，主要会用到PSM这种非实验的因果推断方法。那么用户研究在实践中不仅可以用于新产品/业务的测评，还可以用于产生新指标的想法（比如我在第3节课中讲到的定性+定量相结合的方法来确定指标）。
|
||||
|
||||
那么从开头到今天这节课呢，我们的专栏讲解了A/B测试的统计原理，标准的流程以及实践中各种常见问题及解决方法。说到应用这些经验和方法论呢，工作场景自然是最佳场所，不过还有另一个实践的好机会，那就是在面试中。
|
||||
|
||||
那么在接下来的两节课，我就会带你去过一遍面试中常考的A/B测试问题。同时，我也建议你先梳理下自己面试时曾被问到的那些问题，以及自己当时自己是怎么回答的。这样，我们在学习后面两讲内容的时候，也会更有针对性。
|
||||
|
||||
思考题
|
||||
|
||||
结合自己的经验，想一想你有没有见到过或经历过想进行因果推断相关的分析但是A/B测试却不适用的情况？详细说一说原因和结果。
|
||||
|
||||
欢迎你把对本节课的思考和想法分享在留言区，我会在第一时间给你反馈。
|
||||
|
||||
|
||||
|
||||
|
||||
177
专栏/AB测试从0到1/13融会贯通：A_B测试面试必知必会（上）.md
Normal file
177
专栏/AB测试从0到1/13融会贯通：A_B测试面试必知必会（上）.md
Normal file
@@ -0,0 +1,177 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
13 融会贯通：A_B测试面试必知必会（上）
|
||||
你好，我是博伟。
|
||||
|
||||
在接下来的两节课呢，我们换换脑子，来聊一个相对轻松点的话题：与A/B测试相关的面试应用。
|
||||
|
||||
近几年随着A/B测试在互联网、电商、广告等各个行业的广泛应用，已经成为数据、产品、增长等相关职位面试的一个重要组成部分。所以我就根据自己多年做面试官的经验，帮你总结了常见的A/B测试相关面试考点，一方面我会通过典型真题来讲解面试思路，另一方面也会把我在面试中的一些沉淀与思考分享出来。
|
||||
|
||||
另外我还想强调的是，这两节课虽然是在讲面试题，但其实也是在以另一种方式考查你对所学知识的灵活运用。面试中考察的不仅是你对知识的掌握，更关注你在工作场景中要怎么运用。所以希望你能通过这两节面试课的学习，既能学会拆解题目，提高面试能力，同时也能把我们学过的知识融会贯通。
|
||||
|
||||
面试题目是无穷的，但考点是有限的。我把相关的考点总结成了一张图，方便你着重复习。接下来我们就开始正式的面试讲解吧。-
|
||||
|
||||
|
||||
面试应用一
|
||||
|
||||
某共享出行公司改进了司机使用App的用户界面，希望能给司机更好的用户体验，在提高司机使用App频率的同时，也能提高司机的收入。那么问题就是：请你设计一个A/B测试，来验证新的司机App是否比旧的司机App体验要好。
|
||||
|
||||
考点：
|
||||
|
||||
|
||||
A/B测试的流程。
|
||||
实验组/对照组的独立性。
|
||||
|
||||
|
||||
解题思路：
|
||||
|
||||
很多同学遇到这个面试题，首先想到的就是串一遍A/B测试的流程，于是就按照以下流程开始回答。
|
||||
|
||||
确定目标和假设 —> 确定指标（说出评价指标和潜在的护栏指标）—> 确定实验单位—> 随机分组（一般为均分） —> 确定样本量（这里注意，强调需要已知哪些统计量来确定样本量）—> 实施测试 —> 合理性检验（要说出具体的检验都有哪些）—> 分析结果（注意说明P值法和置信区间法的判断标准）
|
||||
|
||||
如果你只回答了设计流程这一点，可能仅仅是个及格分，因为题中还设置了至少1个隐藏的坑点，这也恰恰就能拉开你与其他面试者的距离。
|
||||
|
||||
首先要注意，在回答流程时一定要结合题目的具体内容展开讲解，否则就是照本宣科，会给面试官留下不能活学活用的印象。如果你不知道怎么回答比较好，可以参照我在第8节课串讲案例的思路和方法。
|
||||
|
||||
不过这道题最大的坑点还不在这儿，你需要再细心点儿。仔细看“共享出行”这个具体情境，如果你对第11节课中两组独立性这个知识点掌握得足够牢固，就会发现面试官在这道题中，想考查你的绝不是串讲一遍流程这么简单。
|
||||
|
||||
面试现场也是工作的实际场景，那你就需要具体情境具体分析，洞察出设计实验时需要保持实验组和对照组的独立性。
|
||||
|
||||
我们来通过一个例子深度剖析一下。
|
||||
|
||||
假设我们选取在上海使用该共享出行的司机，把他们随机分成实验组和对照组，每组各占50%。其中在实验组，司机使用新的司机App，对照组则使用旧的司机App。
|
||||
|
||||
我们先来看实验组： 如果新App的确提升了司机的用户体验，司机的使用频率提高，这意味着实验组的订单量就会增加。因为订单总量（需求）是一定，这样就会导致对照组的订单量减少。
|
||||
|
||||
与此相反的是，如果新App降低了司机的用户体验，司机使用App的频率降低，那么实验组的订单量就会减少，对照组的订单量则会增加。
|
||||
|
||||
这时你就会发现：实验组和对照组不是独立的，而是相互影响的。这就违背了A/B测试中实验组和对照组必须是相互独立的前提假设，从而导致实验结果不准确。
|
||||
|
||||
在题目中的场景下，比较好的解决方法是在不同的城市进行测试：我们找到两个相似的城市A和B（相似的目的是使两组具有可比性，比如业务在当地的发展程度、经济发展程度、人们的出行习惯等），实验组是城市A中的司机使用新App， 对照组是城市B中的司机使用旧App。这样的话两组就不会相互影响。
|
||||
|
||||
所以针对这道题，完整且正确的回答方式应该是：先指出两组独立性被破坏的问题，通过举例分析说明两组是相互影响的；然后提出你的解决方案；最后结合实际情境串讲流程。
|
||||
|
||||
其实啊，如果你是个高手，就应该看出题中还有一个隐藏的考点：学习效应。
|
||||
|
||||
因为题目中是测试新的用户界面，所以还可能会有老用户的学习效应：新奇效应或改变厌恶。关于这个考点，你在这里简单提及，说明识别及解决方法即可，不需要长篇大论再进行展开。因为这道题考察的核心重点依旧是两组的独立性和设计流程，但是如果你能留心到潜在的学习效应问题这个坑，这就相当于你在优秀的回答之外，还给了面试官一个惊喜，证明你有填坑的能力。
|
||||
|
||||
面试应用二
|
||||
|
||||
在过去的实践中，你有没有经历过这种情况：A/B测试虽然得到了显著的结果（比如P值小于5%），但最终还是决定不在业务/产品中实施测试中的变化。原因是什么呢？请举例说明。
|
||||
|
||||
考点：实施A/B测试中的变化要考虑的因素
|
||||
|
||||
解题思路：
|
||||
|
||||
这道题很简短，乍看上去会觉得很容易，往往这个时候你就要小心谨慎了。仔细想想，面试官想通过这道题来考查什么知识点呢？考察你的什么能力呢？
|
||||
|
||||
在知识点上，面试官主要考查的是：在实践中实施A/B测试中的变化时，需要考虑的因素有哪些。
|
||||
|
||||
这个问题其实是非常直接的，你很容易知道面试官在考察什么知识点。不过我想强调的是这类问题在面试中还有很多的变体，你需要在不同的变体中识别出本质问题。
|
||||
|
||||
|
||||
核心问题：面试官会从结论出发（最终没有实施变化），问你可能会有哪些原因。
|
||||
变体1：面试官会给你测试结果的数据，数据中的P值虽然小于5%，但是十分接近5%，比如4%。说明两组变量间的不同其实非常小，对实际业务的影响十分有限。
|
||||
变体2：面试官会直接问你，实施A/B测试中变化的成本是什么。
|
||||
|
||||
|
||||
无论怎么变化，归根结底都是一句话：结果是统计显著的，但是业务并不显著，因此在实践中没有实施变化。
|
||||
|
||||
在实践中，统计上的显著结果只是最终实施变化的原因之一，另一个方面还要考虑到实施变化的成本和收益。收益的话我们可以根据显著结果的差值来估算，但是就成本而言，我们需要考虑的因素是多方面的，就像我在第7节课中讲的，需要估算业务上的显著性。
|
||||
|
||||
所以在回答这类题目时，结合案例围绕着以上这些成本展开讲解，提出结果是统计显著，但是业务上不显著，所以最后才没有在实践中实施变化。
|
||||
|
||||
具体来说，在实践中实施变化主要有以下几种成本。
|
||||
|
||||
人力成本
|
||||
|
||||
指的是要实施变化的相关人员的时间成本，比如工程师需要花时间去实施具体的变化，编写相关代码。产品经理需要花时间去收集整理新的要求，组织相关会议，编写文档。如果变化会引起用户困惑的话，那么客服人员还要花时间去给用户答疑解惑。
|
||||
|
||||
机会成本
|
||||
|
||||
在实践中，时间和资源在业务/产品的不断迭代当中是永远不够用的，请你想象一个场景：在新版本上线前，如果同时有A和B两个变化都具有统计显著性（P值均小于5%），但我们的时间和资源有限，在上线前只能实施一个变化，那这个时候肯定会选择对业务影响较大的变化。
|
||||
|
||||
那你就会问了，当这两个的P值都小于5%时，我该怎么比较哪个变化对业务产生的影响更大呢？
|
||||
|
||||
具体来说有两种方法。
|
||||
|
||||
第一种方法就是估算变化带来的业务影响。这种方法适用于不同变化有着不同的评价指标，或者不同的受众范围。
|
||||
|
||||
比如变化A使转化率提升了2%，每年可以多带来10万的新用户。变化B使留存率提高了0.5%，每年可以多留住5万的现有用户。此时我们就要衡量增加10万新用户和留住5万现有用户的价值哪个更大（比如可以通过数据分析或者建模的方式确定新用户和现有用户的平均价值）。
|
||||
|
||||
当然这也和所处阶段的业务目标有很大关系，你需要看当时的业务重点是拉新还是留存。一旦我们量化估算出变化带来的业务影响，就可以决定该优先实施哪个变化了。
|
||||
|
||||
第二种方法是计算效应值（Effect Size）。这种方法适用于变化相似且评价指标相同时。
|
||||
|
||||
比如改进推荐算法的实验，大都以点击率作为评价指标。那么现在有新算法A和新算法B，和老算法相比都有提升，那么这时就要计算每个实验的效应值：
|
||||
|
||||
-
|
||||
效应值在统计中是用来表示指标变化的幅度的，效应值越大，就说明两组指标越不同。
|
||||
|
||||
如果我们计算得到的新算法A的效应值比新算法B的大，就说明A的改进效果幅度更大，影响也更大，那就可以决定优先实施A变化了。
|
||||
|
||||
计算效应值其实也是估算变化带来的影响，不过因为这些变化都有相同的评价指标，所以我们只需要算出效应值来进行比较即可。
|
||||
|
||||
代码成本
|
||||
|
||||
实施变化一般需要代码的改动，这种改动会潜在地增加代码出错的概率，同时随着代码库越来越复杂，也会增加未来代码改动的成本。
|
||||
|
||||
面试应用三
|
||||
|
||||
我们对公司网站进行了改版，想要以此来提升用户参与度。通过A/B测试发现，新版本的用户参与度确实显著提升了，所以我们随后就对所有用户显示了新版网站。但是过了一段时间后，用户参与度又回到了之前的水平。假设，这个A/B测试本身没有技术上或者统计计算上的问题。你觉得导致这种情况的原因会是什么呢？又该怎么解决呢？
|
||||
|
||||
考点：学习效应
|
||||
|
||||
解题思路：
|
||||
|
||||
这道题在知识点上的难度并不高，主要考察的是学习效应的问题。不过你要是只回答了这一个原因，这其实是大多数面试者都容易想到的，也仅仅只是一个合格的分数。
|
||||
|
||||
我先把自己更推荐的回答方式写出来，然后再带你仔细分析这道面试题。
|
||||
|
||||
比较推荐的回答方式是：先列举导致这种情况可能的原因有哪些，再结合题目的具体场景进行一一排除，最后得出自己的结论，给出解决方法。
|
||||
|
||||
为什么要这么回答呢？主要是因为相比较仅仅回答一个原因，或者直接给出解决方法，这种回答方式更能体现你对问题的全面理解。我在之前的课程中也强调过，知道为什么会出现这个问题，并发现问题，有时候甚至比解决问题还要重要。所以面试官在这里重点想要考察的，就是你对出现问题的原因的探究。
|
||||
|
||||
变化实施后的实际效果和A/B测试的结果不一致，其中的原因有很多种，最常见的原因主要是两个：
|
||||
|
||||
|
||||
实施A/B测试中出现的技术Bug。
|
||||
在计算测试结果时出现错误（比如还没到足够的样本量就去计算结果）。
|
||||
|
||||
|
||||
接下来我们进行一一排除。
|
||||
|
||||
首先，题目中明确说了，技术上和统计计算上都没有问题，那接下来就要排除A/B测试常见的误区。
|
||||
|
||||
其次，由于题目中的场景并不是社交网络或者像共享经济的双边市场，实验组和对照组不会相互干扰，所以也不存在实验/对照组独立性被破坏的情况。
|
||||
|
||||
接着，从测试本身的设置和对结果的描述来看，没有细分分析或者多个实验组，又不会有多重假设问题或者辛普森悖论。
|
||||
|
||||
最后，对于网站不同版本这种问题，其实最常见的问题是学习效应，就像我刚才分析的那样，把其他常见的原因都排除了，那么其实考察的知识点就是学习效应。考察学习效应的面试题形式有很多种，有的会直接问你学习效应，有的就会像是本题中，给你一个具体的场景，让你判断。
|
||||
|
||||
根据题目描述的情况，应该是学习效应中的新奇效应：用户刚开始对于新版本很好奇，所以参与度会上升。但随着时间的推移，慢慢又会回归到正常平均水平。
|
||||
|
||||
至于如何识别和解决学习效应，如果你还不能顺利回答出来，那就得再回去复习第10节课的内容了。
|
||||
|
||||
所以你看，在面试中，面试官考察你的不仅是知识点，更重要的是你对问题的发散理解，以及思考问题的方式。
|
||||
|
||||
小结
|
||||
|
||||
在这节课里，我主要讲了3道面试题，通过我的详细分析你也能够发现，拆解题目是一项很重要的能力。
|
||||
|
||||
很多人在面试前都会去刷题，刷题固然重要，但是在面试这种高压场景下，可能回出现大脑短暂空白的情况。其实面试题目也是有套路的，就像搏击中的双方，你需要猜测对方可能会出什么招式，如果你能在对方出招前反应出他的下一步动作，哪怕是一秒钟，就有机会制胜对方。所以相对于海量刷题，学会拆解题目就显得更重要了。
|
||||
|
||||
相信你通过今天的学习，对于A/B测试相关面试的形式和考点有了初步的了解，你一定还意犹未尽，没关系，我们下节课接着来剖析典型面试题及考点。
|
||||
|
||||
思考题
|
||||
|
||||
你有遇到过什么有意思的A/B测试的面试题吗？或者是有什么好的面试经验吗？欢迎分享出来，我们一起探讨。
|
||||
|
||||
欢迎分享出来，我们一起交流、探讨。也欢迎你把本节课推荐给你的朋友，一起进步、成长。
|
||||
|
||||
|
||||
|
||||
|
||||
139
专栏/AB测试从0到1/14举一反三：A_B测试面试必知必会（下）.md
Normal file
139
专栏/AB测试从0到1/14举一反三：A_B测试面试必知必会（下）.md
Normal file
@@ -0,0 +1,139 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
14 举一反三：A_B测试面试必知必会（下）
|
||||
你好，我是博伟。
|
||||
|
||||
今天这节面试课，在学习的过程中你会发现考察的知识点都已经掌握得差不多了。不过我想要强调的是，知识是你业务精进的基础，也是面试时考察的一个重要方面。但更为关键的，是你能够把知识举一反三，知道在不同的场景中如何应用，这也正是把知识转化为解决问题的能力，是你的面试竞争力。
|
||||
|
||||
好了，那我们就趁热打铁，继续来讲面试这个主题，帮你夯实基础，做到面试不慌！
|
||||
|
||||
面试应用一
|
||||
|
||||
假设你现在负责跑一个A/B测试，根据样本量计算测试需要跑2周。但是业务上的同事会每天关注测试结果，一周之后就观察到显著结果了，这时候他觉得既然结果已经显著了，就想让你停止测试，然后实施测试中的变化。由于业务上的同事对统计不是很熟悉，所以你该怎么用直白的语言来给他解释现在还不能停止实验呢？
|
||||
|
||||
考点：
|
||||
|
||||
|
||||
多重检验问题
|
||||
统计原理的通俗解释
|
||||
|
||||
|
||||
解题思路：
|
||||
|
||||
其实这道题，我在第7节讲分析测试结果时就给出了一个类似的实践背景，由于在样本量还没有达到规定前不断查看结果，就会造成多重检验问题。而一旦出现多重检验，我们之前花费的功夫就会功亏一篑。所以在这道题中，你需要首先指出多重检验问题，接着说明出现的原因，以及可能造成的具体后果（得到假阳性的概率增大，实验结果不准确）。
|
||||
|
||||
你也能看出来，如果只是考多重检验问题，那就太简单了。斟酌一下题目中的问题，就能知道面试官想要考察的是其实是你的表达与理解能力，也就是说你该怎么用通俗直白的语言来给业务同事解释复杂难懂的统计概念和原理。在实际工作中，很多时候需要和没有统计背景的同事去沟通交流A/B测试的相关内容，所以面试官也非常喜欢考察面试者这方面的能力。
|
||||
|
||||
不仅如此，这其实也是在变相考察面试者是不是真正内化了相关统计知识。毕竟如果只是死记硬背概念，肯定是不能在实践中灵活运用这些原理的，更别说再把这些原理用直白的语言去讲给没有统计背景的人听。
|
||||
|
||||
你可能会问，通俗直白的语言到底是什么呢？其实也很简单，就是说人话。我的经验就是“一个避免，两个多用”。
|
||||
|
||||
一个避免，指的是尽量避免使用统计术语（P值、第一类错误、假设检验等）。
|
||||
|
||||
一方面，专业统计术语会加大你们沟通的时间成本和沟通障碍。业务同事是不懂这些术语的，当你用专业术语去向他说明时，你就需要花更多的时间来解释术语，不仅对方难以理解，而且你们的沟通目的也没有达到。
|
||||
|
||||
另一方面，仔细想想，你为什么要去给业务同事解释呢？主要就是为了告诉对方，现在还不能停止实验。所以啊，说清楚为什么不能在此时停止实验就可以了，术语能少则少。
|
||||
|
||||
两个多用指的是多打比方、多举例子。尤其是通过日常生活中的事物来打比方、举例子，这会是非常好的一种方式。
|
||||
|
||||
比如，A/B测试其实是比较两组的表现，既然有比较，那就有好坏输赢的概念。那你就可以选择生活中任何有好坏输赢结果，但是每次发生结果都有可能不同的事件来打比方。
|
||||
|
||||
我比较喜欢拿体育比赛来打比方，比如篮球，就和A/B测试非常类似。每场NBA篮球比赛都会有事先规定的时间：48分钟。而且篮球比赛的结果是以比赛结束后的最终结果为准。如果在比赛结束前的任何时间查看比分，任何一方都有可能领先，但是我们并不会以比赛中间的结果作为最终结果。
|
||||
|
||||
同理，回到A/B测试当中来，如果我们还没有到达规定的时间，看到显著的结果就宣布实验已经完成，从而停止实验，这就和在比赛中看到一方领先就宣布领先的一方获胜、比赛结束是一样的道理。
|
||||
|
||||
再回到我们的面试场景中，多重检验问题在工作中其实是很常见的。尤其是在业务上的同事没有很强的统计背景的情况下，可能只是依靠P值来做决定，不会考虑样本量是否充足这个前提，所以用通俗的语言来解释这些统计原理尤为重要。
|
||||
|
||||
面试应用二
|
||||
|
||||
某产品现在想改变商标，所以想衡量新商标对业务的影响，该如何做？
|
||||
|
||||
考点：-
|
||||
A/B测试的适用范围及替代方法
|
||||
|
||||
解题思路：
|
||||
|
||||
如果你对第12节课讲“什么情况下不适合用A/B测试”的知识足够熟悉，就知道这里并不能用A/B测试来衡量商标改变的影响性。我讲过，“当有重大事件发布时”，是不适合去做A/B测试的，商标即是其中之一。毕竟商标代表了产品和公司的形象，如果一个产品有多个商标同时在市场流通，就会给用户带来困扰，从而会对产品形象有不利的影响。
|
||||
|
||||
还记得A/B测试的两种替代方法吗？分别是非实验的因果推断方法和用户研究。不过啊，在这个情境下非实验的因果推断方法也行不通，因为这个商标是全新的，并没有历史的相关数据。所以用户研究就是我们最终选定的方法。
|
||||
|
||||
在这个案例中，我们只需要收集用户对新商标的看法如何，所以就需要的样本尽可能大一些，这样意见才有代表性，但是并不会涉及到用户体验等很有深度的问题。那么我们就可以选用调查问卷的方式来收集用户反馈，从而给我们一些方向性的指导。让我们知道相较于现有的商标，用户对新商标偏正面反馈，还是更偏负面反馈。
|
||||
|
||||
如果从调查问卷中得到总体正面的反馈后，团队决定在市场中废除现有商标，推出新商标。这时候就可以来衡量更换商标后的影响，相对于比较推出新商标前后产品的北极星指标的变化来计算出差值去推断出新商标影响，一个更加准确的方法是建立模型。
|
||||
|
||||
我们可以用历史数据建立起对北极星指标的时间序列模型，用推出新商标前的数据去训练这个模型，它也可以预测出没有新商标的北极星指标的走势，然后我们可以把模型的预测数据和推出新商标后的实际数据进行比较，从两者的差值来推断出新商标的影响。
|
||||
|
||||
总结一下，这道题的答题思路即：说明题中场景下A/B测试不适用及其原因，然后再给出用户研究和模型的办法来作为替代解决方法。
|
||||
|
||||
面试应用三
|
||||
|
||||
某社交网站准备给用户推荐好友，在首页的右上角推出“你可能认识的人”这个新功能，怎么设计A/B测试才能真正衡量这个功能底层的推荐算法的效果呢？假设这里没有网络效应。
|
||||
|
||||
考点：-
|
||||
A/B测试分组设计
|
||||
|
||||
解题思路：
|
||||
|
||||
当拿到题目一看到社交网站，你会立马想到网络效应，但是读完题发现这里假设没有网络效应。
|
||||
|
||||
你可能会想，想要推出一个新功能，而且还不考虑网络效应，那肯定就是常规的A/B测试设计了呗。所以就把用户随机均分成两组，对照组的用户没有“你可能认识的人”这个新功能，实验组的用户有这个新功能。最后比较两组的指标，来确定推荐新功能的推荐算法的效果如何。
|
||||
|
||||
你看，这没有什么难的！如果真的这么想，那你就在不知不觉中掉进面试官给你设的坑了。
|
||||
|
||||
我们再仔细读题中的场景描述，就会发现这个新功能是在页面的右上角，这意味着增加这个新功能还涉及到用户交互界面的改变。
|
||||
|
||||
如果按照我们刚才所说的实验分组进行设计，把实验组和对照组相比，其实是既增加了推荐算法，又改变了交互界面，是同时改变了两个因素。以此来看，即使实验组的指标相对于对照组有所提升，我们也无法确定究竟是哪个因素在起作用。
|
||||
|
||||
所以这道题的关键点就是如何分离这两个潜在的影响因素。在实践中，解决的方法一般是设计多个实验组，每个实验组只改变一个因素，同时共用一个对照组，也就是改变前的状态。
|
||||
|
||||
是不是觉得这个方法有点熟悉呢？没错儿，这就是我在第9节课中提到的A/B/n测试。不过这个案例的情况比较特殊，因为要增加推荐算法的话，肯定会改变交互界面，也就是说其中一个因素必须依赖另一个因素，不能单独存在。
|
||||
|
||||
但是如果反过来想，其实改变交互界面并不一定要增加推荐算法，所以我们可以把各个分组设计成递进关系：
|
||||
|
||||
|
||||
对照组：改变前的原始版本。
|
||||
实验组A: 增加“你可能认识的人”这个新功能， 其中推荐的内容随机产生。
|
||||
实验组B: 增加“你可能认识的人”这个新功能， 其中推荐的内容由推荐算法产生。
|
||||
|
||||
|
||||
我们可以发现，实验组A相对于对照组只是改变了交互界面，因为它的推荐内容是随机产生的。而实验组B相对于实验组A，则是只增加了推荐算法，而二者的交互界面是相同的。这样我们就可以通过比较对照组和实验组A来衡量改变交互界面是否有影响，比较实验组A和实验组B来判断新功能的底层推荐算法是否有效果。
|
||||
|
||||
面试应用四
|
||||
|
||||
某社交平台开发出了一个新的交互界面，希望能增加用户的点赞次数。团队通过把一部分用户随机分组进行A/B测试，发现用了新界面的实验组的用户平均点赞次数，比对照组高出了5%，结果也是显著的。那么如果把新界面推广给所有用户，你认为用户的平均点赞次数会提升多少呢？是大于5%还是小于5%？为什么呢？在这个案例中，我们假设没有学习效应的影响。
|
||||
|
||||
考点：-
|
||||
网络效应
|
||||
|
||||
解题思路：
|
||||
|
||||
看到“社交平台”就要想到“网络效应”，经过前面的学习，你应该对这一点形成肌肉记忆。
|
||||
|
||||
这道题其实难度不大，考察的是网络效应及其形成原因。不过我想通过这道题，一方面让你清楚网络效应的具体场景，另一方面，也想让你知道在有网络效应的影响下，社交平台开发新交互界面后的真实提升效果和实验结果之间的关系。
|
||||
|
||||
在没有学习效应的情况下，因为是社交平台，存在网络效应，所以随机分组并不能保证实验组和对照组的独立性，意味着两组的独立性被破坏了。
|
||||
|
||||
具体而言，即：如果实验组的用户A因为用了的新界面点赞了一个内容，那么这个被点赞的内容也会被A的好友，在对照组的B看到，B也有可能点赞这个内容。所以这个新界面改动既影响了实验组，还会通过网络效应影响对照组，即实验组的用户平均点赞次数提升，对照组的也会提升。
|
||||
|
||||
以此来看，这里的5%的提升其实是受到网络效应影响后的结果，真实的提升效果应该会更大（即只有实验组的指标提升而对照组的指标不变），即大于5%。
|
||||
|
||||
所以当我们把这个新的交互界面推广到所有用户，也就是在没有对照组的情况下，那么和旧版本相比，真实的提升效果应该是大于5%的。
|
||||
|
||||
小结
|
||||
|
||||
我们两节课的A/B测试的面试之旅，到这里也就告一段落了。你应该也能发现，这些常见的考点我们在前面的课程中都有讲解过，只要你认真学习了专栏的内容，是不会有太大的问题的。
|
||||
|
||||
在最后呢，我还想强调一点。我们在这两节课讲的面试题大都是题目中直接提到A/B测试的，在面试中，A/B测试的考查形式是多种多样的。有时题目中并没有明确提到A/B测试，但是A/B测试是这些题目中答案的有机组成部分，比如让你衡量产品新功能的好坏，是不是应该推进这个产品变化这种问题，你的答案中肯定会有要如何定义目标和指标去表征新功能的影响，如何设计A/B测试去验证新功能是否有效。总之，只要让你进行因果推断，需要量化改变带来的影响时，A/B测试都是你的好帮手！
|
||||
|
||||
思考题
|
||||
|
||||
这里呢我们开动脑筋，如果让你用直白通俗的语言（不用统计上的定义，不引用其他术语）解释A/B测试的相关术语的话，你会怎么解释呢？选取一两个尝试着解释下。
|
||||
|
||||
欢迎把你的解释分享在评论区，我们一起交流、讨论。同时如果你有所收获，也欢迎你把这节面试课分享给你有需要的朋友。
|
||||
|
||||
|
||||
|
||||
|
||||
269
专栏/AB测试从0到1/15用R_Shiny，教你制作一个样本量计算器.md
Normal file
269
专栏/AB测试从0到1/15用R_Shiny，教你制作一个样本量计算器.md
Normal file
@@ -0,0 +1,269 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
15 用R_Shiny，教你制作一个样本量计算器
|
||||
你好，我是博伟。
|
||||
|
||||
A/B测试前的样本量计算是设计实验时不可或缺的一步。在第6节讲样本量计算时，我提到了现在网上的样本量计算器参差不齐的问题，并且网上大部分的计算器都是只能计算概率类指标，不能计算均值类指标，在实际业务应用时十分局限。
|
||||
|
||||
鉴于这些问题，加上我在实践中也想要更加快速且正确地计算样本量，提高工作效率，于是就从统计理论出发，去钻研A/B测试样本量计算的原理，让自己能够识别和掌握正确的计算方法。
|
||||
|
||||
后来渐渐发现身边的同事和朋友在做A/B测试时也有这方面的需求，于是我就把样本量的计算方法工具化，做成App放在了网上。
|
||||
|
||||
所以我今天教你的，就是把样本量计算工具化的详细过程——我会带你制作一个可以发布在网上的实时计算的A/B测试样本量计算器。
|
||||
|
||||
实战指南
|
||||
|
||||
既然是制作App，我们还是需要进行一些简单的编程，包括前端和后端，使用R语言及其前端库Shiny。不过你也不用担心，制作这款App不需要你掌握前端的JavaScript、HTML、CSS，也不需要你会在后端如何搭建数据库。你只需要掌握以下3点就足够了。
|
||||
|
||||
|
||||
A/B测试样本量计算的原理。关于原理，重点学习咱们这门课”统计篇”的两节课和基础篇的第6节课即可。
|
||||
|
||||
最基本的编程知识。我指的是通用的编程，不细指特定的语言。包括变量赋值、基本的数据类型（字符串，数字等），这些最基础的编程知识，即使不是专业的编程人员，也是大部分互联网从业者都会知道和掌握的，难度不大。
|
||||
|
||||
R和Shiny的基本语法。如果你对R和Shiny很熟悉的话，那就可以直接跳过这一点。如果你之前没有接触过R和Shiny，也没关系，这些语法也是可以快速学习和掌握的。我在这里给你一些拓展资料供你参考学习。
|
||||
|
||||
|
||||
|
||||
如何安装R和Rstudio
|
||||
R的基本语法（只需看R Tutorial这部分即可）
|
||||
Shiny教程
|
||||
|
||||
|
||||
如果你没有时间和精力学习R和Shiny的知识，也别担心，我会把我的代码开源贴出来，你可以结合代码和本节课的内容学习理解。
|
||||
|
||||
相信如果你是跟我从头开始认真学习这门课的话，现在你肯定已经掌握了第一点：A/B测试样本量计算的原理。至于第二点：最基本的编程知识，相信作为互联网人的你已经掌握或者有概念性的认知了。那么我们今天就重点讲解下如何把这两点结合起来，制作一个简单方便的样本量计算器，在教你制作的同时呢，我也会穿插讲解R和Shiny的相关知识，还有一些实战案例。
|
||||
|
||||
在讲解前呢，我先把我的代码库和样本量计算器贴出来，供作参考：
|
||||
|
||||
|
||||
代码库
|
||||
样本量计算器App
|
||||
|
||||
|
||||
首先，如果你点开GitHub上的代码库就会发现，主要的文件有两个：server.R和ui.R。这是Shiny App的标准文件结构，其实从文件名就能看出它们大概的功能：
|
||||
|
||||
|
||||
server.R负责后端逻辑的文件，比如我们这次的样本量计算的逻辑都在server.R当中。
|
||||
ui.R负责前端用户交互界面的，你的App做得好不好看全靠它了。
|
||||
|
||||
|
||||
接着，你点开我贴出来的样本量计算器链接就会发现，它已经按照指标类型分成了概率类和均值类：
|
||||
|
||||
|
||||
|
||||
那么我今天就按照这两类指标来分别进行讲解。
|
||||
|
||||
制作过程
|
||||
|
||||
概率类指标
|
||||
|
||||
从概率类指标的样本量计算的逻辑（参看第6节课）上来看，我们需要函数：power.prop.test。下面这段代码（L31-35）是在server.R文件中的具体实施：
|
||||
|
||||
number_prop_test <-reactive({ceiling(power.prop.test(
|
||||
p1=input$avgRR_prop_test/100,
|
||||
p2=input$avgRR_prop_test/100*(1+input$lift_prop_test/100),
|
||||
sig.level=1-numsif_prop_test(),
|
||||
power=0.8)[[1]])
|
||||
})
|
||||
|
||||
|
||||
函数的输入参数这里，我们需要输入以下四项信息：
|
||||
|
||||
|
||||
两组的指标p1和p2。
|
||||
显著水平sig.level。
|
||||
Power。
|
||||
单双尾检验。
|
||||
|
||||
|
||||
我们来对照实际的前端交互界面来看下应该怎么输入：-
|
||||
|
||||
|
||||
两组的指标p1和p2
|
||||
|
||||
在这里，我会让用户输入原始指标，也就是p1，和最小可检测提升。注意这里的“提升”是相对提升=（p2-p1）/p1，而不是绝对提升=p2-p1（注意和均值类指标的绝对提升进行区别）。通过这两个参数就可以算出p2了。
|
||||
|
||||
这是根据我平时实践中的实际使用情况来设置的，因为一般是有原始指标和想要获得的提升，当然你也可以根据自己的需求直接让用户输入p1和p2。
|
||||
|
||||
显著水平sig.level
|
||||
|
||||
在这里，我会让用户输入置信水平（1-α），而不是显著水平α，这也是根据实践中的习惯调整的。
|
||||
|
||||
Power和单双尾检验
|
||||
|
||||
我把Power和单双尾检验都设定成了默认值，是不需要用户改变的。因为很多用我制作的计算器的用户，他们的统计背景并不强，所以我就把Power隐藏了起来，并且设定为默认的80%，这样就可以减少他们的困惑。
|
||||
|
||||
至于单双尾检验，我在第2节课中也讲了，A/B测试中更推荐使用双尾检验，所以我也把它设定为默认的双尾检验（从代码可以看到并没有涉及这个参数，那是因为函数本身对这个参数的默认值就为“two.sided”，即“双尾”）。
|
||||
|
||||
如果你还记得第6节讲的样本量计算公式的话，就会知道影响样本量的因素有显著水平α、Power、两组间的差值δ和两组的综合方差\(\\sigma\_{\\text {pooled}}^{2}\)。
|
||||
|
||||
你可能会有疑问：为什么不让用户直接输入以上4个影响因素呢，而是让用户输入现在交互界面上的参数呢？
|
||||
|
||||
这其实是在帮用户省事，通过在实践中最常出现的参数，来帮助用户计算综合方差。
|
||||
|
||||
通过把函数的输入参数和这些影响因素对比之后，你就会发现，其实通过函数的输入参数完全可以确定这4个影响因素，从而求得样本量。
|
||||
|
||||
输入完这四项信息之后，就可以开始运行了。
|
||||
|
||||
如果你仔细比较server.R和ui.R这两个文件，就会发现整个App中两个文件通过以下方式运行的：
|
||||
|
||||
|
||||
整个App是通过ui.R这个文件接收到用户的输入值，然后把这些输入值存到input函数中。
|
||||
接着呢，server.R再读取input，进行计算，再把结果存储到output函数中，返回给ui.R。
|
||||
最后ui.R再把这些结果显示在用户的交互界面上。
|
||||
|
||||
|
||||
这里再来举个例子说明下我刚才讲的整个过程。
|
||||
|
||||
首先，在ui.R中我们需要用户输入原始指标avgRR_prop_test（L11-12）：
|
||||
|
||||
numericInput("avgRR_prop_test", label = "原始指标", value = 5, min = 0, step=1)
|
||||
|
||||
|
||||
最小可检测相对提升lift_prop_test（L18-19）：
|
||||
|
||||
numericInput("lift_prop_test", label = "最小可检测相对提升", value = 5,min = 0, step=1)
|
||||
|
||||
|
||||
置信水平sif_prop_test（L42-44）:
|
||||
|
||||
radioButtons("sif_prop_test", label = "置信水平",
|
||||
choices = list("80%","85%","90%","95%"),
|
||||
selected = "95%",inline=T)
|
||||
|
||||
|
||||
那么这些用户输入的参数呢，最后都通过input这个函数，传递到server.R文件当中去进行样本量计算（L31-35）：
|
||||
|
||||
number_prop_test <-reactive({ceiling(power.prop.test(p1=input$avgRR_prop_test/100,
|
||||
p2=input$avgRR_prop_test/100*(1+input$lift_prop_test/100),
|
||||
sig.level=1-numsif_prop_test(),
|
||||
power=0.8)[[1]])
|
||||
})
|
||||
|
||||
|
||||
当计算完成后，再把结果存在output函数中（L44-51）：
|
||||
|
||||
output$resulttext1_prop_test <- renderText({
|
||||
"每组的样本量为 "
|
||||
})
|
||||
|
||||
output$resultvalue1_prop_test<-renderText({
|
||||
tryIE(number_prop_test())
|
||||
})
|
||||
|
||||
|
||||
最后output函数再把结果传递给ui.R供前端显示（L57-63）：
|
||||
|
||||
tabPanel("结果",
|
||||
br(),
|
||||
textOutput("resulttext1_prop_test"),
|
||||
verbatimTextOutput("resultvalue1_prop_test"),
|
||||
textOutput("resulttext2_prop_test"),
|
||||
verbatimTextOutput("resultvalue2_prop_test")
|
||||
)
|
||||
|
||||
|
||||
这里要注意的一点是，因为通过power.prop.test函数计算出来的样本量是单组的，如果需要求总样本量时，就要用单组样本量乘上分组数量。这里的分组数量也是需要用户手动输入的。
|
||||
|
||||
同时你可能也注意到了，我在这款App中加入了大量的解释性语言，对于每个需要用户输入的参数都进行了解释说明，这样做其实也是吸取了实践中的用户反馈。就像我刚才说的，很多用户的统计背景并不强，对于这些统计量并不熟悉，所以我们要尽可能地将这些输入参数解释清楚，减少用户使用时的困惑。
|
||||
|
||||
均值类指标
|
||||
|
||||
从均值类指标的样本量计算的逻辑上（参看第6节课）来看，我们需要函数：power.t.test。下面这段代码（L105-109）是在server.R文件中的具体实施：
|
||||
|
||||
number_t_test <-
|
||||
reactive({ceiling(power.t.test(delta=input$lift_t_test,
|
||||
sd=input$sd_t_test,
|
||||
sig.level=1-numsif_t_test(),
|
||||
power=0.8)[[1]])
|
||||
})
|
||||
|
||||
|
||||
从这段代码我们会发现，和概率类指标相比，函数要求的输入参数有所变化，变成了：
|
||||
|
||||
|
||||
标准差sd。
|
||||
最小可检测差值delta（这里是两组指标的绝对差值）。
|
||||
显著水平sig.level。
|
||||
Power。
|
||||
还有单双尾检验。
|
||||
|
||||
|
||||
这是因为均值类指标的标准差（方差）并不能仅仅通过两组指标的值来计算，而是需要知道每个数据点来计算。
|
||||
|
||||
我们先看标准差的计算公式：-
|
||||
-
|
||||
所以标准差需要用户根据以上公式在数据中计算得出。
|
||||
|
||||
最小可检测差值delta是用户根据实际业务情况自定的，显著水平一般为95%。
|
||||
|
||||
Power和单双尾检验这两项我们还沿用概率类指标的设定去设置默认值：Power为80%的双尾检测。
|
||||
|
||||
均值类指标代码的其他部分和概率类指标均类似，这里就不再展开举例了，具体的内容，代码里也写得十分清楚了。
|
||||
|
||||
应用场景和使用案例
|
||||
|
||||
实践中使用样本量计算的应用场景主要分两类：
|
||||
|
||||
|
||||
已知单位时间的流量，求测试时间。
|
||||
已知测试时间，求单位时间的流量。
|
||||
|
||||
|
||||
所以，你会发现在App交互界面右下角区域的结果板块，就有关于测试时间和测试流量的选项。
|
||||
|
||||
下面我来举一个例子来分别说明这两种情况。
|
||||
|
||||
假设我们现在做A/B测试的指标为下载率，原始指标为5%，最小可检测的相对提升为10%，置信水平为95%，一共有一个实验组和一个对照组，通过咱们的样本量计算器，求得的每组样本量为31234，总样本量为62468。
|
||||
|
||||
在单位时间测试可用流量固定的情况下，求测试时间
|
||||
|
||||
这种场景是比较常见的。我们假设以周为单位，每周可用的测试流量约为10000。输入参数后，计算得出一共需要6到7周的时间才能达到充足的样本量：
|
||||
|
||||
|
||||
|
||||
在测试时间固定的情况下，求单位时间内的流量
|
||||
|
||||
这种场景适用于时间紧急的情况，比如一周之内要出结果，一周有7天，那么输入参数后，计算得出我们每天的测试流量至少要有8924。
|
||||
|
||||
知道每天需要的流量后，我们就可以根据这个数字去调整我们的测试流量占总流量的比例了。
|
||||
|
||||
|
||||
|
||||
最后我要说明一点，虽然我举的是一个概率类指标的例子，但这两个使用场景对于均值类指标是同样适用的。
|
||||
|
||||
使用案例
|
||||
|
||||
在使用案例这个版块，我会针对概率类指标和均值类指标各举一个例子，来说明具体情况下应该如何输入不同的参数。
|
||||
|
||||
先看概率类指标的案例。
|
||||
|
||||
|
||||
|
||||
再看均值类指标的案例。-
|
||||
|
||||
|
||||
如何把Shiny App发布在网上
|
||||
|
||||
现在我们完成了server.R和ui.R，在下图中点击右上角的“Run App”即可在本地打开我们的App。-
|
||||
-
|
||||
但是如果你想把App发布在网上，还是得借助ShinyApps.io，它是专门发布 Shiny App的平台，你需要在上面注册一个免费账户，具体过程呢也不难，你可以查看这里的教程。
|
||||
|
||||
小结
|
||||
|
||||
那么到这里呢，关于制作A/B测试样本量计算器的讲解就结束了，相信你通过本节课的学习，结合着我提供的代码和App，已经能成功制作出自己的样本量计算器啦。
|
||||
|
||||
不过有一点也需要再说明一下。虽然样本量计算的逻辑是固定的，但是对于用户交互前端的话，在保证基本功能的前提下，你可以根据自己的喜好来设计的，这里我贴出来Shiny前端的案例集和常用语句供你参考。
|
||||
|
||||
思考题
|
||||
|
||||
其实样本量计算可以在各种编程语言中实施，这里我选用R和Shiny的原因是，它们使用起来相对简单些。那如果让你用Python来实施的话，对于概率类和均值类指标样本量的计算，你会选择哪些函数呢？
|
||||
|
||||
如果你在制作样本量计算器的过程中有遇到什么问题，或者有什么经验，欢迎在留言区和我分享，也欢迎你把课程分享给你的朋友、同事。
|
||||
|
||||
|
||||
|
||||
|
||||
198
专栏/AB测试从0到1/加餐试验意识改变决策模式，推动业务增长.md
Normal file
198
专栏/AB测试从0到1/加餐试验意识改变决策模式，推动业务增长.md
Normal file
@@ -0,0 +1,198 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
加餐 试验意识改变决策模式，推动业务增长
|
||||
你好，我是凯悦。很荣幸能为博伟老师的专栏写篇加餐，写这篇文章，一方面跟我学习A/B测试的经历有关。另一方面，作为极客时间的产品经理，我们团队的试验意识也经历了一个从0到1的过程。
|
||||
|
||||
一年半前我开始自学A/B测试，当时在网上找了很多文章和课程来学习。但有用的资料较少，质量也参差不齐，讲得也不够透彻，所以我花了很长时间来判断资料的正确与否，也因此踩了很多坑。
|
||||
|
||||
所以在博伟老师这个专栏上线之后，我每周追更，越是往后学习兴趣越浓，心想如果在我学习初期就遇到这个专栏，那是多美好的事。
|
||||
|
||||
这篇加餐中，我把我们团队从引入、应用A/B测试到建立起试验意识的整个过程分享给正在学习的你。
|
||||
|
||||
试验意识改变决策模式，推动业务增长
|
||||
|
||||
极客时间不是从产品初期就开始使用A/B测试的，而是经历了纠偏、引入、应用、总结四个阶段，最终形成了较强的试验意识。
|
||||
|
||||
|
||||
纠偏：改变对A/B测试的错误认识，建立正确认识。
|
||||
引入：将A/B测试的方法和工具引入到决策过程中，而非拍脑袋决定。
|
||||
应用：用A/B测试解决一个个实际问题。
|
||||
总结：复盘经验，形成试验意识。
|
||||
|
||||
|
||||
经历了四个阶段的发展，我们建立了完整的试验流程，形成了试验意识，关键点有两个：
|
||||
|
||||
|
||||
每当遇到产品决策问题时，第一时间想到A/B测试。
|
||||
长期坚持使用A/B测试。
|
||||
|
||||
|
||||
这里我着重想说明一下我们在试验意识上的纠偏。正是意识上的纠偏，让我们改变了决策模式，将依据经验决策的单一决策模式切换为依据经验+试验意识的系统决策模式，持续推动业务增长。
|
||||
|
||||
意识纠偏
|
||||
|
||||
曾经以为A/B测试就是设置两个版本，分别让两组用户使用，转化率高的胜出，然后就可以发布上线了。
|
||||
|
||||
但事实真是如此吗？这样做决策科学吗？如果A/B测试如此简单，那为什么还是有很多互联网公司没有使用呢？
|
||||
|
||||
先举个例子，一个详情页版本A转化率是1.76%，版本B转化率是2.07%。如果你是产品经理你会选用哪个版本呢？
|
||||
|
||||
假如再有版本C，转化率是2.76%呢？再有版本D，转化率是11.76%呢？
|
||||
|
||||
按照“哪个版本转化率高就上线哪个版本”的决策模式，我们应该立即上线版本D。过去我也是这么认为的，但实际上是错误地理解了A/B测试。
|
||||
|
||||
在我刚才举的例子中，存在三个问题：
|
||||
|
||||
|
||||
第一，试验只是抽取了一部分用户得出了结论，不是全部用户；那么当全部用户都使用版本D时，转化率还会是11.76%吗？
|
||||
第二，版本B、C和D的转化率分别是2.07%、2.76%和11.76%，相对于版本A的提升分别是0.31%、1%和10%。是差异越大，我们上线这个版本的信心指数就会越高吗？显然不是，还需要考虑，0.31%、1%和10%的提升是实际存在的，还是试验误差导致的？
|
||||
第三，当差异多大时，我们才能下判断呢？换句话说，如果上线版本B，它是否确实能带来转化率的提升呢？实际的提升会是多少呢？
|
||||
|
||||
|
||||
由于这三个问题缺少数据支持，所以无法回答，因此就没法做出是上线版本A还是上线版本B的决策。我们还需要收集更多的信息来回答这三个问题。
|
||||
|
||||
回答这三个问题，就涉及对科学A/B测试的理解。什么是科学、规范的A/B测试呢？博伟老师的专栏已经给出了答案。A/B测试并没有想象中的简单，它是一项科学试验，涉及到抽样、显著性检验、软件工程、心理学等方方面面。重点要关注试验过程是否科学严谨，试验结果是否可信，依据这样的A/B测试结果做决策才真正的能推动业务的发展。
|
||||
|
||||
引入A/B测试
|
||||
|
||||
为什么要引入A/B测试呢？极客时间用户早已破百万，需要实现从野蛮生长到精耕细作的阶段跨越，用户增长、数据决策都离不开A/B测试这个工具。它能够在不进行较大改变的情况下使用小部分流量进行试验，验证假设得出结论，达到优化产品、促进用户留存和活跃的目的。
|
||||
|
||||
引入过程中我们采取了三方面的行动。
|
||||
|
||||
第一，系统学习A/B测试。开始学习时，找了大量的资料，量虽然多但大部分千篇一律。不过经过不断的学习，我们还是总结出了自己的试验流程，并尝试应用。当然，中间也踩了很多坑，进入了不少误区。
|
||||
|
||||
所以当编辑同学策划《A/B测试从0到1》这个专栏时，我们就发现这个专栏非常实用，初学者或进阶者学习过程中遇到的问题，不清楚的细节，以及需要避免的“坑”，博伟老师都有详细的讲解。
|
||||
|
||||
第二，自建分流系统。学习了理论知识之后，就要给研发同学提需求做工具了。我们自建了分流系统，然后将整个A/B测试流程跑通，这样才能真正地帮助到决策者做判断。
|
||||
|
||||
第三，将A/B测试纳入产品迭代的流程。现在在做重要产品的迭代前，都会做多个版本进行A/B测试，这已经成为了团队的共识。
|
||||
|
||||
引入并建立了A/B测试观念和意识后，接下来就需要动手实践了。博伟老师在专栏中也多次讲过，A/B测试的实践性非常强，需要在实际业务场景中不断迭代、精进。下面我就通过两个实际案例，来看看极客时间是如何从0到1利用A/B测试验证假设，以及进行产品迭代的。
|
||||
|
||||
A/B测试实践应用
|
||||
|
||||
极客时间有多个重要业务指标，其中转化率和复购率两项指标尤为重要。所以我就选择了具有代表性的两个案例来讲解。案例一，我们通过A/B测试检验了一个提升复购率的假设。案例二，利用A/B测试选出高转化率的详情页。两个案例都说明了试验和试验意识的必要性。
|
||||
|
||||
案例一：醒目的优惠券样式可以提高复购率吗？
|
||||
|
||||
案例背景
|
||||
|
||||
运营同学想提高完成首单用户的复购率，于是提出想法：在用户完成首单后，让优惠券的展示更加醒目，以促进用户使用。但是这个想法却不被产品经理认可。主要有以下几方面的原因：
|
||||
|
||||
|
||||
首先，现有版本已经有了优惠券展示模块。
|
||||
其次，整体优惠券使用率不高，而且分析历史数据得知优惠券对促进用户再次购买的效果并不理想。
|
||||
最后，也是最重要的一点，现有版本有“分享有赏”功能，用户将课程以海报形式分享到朋友圈，其好友通过该海报购买后，该用户能够得到返现。通过这种形式也能促成复购，还有拉新效果。
|
||||
|
||||
|
||||
运营同学和产品经理各有理由，所以在双方互相不能说服的情况下，我们就决定用 A/B测试来解决这一问题，而试验结果也让大家颇感意外。
|
||||
|
||||
试验设计
|
||||
|
||||
现有方案是用户完成首单后，系统弹出弹窗，用户可以选择使用优惠券购课或者分享给其他用户获得现金奖励。运营同学提出假设，认为以更醒目的样式展示大额优惠券可以提高复购率，试验的假设就可以表述为“醒目的优惠券能促进用户立即使用优惠券，进而增加复购的概率”。
|
||||
|
||||
这里需要说明的是，用户完成首单后，系统会自动将优惠券发送给用户，不需要用户手动领取。
|
||||
|
||||
于是产生了实验组的UI样式：
|
||||
|
||||
|
||||
|
||||
接下来就是按照A/B测试的规范流程来设计试验了：
|
||||
|
||||
|
||||
明确目标和假设。目标是增加复购，零假设是实验组复购率与控制组没有差异。
|
||||
确定指标。用复购率作为衡量指标，同时考虑新用户数和营收。（复购率=已支付订单数大于等于两单的用户数/已支付订单数等于一单的用户数）
|
||||
确定试验单位。使用uid作为试验单位。
|
||||
确定样本量。我们将实验组与控制组的差值设置为0.6%。这个差值也有其他叫法，比如最小可检测效应、实际显著性。算出来最少需要8074个样本。
|
||||
|
||||
|
||||
实施测试
|
||||
|
||||
经过对历史数据的分析，用户分享率和领取优惠券的领取率没有明显的周期性变化，因此按照样本量与流量确定了试验时长。
|
||||
|
||||
做好准备后，开发同学开始使用自建的分流系统，上线测试。
|
||||
|
||||
结果分析
|
||||
|
||||
进入试验的用户有17652人，在功效80%，置信度95%时，置信区间不收敛，并且P值大于0.05，不拒绝原假设。我们又试验了一段时间，发现依然如此。因此判断实验组并不比原版本效果好。
|
||||
|
||||
使用R语言的prop.test函数计算结果如下图：-
|
||||
|
||||
|
||||
试验结果汇总如下表所示：-
|
||||
-
|
||||
试验过程中我们还收集了另外两个指标：-
|
||||
-
|
||||
通过辅助指标，我们发现原版本能带来更多的用户，且用户更有动力分享促进用户购买。并且经过分析，排除了“大部分新用户是由少数几个老用户的分享带来的”这种情况。
|
||||
|
||||
做出决策
|
||||
|
||||
从试验数据来看，置信区间包含“0”值，意味着实验组比控制组的转化率有可能增加0.098%，也有可能降低0.733%。
|
||||
|
||||
此外，在拉新能力上，原版本是实验组的5倍；成交金额上，前者是后者的3.6倍。差别之大令我们感到意外，幸好有试验的意识，先通过A/B测试对idea做了检验，如果拍脑袋决策，直接采纳这个建议，那会给公司带来损失。
|
||||
|
||||
基于以上两个原因我们决定继续使用原版本。
|
||||
|
||||
案例思考
|
||||
|
||||
该案例中采取了“大胆假设，小心求证”的决策方式，当提出了“通过醒目的优惠券设计刺激复购”的idea时，产品经理第一时间想到用A/B测试的方法来验证想法是否可行。既不臆断拒绝，也不盲目接受。而是试验意识驱动，采用A/B测试方法，收集数据，分析数据，科学决策。这也就是我在文章开头所说的试验意识的第一个关键点，当涉及产品变化的决策时，首先想到A/B测试。
|
||||
|
||||
案例二：选出高转化率的详情页
|
||||
|
||||
有了前车之鉴，我们在产品迭代时也开始养成肌肉记忆，不断使用A/B测试。
|
||||
|
||||
案例背景
|
||||
|
||||
APP的课程详情页需要版本迭代。产品经理思考，通过强化促销价格能否提升详情页的转化率？
|
||||
|
||||
试验设计
|
||||
|
||||
设计了两种UI样式，如下图：-
|
||||
|
||||
|
||||
|
||||
确定指标。用转化率作为衡量指标。
|
||||
确定试验单位。使用uid作为试验单位。
|
||||
确定样本量。我们将实验组与控制组的差值设置为1.5%，计算后大概需要样本量1.7万。因为我们流量较大，按照原定分流计划，1-2天的时间就能达到最小样本量。由于用户在周末活跃数据会骤降，为了覆盖一个用户活跃周期，同时为了尽量避免新奇效应，我们适量缩小试验流量占总流量的比例，将试验时长设置为一周。
|
||||
实施测试。做好准备后，开发同学上线测试。
|
||||
|
||||
|
||||
结果分析
|
||||
|
||||
为避免“学习效应”，上线试验后，我们持续监测每天的指标；各项指标的变化都很稳定，符合预期，排除了“学习效应”。
|
||||
|
||||
试验结果如下：
|
||||
|
||||
-
|
||||
进入试验的用户有23686人，在功效80%，置信度95%时，置信区间不收敛，p值大于0.05不拒绝原假设，两个版本没有显著差异。
|
||||
|
||||
此时，陷入僵局，试验结果不显著，增加样本量降低方差都没有改变结果。如何决策呢？
|
||||
|
||||
做出决策
|
||||
|
||||
由于置信区间不收敛，无法根据试验结果决定使用哪个版本。因此需要考虑其他因素做决策。APP整体风格简洁明快，没有大色块设计；而且醒目的“大色块”并没有带来转化率的提升，却将页面分割成上下两个部分。
|
||||
|
||||
基于UI样式的考虑，我们决定使用版本A。
|
||||
|
||||
案例思考
|
||||
|
||||
试验结果有时会与直觉相左。通过严格试验得出的数据能有效反应用户的真实情况，数据驱动的前提是有数据，有数据的前提是有意识的做试验并收集数据。
|
||||
|
||||
很多试验的结果并不能给出明确的决策依据，也需要产品经理主观决策，这并不意味着试验没有作用，试验的作用是将能够用试验验证错误的idea全部排除，且证据充分，将无法用试验解决的问题交给“专家系统”来决策权，即依据负责人或团队的经验决策。
|
||||
|
||||
总结
|
||||
|
||||
今天的核心内容到这里就讲完了，我总结了团队在优化决策模式、推动业务增长过程中积攒的一些经验。
|
||||
|
||||
A/B测试方法是经过验证的最佳实践（Best Practice），要将试验意识写入我们的心智模式，每当遇到增长问题、决策问题时第一时间想到“A/B测试可能是一个好的解决方法”，这是试验意识的第一个关键点。
|
||||
|
||||
试验意识的第二个关键点是，A/B测试需要长期坚持，要形成循环，而不仅仅是闭环。如果说从发现问题到试验结果上线，再到效果回归是一个闭环的话，那么还需要在发现问题前加一个动词“持续”，“持续发现问题”，这就让试验意识形成了循环，在循环中形成持续向上的趋势。这个意识的重要性不在于一次两次试验有效还是无效，而是能让我们在决策前先用试验验证并长期这样做，形成习惯。
|
||||
|
||||
试验意识的建立，让我们的决策模式不再局限于依赖经验和直觉。试验意识加经验的决策模式成为我们的决策系统，由于这个系统有概率优势，虽然单次决策有时有效有时无效，但长期来看每一次微小进步的叠加效果就能驱动业务的整体增长，而其中的经验必将带来惊艳的效果。
|
||||
|
||||
|
||||
|
||||
|
||||
47
专栏/AB测试从0到1/导读科学、规范的A_B测试流程，是什么样的？.md
Normal file
47
专栏/AB测试从0到1/导读科学、规范的A_B测试流程，是什么样的？.md
Normal file
@@ -0,0 +1,47 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
导读 科学、规范的A_B测试流程，是什么样的？
|
||||
你好，我是博伟。
|
||||
|
||||
前面两节课啊，我们花了很大力气去学习做A/B测试的理论前提，这也是为了让你夯实理论基础。不过啊，除非你是统计科班出身，否则我都会推荐你，在学习实战的时候呢，也要不断温习统计篇的内容，把理论与实践结合起来。如果觉得有必要，也可以把我在统计篇讲的统计概念和理论延伸开来，通过查看相关统计专业书籍来加深理解。
|
||||
|
||||
学完了统计理论，接下来就要开始设计实现做A/B测试了。不过在我总结A/B测试的流程之前呢，我要简单介绍下在实践中做A/B测试的准备工作，主要有两部分：数据和测试平台。
|
||||
|
||||
一方面，我们要有数据，包括用户在我们产品和业务中的各种行为，营销广告的表现效果等等，以便用来构建指标。因为A/B测试是建立在数据上的分析方法，正如“巧妇难为无米之炊”，没有数据的话，我们就不能通过A/B测试来比较谁好谁坏。
|
||||
|
||||
一般来说，只要是公司的数据基础架构做得好，埋点埋得到位的话，基本的常用指标都是可以满足的。
|
||||
|
||||
如果说我们要进行的A/B测试的指标比较新、比较特别，或者数据库没有很全面，没有现成的数据可以用来计算相应的指标，那么可以和数据团队进行协商，看能不能在现有的数据中找出可以替代的指标计算方法。
|
||||
|
||||
如果找不到相近的替代指标，那么就要和数据工程团队协商，看能不能构建这个数据，可能需要新的埋点，或者从第三方获得。
|
||||
|
||||
另一方面呢，我们要有合适的测试平台，来帮助我们具体实施A/B测试。可以是公司内部工程团队搭建的平台，也可以是第三方提供的平台。对于这些平台，我们在做A/B测试之前都是需要事先熟悉的，以便可以在平台上面设置和实施新的A/B测试。
|
||||
|
||||
当然，在做A/B测试时，数据库和测试平台是要通过API等方式有机结合起来的，这样我们在测试平台上设置和实施的A/B测试，才能通过数据来计算相应的指标。
|
||||
|
||||
以上的准备工作并不是每次A/B测试都要做的，更多的是第一次做A/B测试时才需要去做的准备，所以更像是A/B测试的基础设施。以下的流程才是我们每次去做A/B测试都要经历的，我把它们总结在一张图中，你可以看一下。
|
||||
|
||||
|
||||
|
||||
以上就是一个规范的做A/B测试的流程了。你看啊，A/B测试的实践性很强，但大体就是这么几步。在这门课里，我会着重讲最核心的5个部分，也就是确定目标和假设、确定指标、确定实验单位、估算样本量以及分析测试结果。
|
||||
|
||||
在整个流程中，除了随机分组的具体实施细节和具体实施测试外，其余环节我都会逐个讲解。你可能会问，为什么不能把全部环节讲解一遍呢？
|
||||
|
||||
其实啊，我会侧重讲解A/B测试的基本原理，实践中的具体流程，还有实践中遇到的常见问题及解决办法，这些都是偏经验和方法论的内容。不管你在哪家公司，处在哪个行业，用什么平台去实施A/B测试，这些经验和方法论都是通用的，学完之后你就可以应用到实践中。
|
||||
|
||||
至于随机分组的不同随机算法，以及实施测试所用的平台，这些更偏工程实施的细节，公司不同，平台不同，那么实施A/B测试时也会有很大的差别。比如A/B测试的平台，大公司一般会自己开发内部的测试平台，中小型公司则会利用第三方的测试平台。
|
||||
|
||||
所以啊，基础篇这几节课呢，我也希望你能在学习的同时，能够跟自己的工作联系起来。如果你在工作中做过A/B测试，但是觉得流程没有很系统化，你就可以把平时做的A/B测试和基础篇的流程进行参照对比，看看还有哪些不足的地方。同时，通过学习基础篇，也会让你知道为什么会有这些流程，它们背后的原理是什么，让你加深对流程的理解，应用起来更加得心应手。
|
||||
|
||||
如果你还没做过A/B测试，也没关系。我会结合实际案例，来给你深入讲解。如果有条件，学习完之后你就可以尝试做自己的第一个A/B测试啦！
|
||||
|
||||
最后，我还要说明一点。A/B测试的前提是数据，这里牵涉到一个公司的数据架构和埋点策略，更多的是工程和数据库建设的问题，不是我们A/B测试的重点。所以在接下来讲课的时候，我就假设我们已经能够追踪A/B测试所需要的数据了，至于如何追踪这些数据，如何埋点这种工程实施的细节我们这里就不展开讨论了。
|
||||
|
||||
好啦，了解了这些，就让我们正式开始A/B测试的旅程吧！
|
||||
|
||||
|
||||
|
||||
|
||||
69
专栏/AB测试从0到1/结束语实践是检验真理的唯一标准.md
Normal file
69
专栏/AB测试从0到1/结束语实践是检验真理的唯一标准.md
Normal file
@@ -0,0 +1,69 @@
|
||||
|
||||
|
||||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||||
|
||||
|
||||
结束语 实践是检验真理的唯一标准
|
||||
你好，我是博伟。
|
||||
|
||||
在过去的这些年里，我一直在和A/B测试打交道，研究的时间越久，越能体会出其中蕴含的深意。所以在设计课程大纲时，结束语这一讲的标题，我毫不犹豫地选择了“实践是检验真理的唯一标准”。这句话很朴素，却是我这么多年和A/B测试朝夕相处的真实体会。
|
||||
|
||||
首先，我想和你聊聊为什么我在课程中会反复强调实践的重要性。
|
||||
|
||||
A/B测试本身，就是一种偏经验和方法论的工具。掌握了我在课程中讲的这些统计原理、规范流程后，也不能保证你在实践中如鱼得水，游刃有余。毕竟听到的经验和方法，想要深刻理解，还是要拿到实际业务场景中反复试炼，才能不断迭代和完善。
|
||||
|
||||
即使是我讲过的一些常见误区和问题，以及一些隐形的坑点，由于业务环境的千差万别，你在实践时大概率还是会遇到，而且还会遇到其他的坑。不过不要害怕，因为有些“弯路”非走不可，正是在和“弯路”的博弈中，你才能摸透A/B测试中的招式和套路，精进业务。
|
||||
|
||||
A/B测试带给公司和团队的不光是持续提升的结果，更重要的是实验意识。团队中的成员提出一个想法，究竟是突发奇想，还是真正可靠的呢？能不能有效落地实施呢？我们完全可以把这个想法通过A/B测试放在实际场景中检验，最后得出具有说服力的结论。正所谓大胆猜想，小心求证，不断调整，快速更迭。
|
||||
|
||||
“实践”并不是件容易的事儿，真正去做的时候，还需要主动、耐心、有勇气。
|
||||
|
||||
与A/B测试相关的项目都可以主动参与。不管你是亲自做测试，还是观摩整个过程，这都是在学习积累。主动提出业务需求，主动尝试，只要去实践，肯定就有收获。
|
||||
|
||||
对“失败”多点耐心。这里的失败我是打引号的，你可能会觉得做完A/B测试后，只要没有把A/B测试中的变化在产品或业务中实施就算“失败”，不过我想告诉你的是，从实践数据来看，一大半的A/B测试中的变化最终都没有最终实施。在做测试的时候，我们肯定希望结果是显著的，但实际上，不显著的概率比较大。这就是期望与现实的落差。那这就算是失败吗？
|
||||
|
||||
在A/B测试领域显然不是这样的。每一次“失败”的测试，对我们来说都是宝贵的经验，你可能会从中发现从而改进测试设置、工程实施等方面的问题。哪怕测试结果真的不显著，也没关系，因为这也能帮我们排除不同的想法，减少给业务带来的潜在损失，从而让我们快速迭代到下一个想法中去。
|
||||
|
||||
要敢于提出自己的想法。我已经记不清有多少次我和同事、领导意见不一致时，A/B测试就成了我们解决问题的法宝。长此以往，也帮助我们在团队中形成了一种实验的氛围，大家越来越敢提出与别人不一样的想法和意见，而不是管理人员的一言堂。
|
||||
|
||||
你看，“实践是检验真理的唯一标准”中包含的朴素智慧，一旦和我们当下的生活、工作结合起来，是不是就有更生动、更丰富的理解了呢？这也正是我平时爱好历史的原因，前人的智慧总能历久弥新。
|
||||
|
||||
不过在今天课程结束之际，我还想给你分享更多我自己学习A/B测试的故事，聊一聊我的学习心得，希望能带给你一些启发和勉励。
|
||||
|
||||
第一个心得，搭建自己的知识框架，能让你的学习效率更高。
|
||||
|
||||
就拿我自己来说吧。我呢，其实并不是科班出身的数据从业者，所以想要在这一陌生领域有立足之地，术业有专攻，就要付出更多的努力。
|
||||
|
||||
举个小例子。为了搞清楚中心极限定理、P值、Power这些难懂的统计概念，我把各种版本的统计课本学了不下20遍。为了全面掌握数据科学方面的知识，就利用业余时间学习了将近10门与数据科学相关的网课。系统化的学习，给我打下了实践的坚实基础，实践中再遇到其他问题，我就知道怎么去搜索资料、寻找解决方法，而不会无从下手。
|
||||
|
||||
所以，这也是我想要做这门课的初衷。根据我多年积累的经验，系统总结A/B测试领域的经验和方法，帮助想要学习这个领域的人搭建一个知识框架，让你能够在短时间内获得非线性的突破。
|
||||
|
||||
第二个心得，学习要有目的，并且要把学到的知识及时应用到实践中，学以致用。
|
||||
|
||||
在学校期间的学习大都是为了学习而学习，工作后的学习就不同了，有目的的学习更能达到一举多得的效果。
|
||||
|
||||
我刚才谈到自己曾把统计课本学习了不下20遍，这只是相对系统的学习遍数，如果算上实际翻看的次数，那远不止百次了。因为我这个人呢，记性一般，纯知识性的东西一旦不常用就很容易忘记。所以统计书对我来说，就像小学学习语文时的《现代汉语词典》一样，平时用到了就去查，形成肌肉动作。
|
||||
|
||||
所以如果你学完这个课程，有些内容没能完全消化，没有关系，我希望你能把它当做你在A/B测试上的工具书，遇到棘手的问题就来翻看、学习，有问题也欢迎继续留言，我也会时不时地回复你的问题。
|
||||
|
||||
还想分享一个我做专栏的心得：文字输出是检验输入质量的重要标准。
|
||||
|
||||
在实践中丰富和完善的知识要怎么检验？文字输出就是一个很好的方式。这也是我在做专栏这几个月保持连续输出的一个重要心得。
|
||||
|
||||
这几年我会经常带学生做项目或者做讲座，但文字输出和“讲”是不一样的。脑海中把一个问题想清楚了，也能给别人讲出来，但要落到笔上，就得斟酌每一个细枝末节：全文是不是有逻辑、用词是不是够精准、例子是不是够恰当等等。这对文字表达、专业逻辑都是不小的磨练。
|
||||
|
||||
做专栏的文字输出，跟我平时写文章也不一样。写专栏文章，我需要去掉那些学术派的语言，调整粗糙的表达，力求用最简单明了的语言去讲清楚一个问题，同时还要考虑读者的阅读习惯等等。所以反复打磨的不仅是文字内容，还有对问题的周密思考。当然了，这对精力、意志力也都是考验。
|
||||
|
||||
我和A/B测试已经亲密相处了7年多，对我来说，它不仅是工作中的一种增长方法，在深入体会它的精妙之后，它代表的“实验意识”更成了我生活中的重要理念和原则。
|
||||
|
||||
当生活中偶遇迷茫找不准方向，或者面对未知的不确定心有焦虑时，我不会畏首畏尾，更不会退缩，而是大胆地去尝试。在考虑到可能的结果后，勇于试错。因为不亲自经历，我可能永远也不知道这件事对自己来说是好是坏。
|
||||
|
||||
就像过去的2020年，注定是个特别的年份，突如其来的疫情打乱了很多人在学习、生活和工作上的节奏。在这种生存与挑战、安稳与不确定的摇摆之间，不如把心里的思绪和想法，投放到实践中，从而突破自己内心的围城。
|
||||
|
||||
这也是我最后想与你共勉的：唯有步履不停，人生路上才能遇到更多的惊喜。
|
||||
|
||||
最后的最后，我也为你准备了调查问卷，题目不多，希望你可以花两分钟填一下。十分期待能听到你的反馈，说说你对这门课程的想法和建议。
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user