专栏首页巡山猫说数据「原理」AB测试-案例串讲及踩坑事项

「原理」AB测试-案例串讲及踩坑事项

上篇文章我们详细的解读了AB测试的原理及流程。今天我们来结合流程,讲讲具体的AB测试案例,以及AB测试中需要注意的问题,还有面试中可能会踩的坑。

AB测试案例串讲

我们先来按照上节课的流程串讲一个案例。

大体背景如下:

某社交APP增加了“看一看”功能,即用户之间可以查阅到对方所填写的一些基础信息。现在要分析该功能,是否有效果。

我们得到这个问题,需要脑子里想到AB测试的整体流程图(如下)。

从流程图中,我们需要想到几个问题:

1、实验前:如何选指标,如何做假设,如何选实验单位,根据实验指标和单位,如何计算最小样本量,以及实验的周期

2、实验中:需要验证是否所有用户仅处于同一个桶,还需要验证线上实验桶策略是否符合预期

3、实验后:需要回收数据,通过计算P值或者置信区间Diff的方法,校验该功能是否有效

从该功能来说,我们需要考虑的主要指标是用户之间建立联系的率值是否有提升。因为社交是为了让用户之间建立联系,增加这种查阅资料的功能,是为了让用户通过资料查阅,与感兴趣的用户建立联系。

所以该功能,我们的指标选择为加好友率。这时候,零假设就是该功能无效果,即两个桶的加好友率无明显差异。备选假设则相反。实验单位我们为了避免数据的不置信,我们选择以用户为实验单位。

假设我们的原有添加好友率如下 ,那么我们计算整体样本量如下:

P:45%,p:47%(由于波动范围是[44%,46%],所以至少是2.0%)

总样本量 = 16 * (45%*(1-45%)+ 47%*(1-47%))/ (47%-45%)^2 = 19864

由于实验桶和基线桶的比例是1:1,所以我们分配为实验桶1w样本,基线桶1w样本量。但是由于我们不能一上来就全量试验,所以我们开20%的流量为实验桶(假设DAU的20%是2000/天,即实验桶的DAU为2000/天),那么,我们预计要实验5天(1w/2000)。

但是通过计算,用户的一次活跃周期是7天,所以我们为了让实验效果可信度更高,计划实验7天。

实验上线后,我们对线上数据进行了验证,确认了以下两个问题:

1、实验策略在实验桶已生效,在基线桶未生效。即相关的看一看功能在实验桶已上线,基线桶保持原样;

2、同一个用户仅处在同一分桶中,未出现一个用户处于两个桶的情况。

实验到期后,我们对线上数据进行了回收。由于我们这个是相对值指标,所以我们使用Z检验。

检验方法有以下两种:

1、算P值,P值小于5%,拒绝原假设,即产品功能有效果。这个场景中(假设)P=0.002,即我们判断产品有效果。

2、算执行区间的差值,如果不含0,则拒绝零假设。同样,我们这里假设算出来期间不含0,我们认为该产品有效果。

以上,就是一个整体的AB实验案例。我们从筛选指标,到设计实验(选取实验单位,计算最小样本量,计算实验周期),到实验上线,再到后面的效果验证。

但是不知道大家注意没有,这个实验有些地方设计的并不合理。因为社交用户之间会有网络效应,即一个用户会影响另一个用户,所以我们实验分桶这么设计并不合理。

AB测试注意事项

下面,我们就来讲讲AB实验的注意事项。

1、网络效应:

这种情况通常出现在社交网络,以及共享经济场景(如滴滴)。举个例子:如果微信改动了某一个功能,这个功能让实验组用户更加活跃。但是相应的,实验组的用户的好友没有分配到实验组,而是对照组。但是,实验组用户更活跃(比如更频繁的发朋友圈),作为对照组的我们也就会经常去刷朋友圈,那相应的,对照组用户也受到了实验组用户的影响。本质上,对照组用户也就收到了新的功能的影响,那么AB实验就不再能很好的检测出相应的效果。

解决办法:从地理上区隔用户,这种情况适合滴滴这种能够从地理上区隔的产品,比如北京是实验组,上海是对照组,只要两个城市样本量相近即可。或者从用户上直接区隔,比如我们刚刚举的例子,我们按照用户的亲密关系区分为不同的分层,按照用户分层来做实验即可。但是这种方案比较复杂,建议能够从地理上区隔,就从地理上区隔。

2、学习效应:

这种情况就类似,产品做了一个醒目的改版,比如将某个按钮颜色从暗色调成亮色。那相应的,很多用户刚刚看到,会有个新奇心里,去点击该按钮,导致按钮点击率在一段时间内上涨,但是长时间来看,点击率可能又会恢复到原有水平。反之,如果我们将亮色调成暗色,也有可能短时间内点击率下降,长时间内又恢复到原有水平。这就是学习效应。

解决办法:一个是拉长周期来看,我们不要一开始就去观察该指标,而是在一段时间后再去观察指标。通过刚刚的描述大家也知道,新奇效应会随着时间推移而消失。另一种办法是只看新用户,因为新用户不会有学习效应这个问题,毕竟新用户并不知道老版本是什么样子的。

3、多重检验问题:

这个很好理解,就是如果我们在实验中,不断的检验指标是否有差异,会造成我们的结果不可信。也就是说,多次检验同一实验导致第一类错误概率上涨;同时检验多个分组导致第一类错误概率上涨。

举个例子:

出现第一类错误概率:P(A)=5%

检验了20遍:P(至少出现一次第一类错误)

=1-P(20次完全没有第一类错误)

=1- (1−5%) ^20

=64%

也就是说,当我们不断的去检验实验效果时,第一类错误的概率会直线上涨。所以我们在实验结束前,不要多次去观察指标,更不要观察指标有差异后,直接停止实验并下结论说该实验有效。

AB测试面试踩坑

针对这些问题,有很多时候,面试官在问问题时,会设下一些坑,我们来举两个例子。

例1:滴滴准备升级司机端的一个功能,该如何校验功能效果?

考点1:常见的AB测试流程设计

考点2:网络效应

解法:

针对考点1:AB测试的流程是 确定目标 --> 确定实验单位 --> 确定最小样本量 --> 确认流量分割方案 --> 实验上线 --> 规则校验 --> 数据收集 --> 效果检验

针对考点2:实验分桶,以两个量级相近城市分割,避免网络效应的相互影响

例2:某app,用户活跃周期是14天,这时,上线了一个实验,计划跑20天在看效果,结果有位新同学,在10天时做了统计推断,发现数据已经有了显著差异,认为可以停止实验,这样做对吗?

考点1:实验周期应该跨越一个活跃周期

考点2:多重检验问题

解法:

由于AB测试的实验周期尽量跨越一个用户活跃周期,且在实验结束时再做统计推断,所以该做法不对,建议跑慢20天再看数据效果

知识点总结

以上,我们就讲完了整体的AB测试案例,以及AB测试中需要注意的问题。

我们来总结下知识点:

1、由于用户之间的相互影响,可能产生网络效应,导致AB测试用户分隔达不到预期,所以我们要尽量从地理上去区隔用户进行实验;

2、由于用户的学习效应,我们的一些改动会引起老用户的好奇或不满,这时候,我们可以拉长实验周期,或者仅用新用户进行实验。

3、由于多重检验问题的存在,我们不要频繁的在实验中检验数据,更不要未到实验结束就下结论说实验有效。

以上,这三个问题,以及上篇文章中的AB测试具体流程,都是大家在工作中需要掌握的知识。在面试过程中很多面试官也会设陷让我们往里跳。大家需要注意一下。

本文分享自微信公众号 - 巡山猫说数据(sven994777),作者:巡山猫

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-04-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • SparkSQL在有赞大数据的实践(二)

    在 2019 年 1 月份的时候,我们发表过一篇博客 SparkSQL在有赞大数据的实践,里面讲述我们在 Spark 里所做的一些优化和任务迁移相关的内容。本文...

    有赞coder
  • 「原理」AB测试-详细过程和原理解读

    AB测试最核心的原理,就四个字:假设检验。检验我们提出的假设是否正确。对应到AB测试中,就是检验实验组&对照组,指标是否有显著差异。

    巡山猫说数据
  • mysql uftb8mb4 储存 emoji 表情失败

    OK 没问题,设置 nick_name 为 utf8mb4 varchar(50)

    用户2141593
  • 我的开发日记(十二)

    这两天继续联调,做一些细节的修改,总体来讲问题不大。总结如下:踩了一个坑,学到了数据库回滚。

    FunTester
  • 盘点 2020 | 我要为分布式数据库 MongoDB 在国内影响力提升及推广做点事

    MongoDB是一款功能完善的分布式文档数据库,在高性能、动态扩缩容、高可用、易部署、易使用、海量数据存储等方面拥有天然优势。虽然MongoDB有很多优势,但是...

    MongoDB中文社区
  • 作为 Java 工程师,你的 Spring 用对了吗?

    这些年,Spring 几乎是 Java 开发的标配,好用归好用,但确实也有不少坑,很多“坑”隐藏的还相当隐蔽,下面这些问题,估计你都遇到过:

    码哥字节
  • 小程序框架选型必看:Taro vs uni-app选型经历!

    公司新产品要求发布到各家小程序,最近研究对比了社区主流的几家小程序开发框架,独坑不如拉人众坑,分享给各位,欢迎和我一起入坑:)

    极乐君
  • 如何快速处理线上故障

    线上故障通常是指大规模的影响线上服务可用性的问题或者事件,通俗点讲就是:掉“坑”里了,这个“坑”就是线上故障!线上故障的处理过程可以形象地表达为:“踩坑”、“跳...

    嘉为科技
  • 【Unity游戏开发】AssetBundle杂记--AssetBundle的二三事

      马三在公司大部分时间做的都是游戏业务逻辑和编辑器工具等相关工作,因此对Unity AssetBundle这块的知识点并不是很熟悉,自己也是有打算想了解并熟悉...

    马三小伙儿
  • 重构一时爽,构错火葬场

    我相信每个接受过老项目的程序员可能都吐槽过 “前人的代码都是屎”。一个已经有些年头的项目,几乎肯定可以看到——到处拷贝来拷贝去的代码,随处可见的拼写错误,头重脚...

    用户1516716
  • Java开发中如何正确踩坑

    之前在这个手册刚发布的时候看过一遍,当时感觉真是每个开发者都应该必读的一本手册,期间还写过一篇关于日志规约的文章:《下一个项目为什么要用 SLF4J》,最近由于...

    Java团长
  • React Native 音频录制例子来解惑入门

    用户1130025
  • 【腾讯 TMQ】不会做 bug 分析?套路走起~

    说起bug分析,测试同学都不陌生。那么,我们为什么要做bug分析?如何做bug分析?又怎样落实bug分析的效果呢?本文来跟你聊聊bug分析的那些事儿......

    腾讯移动品质中心TMQ
  • PyTorch常见的坑汇总

    最近刚开始用pytorch不久,陆陆续续踩了不少坑,记录一下,个人感觉应该都是一些很容易遇到的一些坑,也在此比较感谢帮我排坑的小伙伴,持续更新,也祝愿自己遇到的...

    Datawhale
  • 如何学习源码 | 如何高效学习一个新知识

    如果你不是一个走在行业最前端的人,那么你踩过的坑,一定有前人踩过。你想学的东西,也一定有前辈早已研究透彻。

    scarsu
  • 前任写的代码太垃圾怎么办?

    一个已经有些年头的项目,几乎肯定可以看到——到处拷贝来拷贝去的代码,随处可见的拼写错误,头重脚轻的函数……再看一看当年的提交者,可能是公司里的元老,甚至是大bo...

    Java技术栈
  • Bytom Dapp 开发笔记(二):开发流程

    这章的内容详细分析一下涉及智能合约Dapp的整个开发流程,注意是涉及只能合约,如果你只要一些基本转BTM功能没有太大意义,本内容补充一下官方提供的 比原链DAP...

    比原链Bytom
  • 如何优化让日志处理速达到 5万/s?

    本文来自作者 jason 在 GitChat 上分享 「大数据项目性能优化实战分享」

    CSDN技术头条
  • 年前最后一周的正确打开姿势,写一份项目总结吧

    2019-12-16 关于作者 宜娜,腾讯CSIG部门员工 导语I之前有段时间研究了下达利欧的《原则》这本书,里面提到了一点:要做一个透明人,对自己对他人都做...

    腾讯大讲堂

扫码关注云+社区

领取腾讯云代金券