IT思维

大数据文摘出品

来源：Medium

编译：睡不着的iris、夏雅薇

这是一篇描述A/B测试的文章，作者从产品的角度出发，详细描述其优点与局限性，并表示不要太过于依赖A/B测试，容易忽略产品的本身应有的闪光点。

首先，作者是喜欢使用A/B测试的。

对于不熟悉的人来说，A/B测试是通过改变产品的某一特性（或者包装，消息推送，价格…），然后测量改进版本与原始版本（“控制版本”）的性能差异（一般通过一些可衡量的KPI实现）。测试过程中，随机选取一定数量的用户（如客户，访客），将其分成对照组或测试组，然后测量这两个组的行为有何差异。由于分配是随机的，所以两个组具有相似的特征（从人口分布来说），并且两组之间的任何可测量差异都应与产品的改动有关。

A/B测试借鉴医学领域的随机对照试验，用以确定新疗法的有效性。显然，医学试验具有很高的标准。所以，A/B测试被称为“产品开发的科研手法”。

数字产品开发过程中的残酷真相是大多数点子都会失败。因此，我们必须验证我们的点子是否能达到预期效果，并识别出那些注定要失败的点子。毫无疑问A/B测试是一个非常有效的方法。

有些人会没有习惯进行验证就直接发布产品，我不主张这样。我觉得应该用A/B测试去尽可能准确地评估一个产品变化带来的影响。

然而，A/B测试本身存在局限性和风险。另外，只依赖A/B测试，你的产品不会出错，但一定不会出彩。

创造性地推倒重来

伟大而创新的东西都伴随着创造性破坏，即推翻某些不再成立的条件，建立新的假设。例如，iPhone作为有史以来最伟大，最成功的产品，它挑战了智能手机需要键盘或触控笔的假设。

创造性破坏不仅要有远见，也需要一定的假设以及 “基本理论”。作为产品团队，你需要设定一个目标 – 找到一种优于当前的方法从根本上解决用户的问题，然后实现该目标。

当然，这个目标并不是单独存在的。应该通过对客户需求的基础研究以及对技术趋势或市场发展的洞察力逐步明确。但是，一个真正伟大而新颖的想法一般都具有争议。如果基本假设是正确的，那么早就该有人把这个产品做出来了。（2012年的时候，Facebook首次公开募股期间，一位商学院教授告诉我，Facebook的财务状况有多糟糕。如今，Facebook拥有了出色的盈利能力，但即使IPO后，其商业模式还被不少人质疑。）

为了实现卓越，团队需要坚定地追求对现状有极大突破的愿景。这个过程中会充满挫折，即便你的想法没有奏效，也不能因此而放弃追求这个愿景。在失败的时候，你只是排除了一个错误选项。

要创造伟大的东西，你必须从本质上创新，给出一个完全不一样的解决方案，而不只是比当下方案好一点点。因为你选择了一条没人走过的路，所以你的第一个方案可能不会太好。要挑战现状，就意味着你要停止与之前的方案作比较，因为之前的方案是基于旧认知所做的优化方案。把这两个比较没意义。

新方法的根本假设取决于你的愿景，你应该设计实验来逐一验证它。但是，只做一个方案然后就进行A/B测试，是不会有什么结果的。

克莱·克里斯滕森（Clay Christensen）的颠覆理论提出市场的根本变化通常是由一项新技术所触发，然而以传统方式衡量新技术的性能会明显低于现有技术。例如，回顾下PC如何替代小型计算机。在各方面，PC的性能都比小型计算机低得多，但是PC体积小且价格适中，意味着它可以服务比小型计算机更大的市场。你如何进行A/B测试来验证这样的根本转变？

好的产品能够打破现状，并挑战基本认知。构建新的认知需要有新的愿景，即使面对挫折也要下决心去实现它。当然，这并不意味着你不应该验证自己的愿景是否能成功，但这种情况下A/B测试不能给你答案。

渐进思维

A/B测试提倡一种与创造性破坏完全相反的方法。主要是局部最优问题：如果你将优化的控制版本与一种创新但未优化过的方法进行A/B测试，显然控制版本会优于新版本，但是你不知道这是不是只是因为新方法还没优化过。通过优化，你已经取得了当前方案的最佳体验（局部最大值）。所以当你对一种完全不同方案进行测试的时候，你真正想知道的是，如果这个方案优化后，是否能超过当前的最佳体验——A/B测试无法验证这一点，因为你无法测试还未实现的方案。

A/B测试提供的是一种渐进式思维方式：通过比较找到更好的方案，而不是通过失败慢慢靠近自己的愿景。这种渐进式方法能够达到优化的目的，但不利于创新。

过度依赖A/B测试会使人短视。因为你不希望等待数月或数年才测量那些指标（例如长期客户保留），所以在A/B测试中往往会设定一个短期关键指标作为成功标准（例如早期客户参与度作为长期存留的关键指标）。但是，从短期来看，这些指标很容易会把你“带偏了”，并非说是有意，但会导致只关注指标而不是客户和业务价值。

过度依赖A/B测试，还存在误入测试一切的误区，比如“如果我们把按钮变大，就会有更多人点击按钮”。如果结论非常显而易见的时候，做实验去验证就变得有点教条主义。不过有时候是否要做测试，不是一个很显而易见的决定，所以需要小心去平衡。

举个例子，在8fit（一款运动健身app），我们希望增加客户早期留存率。我们发现进行过一次锻炼的客户留存的可能性更大——锻炼这项功能是否被使用过是客户留存的一个很好的预测指标。因此，我们尝试通过在用户注册流程结束时加入一个新界面来鼓励用户开始第一次锻炼，或者进行第一次预约（之后有推送提醒）。当前，最直接的验证方法是进行A/B测试这个功能是否会增加使用锻炼功能的用户。这个情况下，我们就陷入了“按钮更大，点击更多”的陷阱中——在入口处强化“锻炼”提示，很显然会有更多人进行锻炼。

测量锻炼的完成度（即用户不只是开始了锻炼，还完成了锻炼）也会产生误导性——如果更多的人开始锻炼，完成锻炼的人肯定会增加（即使增长幅度较小）。所以我们借助滞后指标，测量第二周的留存率来查看这个改动是否存在持久影响。尽管你可以避开这些，但需要特别注意。

总而言之，仅依靠A/B测试之类的优化技术意味着你会陷入只在优化、渐进式思维的风险——而不敢大胆创新。

加速洞察

要打造出色的产品，你必须快速行动。快速响应不断变化的客户需求。你得比你的竞争对手更快，即使他们有更丰富的资源。还要比其他潜在竞争对手更快。速度和敏捷性是初创公司的利器，甚至可以和资金雄厚的大公司比拼。

A/B测试可以作为一种有效的方法来收集信息，达到优化的目的。比如调整页面的布局，跑几周的A/B测试后，你会清楚地知道新版本是否比控制版本好。

如上所述，真正的创新不仅仅需要边际优化，更需要挑战的基本认知，以做出实质性的改变。

想要测试一些颠覆性的改变，A/B测试就没那么快能看出结果了。测试时间会大大延长，如果返回的结果是两个方案没差别，你还浪费了很多时间。如果是颠覆性的改变，你可能一次性会改很多。这也会增加A/B测试的复杂度—一般来说“纯” A /B测试只能测试一个变量，从而可以建立明确的因果关系。

在早期，初创企业经常遇到的另一个问题是数据不够。如果你没有足够的客户，你就需要很长时间才能使得A/B测试达到符合统计意义的标准。

当产品发生重大变化，构建初期原型并与实际客户进行验证的方法更直接有效。如果你依赖A/B测试来发现问题，你会浪费很多时间，而且也不能快速迭代，难以打造出真正出色的产品。做一次A/B测试所花的时间相当于做十次初期原型验证。使用全新方法，风险和回报都更高，因此，尽早验证很重要。

优化假设

通常，A/B测试不是完善产品的好工具。但是，如果产品总体的点子已得到验证，并且你想快速验证优劣，那A/B测试会是进行优化的绝佳工具。如果你仍在尝试验证方向，那么A/B测试就不是很有效。

定性的验证方法为你提供了更丰富的信息。它不仅告诉你发生了什么，还能告诉你具体原因。这种方法可以帮助你发现你解决了客户的哪些痛点，还有哪些问题没解决，以及你无意造成的新痛点。在定义产品方向或进行产品迭代时，这类信息是最有用的。

A/B测试需要配有可量化的标准。总的来说，这并不是一件坏事——正如彼得·德鲁克（Peter Drucker）那句永不过时的管理名言，“你无法改善你无法测量的东西”。然而，某些产品特点很难衡量其短期提升，但从长远来看，忽略它们又会带来负面影响。这些包括质量和用户“喜好”，还包括隐私、安全性和可访问性。

此外，对于新产品而言，没法像成熟产品那样建立完善的可量化的成功标准。指标衡量的是客户产生的价值。仅依靠A/B测试意味着用一些其他指标来代替实际的客户价值和产品愿景。如果你都没法确定这个指标是否代表客户价值，那可能就是南辕北辙了。

如果A/B测试不是实现卓越的最佳方法，那么你应该怎么做呢？有几件事情可以做：确定一个清晰的愿景和策略。重心放在产品发掘上：与客户交谈，了解他们的需求和痛点，找到机会，然后才开始提出解决方案。在设计完整的产品之前，使用原型对解决方案进行定性验证。

完成以上操作并得到经过定性验证的新方案后，是否仍可以进行A/B测试？当然可以。在这种情况下，需要注意几个方面：

首先，不同于常规A/B 测试，你对产品进行了重大改进，你对一系列的变动进行测试，我们应该给这类测试起一个别的名字。在8fit，我们叫“影响力测试”。这类产品发布是分阶段的，风险也比较小，因为你已经有了一些定性证据来支持你的猜测。

如果这类A/B测试后，发现产品指标没有提升，有可能是出现了局部最优问题。鉴于你已经通过定性测试证明了新解决方案的价值，你可以直接开始迭代这个新方案。

小心选择测量指标，并评估这些指标能否真正代表用户价值。另外，避免仅关注短期指标。多收集外部的反馈，这些反馈可能会比A/B测试的结果更能体现长期的影响。

相关报道：
https://medium.com/@jefago/you-cant-a-b-test-your-way-to-greatness-e5892c7da53e