写点什么

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:001583
用户头像

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

关注

评论

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

垃圾分类与AI的反碎片之旅

百度大脑

人工智能 EasyDL

Java中对千万级数据量的表进行插入操作(MYSQL)

张音乐

Java MySQL JDBC 9月日更

Python顺序结构选择结构

在即

9月日更

腾讯云签约广州知识城商用密码项目,助力黄建设密码产业示范区

腾讯安全云鼎实验室

腾讯云 商用密码

各编程语言里对 Iterator 进行修改时的对比

BlockQuant

Java Python rust Go 语言

五行兼备:联想TruScale服务的太极之道

脑极体

ULP Fec与 Flex FEC 概述

webrtc developer

WebRTC fec

低代码开发:实现传统系统信息化的3种方案!

优秀

低代码 低代码开发

活动推荐 | 云原生社区 Meetup 第七期深圳站开始报名啦!

CODING DevOps

Kubernetes DevOps 微服务 活动 Meetup

Frida笔记 - Android 篇 (一)

GrowingIO技术专栏

android Frida

防沉迷系统的bug,技术如何查漏补缺?

脑极体

HashMap为什么是线程不安全的?

Java技术精选

APM领域国产化先锋!博睿数据与麒麟、统信、中科方德完成兼容性认证

博睿数据

用数据搭建反馈系统

石云升

数据分析 9月日更

前端独立交付需求背景下的Mock数据多方案解读

爱数技术范儿

JavaScript 大前端 Mock

Vue进阶(幺零四):elementUI 应用 $notify 提示信息中换行问题

No Silver Bullet

Vue 9月日更

HTML进阶

Augus

html 9月日更

justswap市值管理机器人系统软件开发技术(案例搭建)

量化系统19942438797

交易所 做市机器人 justswap

北鲲云超算平台赋能蛋白设计助推生物制药行业发展

北鲲云

Java 操作 Office:POI word 之表格格式

程序员架构进阶

Java Apache POI 9月日更 word文档

总结下ThinkPHP的代码审计方法

网络安全学海

php 网络安全 信息安全 WEB安全 代码审计

性能测试中异步展示测试进度

FunTester

性能测试 接口测试 测试框架 进度条 FunTester

博睿数据云主机性能评测新增6家云厂商,8月报告亚马逊云科技登榜首

博睿数据

Python代码阅读(第25篇):将多行字符串拆分成列表

Felix

编程 Code Programing 阅读代码 -python

微信亿级用户异常检测框架的设计与实践

OpenIM

我怀疑,你对996的力量一无所知!

艾小仙

程序员 996

微信开源PhxQueue:高可用、高可靠、高性能的分布式队列

OpenIM

谁在制造“完美男性”?

脑极体

ServiceWorker工作原理、生命周期和使用场景

devpoint

Service Worker 9月日更

开源之夏项目分享:图数据库 Nebula Graph 支持 JDBC 协议

NebulaGraph

maven-dependency中作用域scope含义

一个大红包

9月日更

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