mirror of
https://github.com/cheetahlou/CategoryResourceRepost.git
synced 2025-10-21 01:13:45 +08:00
mod
This commit is contained in:
@@ -0,0 +1,164 @@
|
||||
<audio id="audio" title="03|确定目标和假设:好的目标和假设是什么?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/95/a9/959c6b83108b182f1faa8bd1878c18a9.mp3"></audio>
|
||||
|
||||
你好,我是博伟。
|
||||
|
||||
今天这节课我们就进入到“基础篇”模块了,通过前面的学习,你已经清楚了做A/B测试的基本流程,接下来呢,我会带你去看看在实践中确定目标和假设、确定指标、选取实验单位、估算样本量大小,以及分析测试结果这5步,具体应该怎么操作。
|
||||
|
||||
我们知道,确定目标和假设、确定指标这两步决定了测试的方向,可谓至关重要。那么,如何一步步地把业务问题转化为A/B测试的目标和假设呢?又如何根据目标来选择合适的指标呢?在接下来的两节课,我会通过大量的案例来给你解答这两个问题。在讲解案例的同时,我也会结合我的实践经验,给你一些可落地执行、切实可操作的建议,让你知道该如何规避坑点。
|
||||
|
||||
## 确定目标和假设
|
||||
|
||||
首先,我们要明确,做A/B测试肯定是为了解决业务上遇到的问题,而绝不是为了做而做。所以,找到了要解决的业务问题,也就基本找到了A/B测试目标。为什么这么说呢?
|
||||
|
||||
让我们来回顾下开篇词中讲的A/B测试解决的常见业务问题,看看A/B测试可以用在什么领域,解决什么问题:
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/13/df/13059daa26b391d55e4dc357124b51df.png" alt="">
|
||||
|
||||
总结一下这些业务问题,我们就会发现一些共性:
|
||||
|
||||
1. 所有的业务问题都会有一个目标,比如提升用户粘性是业务问题的目标,同时我们也把这个目标称作“**结果**”。
|
||||
1. 有的业务问题会有明确的努力方向,比如,通过改变外观来提升点击率,这里的“改变外观”就是明确的努力方向,同时我们也把“改变外观”等变化称作“**原因**”。不过有的业务问题没有明确的努力方向,这时候我们需要根据具体的情况去发现原因。比如对于“如何确定最优的营销时间”这个业务问题,我们分析发掘之后会发现,周五晚上的营销效果会比较好。那么这里的“原因”就是大家结束了一周忙碌的工作,就会比较有时间。
|
||||
|
||||
你看,**把产品/业务的变化作为原因,把业务目标变成结果,我们就把业务问题转换成了因果推断**。而对于做A/B测试来说,把业务问题转换成因果推断,也就意味着找到了测试的目标。**所谓的假设,在A/B测试的语境下,就是既包含了想要做出的改变,又包含了期望达到的结果。**
|
||||
|
||||
接下来,我就以一款按月付费的音乐App要提高营收为例,带你看看该如何确定目标和假设。
|
||||
|
||||
**首先,分析问题,确定想要达到的结果。**
|
||||
|
||||
想要提高营收,我们首先得清楚问题出在哪里。这个时候,我们可以进行数据分析。比如,和竞品进行对比分析后发现,我们App的用户留存率低于行业平均水平。因此,用户留存率就是我们这款App目前存在的问题。
|
||||
|
||||
**其次,提出解决业务问题的大致方案。**
|
||||
|
||||
影响用户留存的原因有很多种。比如,内容是否足够丰富,能满足不同用户的音乐需求?产品是否有足够多的便利功能,可以给用户更好的使用体验?App的开启和运行速度是否足够流畅?
|
||||
|
||||
通过进一步的分析发现,我们的产品在歌曲库的内容和丰富程度上,都在行业平均水平之上,而且App的运行也十分流畅,但是缺少一些便利的产品功能。所以,我们提出的大致解决方案就是,要通过增加产品功能来提升用户留存。
|
||||
|
||||
**最后,从大致的解决方案中提取出具体的假设。**
|
||||
|
||||
那针对这款音乐App,可以增加什么具体的产品功能呢?你可能会想到,**在每个专辑/歌单播放完成后增加“自动播放下一个专辑/歌单”的功能,以此来提升用户留存。**
|
||||
|
||||
这样一来,我们就通过三个步骤基本确定了目标和假设。
|
||||
|
||||
为什么说是“基本确定”了呢?因为确定目标和假设到这里还没有完全完成。要注意了,我们在上面确定目标和假设的时候其实还忽略了一个隐形的坑:这个假设中的“提升用户留存”还不能算是一个好的目标。因为这个假设还不够具体,目标没有被量化,而没有量化就没有办法提升。所以在这里,我们还需要做的就是量化“用户留存率”这个概念。
|
||||
|
||||
在按月付费的音乐App这个案例中,用户只要每个月按时付费续订,就是留存。所以,我们可以把用户留存定义为下个月的续订率,这样我们就把假设变得更加具体,并且目标可被量化。
|
||||
|
||||
那我们优化后,这个A/B测试的假设就变成了:**在每个专辑/歌单播放完成后增加“自动播放下一个专辑/歌单”的功能,可以提升用户下个月的续订率。**
|
||||
|
||||
为了帮你理解怎样才能做出好的假设,我根据自己的经验,把到底啥是好的假设,啥是不好的假设归纳到了一张图中,你一看就明白了:
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/07/c3/074305ea12510d47c7b76547fa2yy2c3.png" alt="">
|
||||
|
||||
以上就是确定目标和假设的核心内容,你只要记住以下两点就够了:
|
||||
|
||||
- A/B测试是因果推断,所以我们首先要确定原因和结果。
|
||||
- 目标决定了结果(用户留存), 而假设又决定了原因(增加自动播放的功能),所以目标和假设对于A/B测试来说,是缺一不可。
|
||||
|
||||
有了测试目标和假设,我们就可以进入A/B测试的第二步了:确定指标。具体该如何确定指标呢?在解答这个问题之前,我们还需要先熟悉下指标的分类。
|
||||
|
||||
## A/B测试的指标有哪几类?
|
||||
|
||||
一般来说, A/B测试的指标分为评价指标(Evaluation Metrics)和护栏指标(Guardrail Metrics)这两类。
|
||||
|
||||
**评价指标**,一般指能驱动公司/组织实现核心价值的指标,又被称作驱动指标。评价指标通常是短期的、比较敏感、有很强的可操作性,例如点击率、转化率、人均使用时长等。
|
||||
|
||||
可以说,评价指标是能够直接评价A/B测试结果的指标,是我们要重点关注的。
|
||||
|
||||
那有了评价指标,就可以保证A/B测试的成功了吗?显然不是的。很多时候,我们可能考虑得不够全面,忽略了测试本身的合理性,不确定测试是否会对业务有负面效果,因此很可能得出错误的结论。
|
||||
|
||||
举个例子。如果为了优化一个网页的点击率,就给网页添加了非常酷炫的动画效果。结果点击率是提升了,网页加载时间却增加了,造成了不好的用户体验。长期来看,这就不利于业务的发展。
|
||||
|
||||
所以,我们还需要从产品长远发展的角度出发,找到**护栏指标**。概括地说,护栏指标属于A/B测试中基本的合理性检验(Sanity Check),就像飞机起飞前的安全检查一样。它的作用就是作为辅助,来保障A/B测试的质量:
|
||||
|
||||
- 衡量A/B测试是否符合业务上的长期目标,不会因为优化短期指标而打乱长期目标。
|
||||
- 确保从统计上尽量减少出现各种偏差(Bias),得到尽可能值得信任的实验结果。
|
||||
|
||||
到这里我们小结一下。在确定指标这一步,其实就是要确定评价指标和护栏指标。而护栏指标作为辅助性的指标,需要在选好了评价指标后才能确定。
|
||||
|
||||
那么问题来了,什么样的指标才能作为评价指标呢?
|
||||
|
||||
## 什么样的指标可以作为评价指标?
|
||||
|
||||
既然A/B测试的本质是因果推断,那么我们选择的业务指标的变化(结果)必须要可以归因到实验中的变量(原因)。所以,**评价指标的第一个特征,就是可归因性。**
|
||||
|
||||
比如,我们要测试增加“自动播放”功能,是否可以提升App的续订率。那么,这里的评价指标续订率的变化,就必须可以归因于增加了“自动播放”功能。在测试中我们控制其他可能影响续订率的因素都相同的情况下,增加了“自动播放”功能的变化就成了续订率的唯一影响因素。
|
||||
|
||||
刚才我们提到了,好的假设要能够被量化,否则就没有办法进行实验组和对照组的比较。这也就是**评价指标要有的第二个特征:可测量性。**
|
||||
|
||||
比如,对于音乐App来说,像用户满意度这个指标就不是很好量化。但是像用户续订率这样的指标,就可以量化。所以,我们就可以把“用户满意度”转化成“用户续订率”这种可以量化的指标。
|
||||
|
||||
可测量性和可归因性这两个特征都比较容易判断,除此之外,评价指标还具有第三个特征:**敏感性和稳定性**。那怎么理解呢?我用一句话来解释下:如果实验中的变量变化了,评价指标要能敏感地做出相应的变化;但如果是其他因素变化了,评价指标要能保持相应的稳定性。
|
||||
|
||||
看一个例子吧。还是在音乐App中,如果我想测试某一个具体内容的推送效果,比如推送周杰伦的新专辑,那么续订率会是一个好的指标吗?答案是否定的。
|
||||
|
||||
因为具体的推送是一次性的,而且推送只会产生短期效果(比如增加用户对杰伦新专辑的收听率),但不太会产生长期效果(比如增加续订率)。所以,续订率这个指标就对杰伦的推送不是很敏感。相反,短期的收听率是对单次推送更加敏感且合适的指标。
|
||||
|
||||
从这个例子中,我们可以得出两个结论:
|
||||
|
||||
- 用A/B测试来检测单次的变化时(比如单次推送/邮件)一般选用短期效果的指标,因为长期效果目标通常对单次变化并不敏感。
|
||||
- 用A/B测试来检测连续的、永久的变化时(比如增加产品功能),可以选用长期效果的指标。
|
||||
|
||||
可见,如果选取的评价指标对A/B测试中的变化不敏感,或者对其他变化太敏感,我们的实验都会失败。那么,具体该如何测量评价指标的敏感性和稳定性呢?业界通常采用A/A测试来测量稳定性,用回溯性分析来表征敏感性。我来给你具体解释一下。
|
||||
|
||||
和A/B测试类似,A/A测试(A/A Test)也是把被测试对象分成实验组和对照组。但不同的是,A/A测试中两组对象拥有的是完全相同的体验,如果A/A测试的结果发现两组的指标有显著不同,那么就说明要么分组分得不均匀,每组的数据分布差异较大;要么选取的指标波动范围太大,稳定性差。
|
||||
|
||||
如果没有之前实验的数据,或者是因为某些原因(比如时间不够)没有办法跑新的实验,那我们也可以通过分析历史数据,进行**回溯性分析(Retrospective Analysis)**。也就是在分析之前不同的产品变化时,去看我们感兴趣的指标是否有相应的变化。
|
||||
|
||||
比如,我们选取续订率作为衡量增加“自动播放”功能是否有用的指标,那么我们就要去分析,在过去增加其他有利于用户留存的产品功能前后,续订率是不是有明显的变化。
|
||||
|
||||
好了,知道了应该选择什么样的指标作为评价指标之后,我们就可以开始选取适合我们自己业务的指标了。
|
||||
|
||||
## 如何选取具体的评价指标?
|
||||
|
||||
正像我们今天所看到的,确定评价指标的方法林林总总,但到底哪些是好用的,是真正可落地的呢?经过这些年的实践,我逐步总结积累了3种经验证确实简单、可落地的方法。
|
||||
|
||||
我还是以音乐App为例,和你解释下。
|
||||
|
||||
**第一,要清楚业务或产品所处的阶段,根据这个阶段的目标,来确定评价指标。**
|
||||
|
||||
这是因为,不同的业务/产品,甚至是同一个业务/产品的不同阶段,目标不同评价指标也会差别较大。
|
||||
|
||||
拿音乐App来说,在起步阶段,我们一般把增加新用户作为主要目标,把在拉新过程中的各种点击率、转化率作为评价指标;在发展和成熟期,一般会重点关注现有用户的使用和留存情况,把用户的平均使用时间和频率、产品特定功能的使用率,以及用户的留存率等作为评价指标。
|
||||
|
||||
比如要提高留存,首先要明确什么是留存:用户只要每个月按时付费续订,就是留存。那么这个时候,我们可以把用户留存的评价指标定义为下个月的续订率。
|
||||
|
||||
**第二,如果目标比较抽象,我们就需要采用定性+定量相结合的方法了。**
|
||||
|
||||
对于一些比较抽象的目标,比如用户的满意度,我们可以使用一些定性的方法,确定一些假设和想法,像**问卷调查、用户调研**等。同时,我们还可以利用用户使用产品时的各种数据,进行定量的数据分析,来了解他们的使用行为。
|
||||
|
||||
最后,我们把定性的用户调研结果和定量的用户使用行为分析结合起来,找出哪些使用行为和用户的满意度有着强烈的关系。
|
||||
|
||||
对于音乐App来说,我们具体可以这么做:
|
||||
|
||||
- 首先,通过定性的用户调研,来确定哪些用户满意、哪些用户不满意,完成分组。
|
||||
- 接着,我们对每组用户(满意的用户和不满意的用户)分别做定量的用户使用习惯的数据分析,发现把音乐收藏到自己曲库的用户有较高的满意度,说明收藏音乐这个行为和用户满意度有强烈的正相关性。这时候,我们就可以把收藏音乐作为评价指标(比如收藏音乐的数量)。更进一步,我们还可以通过数据分析确定“收藏X首以上音乐的用户非常满意”中X的最优值是多少。
|
||||
|
||||
**第三,如果有条件的话,你还可以通过公开或者非公开的渠道,参考其他公司相似的实验或者研究,根据自己的情况去借鉴他们使用的评价指标。**
|
||||
|
||||
公开的渠道,是指网络上公开的各个公司关于A/B测试的文章或者论文。我经常会看的大公司的博客是[Facebook](https://www.facebook.com/business/insights/advertising/measurement)、[Google](https://www.thinkwithgoogle.com/)、[Twitter](https://blog.twitter.com/engineering/en_us/topics/insights.html),也推荐给你,你可以重点看Facebook中Measurement相关的文章,都是介绍评价广告效果的指标。
|
||||
|
||||
另外,你还可以去看一下《精益数据分析》这本书。在这本书里,你几乎可以找到所有重要互联网商业模式(电商,社交网络,移动App等)在各个阶段的典型指标。
|
||||
|
||||
为什么其他公司的评价指标有借鉴意义呢?原因很简单,To C的产品用到A/B测试的场景都很相似。比如,我们想要通过A/B测试提升音乐App中广告的效果,那么Facebook在广告业务上的经验就能给我们很大的启发。
|
||||
|
||||
相应地,非公开的渠道,是指你的从事A/B测试并愿意和你分享经验的朋友,以及A/B测试相关的行业峰会。
|
||||
|
||||
在实践中,大部分的指标是根据产品/业务发展阶段的目标来确定的;如果实验的目标比较抽象或者比较新,通过经验和数据分析无法产生,你就可以采用定性+定量的方法了。
|
||||
|
||||
## 小结
|
||||
|
||||
今天这一讲,我们解决了下面两个问题。
|
||||
|
||||
第一,确定目标和假设,其实就是三大步:分析问题,确定结果;找出大致的解决方案;确定假设。
|
||||
|
||||
第二,确定指标,就是要确定评价指标和护栏指标。这节课主要讲了评价指标,其中关键的是我们要从目标入手,把目标量化。
|
||||
|
||||
最后,我要再和你强调一下,在A/B测试中确定目标和假设的重要性。A/B测试是和业务紧密相关的,但我们往往会忽视业务中的目标,把注意力过多地放在选取评价指标上。在我看来,这就是本末倒置,就像一个不知道终点在哪里却一直在奔跑的运动员,如果能先明确终点,朝着终点的方向努力,会更快地取得成功。所以,你一定要按照今天学的内容,在做A/B测试时先试着找出你的目标和假设。
|
||||
|
||||
实际的业务场景大多比较复杂,很多时候单一的评价指标不足以帮助我们达成目标,而且指标也有波动性。所以,下节课,我会给你讲一讲综合多个指标建立总体评价标准的方法,以及指标的波动性。同时,我还会具体给你介绍护栏指标,保证你的A/B测试在业务和统计上的品质和质量。
|
||||
|
||||
## 思考题
|
||||
|
||||
根据生活和工作中的经历,结合今天所学内容,说说你认为有哪些指标是不适合做A/B测试的评价指标的?为什么呢?
|
||||
|
||||
欢迎在留言区写下你的思考和想法,我们可以一起交流讨论。如果你觉得有所收获,欢迎你把课程分享给你的同事或朋友,一起共同进步!
|
@@ -0,0 +1,210 @@
|
||||
<audio id="audio" title="04|确定指标:指标这么多,到底如何来选择?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/13/cd/135ed2e09fe4930c3b1bccf539ed97cd.mp3"></audio>
|
||||
|
||||
你好,我是博伟。
|
||||
|
||||
上节课,我们学习了确定评价指标的几种方法,包括量化产品/业务不同阶段的目标,采取定量+定性的方法,或者借鉴行业内其他公司的经验等。你也发现了,这些方法的局限性在于只能选出单个评价指标,而且也没有考虑到评价指标的波动性对结果准确度的影响。
|
||||
|
||||
今天我们会更进一步,去看看在实际的复杂业务场景中,确定评价指标的方法,以及计算指标的波动性的方法。然后,我们再看看为了确保A/B测试结果的可靠性,应该如何去确定护栏指标。
|
||||
|
||||
## **综合多个指标,建立总体评价标准**
|
||||
|
||||
在实际的业务需求中,有时会出现多个目标,同一目标也可能有多个都很重要的评价指标,需要我们把它们都综合起来考虑。对于单个指标,我们可以用上一讲的方法来确定;但如果要综合考虑多个指标时,又要如何考虑呢?
|
||||
|
||||
我们先看一个例子。
|
||||
|
||||
亚马逊和用户沟通的一个重要渠道就是电子邮件,它有一个专门给用户发送电子邮件的平台,通过两种方式来精准定位用户:
|
||||
|
||||
- 基于用户的历史购买数据来构建用户的个人喜好,通过推荐算法来发邮件给用户做推荐;
|
||||
- 亚马逊的编辑团队会人工精选出推荐产品,通过电子邮件发送给用户。
|
||||
|
||||
确定了精准用户以后,亚马逊还面临一个问题:要用什么指标来衡量电子邮件的效果呢?
|
||||
|
||||
你可能会想到,给用户发送邮件是为了让他们购买,所以邮件产生的收入可以作为评价指标。
|
||||
|
||||
实际上,亚马逊最初就是这么做的:他们确定的假设是通过多发电子邮件来增加额外的收入,评价指标就是邮件产生的收入。
|
||||
|
||||
那么这个时候,一个假想的A/B测试就被设计了出来。
|
||||
|
||||
- 在实验组,我们给用户发邮件。
|
||||
- 在对照组,我们不给用户发邮件。
|
||||
|
||||
结果可想而知。对照组没有收到任何邮件,也就不会有邮件产生的收入。而在实验组的用户,由于收到很多邮件,所以产生了不少收入。
|
||||
|
||||
出现这个结果的根本原因是,这个指标本身是单调递增的。也就是说,发的电子邮件越多,点击的用户也会越多,从邮件中获得的收入也会越多。所以,想要有更多的收入,就要发更多的邮件。
|
||||
|
||||
但现实情况是,用户收到的邮件多到一定程度后,他们就会觉得是垃圾邮件,被骚扰了,结果就是影响了用户体验,用户选择退订(Unsubscribe)邮件。而用户一旦退订,以后就再也接收不到来自亚马逊的邮件了。
|
||||
|
||||
把邮件产生的收入作为评价指标,可以说只是用来优化短期的收入,并没有考虑到长期的用户价值。用户一旦因为被骚扰而退订,亚马逊就失去了在未来给他们发邮件做营销的机会了。所以,邮件产生的收入并不适合作为评价指标,我们需要综合考虑发邮件所带来的好处和潜在的损失,结合多个指标,构建一个总体评价标准 (Overall Evaluation Criteria,简称OEC)。
|
||||
|
||||
那具体怎么做呢?我们可以给每个实验/对照组计算OEC:
|
||||
|
||||
$$<br>
|
||||
\mathrm{OEC}=\frac{\left(\Sigma_{i}{ Revenue-S*Unsubscribe\_lifetime\_loss}\right)} {n}<br>
|
||||
$$
|
||||
|
||||
我来具体解释下这个公式。
|
||||
|
||||
- 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测试的目的了吗?答案显然是否定的。
|
||||
|
||||
虽然实验组的数据要比对照组的好,但是这些数据都在正常的波动范围内。所以,**增加自动播放功能**和**提升续订率**之间的因果关系,在这次实验中就没有被建立起来,因为这两组指标的差异也可能只是正常的波动而已。但是,如果我们事先不知道评价指标的波动性和正常波动范围,就很有可能建立错误的因果关系。
|
||||
|
||||
那么,如何才能知道评价指标的这个正常波动范围呢?
|
||||
|
||||
在统计学里面,指标的波动性通常用其平均值和平均值的标准差来表示,一个指标平均值的标准差越大,说明其波动性越大。**这里面要注意,<strong>变量平均值的标准差又叫做标准误差**</strong>(**<strong>Standard Error**</strong>)。关于标准差的概念,你可以再回顾下第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节课的相关内容)。
|
||||
|
||||
所以,概率指标的标准误差,我们可以通过下面这个公式计算:<br>
|
||||
$$<br>
|
||||
\text { Standard Error }=\sqrt{\frac{p(1-p)}{n}}<br>
|
||||
$$
|
||||
|
||||
其中,p代表事件发生的概率。
|
||||
|
||||
**均值类的指标**,常见的有用户的平均使用时长、平均购买金额、平均购买频率,等等。根据中心极限定理,这类指标通常也是正态分布。
|
||||
|
||||
所以,均值类指标的标准误差,我们可以这样计算:
|
||||
|
||||
$$<br>
|
||||
\text {Standard Error}=\sqrt{\frac{s^{2}}{\mathrm{n}}}=\sqrt{\frac{\sum_{i}^{n}\left(x_{i}-\bar{x}\right)^{2}}{n(n-1)}}<br>
|
||||
$$
|
||||
|
||||
其中,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测试都要有相应的护栏指标。**
|
||||
|
||||
接下来,我们就从业务品质和统计品质这两个维度,来学习如何选取护栏指标。这里我先用一张图,帮你总结下:
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/bb/c7/bbf3c75f0cebaf6029e2c37e6ec197c7.png" alt="">
|
||||
|
||||
### **业务品质层面**
|
||||
|
||||
在业务层面的护栏指标,是在保证用户体验的同时,兼顾盈利能力和用户的参与度。所以,我们通常会用到的护栏指标主要是三个:网络延迟(Latency)、闪退率(Crash Rate)和人均指标。
|
||||
|
||||
1. **网络延迟**
|
||||
|
||||
**网页加载时间、App响应时间等,都是表征网络延迟的护栏指标**。增加产品功能可能会增加网页或App的响应时间,而且用户可以敏感地察觉出来。这个时候,就需要在A/B测试中加入表征网络延迟的护栏指标,确保在增加产品功能的同时,尽可能减少对用户体验的影响 (一般是通过优化底层代码)。
|
||||
|
||||
1. **闪退率**
|
||||
|
||||
对于不同的应用程序App来说,不管是在个人电脑端,还是在移动端,都有可能因为CPU、内存或者其他原因出现闪退,导致程序突然关闭。
|
||||
|
||||
说到这儿,我想和你分享一件趣事。我在用MS Word写这节课的内容时,就出现了软件闪退。关键是我当时还没有保存,心想几个小时的努力不就白费了嘛,特别心灰意冷。万幸的是,MS Word有自动保存功能。
|
||||
|
||||
你看,闪退发生的概率虽然不大,但是会严重影响用户体验。所以,在测试应用程序的新功能时,尤其是针对一些大的改动,闪退率就是一个比较好的护栏指标。
|
||||
|
||||
1. **人均指标**
|
||||
|
||||
人均指标可以从两个角度来考虑:
|
||||
|
||||
- **收入角度**,比如人均花费、人均利润等。
|
||||
- **用户参与度**,比如人均使用时长、人均使用频率等。
|
||||
|
||||
这两个角度一般都是实际业务中追求的目标,收入角度代表了产品的盈利能力,用户参与度代表了用户的满意程度。但是,在具体的A/B测试中,我们往往会只关注产品的被测试部分的功能,忽视了对大局的把握。
|
||||
|
||||
举个例子。应用商店优化了推荐算法后,推荐的内容更贴近用户的喜好,提高了用户对推荐内容的点击率。我们关注的评价指标点击率提高了,是不是皆大欢喜呢?不是的,因为我们分析后发现,这个新算法推荐内容中的免费App的比例增加了,使得人均花费降低了,进而影响到了应用商店的总体收入。
|
||||
|
||||
这个时候,我们可以把人均收入作为护栏指标,去继续优化推荐算法。
|
||||
|
||||
### **统计品质层面**
|
||||
|
||||
统计方面主要是尽可能多地消除偏差,使实验组和对照组尽可能相似,比如检测两组样本量的比例,以及检测两组中特征的分布是否相似。
|
||||
|
||||
造成偏差的原因有很多,可能是随机分组的算法出现了Bug,也可能是样本不够大,还有可能是触发实验条件的数据出现了延迟,不过更多的是具体实施中的工程问题造成的。这些偏差都会影响我们获得准确的实验结果,而护栏指标就是我们发现这些偏差的利器!
|
||||
|
||||
**1.实验/对照组样本大小的比例**
|
||||
|
||||
在设计A/B测试的时候,我们就会预先分配好实验组和对照组,通常是把样本等分。也就是说,实验组和对照组样本大小的比例,预期是1:1=1。但有的时候,当实验结束后却发现两者的比例并不等于1,甚至也没有很接近1。这就说明这个实验在具体实施的过程中出现了问题,导致实验组和对照组出现了偏差。
|
||||
|
||||
**2.实验/对照组中特征的分布**
|
||||
|
||||
A/B 测试中一般采取随机分组,来保证两组实验对象是相似的,从而达到控制其他变量、只变化我们关心的唯一变量(即A/B测试中的原因)的目的。
|
||||
|
||||
比如说,如果以用户作为实验单位的话,那么,在试验结束后去分析两组数据时,两组中用户的年龄、性别、地点等基本信息的分布应该是大体一致的,这样才能消除偏差。否则,实验本身就是有问题的,得出的结果也不是可信赖的。
|
||||
|
||||
## **小结**
|
||||
|
||||
今天,我们学习了复杂业务场景下如何选取评价指标、评价指标的波动性这个易错点,以及如何选取护栏指标。
|
||||
|
||||
<li>
|
||||
有多个指标出现的情况下,我们可以把它们结合在一起,建立总体评价标准,也就是OEC。这里面需要注意的一点是,不同指标的单位、大小可能不在一个尺度上,需要先要对各个指标进行归一化(Normalization)处理,使它们的取值都在一定的范围内,比如[0,1], 之后再进行结合,从而剔除指标单位/大小的影响。
|
||||
</li>
|
||||
<li>
|
||||
评价指标的正常波动范围,就是置信区间。计算置信区间是一个重点,对于分布比较复杂的指标我推荐用bootstrapping来计算,对于概率类或者均值类的这些符合二项分布或者正态分布的指标,建议同时用统计公式和Bootstrapping两种方法来计算。
|
||||
</li>
|
||||
<li>
|
||||
在实践中选取护栏指标的时候,我们主要是从业务品质和统计品质这两个维度来考虑。可以选择的护栏指标有,网络延迟、闪退率、人均指标、**实验/对照组样本大小的比例和实验/对照组中特征的分布等。**
|
||||
</li>
|
||||
|
||||
## 思考题
|
||||
|
||||
你之前在工作中接触过的A/B测试,都会有相应的护栏指标吗?如果有的话,是什么具体的指标呢?这些护栏指标的作用又是什么呢?
|
||||
|
||||
欢迎在留言区写下你的思考和想法,我们可以一起交流讨论。如果你觉得有所收获,欢迎你把课程分享给你的同事或朋友,一起共同进步!
|
@@ -0,0 +1,152 @@
|
||||
<audio id="audio" title="05|选取实验单位:什么样的实验单位是合适的?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/04/86/04424724eef4fcf0172d2c20908ae186.mp3"></audio>
|
||||
|
||||
你好,我是博伟。
|
||||
|
||||
上节课我们确定了实验的目标、假设以及各类指标,那么今天我们就来讲一讲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就有可能一个被分配到实验组,一个被分配到对照组。
|
||||
|
||||
到这里,我们就可以对比着理解下这三个层面了。
|
||||
|
||||
1. 访问层面和页面层面的单位,比较适合变化不易被用户察觉的A/B测试,比如测试算法的改进、不同广告的效果等等;如果变化是容易被用户察觉的,那么建议你选择用户层面的单位。
|
||||
1. 从用户层面到访问层面再到页面层面,实验单位颗粒度越来越细,相应地可以从中获得更多的样本量。原因也很简单,一个用户可以有多个访问,而一个访问又可以包含多个页面浏览。
|
||||
|
||||
看到这儿,你可能觉得信息量有些大,这么多单位,具体操作时到底怎么选呢?不用担心,下面我就通过一个“视频App增加产品功能来提升用户留存率”的具体案例,来带你一步步地选出合适的实验单位。
|
||||
|
||||
## 一个案例:如何选择实验单位?
|
||||
|
||||
某视频App最近收到了不少用户反馈,其中很大一部分用户希望在没有网络或者网络不好的情况下也能看视频。于是,产品经理希望增加“离线下载”的功能,来提高用户的留存率。
|
||||
|
||||
现在,产品经理要通过A/B测试,来看看增加“离线下载”的功能是否真的能提升留存。那应该怎么选取实验单位呢?
|
||||
|
||||
如果把用户层面的ID作为实验单位的话(即把每个用户作为最小单位来分组),由于收集样本的时间比较紧迫,可能收集到的样本量就不够。因此,我们要去寻找颗粒度更细的实验单位,来产生更大的样本量。所以,我们可以选择访问层面或者页面层面作为实验单位。
|
||||
|
||||
数据分析师通过查看发现数据中有访问ID,但没有pageview ID,所以这里选择访问层面,把每一次访问作为最小单位来分组,因为一个用户可以产生多次访问。
|
||||
|
||||
这样一来样本量是足够了,但是我们分析计算实验结果之后发现,实验组的用户的留存率不仅没有上升,反而低于对照组。
|
||||
|
||||
这就很奇怪了,难道是因为“离线下载”功能导致用户体验变差了吗?这不是和之前用户反馈的结果相反了吗?
|
||||
|
||||
于是,我们再次对这些用户进行采访调研,得到的结论确实是用户体验确实变差了,但并不是因为用户不喜欢新增加的功能。那么问题究竟出在哪儿了呢?
|
||||
|
||||
其实,这里的问题就在于选择了不恰当的实验单位。在刚才的实验中,我们把每一次访问作为最小单位来分实验组和对照组,就造成了同一个用户因为有多个访问而被分到了不同的组。
|
||||
|
||||
所以,用户在实验组时可以使用新功能,但是被分到对照组时就会发现没有新功能,让用户很困惑。就好比,昨天你还在用一个很好用的功能今天突然消失了,是不是很沮丧呢?
|
||||
|
||||
所以,当业务的变化是用户可以察觉的时候,我建议你一定要选择用户层面作为实验单位。
|
||||
|
||||
在这种情况下,如果样本量不足,那就要和业务去沟通,明确样本量不足,需要更多的时间做测试,而不是选取颗粒度更小的单位。如果不能说服业务方增加测试时间的话,我们就要通过其他方法来弥补样本量不足会给实验造成的影响,比如增加这次A/B测试使用的流量在总流量中的比例,选用波动性(方差)更小的评价指标等方法(我会在第9节课和你讲这些方法)。
|
||||
|
||||
回过头我们再看看这个案例,是不是可以提炼些选取实验单位的经验和坑点呢?没错儿,我将其归纳为了三个原则:
|
||||
|
||||
1. 保证用户体验的连贯性。
|
||||
1. 实验单位应与评价指标的单位保持一致。
|
||||
1. 样本数量要尽可能多。
|
||||
|
||||
掌握了这三条原则,你就能根据实际情况去选择最佳的实验单位啦!
|
||||
|
||||
## **确定实验单位的三大原则**
|
||||
|
||||
**1.保证用户体验的连贯性**
|
||||
|
||||
保证用户获得最好的体验几乎是所有产品的目标之一,用户体验的连贯性尤其重要,视频App的例子告诉我们:**如果A/B测试中的变化是用户可以察觉到的,<strong><strong>那么**</strong>实验单位就要**<strong>选择**</strong>用户层面</strong>**。**
|
||||
|
||||
否则,同一个用户同时出现在实验组和对照组,就会体验到不同的功能、得到不同的体验。这种体验的不连贯性,就会给用户带来困惑和沮丧,很容易导致用户流失。
|
||||
|
||||
**2.实验单位要和评价指标的单位保持一致**
|
||||
|
||||
为什么这么说呢?我们还得从统计学上入手去理解。
|
||||
|
||||
A/B测试的一个前提是实验单位相互独立且分布相同的(Independent and identically distributed),简称IID。如果两个单位不一致,就会违反相互独立这一前提,破坏了A/B测试的理论基础,从而导致实验结果不准确。
|
||||
|
||||
举个例子。如果用A/B测试来检测音乐App推送新专辑的效果,评价指标为用户的新专辑收听率(收听新专辑的用户数量/收到推送的用户数量),这里评价指标是建立在用户层面上的,那么实验单位一般也要为用户。
|
||||
|
||||
假如我们把实验单位变为新专辑页面层面,由于每个用户可以多次浏览该页面,所以对于同一个用户的多次页面浏览,每次页面浏览其实并不是独立的,IID的假设前提就被破坏了,那么实验结果也就变得不准确了。
|
||||
|
||||
所以,在选择实验单位时,你一定要记住:**A/B测试中的实验单位应与评价指标的单位保持一致。**
|
||||
|
||||
**3.样本数量要尽可能多**
|
||||
|
||||
在A/B测试中,样本数量越多,实验结果就越准确。但增加样本量的方法有很多,我们绝对不能因为要获得更多的样本量,就选择颗粒度更细的实验单位,而不考虑前面两个原则。
|
||||
|
||||
所以我们选取实验单位的第三个原则就是:在保证用户体验连贯性、实验单位和评价指标的单位一致的前提下,可以尽可能地选择颗粒度更细的实验单位来增加样本量。
|
||||
|
||||
那么现在三个原则就讲完啦,我来给你总结下:前两个原则是一定要考虑和满足的,第三个原则则是锦上添花,有条件的情况下可以考虑。
|
||||
|
||||
## **小结**
|
||||
|
||||
这节课,我详细讲解了实践中常用的实验单位及其适用范围,也结合我的实际经验,给你总结了选取不同单位时需要考量的主要因素,让你真正理解并掌握背后的逻辑,从而帮助你在将来的实践中做出正确的判断。
|
||||
|
||||
我还给你总结了一个简化版的决策图,便于你回顾和记忆:
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/65/d0/65b9c0277a2ef429ccd32832057147d0.png" alt="">
|
||||
|
||||
在实践中,我们要考虑的最重要的两点就是:**用户体验的连贯性、实验单位和评价指标单位的一致性**。毕竟用户是上帝,维持好的用户体验适用于所有的业务/产品。所以,针对用户可见的变化(比如UI的改进),大部分的实验都是把用户作为最小的实验单位(用户ID/匿名ID/设备ID),同时也把用户作为评价指标的单位。
|
||||
|
||||
如果你想要更多的样本量,同时A/B测试的变化是用户不易察觉到的(比如推荐算法的提升),可以用比用户颗粒度更细的访问或者页面作为实验单位。与此同时,也要让评价指标与实验单位保持一致。
|
||||
|
||||
## **思考题**
|
||||
|
||||
你平时做A/B测试时,是不是都以用户为单位的?学完了这节课以后,你可以再回想一下,有些A/B测试是不是可以用其他单位?为什么?
|
||||
|
||||
欢迎在留言区写下你的思考和想法,我们一起交流讨论。如果你有所收获,也欢迎你把今天的内容分享给你的朋友,一起共同进步!
|
@@ -0,0 +1,219 @@
|
||||
<audio id="audio" title="06 | 选择实验样本量:样本量越多越好吗?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d1/a0/d1f9112fdc26b26e49f305a8197021a0.mp3"></audio>
|
||||
|
||||
你好,我是博伟。
|
||||
|
||||
前面聊了很多A/B测试的准备工作,我们确定了目标和指标,也选取了实验单位,那么,现在可以正式开始测试了吗?
|
||||
|
||||
先别着急,我们还需要解决正式测试前的最后一个问题:**到底多少样本量是合适的呢?**
|
||||
|
||||
## 打破误区:样本量并不是越多越好
|
||||
|
||||
如果我问你,做A/B测试时多少样本量合适,你的第一反应肯定是,那当然是越多越好啊。样本量越多,实验结果才会越准确嘛!
|
||||
|
||||
从统计理论上来说,确实是这样。因为样本量越大,样本所具有的代表性才越强。但在实际业务中,样本量其实是越少越好。
|
||||
|
||||
为什么会这样说呢?我来带你分析一下。
|
||||
|
||||
要弄明白这个问题,你首先要知道A/B需要做多长时间,我给你一个公式:**A/B测试所需的时间 = 总样本量 / 每天可以得到的样本量。**
|
||||
|
||||
你看,从公式就能看出来,样本量越小,意味着实验所进行的时间越短。在实际业务场景中,时间往往是最宝贵的资源,毕竟,快速迭代贵在一个“快”字。
|
||||
|
||||
另外,我们做A/B测试的目的,就是为了验证某种改变是否可以提升产品、业务,当然也可能出现某种改变会对产品、业务造成损害的情况,所以**这就有一定的试错成本**。那么,实验范围越小,样本量越小,试错成本就会越低。
|
||||
|
||||
你看,实践和理论上对样本量的需求,其实是一对矛盾。所以,我们就要在统计理论和实际业务场景这两者中间做一个平衡:**在A/B测试中,既要保证样本量足够大,又要把实验控制在尽可能短的时间内**。
|
||||
|
||||
那么,样本量到底该怎么确定呢?
|
||||
|
||||
你可能会说,网上有很多计算样本量的网站,我用这些网站来计算出合适的样本量,难道不可以吗?这当然也是一种方法,但你有没有想过,这些网上的计算器真的适用于所有的A/B测试吗?如果不适用的话,应该怎么计算呢?
|
||||
|
||||
事实上,我们只有掌握了样本量计算背后的原理,才能正确地计算出样本量。
|
||||
|
||||
所以,这节课,我会先带你熟悉统计学上的理论基础,再带你进行实际的计算,让你学会计算不同评价指标类型所需的样本量大小。最后,我再通过一个案例来给你串讲下,帮助你掌握今天的内容。
|
||||
|
||||
## **样本量计算背后的原理**
|
||||
|
||||
这里咱们开门见山,我先把样本量的计算公式贴出来,然后再来详细讲解:
|
||||
|
||||
$$<br>
|
||||
\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}}<br>
|
||||
$$
|
||||
|
||||
其中:
|
||||
|
||||
$Z_{1-\frac{\alpha}{2}}$ 为 $\left(1-\frac{\alpha}{2}\right)$ 对应的 $Z$ Score。 $Z_{\text {Power}}$ 为 Power 对应的 Z Score。<br>
|
||||
$\delta$ 为实验组和对照组评价指标的差值。<br>
|
||||
$\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}$,以及两组评价指标的差值δ。因此样本量计算的公式可以简化为:<br>
|
||||
$$<br>
|
||||
\mathrm{n} \approx \frac{8 \sigma_{p o o l e d}^{2}}{\delta^{2}}<br>
|
||||
$$
|
||||
|
||||
现在,我们就可以用这个简化版的公式来估算样本量大小了。
|
||||
|
||||
其中,方差是数据本身的属性(代表了数据的波动性),而两组间评价指标的差值则和A/B测试中的变量,以及变量对评价指标的影响有关。
|
||||
|
||||
以上公式其实是在两组评价指标的综合方差为 $\sigma_{\text {pooled}}^{2}$,两组评价指标的差值为δ的情况下,要使A/B测试结果**达到统计显著性的最小样本量。**
|
||||
|
||||
注意,这里重点强调“最小”二字。理论上样本量越大越好,上不封顶,但实践中样本量越小越好,那我们就需要在这两者间找一个平衡。所以由公式计算得到的样本量,其实是平衡二者后的最优样本量。
|
||||
|
||||
样本量计算出来了,接下来就要分对照组和实验组了,那这里就涉及到一个问题,实验组和对照组的样本量应该如何分配?在这个问题中,其实存在一个很常见的误解。那么接下来,我就带你来好好分析一下样本量分配这个问题。
|
||||
|
||||
### 实验组和对照组的样本量应保持相等
|
||||
|
||||
如果A/B测试的实验组和对照组样本量相等,即为50%/50%均分,那么我们的总样本量(实验组样本量和对照组样本量之和)为:<br>
|
||||
<img src="https://static001.geekbang.org/resource/image/3e/b8/3e573dd7ef99eyy1b520a7c651ab30b8.png" alt="">
|
||||
|
||||
你可能会问,实验组和对照组的样本量必须要相等吗?
|
||||
|
||||
虽然两组的样本量不相等在理论上是可行的,实践中也可以如此操作,但是我强烈不建议你这样做。下面听我来仔细分析。
|
||||
|
||||
一个常见的误解是,如果实验组的样本量大一些,对照组的样本量小一些(比如按照80%/20%分配),就能更快地获得统计上显著的结果。其实现实正好相反:两组不均分的话反而会延长测试的时间。
|
||||
|
||||
为什么会这样呢?因为我们计算的达到统计显著性的最小样本量,是以每组为单位的,并不是以总体为单位。也就是说,**在非均分的情况下,只有相对较小组的样本量达到最小样本量,实验结果才有可能显著,并不是说实验组越大越好,因为瓶颈是在样本量较小的对照组上。**
|
||||
|
||||
相对于50%/50%的均分,非均分会出现两种结果,这两种结果均对业务不利。
|
||||
|
||||
- 准确度降低。如果保持相同的测试时间不变,那么对照组样本量就会变小,测试的Power也会变小,测试结果的准确度就会降低;
|
||||
- 延长测试时间。如果保持对照组的样本量不变,那么就需要通过延长测试时间来收集更多的样本。
|
||||
|
||||
**所以只有两组均分,才能使两组的样本量均达到最大,<strong><strong>并且**</strong>使总样本量发挥最大使用效率,**<strong>从而保证**</strong>A/B测试更快更准确**<strong>地**</strong>进行。</strong>
|
||||
|
||||
你可能会问,这个样本量的估算是在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 – 60%),所以我们希望的差值δ至少为8.2%。
|
||||
|
||||
第二种方法是,如果收益和成本不好估算的话,我们可以从历史数据中寻找蛛丝马迹,根据我在第4节课介绍的计算指标波动性的方法,算出这些评价指标的平均值和波动范围,从而估算一个大概的差值。
|
||||
|
||||
比如说我们的评价指标是点击率,通过历史数据算出点击率的平均值为5%,波动范围是[3.5%, 6.5%],那么我们对实验组评价指标的期望值就是至少要大于这个波动范围,比如7%,那么这时δ就等于2%(7%–5%)。
|
||||
|
||||
### 计算实验组和对照组的综合方差$\sigma_{\text {pooled}}^{2}$
|
||||
|
||||
至于两组综合方差$\sigma_{\text {pooled}}^{2}$的计算,主要是选取历史数据,根据不同的评价指标的类型,来选择相应的统计方法进行计算。评价指标的类型主要分为概率类和均值类这两种。
|
||||
|
||||
概率类指标在统计上通常是二项分布,综合方差为:<br>
|
||||
$$<br>
|
||||
\sigma_{\text {pooled}}^{2}=p_{\text {test}}\left(1-p_{\text {test}}\right)+p_{\text {control}}\left(1-p_{\text {control}}\right)<br>
|
||||
$$
|
||||
|
||||
其中,$p_{\text {control}}$为对照组中事件发生的概率,也就是没有A/B测试变化的情况,一般可以通过历史数据计算得出;$p_{\text {test}}=p_{\text {control}}+\delta$,得出的是期望的实验组中事件发生的概率。
|
||||
|
||||
均值类指标通常是正态分布,在样本量大的情况下,根据中心极限定理,综合方差为:<br>
|
||||
$$<br>
|
||||
\sigma_{p o o l e d}^{2}=\frac{2 * \sum_{i}^{n}\left(x_{i}-\bar{x}\right)^{2}}{n-1}<br>
|
||||
$$<br>
|
||||
其中:
|
||||
|
||||
- n为所取历史数据样本的大小。
|
||||
- $x_{i}$为所取历史数据样本中第i个用户的使用时长/购买金额等。
|
||||
- $\bar{x}$为所取历史数据样本中用户的平均使用时长/购买金额等。
|
||||
|
||||
好了,到这里,这节课的核心内容就全部讲完了。不过为了帮助你更好地掌握这些公式原理和计算方式,现在我就用优化注册流程来增加用户注册率的这个例子,来给你串一下该怎么计算样本大小。
|
||||
|
||||
### 案例串讲
|
||||
|
||||
我们可以根据前面介绍总样本量的公式来计算样本量:
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/a0/bd/a09ed6094ffyy19f3c7baac0f86610bd.png" alt="">
|
||||
|
||||
首先,我们来计算实验组和对照组之间评价指标的差值δ。在前面某App优化用户注册率的案例中,可以看到,我们从成本和收益的角度估算出$\delta_{\text {收支平衡}}$=8.2%。
|
||||
|
||||
其次,我们来计算$\sigma_{\text {pooled}}^{2}$。根据历史数据我们算出注册率大约为60%($p_{\text {control}}$),结合前面算出的$\sigma_{\text {pooled}}^{2}$=8.2%,这时就可以把流程改变后的注册率定为68.2%, 然后再根据概率类指标的计算公式求出$\sigma_{\text {pooled}}^{2}$ = 60%*(1-60%) + 68.2%*(1-68.2%)=0.46。
|
||||
|
||||
最后,我们在A/B测试中把实验组和对照组进行50%/50%均分,利用公式最终求得样本总量为:
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/66/b0/6644bc25879e53d8681d9f3e2a4983b0.png" alt="">
|
||||
|
||||
这样我们就求得每组样本量至少要有548,完成了样本量的计算。
|
||||
|
||||
还记得开头我提到的网上各种各样的A/B测试的样本量计算器吗?比如[这款](https://abtestguide.com/abtestsize/)。如果你仔细研究这些计算器,就会发现这些计算器几乎全部是让你输入以下4个参数:
|
||||
|
||||
1. 原始转化率 $p_{\text {control}}$(Baseline Conversion Rate)。
|
||||
1. 最小可检测提升δ(Minimum Detectable Lift)或者优化版本转化率$p_{\text {test}}$ 。
|
||||
1. 置信水平 (1-α)(Confident Level)或者显著水平α(Significance Level)。
|
||||
1. Statistical Power(1-β)。
|
||||
|
||||
细心的你可能已经发现:上面这些参数都是计算概率类指标要用的参数,所以现在网上的这些样本量计算器只能计算概率类的指标,并不能计算均值类的指标,所以我们在使用时一定要注意要求输入的参数是什么,才能根据不同类型的指标选择正确的计算方法。对于均值类指标,现在网上还没有比较好的样本量计算器,在这种情况下我建议你通过公式来计算。
|
||||
|
||||
为了方便大家日后计算A/B测试中各类指标的样本量,我会在专栏的最后一节课,教大家用R做一个既可以计算概率类指标,还可以计算均值类指标的线上样本量计算器,敬请期待!
|
||||
|
||||
## **小结**
|
||||
|
||||
这节课我们主要学习了怎么确定A/B测试所需的样本量大小,了解了背后的理论基础,我给你总结了影响样本量的四个因素,其中,向上箭头表示增大,向下箭头表示减小。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/16/50/1643bf408780d8621a5d94149f1f1750.png" alt="">
|
||||
|
||||
这里我想要再强调一下,这节课介绍的计算A/B测试样本量的方法,是测试前对样本量的估计值,是为了让A/B测试结果达到统计显著性的最小样本量,所以,只要最终的实际样本量大于最小样本量就行。当然如果业务条件允许的话,样本量自然是越多越好。
|
||||
|
||||
最后我想说的是,当我们用网上的A/B测试样本量计算器时,要注意输入的参数是什么,因为绝大部分的计算器都是让用户输入转化率,只能计算概率类的指标,所以当计算概率类指标时我们可以用网上的计算器,但如果是其他类的指标(如均值类)的话不能用网上的计算器,还是得靠你自己利用公式计算测试所需的最小样本量,或者跟着我在专栏的最后,一起做一个既包含概率类指标,又包含均值类指标的线上样本量计算器。
|
||||
|
||||
## **思考题**
|
||||
|
||||
你有用过网上的A/B测试样本量计算器吗?有没有想过为什么网上大部分的样本量计算器只能算概率类的指标而不能计算均值类指标呢?
|
||||
|
||||
欢迎在评论区留言、讨论,也欢迎点击“请朋友读”,把今天的内容分享给你的同事、好友,和他一起学习、成长。好,感谢你的收听,我们下节课再见。
|
@@ -0,0 +1,200 @@
|
||||
<audio id="audio" title="07| 分析测试结果:你得到的测试结果真的靠谱吗?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/bd/40/bdc43bba782494db6780871c87b85840.mp3"></audio>
|
||||
|
||||
你好,我是博伟。
|
||||
|
||||
经过前面的确定目标和假设、确定指标、选取实验单位、计算所需样本大小后,我们终于来到了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。通过公式我们求得标准误差为:<img src="https://static001.geekbang.org/resource/image/11/68/11bbd59c8bb96e725b0279bc3f31f268.png" alt=""><br>
|
||||
计算出来的结果是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种检验方法的使用场景就可以了:
|
||||
|
||||
1. Z检验(Z Test)
|
||||
|
||||
当评价指标为概率类指标时(比如转化率,注册率等等),一般选用Z检验(在A/B测试中有时又被称为比例检验(Proportion Test))来计算出相应的P值和置信区间。
|
||||
|
||||
1. T检验(T Test)
|
||||
|
||||
当评价指标为均值类指标时(比如人均使用时间,人均使用频率等等),且在大样本量下可以近似成正态分布时,一般选用T 检验来计算相应的P值和置信区间。
|
||||
|
||||
1. 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,还有网上的一些在线工具(比如这个[网站](https://abtestguide.com/calc/)),都可以计算P值。具体选择哪个工具,根据自己的喜好来就可以。我个人比较喜欢选用R来计算:
|
||||
|
||||
```
|
||||
results <- prop.test(x = c(7566, 6303), n = c(315256, 315174))
|
||||
|
||||
```
|
||||
|
||||
因为用户升级率这个评价指标属于概率类指标,所以我们选择了专门针对概率类指标的函数[prop.test](https://www.rdocumentation.org/packages/stats/versions/3.6.2/topics/prop.test)。
|
||||
|
||||
通过计算,我们可以得到P值 < $2.2 e^{-16}$:
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/75/c1/752de9629816c6124ed3d549cae367c1.png" alt="">
|
||||
|
||||
根据统计惯例,一般我们会把测试的显著水平(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](https://www.rdocumentation.org/packages/stats/versions/3.6.2/topics/prop.test)这个函数。
|
||||
|
||||
其实当我们在上面用这个函数计算P值时,R也顺便把95%的置信区间算出来了:<br>
|
||||
<img src="https://static001.geekbang.org/resource/image/75/c1/752de9629816c6124ed3d549cae367c1.png" alt="">
|
||||
|
||||
由图可见,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节课再来好好讨论!
|
||||
|
||||
## **思考题**
|
||||
|
||||
你觉得分析结果前的合理性检验还可以参考哪些护栏指标呢?为什么?
|
||||
|
||||
欢迎在留言区写下你的思考和答案,我们一起交流讨论。如果你觉得有所收获,欢迎你把这一讲分享给你的朋友,邀请他一起学习。
|
@@ -0,0 +1,140 @@
|
||||
<audio id="audio" title="08 | 案例串讲:从0开始,搭建一个规范的A/B测试框架" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e7/22/e706yy6080afee663f338886674eb622.mp3"></audio>
|
||||
|
||||
你好,我是博伟。
|
||||
|
||||
经过前面几节课的学习,相信你不仅掌握了做A/B测试的统计原理,还知道了一个规范的A/B测试的流程是什么样的,以及关键步骤中有哪些需要注意的地方。
|
||||
|
||||
今天这节课的内容,整体来说不会太难,主要是用一个音乐App提升留存率的案例,来串讲一下我们学过的统计知识,以及做A/B测试的几个核心步骤。
|
||||
|
||||
在学习这节课的过程中,一方面,如果你还有一些没有完全搞懂的内容,可以再针对性地复习下,查漏补缺;另一方面,之前几节课的内容容量都比较大,今天的案例串讲相当于帮助你理清思路,清空大脑,然后再有效地去吸收进阶篇的知识。
|
||||
|
||||
好了,那我就通过下面音乐App这个案例,来带你走一遍流程。
|
||||
|
||||
## 从业务问题出发,确定A/B测试的目标和假设
|
||||
|
||||
咱们今天案例里的产品是一款音乐App,用户只要每月付费就可以免广告畅听千万首音乐。当然,除了最基本的播放音乐功能,产品经理还给这款App设计了很多便利的功能,比如用户可以把喜欢的音乐加入收藏夹,可以创建不同的歌单,还可以离线下载以便随时随地畅听自己喜欢的音乐,等等。
|
||||
|
||||
数据科学家通过数据分析也发现,使用这些便利功能的用户往往有着高于平均水平的续订率,说明这些便利功能确实有助于提升用户留存。但是也有一个问题一直困扰着团队:这些功能虽然方便实用,有助于优化用户的听歌体验,但是使用率却一直不高。使用率不高,从长期来看,势必会影响用户留存。
|
||||
|
||||
团队通过用户调研才发现其中的原因。
|
||||
|
||||
由于App的页面设计崇尚简洁,这些功能一般就存放在每首歌曲的功能列表中,而用户往往需要点击两次才能使用:第一次先点击功能列表,第二次再点击具体的产品功能。一方面,很多用户,尤其是新用户,并没有发现这些功能。另一方面,点击两次才能使用,用户体验并不好,慢慢地也就退订了。
|
||||
|
||||
那么,我们现在的目标就非常明确了:**增加用户对产品功能的使用率。**
|
||||
|
||||
如何增加这个使用率呢?你可能会说,把每个功能都直接显示出来,让用户一目了然,不就可以提高它们的使用率了嘛!产品经理刚开始就想到了这一点,但是后来发现功能太多,全部直接显示出来,会让歌曲界面看起来非常杂乱,会让用户体验更糟糕。
|
||||
|
||||
既然产品交互界面的改动被否定了,那么我们可不可以主动告知用户这些功能怎么使用呢?
|
||||
|
||||
比如说,在新用户刚注册登录后就告知他们每个功能的用法。不过这个想法很快也被产品经理否定了,毕竟新用户刚登录时并不会用到所有功能。这很好理解,因为没有需求嘛,新用户在看到这些功能时肯定也没有什么反应,所以新用户在第一次登录时一般都会跳过产品功能介绍。
|
||||
|
||||
之前的A/B测试也验证了这一点。只有在用户有使用这个功能的需求时,再告知他们,才最有效果。
|
||||
|
||||
于是团队的假设就是:**在用户有需求时,通过弹窗的形式告知用户相关使用功能,以此提升相关功能的使用率**。这样的话,既能避免对每一个新用户的打扰,又能满足有需求的用户,两全其美。
|
||||
|
||||
## 确定A/B测试的评价指标
|
||||
|
||||
确定了目标和假设之后,就可以开始定义评价指标了。
|
||||
|
||||
团队准备先拿“把喜欢的音乐加入收藏夹”这个功能来做一个A/B测试,验证以上的假设是否成立。
|
||||
|
||||
因为要在用户有需求的时候再告知用户,所以我们就需要一个条件来触发这个告知。那么,我们的首要任务就是**确定触发条件**:只有当用户从来没有用过这个功能(如果用户知道这个功能的话我们就没有必要告知了),并且播放同一首歌曲达到x次时(以此来判断用户对某首歌曲的喜爱程度),我们才会给用户发送弹窗通知。
|
||||
|
||||
经过数据科学家的数据分析,最终确定了x的最优值为4,所以该功能的弹窗的最终触发条件为:
|
||||
|
||||
- 该用户从来没用过“把喜欢的音乐加入收藏夹”这个功能。
|
||||
- 该用户已经对某首歌听了4次,当播放第5次时触发弹窗。
|
||||
|
||||
需要说明的是,因为弹窗是为了要告知用户,不需要重复提醒,所以每个符合触发条件的用户也只能收到一次,不能多次触发。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/1e/ac/1e95041c0ea9f0494b3c3110d04eb0ac.png" alt="">
|
||||
|
||||
在这个A/B测试中把用户随机分为实验组和对照组,每组50%。
|
||||
|
||||
- 在实验组中,如果用户满足了触发条件,系统就会发送弹窗提醒(如上图)。
|
||||
- 在对照组中,用户不会收到弹窗提醒,不管是否符合触发条件。
|
||||
|
||||
确定了目标和假设,现在我们来具体定义下评价指标:
|
||||
|
||||
**“把喜欢的音乐加入收藏夹”功能的使用率 = 使用了“把喜欢的音乐加入收藏夹”的用户总数 / 实验中的用户总数。**
|
||||
|
||||
很明显,这是一个概率类的指标,也就是说在实验中的这些用户,使用了“把喜欢的音乐加入收藏夹”这个功能的概率有多少。不过,为了使我们的评价指标更加具体,也方便之后的计算,所以这里我们要搞清楚两个问题。
|
||||
|
||||
**第一个问题,如何定义“实验中的用户”?**
|
||||
|
||||
鉴于用户只有满足了条件才会触发弹窗,并不是所有在实验中的人都会受到影响,所以测试时不能用所有被分配在实验中的用户,因为这样就会引入没有受到影响的用户(那些被分配在实验中但是却没有满足触发条件的用户),从而降低测试的准确性。所以一定要注意,这里的“实验中的用户”应该是符合触发条件的用户(下图中虚线部分)。
|
||||
|
||||
在实验组中就是触发弹窗的用户,在对照组中则为符合触发条件的用户(因为对照组中的用户不管符合不符合触发条件都不会触发弹窗)。<br>
|
||||
<img src="https://static001.geekbang.org/resource/image/f0/2f/f0fe9cd48fc055f77d95d1413f8dac2f.png" alt=""><br>
|
||||
**第二个问题,如何确定用户从触发弹窗开始到最终使用功能的时间窗口期呢?**
|
||||
|
||||
因为本次A/B测试是要检测弹窗是否会对相关功能的使用率有所提升,而且每个用户触发弹窗的时间不同,所以需要事先规定一个统一的时间窗口期来衡量,比如触发后x天之内的使用率,这样统一化是为了使指标更加清晰准确。
|
||||
|
||||
因为弹窗告知在这里具有及时性,及时性也就是说在用户有需求时,所以如果用户是受到弹窗的影响才使用相关功能时,肯定会在看到弹窗不久后就使用了。我们这里就把x设为1,即触发后1天内的使用率。
|
||||
|
||||
搞清楚了这两个问题,我们就可以把评价指标最终定义为:<br>
|
||||
**“把喜欢的音乐加入收藏夹”功能的使用率 = 在符合触发条件后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%。
|
||||
<li>对照组:样本量为80689,符合触发条件一天之内使用功能的用户为1598,使用率为1.98%。<br>
|
||||
<img src="https://static001.geekbang.org/resource/image/ca/4b/ca7cb0f33a0fa3e9d485d975ce1ff04b.png" alt=""></li>
|
||||
|
||||
根据结果我们得到的P值接近于0而且远远小于5%,同时我们计算出两组评价指标差值的95%的置信区间为[1.72%,2.05%],不包括0,说明这两组的使用率显著不同,事实上实验组的使用率几乎等于对照组的两倍,证明了在用户需要时的弹窗提醒确实有效果!
|
||||
|
||||
得到这个振奋人心的结果后,团队决定把“把喜欢的音乐加入收藏夹”功能的弹窗提醒推广到所有符合触发条件的用户,同时也计划对其他功能的弹窗做类似的A/B测试,来验证它们的效果。如果一切进行顺利的话,就将这些弹窗全部推广,长期来看肯定会增加用户的留存率!
|
||||
|
||||
**小结**
|
||||
|
||||
通过这个案例串讲,你肯定对做A/B测试的关键步骤有了更具体、更深层次的认识了。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/ae/c6/ae4816aeb940032499b93aa5bc6039c6.png" alt="">
|
||||
|
||||
那么基础篇的内容到这里也就结束了。接下来我们就会进入到进阶篇的学习。
|
||||
|
||||
在进阶篇,我会给你讲解更多偏经验和方法论的知识。针对做A/B测试时经常出现的一些问题,我会给你讲解它们的成因,给出解决办法。针对面试中常出现的一些考点,我会结合我做面试官的经验,来给你一些解题思路。
|
||||
|
||||
最后我还想强调一下,学习这件事本来就是反复和持续的。进阶篇的内容会和基础篇有不少联系。所以在学习进阶篇的课程时,我也希望你能够不断温习、思考之前学过的知识。待课程结束,再回头看基础篇这些内容,相信你会有一种“蓦然回首,原来A/B测试如此简单”的畅快感和收获感。
|
||||
|
||||
**思考题**
|
||||
|
||||
回忆你之前做过或者经历过的A/B测试,它们是否有这些基本的流程步骤?如果缺少的话,是缺少哪些步骤,为什么?如果还有其他步骤,也和我分享一下吧。
|
||||
|
||||
如果你学完今天的案例串讲,对A/B测试的流程、步骤有了更清晰的认识,欢迎你点击“请朋友读”,把今天的内容分享给你的同事、好友,大家一起学习、成长。好,感谢你的收听,我们进阶篇的课程再见。
|
@@ -0,0 +1,39 @@
|
||||
<audio id="audio" title="导读 | 科学、规范的A/B测试流程,是什么样的?" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/50/5b/5082af91d3e6d68yyedf949de494335b.mp3"></audio>
|
||||
|
||||
你好,我是博伟。
|
||||
|
||||
前面两节课啊,我们花了很大力气去学习做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测试都要经历的,我把它们总结在一张图中,你可以看一下。
|
||||
|
||||
<img src="https://static001.geekbang.org/resource/image/86/e5/86a26b183d53e37a247d54f06e38bae5.png" alt="">
|
||||
|
||||
以上就是一个规范的做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测试的旅程吧!
|
Reference in New Issue
Block a user