生成式AI领域的最新成果都在这里!抢 QCon 展区门票 了解详情
写点什么

增长黑客必看的 11 个 AB 测试问答

  • 2020-04-08
  • 本文字数:4569 字

    阅读完需:约 15 分钟

增长黑客必看的11个AB测试问答

AB 测试是一种用数据驱动产品迭代的解决方案,使用 AB 测试驱动产品业绩增长的方法,深受 Google,Facebook,微软,百度,腾讯,阿里等众多公司青睐。Testin 云测是业界第一家提供全生命周期 AB 测试服务的企业,对应用发布前和发布后的产品实验需求提供了完整的解决方案,已帮助数千家客户有效提升了 Web/H5、Android、iOS、小程序等应用的转化率、留存率、点击量、成交额等核心业务指标。

2017 年 12 月 28 日,Testin 副总裁、AB 测试首席顾问陈冠诚在 Gitchat 上为大家分享了如何用 AB 测试驱动产品增长的心得体会。



以下为整理后的访谈内容——


问题 1:AB 测试如何与版本管理结合,比如 Git?它是通过开启多个分支来进行的吗,能否同时灰度多个功能?只有一台服务器能做灰度测试吗,是否每进行一个 AB 测试就需要一台服务器?


:我将这个问题拆成几个部分来回答。


一个基本的 AB 测试系统,有两个核心模块:分流系统和数据统计系统。AB 测试系统当然可以跟 Git 这样的版本管理系统结合。


举例,如果是原始版本页面的后端接口基于 Http 协议,新版本的后端接口基于 Https 协议,两个版本在不同的代码分支里,分别进行部署之后,要利用 AB 测试系统的分流模块,将一定比例的用户分流到新接口进行灰度测试,同时其他用户分流到老接口。


在此过程中通过分流系统完成新老接口的用户流量分配以及灰度测试。


利用 AB 测试系统同时灰度多个功能也是可以的。如果要进行灰度测试的功能相互独立,只需要同时为不同的功能进行用户分流即可。


只有一台服务器也能做灰度测试,例如需要灰度测试的新老接口可以同时部署在同一台服务器上,再通过用户分流进行灰度测试。


同样,并不是每进行一个 AB 测试就需要一台服务器,具体需要多少服务器资源,取决于进行灰度测试的应用服务器的负载压力等其他情况。


问题 2:自建 AB 测试工具在人力、资金、时间等方面大概需要多少成本,可以从哪些方面入手?


:自建 AB 测试工具方面需要多少成本,给大家一个参考:BAT 这种量级的公司,从零开始做一个通用的 AB 测试系统,需要大概 8-10 位工程师做 0.5-1 年的时间才能出一个基本的、可用的系统。


当然,如果仅仅只是实现一个最基本的 AB 测试系统,例如最基本的分流功能和最基本的统计功能,耗费时间会短一些。


仅就分流这个功能模块来说,最基本的分流方式(例如基于 client id、cooike 做随机分流)在一些场景下其实是不太能满足需求的,例如他们不能保证唯一性、相似性。


  • 唯一性:在流量分配不变的情况下,同一个用户每一次重新访问这个 app 或者打开这个网页被分配的版本应该前后一致。不能今天登陆 app 分到版本 A,明天登登录的时候就跳到版本 B 了。版本前后不一致会导致实验结果不可信,因为引入了额外的干扰因素。

  • 相似性:分流后的不同用户群体的整体特征相似。例如不能 A 组人群中 iPhone7 用户特别多,而 B 组人群中 iPhone8 用户特别多,如果人群特征不相似,也会干扰实验结果的准确性。


统计模块也是类似,除了最基本的转化率、点击量等指标之外,一个合格的 AB 测试系统最基本的指标还应该包括置信区间、p-value、统计功效等。


如果你对实现一个 AB 测试系统感兴趣,可以参考 2 篇论文。分别是 Google 的《Overlapping Experiment Infrastructure: More, Better, Faster Experimentation》和 Facebook 的《Designing and Deploying Online Field Experiments》。


问题 3:使用 TestinData.AI 提供的 AB 测试系统,在人力、资金、时间的成本是怎样的?


:TestinData.AI 是一个第三方的工具,所提供的 AB 测试支持 SaaS 交付和私有化部署交付两种方式。以 SaaS 交付为例,如果选择直接使用 TestinData.AI 的 AB 测试系统,我们就不需要再去管分流、统计、可视化编辑等功能该怎么实现,而且直接用就好了。


最简单的情况下,只需要一个产品经理和一个开发,就可以每周跑几十上百个 AB 测试了。


这也是像 TestinData.AI 这样的第三方 AB 测试工具最大的价值:开箱即用,把注意力放在业务如何开展 AB 测试和如何提高转化率上面,而不是费力气搭建工具。


对我们产品感兴趣的朋友,可以直接访问 http://ab.testin.cn ,申请试用。



问题 4:做 AB 测试是否有建议的时长?假如一个选择必须在 3 天内做出,是不是意味着没时间做 AB 测试了?如果强行做测试,是否会因为测试时间太短而造成结果有偏向?


:一般来说,建议一个实验最少运行一周,这样能覆盖工作日和周末的场景。一个实验周期从一周到一个月是比较常见的。


如果一个选择必须在 3 天内做出,其实也可以做 AB 测试。这个时候,需要注意的就是:


  • 参与测试的样本量是否够;

  • 得出的统计结果的置信区间、统计功效、统计显著性等指标是否证明新版本跟老版本之间存在显著的统计学差异;

  • 因为这个结论是 3 天之内得出的,它在放到其他时间段时,是否会因为时间因素(例如假期等)而产生干扰?


例如电商秒杀活动,要做两个不同的广告物料,不确定哪个版本效果好,所以做了一个 AB 测试,但是必须一天就出结论,因为这个活动本身只持续 3 天,就是类似你说的情况。


此外,遇到这种情况,我们推荐使用 TestinData.AI 的智能优化功能,放弃传统 AB 测试,直接优化这 3 天的整体转化率。该功能基于强化学习的智能优化引擎,实时持续动态分析不同产品版本转化率数据,并进行智能流量调节,无需人工干预,即可自动提升转化率。


问题 5:微软 Bing 搜索引擎从 08 年的每周 20-30 个到 15 年之后的每周 400 多个,很明显他们很看重 AB 测试的重要性,请问 AB 测试数量增长的过程中,有没有什么是需要额外注意的问题?如何平稳过渡?


:这个问题,我需要拿出一个数据和大家分享:



这张图里面的 4 个阶段,就是一个企业内部 AB 测试系统从起步到成熟所经历的阶段。简单来说,从组织架构、AB 测试系统的技术架构、实验评价体系都会经历很多发展和变化,具体细节大家可以参考截图里提到的点。


还是一句话,罗马不是一天建成的,像 Bing 这样从 08 年到 15 年,7 年的时间,又有足够的资源,业务也在稳定发展,才完整实现了从 0 到 100 的过程。


其实我们在跟很多企业合作的过程中发现,很多公司的产品运营同学都听过 AB 测试,但是没有实际动手做过,不过他们又很清楚 AB 测试的价值,所以选择跟 Testin 合作,快速地将 AB 测试在公司内部推进起来。


问题 6:对同样两个页面做 AB 测试,运行 1 次就能得出结果,还是需要运行 10 次甚至 100 次,这取决于什么?如果运行 100 次中只有 1 次说明 A 是最佳选择,99 次都说明 B 是最佳选择,这时是否说明 B 是当下的最佳选择?


:一般来说,如果你有一个靠谱的 AB 测试系统的话,只要运行一次 AB 测试就能对两个页面的转化率优劣做一个结论了。


两个页面的转化率的优劣取决于 AB 测试的数据。这里面需要牵涉到一些统计学的概念,我给大家举一个例子。


假设我们对两个页面进行 AB 测试,页面 A 用了 5% 的真实用户流量参与了实验,它的转化率是 6.9%,页面 B 也用了 5% 的真实用户流量参与了实验,测试出的转化率是 7.2%,那么我们知道页面 B 的转化率比页面 A 的转化率提升了 4.17%。


但是,这百分之 4 点几的提升,只是在两个版本各 5%、共 10% 的用户测试流量下得出的结论,它是否足够可信呢?这就需要我们拿到 95% 置信区间、统计功效、统计显著性等数据了。


这些数据的概念我就不在这里详细解释了,我还是拿一个样例数据来给大家解释下。


例如,还是在前面那个例子中,页面 B 在 5% 测试人群中转化率是 7.2%,它的 95% 置信区间是 [+1.7%, 6.6%],那么说明页面 B 如果推广给全部用户之后,95% 的概率下,至少会比页面 A 提升 1.7%,至多会比页面 A 提升 6.6%。


基于这个统计数据,我们有理由相信,页面 B 如果真的全量上线后,确实大概率下会比页面 A 的转化率更好,这也是 AB 测试基于统计算法去做决策的理论依据所在。


相反,如果页面 B 的 95% 置信区间是 [-10.4%, 24.8%],那说明页面 B 如果推广给全体用户,不一定会比页面 A 的转化率更高,因为他可能出现转化率下降 10.4%。


同样,一个靠谱的 AB 测试系统,除了 95% 置信区间之外,还会提供 p-value、power 等统计相关的数据结果,它们都是用来帮助使用者分析实验结论是否 “靠谱” 用的。


问题 7:就落地页而言,如果一个页面在原版本的基础上改动了多处,既改了颜色又改了文案,改了位置还改了背景图,变得大相径庭,这只叫做两个方案 PK 而不是 AB 测试了吗?


:这也是 AB 测试,叫做多变量测试。所谓多变量测试,是相对于单变量测试而言的。单变量测试的情况下,不同版本之间只有一个变量,例如按钮的颜色。


如果不同版本直接有多处变量不同,就像你说的(一个页面在原版本的基础上改动了多处,既改了颜色又改了文案,改了位置还改了背景图,变得大相径庭),那就是多变量测试。


单变量测试最大的好处是可以做归因分析。因为不同版本之间,只有一个变量是变化的,那么不同版本转化率等指标的优劣,可以归因到这个变量上去。


而多变量的情况下,虽然可以比较出不同版本的优劣,但是不能直接将版本的优劣归因到某个单一变量上去,因为可能是多个变量综合影响才导致指标的变化。


在实际应用中,之所以会要做多变量测试,是因为大家想尽快实现产品的优化、以提升转化率等核心业绩指标。


因为多变量虽然不能归因到具体是因为哪个改动造成了转化率的提升,但是因为在一个测试周期里,就对多个变量进行了对比测试,所以可以达到尽快实现转化率提升的目的。


问题 8:多变量测试中,如果想确定是改了哪个真正起效了,是否需要进行更多的 AB 测试?


:是的,如果你需要确定到底是哪个变量造成了转化率的变化,那么就需要再做更多的测试。


当然,实际场景中,可能没必要去做,因为时间永远是有限的。如果一个新版本已经提升了 15% 的转化率,下一次迭代就会基于这个版本再去做优化了。


问题 9:一个电商类型的互联网项目,大概用户量到什么样的规模之上适合用 AB 测试?


:一般来说,如果每个实验版本的用户量可以在 1000 人以上,就可以尝试 AB 测试了。具体每个实验需要多少样本量,Testin 专门有样本量计算器来帮大家进行计算。


问题 10:同一个站点有多个 AB 测试时,一个用户是否会同时分流到多个功能点上?


:这取决于分流机制是怎么设计的。如果是简单的基于用户 id 进行分流的话,不同功能点的 AB 测试分别占用了不同的用户 id 群,那么就不会出现一个用户同时分流到多个功能的 test 的情况。


如果是像 Testin 这样拥有分层分流机制的 AB 测试系统,如果两个功能点的实验分别处在不同的用户流量层,是有可能出现一个用户同时分到不同功能点的 AB 测试的情况的。


问题 11:挑选分流用户的逻辑和维度一般有哪些?


:常见的设备标签、用户的业务标签都可以拿来做分流。例如,机型、操作系统、语言、版本号等等。


如果做定向分流实验,例如只对 iPhone8 的一线城市的 VIP 用户做实验,那就同时需要手机的设备标签和用户的业务标签了。




AB 测试本质上是个分离式组间实验,以前进行 AB 测试的技术成本和资源成本相对较高,但现在一系列专业的实验工具的出现,AB 测试已越来越成为网站、App 优化常用的方法。你可以将你设计的诸多版本都丢到 TestinData.AI 的 AB 测试系统上去,一个个测试他们的转化能力。


不过,除了传统 AB 测试之外,还有一个更高效的办法:用 TestinData.AI 的智能流量调节引擎,根据转化率自动变更流量分配、高效执行智能选优。


2020-04-08 19:37953

评论

发布
暂无评论
发现更多内容

古董系统的并发安全改造

hasWhere

模块八作业

河马先生

架构实战营

架构实战营-模块八作业

老实人Honey

架构实战营模块8作业

zlz

网络攻防学习笔记 Day143

穿过生命散发芬芳

9月日更 虚拟化技术

架构实战营模块八作业

技术是伙伴

架构实战营

模块8作业

脉动

JavaScript进阶(六)继承

Augus

JavaScript 9月日更

产品分析:如何给出解决方案?

石云升

产品经理 产品思维 9月日更

【LeetCode】最后一个单词的长度Java题解

Albert

算法 LeetCode 9月日更

【架构设计模块八】:设计消息队列存储消息数据的 MySQL 表格

Ryoma

架构设计的一些思考

hasWhere

过滤器、拦截器、监听器

hasWhere

TCP/IP参考模型与标准协议

Regan Yue

TCP/IP 9月日更

中秋晴朗夜,我们与星月相见

白洞计划

技术圈的【多肉小达人】,一篇文章你就能做到

梦想橡皮擦

9月日更

数据仓库的数据从哪来?

奔向架构师

数据仓库 9月日更

SpringMVC源码分析-HandlerAdapter(2)-RequestMappingHandlerAdapter的初始化

Brave

源码 springmvc 9月日更

JVM启动参数学习笔记三

风翱

JVM 9月日更

手机测试岗位常见面试问题汇总(持续更新中)

IT蜗壳-Tango

9月日更

《转》搭建websocket消息推送服务

hasWhere

Vue进阶(幺贰肆):前端用户体验提升(一)

No Silver Bullet

用户体验 9月日更

模块四作业

Geek_fc100d

「架构实战营」

Elasticsearch 源码学习(1)源码编译调试

Se7en

高可用延迟队列设计与实现

万俊峰Kevin

微服务 延迟队列 microservice Go 语言 定时队列

Ember.js 项目开发之 Ember Data

devpoint

ember.js 9月日更

架构实战营-模块八作业

以吻封笺

python学习笔记:day1——python入门了解

秦时明月

Python编程

缓存系统设计与实现

hasWhere

架构训练营-模块八作业

hello

架构训练营

架构训练营模块八作业

喻高咏        

架构训练营

增长黑客必看的11个AB测试问答_文化 & 方法_云测数据_InfoQ精选文章