企业网站的 A/B 测试与转化优化：用证据而不是喜好做决定

许多网站决策是以同样的方式做出的：有人认为按钮应该换个颜色，标题应该更短，或者表单应该减少字段。谁的声音最大或职位最高，通常谁就赢。结果有时好，有时不好，而且几乎没有人确切知道原因。

A/B 测试提供了一种更平静的方式：在同一时间向不同的访客展示两个版本，然后看哪个更常带来你想要的行动。你不必争论，而是让访客的行为来回答。但 A/B 测试也很容易被滥用，许多看起来令人信服的结果其实具有误导性。

本文介绍如何为中小企业的网站和网店健康地开始测试：何时值得测试、如何提出假设、测量什么、测试应运行多久，以及如何避免错误的结论。我们不给出确切的提升数字，因为每个网站都不同。

摘要

• A/B 测试在随机分流的访客上比较两个版本，看哪个表现更好
• 从通过数据和观察发现的问题出发，而不是从个人喜好出发
• 一次只改变一件事，并在测试开始前确定成功的衡量标准
• 在下结论之前，给测试足够的时间和足够的访客数量
• 如果流量太小，基于观察的改进往往比测试更有用

用简单的话解释 A/B 测试

想象一家实体店想知道，把主推商品放在门口附近是否能提高销售。公平的做法是在同一时期把两家相似的店铺做不同的布置，然后比较结果。如果只改变一家店并与上个月比较，结果会与季节、促销和天气混在一起。

网站上的 A/B 测试遵循同样的原理。每位访客被随机分配到版本 A（通常是当前运行的页面）或版本 B（被测试的变体）。因为两组在同一时期看到页面，足够大的结果差异就可以归因于这个改变，而不是其他因素。

还有其他变体，例如同时测试多个版本，或测试多个组合元素。对大多数企业来说，只有两个版本的简单 A/B 测试就足够了，而且更容易正确解读。

何时值得测试，何时不值得

测试需要足够数量的访客。如果你的页面每天只有几十人访问，其中只有少数人执行目标行动，两个版本之间的差异要经过很长时间才会显现，而且即便显现也很脆弱。在这种情况下，测试结果更多是巧合而不是现实。

流量小的时候，有更有效的办法：修正明显可见的问题。观看访客的会话录像，在手机上检查页面，阅读经常进入客服的问题，并访谈几位顾客。被遮挡的按钮、令人困惑的表单或不清晰的价格这类问题通常不需要测试，只需要修复。

当问题明确但解决方案存在几种合理的意见，并且预期影响大到足以值得付出努力时，测试最有用。选择按钮颜色很少属于这种情况；更改优惠、结账步骤的顺序或价格的展示方式，则更值得测试。

从问题出发，再提出假设

好的测试从观察出发，而不是从想法出发。例如，分析数据显示许多访客把商品放入购物车，却在配送页面停下。由此产生一个猜测：运费直到最后才显示，让买家感到意外。

把这个猜测变成可检验的假设：如果我们在商品页面显示预估运费，更多访客会完成购买，因为他们在最后不会感到意外。假设要说明改变、原因和预期结果。原因很重要，因为即使结果不如预期，你也能学到东西。

在测试运行之前写下假设和成功标准。看到结果之后才确定标准，会为牵强的辩解打开大门：如果主要指标没有上升，总能找到恰好上升的其他指标。

选择成功的衡量标准

主要指标应当只有一个，并且与业务目标直接相关：完成购买、提交报价申请表单或注册的访客比例。像按钮点击次数这样更浅层的指标很容易上升，却不会带来实际的好处。

除了主要指标之外，还要设定护栏指标，即不能变差的东西。例如，如果你为获得更多提交而简化表单，也要检查进来的潜在客户的质量。数量增加而质量下降并不是胜利。

在测试开始之前确保追踪正常工作。许多测试白费，是因为被测量的事件在某个版本中没有被正确记录。通过在两个版本上亲自执行目标行动并检查一切是否被记录，来测试追踪。

测试应运行多久

最大的诱惑是一旦某个版本看起来领先就停止测试。在最初几天，数字会因偶然而起伏，看起来获胜的版本往往之后会失去领先优势。在有利的时刻停止，是得到虚假胜利最常见的方式。

事先决定测试将进行多少访客或多长时间，然后坚持下去。至少运行一个完整的周周期，使工作日和周末的模式都有代表性；如果你的业务购买周期长，则运行得更久。测试工具通常提供样本量计算器，可以提供帮助。

避免在异常事件期间运行测试，例如大型促销活动、长假或技术故障。这些事件会改变访客的构成，可能以与被测试的改变无关的方式扭曲结果。

读懂结果而不被愚弄

测试结果通常附带统计置信度的度量。大致了解它的含义：所见的差异仅由偶然造成的可能性有多大。高置信度意味着差异很可能是真实的，但并不保证影响很大或对你的业务有意义。

也要看影响的大小。真实但非常小的改进，可能不值得为实施它付出成本。反过来，看起来很大但建立在少量数据上的结果，应被视为需要重新测试的线索，而不是证据。

如果你同时运行许多测试，或深入挖掘许多访客群体，发现偶然模式的机会就会增加。按设备或流量来源的细分可以用来产生想法，但这些发现需要经过自己的测试才能被信任。

最值得先测试什么

• 页面顶部的价值主张：访客是否能立即理解你提供什么
• 优惠及其呈现方式，例如保证、免运费或试用
• 表单或结账中的字段数量和步骤顺序
• 价格、额外费用和支付选项的展示方式
• 社会认同，例如评价、顾客数量或合作伙伴标志（如果属实）
• 主要行动号召按钮的文字和位置

按预估的影响和难易程度排序。影响大且容易实施的改变优先。以这种方式处理想法清单，可以避免团队花数周时间做结果最多只是很小的测试。

一次测试从头到尾

作为一个假设性的例子，一家体育用品店发现许多访客停在购物车页面。会话录像显示访客上下滚动，寻找运费信息。假设：直接在购物车里显示预估运费和预计到达时间，会让更多访客继续付款。

团队把主要指标定为继续付款的购物车比例，护栏指标定为取消率和退货率，并把时长定为三周以涵盖几个周周期。先在两个版本上测试追踪，然后把流量随机平均分配。

测试期结束后，团队对照已设定的指标阅读结果，检查护栏指标，并决定是否把改变应用到所有访客。无论结果如何，都记录假设、数字和经验教训。这个例子有意设计得简单；关键在于有序的工作步骤，而不是改变的大小。

让测试值得信赖的技术要点

确保访客的分流真正随机且一致。访客在测试期间必须始终看到同一个版本，包括第二天回访时。不一致的分流会让体验令人困惑，并破坏数据。

留意闪烁，即访客在测试版本出现之前短暂看到原始版本的情况。除了令人不快，闪烁还会影响行为，并偏离真实体验。在服务器端或采用正确技术运行的测试通常能避免这个问题。

过滤掉非人类流量，例如搜索引擎爬虫和机器人，以及你自己团队的内部流量。两者都可能扭曲结果，尤其是在访客较少的网站上。最后，检查两个版本的加载速度相当，因为较慢的版本会因为与设计无关的原因而落败。

在应用和移动体验上测试

同样的原则适用于手机应用，但有几点需要注意。应用更新需要时间才能到达用户，因此测试通常通过远程配置来运行，无需发布新版本即可开启某些变体。确保应用从一开始就设计为支持这一点。

应用用户也往往比网站访客更少、更忠诚，因此对新用户早期流程的改变，例如注册和功能介绍，往往是最有意义的测试位置。在收集行为数据时，也要留意应用商店政策和隐私规则。

何时停止、应用或重复

测试结束后有三种可能。如果新版本明显更好且护栏指标安全，就应用到所有访客，并监测几周以确保结果持续。如果结果没有差异，就选择更简单或维护成本更低的版本。

如果由于数据不足而结果不明确，可以在一开始就设定的规则下延长测试，或测试更大胆的改变，使差异更容易被检测到。过于细微的改变很难证明，而且往往对访客确实意义不大。

伦理、隐私与维护信任

测试不是操纵访客的许可证。避免误导性的模式，例如虚假倒计时、不实的库存紧张声明，或隐藏取消订阅的选项。这类做法除了损害信任，还可能违反消费者保护规定。

注意隐私。通过隐私政策告知访客数据收集情况，按适用规定征求同意，并且不要收集测试不需要的个人数据。请参考当前有效的个人数据保护规定。

最后，不要让测试使体验显得不一致。回访的访客应当看到与之前访问相同的版本，并且所有版本在所有设备上都必须正常工作。

培养学习的习惯，而不只是寻找赢家

测试最大的价值不是单次的胜利，而是对顾客不断积累的理解。保留每次测试的记录：假设、改变、结果以及学到了什么。这些记录可避免团队重复同样的测试，并揭示顾客重视什么的规律。

失败的测试同样有价值。显示改变没有效果的结果让你不必再继续讨论它，而显示改变有害的结果则让你避免了一个本可能被推广到整个网站的错误。

让测试成为轻量工作节奏的一部分，例如同一时间进行一两个测试，并每月复盘。持续一点一点学习的小团队，通常会胜过一年只做一次大型测试的团队。

应避免的常见错误

• 一旦某个版本看起来领先就停止测试
• 同时测试许多改变，然后声称知道哪个起了作用
• 在看到结果之后才确定成功标准
• 在流量太小的情况下测试，并把结果当作确定无疑
• 为了提高行动数量而忽视结果的质量
• 不记录结果，导致经验教训丢失

本周就能开始的第一步

1. 01确定网站上的一个主要行动，并确保其追踪准确
2. 02通过数据和会话录像，找出一个有许多访客流失的点
3. 03写下完整的假设，包括理由和成功标准
4. 04事先确定所需的时长或访客数量
5. 05准备一份简单的记录表，保存每次测试及其经验教训

结语

A/B 测试是用证据取代争论的有力工具，但前提是有纪律地运行：清晰的问题、书面的假设、事先设定的指标，以及等待足够数据的耐心。

如果你的流量还不够，不要勉强测试。修复明显有问题的地方，直接观察访客，并把测试留到流量足够时再做。基础修复带来的确定提升，往往比仓促的测试所承诺的更大。