那些年我们一起追过的 AB testing 之 Airbnb 试验面面观

在产品发展的每一阶段，从设计到算法，Airbnb都用对照试验来进行了解和做出决策。它们与塑造用户体验同样重要。...

本文由吆喝科技翻译，如需转载，请注明出处及原文链接

作者：Jan Overgoor

原文链接：http://nerds.airbnb.com/experiments-at-airbnb/

Airbnb 是一款可以同时满足想要出租自己房屋的人（房东）和想找房子住的人（客人）的需求的线上产品。在产品发展的每一阶段，从设计到算法，我们都用对照试验来进行了解和做出决策。它们与塑造用户体验同样重要。

虽然对照试验背后的基本原则是比较明显的，但是像 Airbnb 这样复杂的线上生态系统，在产品快速发展阶段进行试验时可能会遇到一些常见的陷阱。比如大多数都可能犯的一个错误就是，太快停止一个试验。再比如一些由于市场层面的偏见引起的错误，就比较容易出现在像 Airbnb 这样更专业化的应用中了。我们希望通过分享我们经历过以及学着去避免的陷阱，帮助你对你的应用设计与执行更好的更可靠的试验。

为什么要做试验？

试验为我们得出结论提供了一种简洁的方式。而现实中往往很难只通过执行和观察就能预测事情的效果，就像图一描述的那样。



图1 很难预测产品发布的效果

外界对于数据的影响往往比产品改变要大得多。一周内不同的日子、一年内不同的时间、天气（尤其是是像 Airbnb 这样的旅行公司），或者是他们找到网站的方式（线上广告还是直接搜索到的），都会造成用户表现出不同的行为。对照试验隔离了外部原因对产品改变带来的影响。在图2中，你可以看到我们测试了一个新特性然后否定了的例子。我们想出了一种在搜索页搜索你想看的价格的新方法，但是用户却似乎更常用旧的那个价格过滤器，于是最后我们并没有发布这个新特性。



图2 测试并且放弃新特性的例子

当你在测试像这样的单变量时，这种方法通常叫做 AB 测试或者分裂测试。这篇文章不会讲如何运行一个 AB 测试这样基本的事情。已经有大量公司提供简单 AB 测试的解决方案，也有一些更大一点的技术公司已经将这些框架或方案开源便于更多人使用。比如，Cloudera 的 Gertrude、Etsy 的 Feature 和 Facebook 的 PlanOut。

插入广告：当然，最好还是直接采用吆喝科技的技术方案 AppAdhoc A/B Testing，推荐其实不是为了省事，而是如果真的想让 AB 测试的结论可信，很多坑真的不是简单用套开源改改就能趟过的。

Airbnb 的案例

在 Airbnb 我们已经打造了我们自己的 AB 测试框架，并用它来运行试验了，你可以在我们之后的博文中了解更多关于这方面的细节信息。除了按钮颜色等常规改变之外，我们还测试了很多别的特性，这就是为什么我们决定去创建自己的测试框架。

首先，用户不登录或者注册就可以浏览，这会让用户「捆绑」变得困难。人们在预订的过程中也会经常切换设备（在网站和移动端之间）。并且考虑到预订会花几天来确认，我们需要等待这些结果。最后，成功的预订经常取决于房间的剩余量和房东的责任感，这些都是在我们控制以外的因素。

我们的预订流程也十分复杂。首先，访客必须先搜索房子。下一步是与房东进行联系。然后，房东接受请求后，顾客才能预订到这个地方。除此之外，我们还有很多流程引导用户进行预订——一个顾客可以不经过联系直接预订，或者在进行预订咨询时就进行预订。这个四步骤的流程在图3中表现出来了。我们会看这四个阶段的每个过程，但是搜索和预订之间的转化是我们最关心的数据。



图3 按照预订流程步骤分解试验结果的例子

一个试验需要跑多久？

在线上做对照试验最常见的一个困惑就是，究竟要用多少时间才能对试验结果做出一个判断，从而得出结论。单纯使用 p-value 作为停止试验的准则，问题在于试验给出的 p-value 值是基于认为你设计的试验是已知样本和效应大小的。如果你持续的监控试验的发展和 p-value，你就很有可能看到效果，即使什么都没有。另外一种常见的错误就是在效果还不明显的时候太早结束一个试验。

这里有一个我们实际运行的试验的例子。我们调大了搜索页上的价格过滤器的最大值，从300到1000，就像图4下面显示的这样。



图4 测试价格过滤器的值的试验案例

在图5中，我们展示了这个试验随着时间的发展情况。上面那个图展示了试验效果，下面那个展示了 p-value 随着时间的变化。就像你可以看到的一样，p-value 曲线在7天之后达到了常用的显著值0.05，这个时候的效应大小是4%。如果我们把试验停在这，我们可以得出试验版本在预订方面起到了很显著的效果。然而当我们继续运行试验的时候，我们会发现这个试验开始趋向于中立。最后的结果其实是两个版本差异不大，p-value 指出无论剩下的效果大小是多少，都会被当成噪声。



图5 价格过滤器试验随时间变化的结果

为什么我们知道当 p-value 达到0.05时不应该停止试验呢？事实上这种很早达到「显著」的模式然后之后又回到中立的结果在我们的系统中很常见。有很多原因导致了这个结果。用户经常需要花很长时间预订，所以早期的转化在试验最开始有不太恰当的比较大的影响。而且，甚至是在线试验中小样本尺寸也会在统计学上有很大的变化。因为基于统计的测试是一种样本-效果大小方法，所以如果早期的效果大小是大于中立变化的话，早期的 p-value 是小于0.05的。但是最重要的原因是你每次观测统计测试的表现时都要计算 p-value，以及你做的越多，你就越容易找到效果。

补充说明一下，熟悉我们网站的人都会发现，在写这篇文章的时候，我们事实上已经发布了这个增加最大值的价格过滤器，即使结果是中立的。我们发现某些用户喜欢这种搜索高端住宿地方的功能，并且我们决定为他们提供住宿，即使没有其他数据。

试验需要运行多久呢？为了避免假阴性错误（即Ⅱ型错误），最好的实践方法就是基于样本的总量（每天出现的新样板的数量）来决定你所关心的最小效果大小，并且进行计算。以及在你开始试验之前，想好你要运行多久。这儿有资源可以帮你进行计算。提前设置好时间也可以降低没有结果的时候找到结果的可能性。

这儿有资源可以帮你进行计算：

Sample Size Calculator (Evan's Awesome A/B Tools)

链接为：http://www.evanmiller.org/ab-testing/sample-size.html

备注：为了便于理解，内容来源于百度百科
Ⅰ型错误：也称假阳性错误。即当原假设 H0 客观上成立，但根据假设检验的规则，将有 α 大小的概率错误地拒绝 H0，同时错误地接受备择假设 H1。

Ⅱ型错误：也称假阴性错误。即当 H0 客观上不成立，但根据假设检验的规则，将有 β 大小的概率错误地拒绝 H1，同时错误地接受 H0。

Ⅲ型错误：即最终回答的是1个错误的问题。此错误主要是由于试验设计不周密不完善所致，如在试验设计中未将重要的试验因素包括在内。

Ⅳ型错误：即对1个假设进行了多项正确的检验，但在对因果关系的分析时作出了错误的比较和解释，这些比较并非是由被使用的模型所定义的。此错误主要出现在结果的解释阶段。

有一个问题是我们对样本量，甚至是试验的方向往往没有很好的想法。改变可能会很成功，但也可能因为没有及时地发布成功的版本而造成主要的利润损失。或者，另一方面，有时候试验会引进一个 bug，这样的话在用户流失之前早点关掉试验比较好。

当试验进入到其他「显著」区域的那一刻会很有趣，这个时候可能甚至连流量都还没有分配完。在价格过滤器的试验中，你可以看见当第一次达到「显著」时，图看起来像没有转化的一样。我们觉得这个启发在判断结果是否稳定时很有帮助。一直监测相关的数据发展是很重要的，而不是仅仅考虑 p-value 造成的单个的结果影响。

如果是在分配流量之前，我们可以利用这个观点来正式说明什么时候该停止试验。如果你确实想要自动的判断试验版本的表现如何，尤其是同时跑很多个试验，却没法系统地监测的时候，这个是很有帮助的。背后的理念其实就是你应该对早期的结果更持怀疑态度。因此在最开始结果的调用门槛是很低的。当有更多的数据进来时，你可以提高门槛，因为找到假阳性错误的可能性会越来越小。

我们已经通过运行一些刺激试验，和得到动态 p-value 门槛的分离曲线解决了，应该在什么地方设置 p-value 门槛来停止试验。我们写代码来驱动我们这个有很多参数的生态系统，然后再用它跑很多参数值，比如实际效果尺寸，变量和不同水平的确定性不同的刺激试验。这也给了我们一些关于怎样去观测假阴性和假阳性的错误，以及估计的效果范围离真正的有多远的提示。在图6中我们展示一个决策边界的例子。



图6 一个动态 p-value 曲线例子

应该注意的是这个曲线对我们的系统和我们在试验中使用的参数是独有的。我们把这个案例分享出来，便于你用到自己的分析中。

在背景中理解结果

第二个陷阱是未能在整个背景中理解结果。通常而言，基于简单的利益数据来评估试验是否成功是很好的实践方式。这是为了避免在无数的中立结果中挑出「显著」的结果。然而，仅仅看单独的数据，你会丢失很多可以指示你理解试验结果的环境因素。

让我们看一个例子。去年我们计划重新设计一下搜索页。搜索是 Airbnb 生态系统中很基础的一个组成部分。这是我们库存的主要界面，也是用户与我们的网站最常见的交互方式。所以，让它展示正确是我们要做的一件很重要的事情。在图7中，你可以看见这个项目前后的对比。新的设计更加强调了列出的图片（我们的一个特点就是我们为房东提供了很专业的照片），以及这些房屋所在的位置。你可以在我们的另一篇博文中了解设计和补充的过程。



图7 重新设计搜索页的前后对比

这个项目花费了许多精力，而且我们都觉得一定是更好的；在用户定性研究中我们的用户也同意这样做更好。尽管如此，我们也想要利用试验来定性的评估这个新设计。这似乎很难让人支持，尤其是要测试一个这么大的新项目。可以想象如果我们不同时把新版本发布给所有人的话，将会损失多少市场。然而，为了保持我们一贯的测试文化，我们的确测试了新的设计方案——衡量实际的效果，以及更重要的是，可以通过数据收集了解到哪一块工作了，哪一块没有起到作用。

在等了足够长的时间以后，用文章上半部分描述的方法进行了计算，我们得到了一个中立的结果。全局数据的变化很微小，并且 p-value 显示新版基本上没有什么大的效果。然而，我们决定调查一下环境因素，试着去看为什么会变成这个结果。因为我们做了这个事情，结果发现新的设计版本在很多情况下表现的的确还不错，除了 IE 浏览器下。我们随即意识到新的设计打破了使用老版本 IE 会做的一些重要的点击，而这个明显为全局的结果造成了很消极的影响。当我们把这个修补了以后，IE 可以展示和其他浏览器一样的结果，整个数据增长了2%以上。



图8 新的搜索设计结果

除了教会我们要更重视 IE 的质量检测以外，这也是一个很好的例子可以让你知道不同的环境下结果带来的影响可能是不一样的。你可以将结果分解成许多因素，比如浏览器、国家和用户类型。也就是说在经典的 AB 测试框架中做这些时需要多一些注意。如果你分别测试这些互相独立的分解的部分，你会冒一个很大的风险找到与持续监控所看到的效果不同的结果，但对一个中立的试验，拆开来然后找到一个单独的「显著」效果是很常见的。对特别的组宣告胜利是不正确的。原因是你在评估这些试验的表现时，是假设所有的这些都是独立的，但事实上他们并不是。解决这个问题的其中一个办法就是减少 p-value 直到你觉得效果是真实的为止。了解更多的方法请点击这里 How Not To Run An A/B Test (http://www.evanmiller.org/how-not-to-run-an-ab-test.html)。另外一个方法是用逻辑回归等更高级的方法来直接对所有的分解进行建模。

广告时间：多维度数据分析在 AB 测试中是一个很重要的功能，经常发生看起来差不多的实验结果，在某个细分维度上差异巨大。

假设这个系统可以正常工作

第三个也是最后一个陷阱是假设这个系统可以按照你希望的那样工作的。不管你是建造你自己的系统去评估试验，还是使用第三方的工具，这个都应该注意。在上面的任何一种情况下，系统告诉你的可能都无法反应真实的情况。这个会发生的原因可能是本身系统的错误，也可能是你使用不当。评估这个系统和你的解释的一个方法是创建假设然后验证它们。



图9 一个 AA 试验例子的结果

另一个看待这个的方式是意识到那些看起来特别好的结果很有可能是错误的。当你碰到这样的结果时，在认为它们都是精确的前，对他们保持怀疑态度是很好的，以及你应该从任何你能想到的地方仔细检查。

一个简单的例子是运行一个试验版本与控制版本相同的试验。这种试验叫做 AA 或者伪试验。在完美的世界里，系统会返回一个中立的结果（大部分时间）。你的系统返回的是什么？我们跑了许多这样的试验（看图9中的例子）并且在我们自己的系统中定义了许多指标作为结果。一种情况是，我们改变了不同的控制和试验组的大小，来跑了大量的伪试验。它们中的一部分的流量是平均分配的，比如50%的控制和50%的试验组（每个人看到的都是一样的界面）。我们也加了一种情况是，75%的控制版本和25%的试验组。图10中展示了我们做的这些伪试验的结果。



图10 一组 AA 试验的结果

你可以看到试验中当两个组大小相同时，结果看起来就像期待的一样中立（因为是伪试验，所以试验本版和控制版本看起来一样）。但是，对于那些尺寸大小不一样的组而言，人们对试验组有更大的偏见。

我们调查了这种现象出现的原因，然后发现对于那些我们没有分配给试验组的访客，出现了些问题。这个问题与我们系统有关系，但是通用的点是验证系统是不是按照你们想的那样进行工作，这是很值得思考并且可以告诉你们一些有用的想法的问题。

当你跑 AA 试验时一定要记住的一件事就是你应该期待有些结果出来是非中立的。这是因为 p-value 的工作方式。举个例子，如果你跑了一个伪试验并且把结果分解成100个不同的国家再来查看，你应该能够预料到，平均他们中的5个就会给你一个非中立的结果。所以当你仔细检查第三方工具的时候一定要留心。

总结

对照试验是一种在产品发展迭代的过程中做决策的好方法。我们希望，这篇文章中的教训可以帮助你们避免 AB 测试中一些常见的错误。

首先，决定你花多久时间运行一个试验的最好办法就是提前计算你需要的样本大小。如果系统给你一个早期的结果，你可以尝试对是否转化做一个启发性的判断。在这种情况下保守是比较好的。最后，如果你真的需要做程序上的发布和停止的决策，采用动态 p-value 门槛来决定结果需要格外小心。我们在 Airbnb 用来评估试验的系统采用了所有三点来帮助我们做产品迭代的数据决策。

在不同环境中考虑结果是很重要的。将它们分解成有意义的小项，然后试图深入理解你所做的改变带来的影响。通常来说，做试验是为了在改进产品上做出好的决策，而不是激进地为了得到更优化的数字。优化不是不可能，但是会经常导致为了短期的增长而做出投机取巧的决定。通过聚焦在了解产品上，你为自己设置了更好的未来决策，和更有效的测试。

最后，让你的报告系统变得科学性是很好的。如果一些事情看起来不对，或者看起来太好了以至于不对，那就调查研究看看。一个简单的方法是跑 AA 测试，但是任何关于系统如何表现的理论对于结果的解释都是很有用的。在 Airbnb 通过使用这种方法我们找到了大量的 bug 和反直觉的行为。

与 Will Moss 一起，我在2014年4月针对这个话题做了一个公开演讲。你可以访问 https://www.youtube.com/watch?v=lVTIcf6IhY4 查看当时的视频回放。Wii 也发表了另一篇关于基础设施方面的博文，可以读这里 Experiment Reporting Framework (http://nerds.airbnb.com/experiment-reporting-framework/) 进行了解。我们希望这篇文章可以对那些想要改善自己试验的人们有所帮助。

点击文章左下方「阅读原文」，现在就开始做 AB 测试吧。



点击以下你感兴趣的标签，立即阅读相关精彩文章

什么是Growth Hacking | 初创团队如何践行Growth Hacking | 揭开Growth Hacking面纱 | 增长黑客线下活动 | 吆喝科技

AB测试基础 | 广告 | 着陆页优化 | 导航栏设计 | 改标题 | 用户增长 | loading动画 | APP注册率 | CTA转化率 | 科学分配流量 | 大数据

案例：Facebook | Twitter | Google | APP Store | Airbnb & Dropbox | 天猫 | 今日头条 | 大众点评 | 美团

人生没有AB可选，做产品可以

……



吆喝科技开发的 AB 测试云服务，用数据帮助用户优化产品，是国内唯一同时支持前端(Web/H5、iOS、Android)及后端(Node.js、PHP、Java 等)AB 测试服务的专业 SaaS 平台。

AppAdhoc 优化平台：能够帮助用户用数据验证最佳方案，提高产品的设计、研发、运营和营销的效率，降低产品决策风险。平台特色包括：线上灰度发布、多维度数据统计分析、科学的流量分配系统、一键发布新版本无需应用市场审核、定向测试等。

    关注 吆喝科技