写点什么

Twitter 的 A/B 测试实践(一):为什么要测试以及测试的意义

2016 年 3 月 13 日

【编者的话】A /B 测试曾在多个领域产生深远的影响,其中包括医药、农业、制造业和广告。 在软件开发中, A/B 测试实验提供了一个有价值的方式来评估新特性对客户行为的影响。在这个系列中,我们将描述 Twitter 的 A/B 测试系统的技术和统计现状。

本文是该系列的第一篇,主要介绍了为什么进行 A/B 测试和如何避免其中的陷阱。

注:本文最初发布于 Twitter 博客,InfoQ 中文站在获得作者授权的基础上对文章进行了翻译。

正文

实验是 Twitter 产品开发周期的核心。这种实验文化可能是因为 Twitter 对工具、研究和培训进行了大量的投资,以确保特性团队能够对他们的想法进行无缝、严格的测试和验证。

Twitter 实验的规模无论数量还是种类都是庞大的——从细微的 UI/UX 变更,到新特性,到机器学习模型的改进。我们喜欢将实验看作是是一个无尽的学习环。

  • 建立假设:提出新特性想法或者为现有特性提出改进建议。
  • 定义成功指标:评估“机会大小(opportunity size)”——受该变更影响的用户数量。正式定义实验成功和失败的指标;考虑可接受的折衷方案。
  • 检验假设:实现拟定的变更,”检测(instrument)“相应的日志,并执行合理性检查以确保实验正确配置。
  • 学习:检查实验中收集的数据,吸取其中的经验教训,并与其他 Twitter 团队共享。
  • 发布:收集完数据后,判断实验是否验证了假设,并决定发布或者不发布。
  • 建立另一个假设:结合实验中的新想法,为更多的改进建立更多的假设。

A/B 测试、决策制定和创新

Twitter 的”产品检测和实验(Product Instrumentation and Experimentation)”(PIE)团队对实验哲学进行了大量的思考。A/B 测试可以带来很多好处,但是它也有很多众所周知的、容易陷入的陷阱。它的结果往往是出人意料、违反直觉的。我们如何避免这种陷阱?什么时候我们应该建议进行 A/B 测试,从而试验特性或者拟定的变更?在决策制定过程中我们如何保持敏捷,且在承受重大风险的时候仍能保持严谨?

测试的好处以及增量测试

特性变更A/B 测试文化重点关注的是它带来的是小增量收益,大部分实验只能带来个位数百分比的改进,或者甚至是分数百分比。因此,有些观点认为,这有什么意义呢?为什么不从事一些更有影响力、更有革命性的事情呢?

这是事实:如果存在实验能够提升指标,那么到目前为止,大多数实验在以最低限度的方式提升着指标;某个实验如果能够为大部分用户将某个核心指标提升数个百分点就被视为一种非凡的成功。

这与 A/B 测试的基本原理无关。这是因为一个成熟的产品很难通过大幅度改进指标的方式改变。很多人认为的全垒打想法根本没有带来一点点的改进:人类原来极其不善于预测什么可行(更多信息请参阅 “ Seven Rules of Thumb for Web Site Experimenters ”)。大多数时候,不理想的 A/B 测试结果让我们能够及早发现,看上去不错的想法其实可能不怎么样。因此我们更愿意尽可能快的获得坏消息,重新回到绘图板;这就是我们实验的原因。

A/B 测试是一种可以确保好想法不会夭折的方法,使好的想法有机会全面充分开发。当我们真正的信任某个想法,而初步实验结果不能满足我们的期望的时候,我们可以对产品做进一步改进,持续改进直到符合期望可以发布给数百万的人使用。另一种方法是,构建一些感觉良好的特性并发布,之后开发其它新的想法,一年后有人意识到根本没人在使用这个特性,它就这样静静地陨落了。

在我们从事各种各样原型开发的时候,快速迭代和衡量拟定的变更带来的影响让我们团队能够及早将隐式用户反馈吸收进产品中。我们可以发布一个变更,研究哪些能够产生改进,哪些不能,接着为能够进一步改进产品的变更建立假设,然后发布变更,周而复始直到拥有能够推送给更广泛用户的变更。

有些人可能认为这种增量变更效率太低。当然,发布“大创意”听起来远比小改进好太多了。然而仔细想一下,将许多小变更叠加起来就能产生复合效果。回避增量变更的产品改进方法很大程度上不是一个好方针。一个好的金融投资组合要能够平衡尽管回报不那么高但可预测的无风险赌注和高风险、高收益赌注。在这方面产品组合管理没有什么不同。

这就是说,有很多东西我们不能,或者不应该测试。有些变更被设计用于形成网络效应,而这些基于用户分桶的 A/B 测试不会捕获(尽管确实存在其它技术能够量化这种影响)。当只针对一个随机比例的人群时,某些特性可能会失灵。例如,在简单的 A/B 测试中, Group DMs 就不是一个可使用的特性,因为可能那些有幸获得此特性的人想要给那些没有获得此特性的人留言,这使得该特性基本无用。其它特性可能是完全的正交——例如推出像 Periscope 一样的新应用程序就不是 Twitter 应用实验。但是一旦推出,A/B 测试就成为一种重要的驱动应用程序内可度量增量和不那么容易度量的增量变更的方法。

还有另一类变更是,主要的新特性在内部构建过程中通过用户研究进行测试,但是考虑市场战略原因,在特定爆炸性时刻发布给所有的用户。作为一个组织,我们在自认为对产品和用户都有利的时候做出这个决定。我们相信尽管增量变更可能带来更好的初始版本,使更多用户尝试和使用,但是我们能够从大版本中获得更多收益。这是产品负责人需要权衡取舍的。那么当这么一个新特性发布后,我们要对其增量变更进行 A/B 测试吗?当然啦!随着想法的成熟,我们使用完善的科学原理指导它们的演化——并且实验是该过程的关键部分。

实验的可靠性

既然我们已经对运行实验进行了案例说明,接着让我们来讨论怎么做可以避免陷阱。实验的配置和分析是复杂的。即使是正常的人类行为也很容易引起对结果的偏差和误解。这里有几种实践方法,可以降低风险。

需求假设

通常实验工具能够揭示大量数据,常常允许实验者设计自定义的指标来衡量变更的影响。但这可能触发 A/B 测试中最隐匿的陷阱之一:“cherry-picking”和“ HARKing ”——从许多数据点中选择仅仅支持你的假设的指标,或者看到数据后调整假设,从而让它匹配实验结果。在 Twitter,一个实验收集上百个指标是很常见的,这些指标可以分解成大量的维度(用户属性、设备类型、国家等等),生成数以千计的观测值——如果你希望拟合使其适应任何故事,就需要从中挑选。

我们指导实验者远离 cherry-picking 的一个方法是,要求他们在配置阶段明确指定希望改进的指标。实验者愿意跟踪多少指标都可以,但是只有少数指标可以用这种方式明确标记。然后工具在结果页面突出显示这些指标。实验者可以自由探索所有其它已经被收集的数据,建立新的假设,但是最初的主张应该是固定的,并且要容易检查。

实验过程

无论工具有多好,一套配置不完善的实验仍然会交付不理想的结果。在 Twitter,我们已经对创建实验过程进行了投资,从而提高实验成功、正确运行的概率。在这个过程中大多数步骤是可选的——但是我们发现,使其可用和详细记录能够大大降低重新运行实验的时间损失从而收集更多数据,并降低等待 App Store 发布周期的时间损失,等等。

所有的实验者都被要求记录他们的实验。你在改变什么?你期望的结果是什么?期望的“受众规模”(将要看到这一特性的用户比例)?收集这些数据不仅保证了实验者考虑过这些问题,而且让我们能够建立一个制度性学习的资料库——一份已经实验的正式记录和实验结果,包括负面结果。我们可以用此提醒后面的实验。

实验者还可以利用实验牧羊人的优势。实验牧羊人都是经验丰富的工程师和数据科学家,负责评审实验假设和拟定的指标,以减少实验出错的几率。这是可选的,建议不具有约束力。随着人们对实验正确配置、跟踪正确的指标、能够正确分析实验结果有了更多的信心,该项目也从参与者中收到了大量的反馈。

一些团队也会举行每周例会,在例会上评审实验结果以便决定哪些应该哪些不应该发布给更广泛的受众。这有助于解决 cherry-picking 和误解统计显著性的问题。重要的是要注意这不是一场“给我一个理由说不”的例会——我们已经明确,“红色”实验发布,“绿色”实验不发布。这里重要的是坦诚及明确我们引入变更的期望和结果,而不是容忍停滞和奖励短期收益。引入这些评审显著提高了我们发布的变更的整体质量。同时这也是个有趣的会议,因为我们能够看到团队正在进行的所有工作以及人们对产品的看法。

另一个我们经常使用的实践是使用 “holdbacks”,如果可能——向 99%(或者其它高百分比)的用户推送该特性,并观测随着时间推移关键指标是如何偏离被阻止的 1% 的。这使得我们能够快速迭代和发布,同时密切关注实验的长期影响。这也是一种很好的验证实验中真正实现的收益的方法。

实验培训

确保实验者提防陷阱最有效的方法之一就是培训他们。Twitter 数据科学家会开设多门实验和统计直觉课程,其中统计直觉是所有新工程师加入公司后的前几周都要参加的课程。目标是使工程师、PM、EM 和其它一些角色熟悉实验过程、警告、陷阱和最佳实践。增强实验品质和陷阱的意识有助于我们避免在可避免的错误和误解上浪费时间,让人们更快洞察和改进节奏和质量。

即将推出

在后面的文章中,我们将介绍我们的实验工具 DDG 是如何工作的;我们将直接介绍一些我们遇到的有趣的统计问题——检测有偏差的分桶,使用(或不使用)第二控制(control)进行合理性检查,自动确定合适的 bucket 大小,基于会话的指标和处理异常值。

致谢

感谢 Lucile Lu Robert Chang Nodira Khoussainova Joshua Lande 对此文章的反馈。很多人都为 Twitter 实验背后的理念和工具作出了贡献。我们想特别感谢 Cayley Torgeson Chuang Liu Madhu Muthukumar Parag Agrawal ,和 Utkarsh Srivastava

编后语

《他山之石》是 InfoQ 中文站新推出的一个专栏,精选来自国内外技术社区和个人博客上的技术文章,让更多的读者朋友受益,本栏目转载的内容都经过原作者授权。文章推荐可以发送邮件到 editors@cn.infoq.com。

查看英文原文: The what and why of product experimentation at Twitter


感谢郭蕾对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作,请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博( @InfoQ @丁晓昀),微信(微信号: InfoQChina )关注我们。

2016 年 3 月 13 日 16:215639
用户头像

发布了 92 篇内容, 共 15.8 次阅读, 收获喜欢 4 次。

关注

评论

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

架构师训练营第 1 期 大作业二

李循律

Week12总结

lggl

关于坚持的思考

.

28天写作

赫拉利其人其书之我见(1)

石君

科技 简史 社科

DAPP智能合约APP开发|DAPP智能合约软件系统开发

开發I852946OIIO

系统开发

解密Android开发常见误区!耗时两个礼拜,8000字安卓面试长文,详细的Android学习指南

欢喜学安卓

android 程序员 面试 移动开发

架构师训练营第二周作业

架构师训练营 4 期

架构师设计大作业二

小诗

「架构师训练营第 1 期」

软件架构设计实战

andy

上链智能合约系统开发|上链智能合约APP软件开发

开發I852946OIIO

系统开发

第十二周课后练习

落朽

一款基本靠谱,略微出圈的2021十大科技预测

脑极体

联想小新潮7000安装CentOS8.8步骤

莫问

十二周作业

水浴清风

供应链产品溯源介绍

无誉

区块链 产品 电商 供应链 盘点2020

他们说飞机很安全,你信吗?

心理学 概率 28天写作

从代码到部署微服务实战(一)

Kevin Wan

go 微服务 microservice go-zero

解析底层原理!2021年移动开发者未来的出路在哪里,论程序员成长的正确姿势

欢喜学安卓

android 程序员 面试 移动开发

第十二周课后练习

晴空万里

架构师训练营第2期

架构师训练营第 1 期 - 第 13 周 - 学习总结

wgl

「架构师训练营第 1 期」

极客时间 架构大作业,快递平台架构搭建

博古通今小虾米

极客时间 架构

架构入门感悟之十二

莫问

案例研究之聊聊 QLExpress 源码 (二)

小诚信驿站

源码分析 小诚信驿站 28天写作 QLExpress源码 聊聊源码

架构师训练营第 1 期 大作业一

李循律

数字货币合约交易系统软件APP开发

开發I852946OIIO

系统开发

Week12作业

lggl

大作业二

golangboy

架构师训练营第 1 期

架构师训练营第 1 期 - 第 13 周 - 命题作业

wgl

「架构师训练营第 1 期」

十二周总结

水浴清风

OpenLookeng连接器-Clickhouse connector性能测试报告

Galaxy数据平台

数据库 数据分析 Clickhouse

软件架构知识树

andy

InfoQ 极客传媒开发者生态共创计划线上发布会

InfoQ 极客传媒开发者生态共创计划线上发布会

Twitter的A/B测试实践(一):为什么要测试以及测试的意义-InfoQ