我们希望通过客户的观点来驱动我们的产品开发，而经过实验证明的各种假设则是探索客户观点的最佳手段。目前，在阿姆斯特丹举办的 OSCON 大会上，来自于 booking.com 的首席设计师 Stuart Frisby 为与会者讲述了他们如何在产品开发中大量应用 A/B 测试实践的情况。
A/B 测试是一种通过比较某个指定特性不同版本的差异，以理解哪一个版本的效果更好的一种行为。但要正确地实践 A/B 测试，需要满足一些前提条件。
每个特性都需要进行完整的测试，但这种测试必须是原子性的。如果你不能做到每次测试只针对一项变更，你就无法控制变化因素，从而不可能得到清晰无误的结果。虽然目前市面上已经出现了许多 A/B 测试工具，但 Frisby 认为这些工具都不够理想，因为他们都缺少进行恰当的、完整的测试所必需的上下文与灵活性。他建议你创建一套属于自己的工具，或者至少也要使用某种能够允许你修正并匹配你的上下文的工具。
应用这一实践的软件组织必须建立一种数据驱动产品开发的文化，而不是依赖于专家的意见。所招聘的员工应具备企业家的心态，这样就能够促成一种“刨根问底”的组织文化，从而促使每个人对于他所不了解的内容提出疑问。作为一种终极的促进因素，优秀的 A/B 测试实践在许多情况下会证明，在当前上下文中，你、你的老板或业界专家的想法其实是错误的。
Frisby 描述了一个假想的 A/B 测试场景，以了解改变背景颜色所产生的效果。在实践中，Frisby 并不推荐这种类型的 A/B 测试，他相信改变颜色不是一种解决用户问题的正确方式。但这一场景能够简单地表现出整个流程，这个实验的假设场景是这样的：
由于在网站中使用了一些较高对比度的元素，使得我们的业务中一个主要的行为功能（即“立即预定”按钮）显得不够突出。
用于对此次实验的结果进行分析的衡量标准：
如果有更多的用户选择单击某个对比度较高的按钮，并最终下了订单，我们就知道这个假设是正确的。
团队将发布该按钮的两个版本：一个是正在使用中的蓝色背景按钮，一个是全新的绿色背景按钮：
让我们假定绿色的按钮会使预定转化率从 2.7% 下降至 2.2%，那么这个假设就是不成立的，因此 booking.com 将继续延用原来的按钮样式。
在开展 A/B 测试的过程中，软件组织必须注意一些常见的错误。首先，不要尝试“大范围的 A/B 测试”，即一次性改动过多的内容。也不要尝试“边缘 A/B 测试”，即仅仅专注于产品中某个很小的部分，即便它非常重要，例如你的登陆页面。此外，Frisby 还简略地描述了“假定可再现性”这一思想。
“假定可再现性”这一思想是指由他人所进行的实验也能够在你自己的环境中再现。但上下文始终是最关键的因素，对于其他人有效的做法未必就适合你。Frisby 提出了一种层次型的可信赖数据源（按可信赖度从高到低排列）：你自己的实验数据；你个人的观点，因为你最了解你自己的产品；他人的观点；他人的实验数据，因为它会为你造成一种假象，让你错误地确信它的结果。
Frisby 并不建议在所有场景中都应用 A/B 测试，如果你的 web 应用程序没有达到一定的访问量，那么测试的结果可能也是无意义的。此外，如果你没有定义客观的衡量指标，并通过这些指标根据你的测试结果进行决策，那么也不应当采用 A/B 测试。最后，软件组织必须要做好准备，因为 A/B 测试的结果很可能会与组织所确信的恰恰相反，而接受这一点并不像人们想象中那么容易。
查看英文原文： A/B Testing at Booking.com
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论