写点什么

Spotify 的大规模实验

  • 2016-12-21
  • 本文字数:2196 字

    阅读完需:约 7 分钟

Spotify 的实验主管 Ben Dressler 认为,要扩大 A/B 测试的规模以便同时进行大量的实验,就需要调整流程和平台,这也可能影响企业文化。使用对照实验进行产品研究有助于审视我们对客户实际使用产品方式的设想,检查这些设想是否真的影响用户行为。

Dressler 说道,绝大多数时候,用户同时参与几个 A/B 测试是没有问题的,因为随机分配会将影响均摊到测试组中。但是,如果我们给用户造成了相互冲突的体验,这就有问题了,例如在一个测试中使用白色字体,而在另一个测试中使用白色背景。

Dressler 在 2016 年 GOTO Berlin 大会上作了关于构建Spotify 的实验文化的发言。InfoQ 对大会进行了报导,并提供了大会相关的问答、内容总结和文章。

InfoQ 在 Dressler 发言后采访了他,讨论了公司应该进行实验的原因、扩展 A/B 测试的方法以及当人们怀疑 A/B 测试时我们能做什么。

InfoQ:公司为什么应该进行实验?

Ben Dressler:多数公司和机构都努力影响某个成果。在像 Spotify 这样的产品驱动的机构中,这些成果通常就是一套业务度量标准,基于大量的发生特定动作的客户,如购买东西或者继续使用产品。通常员工会有一些关于最好实现该目的的方法的创意。收集大量高质量的关于这些顾客的数据是一个很好的方式,它能促进我们理解哪些因素促使这些关键行为更可能发生,哪些使其更不可能发生。但是不进行对照实验,我们不可能知道我们的动作,如发布新特性,是否真的引起这些行为发生改变,也不会知道它是否纯粹是一种相关性,在该特性上投入更多的资源是否有回报。

虽然 A/B 测试被公认为一个纯粹的网站优化工具,但是它本质上是用现实审视我们创意的工具,检查我们的创意是否和我们预期的一样。

InfoQ:怎样扩展 A/B 测试呢?

Dressler: 扩展 A/B 测试的数量依赖于几点:测试执行的速度、受众数量和每个用户的可运行测试数。既然受众数量通常是固定的,我们只能给每个用户运行更多的测试以及让测试执行得快一点。在这个阶段,如果我们没有足够简化流程,通常发生的问题就是团队的技术和流程负担。如果我们有一个应用需要硬编码每一次变更,我们就会遇到应用发布周期的瓶颈。工程师和设计师需要接受不完美测试的事实。一个好的办法是挑几组带头这样做,然后弄清要推广到所有组,我们需要对平台和流程做那些修改。

给每个用户运行更多测试意味着实验会发生潜在的冲突,造成糟糕的用户体验。如果一个组测试将所有字体改成白色,另一组将所有背景改为白色,参与了两组测试的人就没办法使用这个产品了。还有其它不同的解决办法,但是值得指出的是,多数时候一次参与多个测试的用户是可以的。因为用户是随机分配到测试组的,所有测试组中受影响的用户数应该是均匀的。A/B 测试只关注各组的区别,所以如果所有人都受到相同影响,结果不会被扰乱。

InfoQ:你能举一个实验的例子吗?

Dressler:不久前我们在研究中发现了一些规律,让我们意识到我们在 Spotify 浏览导航方面似乎错过了一些机会。我们形成了一个想法,通过简化我们的应用程序导航,我们可能能够让新用户更好地了解他们可以在 Spotify 做什么,从而增加他们留在平台上的机会。

按照传统思维,我们会马上进入设计冲刺,做一些用户测试,然后最终无论我们做出了什么,都会发布出去。然而,我们的设计师事实上确实领导负责了一些早期探索,我们才能迅速投入到第一轮 A/B 测试。一个测试检查改变导航 UI(并且仅仅 UI),而另一个测试改变信息架构(分类标签和结构)。这些经验并不完美,目的也绝不是要将它们推行到更广大的受众。我们关心的是使用它能否真的影响用户行为。如果根本的改变都无法带来更高的点击率,我们很可能不会在该创意上投入更多资源。然而,结果表明我们正在改变一些测试组中用户的行为,这个改变是我们想看到的。以这种方式建立了信心,我们就继续探索小样本用户测试中的不同设计原型,以排除变化,并快速收集大量相关经验。直到这时,我们才进行更传统的 A/B 优化,以达到我们最终向用户发布最好的版本。

InfoQ:你想对怀疑 A/B 测试的人说些什么?

Dressler:首先,我想说对实验怀着敬畏之心是好的。复杂的工程和高级的统计数据掺杂在一起的时候,就很容易犯错误。当构建许多版本和运行统计测试的时候,开发流程和数据收集的不足会被放大。A/B 测试是进行产品研究非常有力的工具之一,它需要专业的知识,可能需要改变流程和文化。在这过程中,我们很可能遇到一些问题。

那就是说,实验也很强大,拥有无限潜力,而不仅仅是消除几次点击。如果我们处理得当,运行一些灵活的实验,我们就能避免在错误的主意上浪费大量资源,尽早收集关键信息消除大型工程的风险,或者通过测试许多小主意,激励行之有效的主意进行自下而上的创新。至于速度,只需要想想这个:如果方向跑错了,200 英里每小时也快不到哪去。

我想鼓励所有人尝试实验。在几百年的处理错误实验和不完美测量的过程中,科学给了我们一些良好的应对机制:重新运行测试,检查结果是否能重现,成立互相检查的社区,在实践和底层工具的基础上不断迭代。最重要的是,要注意没有绝对的确定性。 基于不完全信息做出决策将始终是产品经理的工作,实验不过是有助于这项工作的有力工具。

查看英文原文: Large Scale Experimentation at Spotify


感谢薛命灯对本文的审校。

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

2016-12-21 18:001457
用户头像

发布了 33 篇内容, 共 12.0 次阅读, 收获喜欢 10 次。

关注

评论

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

第三周总结

Geek_ac4080

看动画学算法之:linkedList

程序那些事

数据结构和算法 看动画学算法 看动画学数据结构 算法和数据结构

架构师训练营第一期 - 第四周课后 - 作业一

极客大学架构师训练营

干货 | 全面解析“数字经济”

CECBC

数字经济 经济 经济建设

线上服务平均响应时间太长,怎么排查?

小Q

Java 程序员 测试 Jmeter 性能调优

Python时间序列分析简介(1)

计算机与AI

Python pandas 数据处理 时间序列

2N方定点算法

武夷梅占

php 数据库 分布式 算法 后端

第三节课后作业

happy

第三周作业

Geek_ac4080

Nginx 整合 FastDFS 实现文件服务器

哈喽沃德先生

nginx 文件系统 分布式文件存储 fastdfs 文件服务器

节日快乐…吗?

小天同学

个人感悟 国庆中秋 假期 节日

MySQL-技术专题-主从复制原理

码界西柚

【第三周】课后作业

云龙

云原生虚机应用托管-设计篇

8小时

区块链技术最重要价值所在

CECBC

区块链 数字经济 经济

架构师训练营第三周:系统架构

m

开源的意义与价值

Braisdom

Java 开源 ORM

JavaScript 语言通识 — 重学 JavaScript

三钻

Java 大前端

【第三周】代码重构

云龙

基于区块链技术实现“资产通证化”

CECBC

资产证券化 流动性

如果朋友圈没有点赞功能,你还会发朋友圈吗

彭宏豪95

微信 产品 互联网 写作

关于代码审查的一点体会

KJ Meng

敏捷开发 研发管理 代码审查 Code Review

私有云PAAS平台的思考

8小时

如何使用 dotTrace 来诊断 netcore 应用的性能问题

newbe36524

微服务 .net core netcore ASP.NET Core

手把手教你锤面试官 03——Spring怎么那么简单

慵懒的土拨鼠

第四周

Geek_fabd84

各角色如何从DevOps中受益?

禅道项目管理

DevOps 产品经理 测试 开发 运维工程师

「剑指offer」27道Mybatis面试题含解析

Java架构师迁哥

架构师训练营 第三周作业

haha

极客大学架构师训练营

这可能是GitHub上最适合计算机专业学生看的编程教程

小Q

Java 学习 编程 面试 基础

~~寒露节记~~

wo是一棵草

Spotify的大规模实验_文化 & 方法_Ben Linders_InfoQ精选文章