增长黑客之“法”——增长实验如何设计

引言#

一条策略值得优先验证，并不意味着应该马上把它完整做出来。增长工作里很常见的一种浪费，是团队花了几周甚至几个月把方案做到接近正式上线，最后才发现最基础的判断根本没有成立。另一种浪费刚好相反：为了追求“数据驱动”，什么问题都想做 A/B 测试，即使样本不足、变量无法隔离，也坚持跑出一个百分比，再把随机波动当成结论。

实验设计要解决的问题很实际：面对当前最关键的不确定性，用什么方式、投入多少成本，才能得到足以支持下一次决策的证据。有些问题需要先理解用户为什么没有行动，有些需要确认一个机制在真实场景里能不能成立，还有一些已经具体到两个版本之间的效果差异。验证方式不同，但底层要求是一致的：实验要围绕已经形成的假设展开，指标能够反映假设，受众和版本与问题匹配，样本和分流足以支撑比较。实验设计的完整结构，最终都落在这几个条件上。

5.1 验证方式#

选择验证方式之前，最好先忘掉“A/B 测试”这四个字，重新看一次自己到底不知道什么。如果不确定的是“用户为什么没有行动”，直接做两个页面版本，最多只能告诉我们哪个表现更好，却未必解释原因。这个时候，用户访谈、行为观察、可用性测试能够更快暴露问题。如果已经比较清楚用户的阻力，只是不知道某种解决机制能不能改变真实行为，可以先通过一个小范围 MVP 验证。如果问题已经收敛到一个明确、可控的线上变量，并且具备足够流量，A/B 测试会更适合比较变化是否真的带来了差异。

这里有一个容易被忽略的取舍：证据强度应该和决策成本匹配。如果只是判断一个方向值不值得继续研究，没有必要一开始就建设完整系统；如果准备把一个变化全量推给数百万用户，或者它涉及较高业务风险，仅凭几个访谈和短期趋势就明显不够。同一个假设也可能经历不同层次的验证：先用定性信息确认问题，再用 MVP 判断真实行为，条件成熟后再通过对照实验评估效果。验证不一定一步到位，关键是每一轮都消掉一个会影响决策的不确定性。

前后对比尤其需要谨慎，改版后转化从 10% 提高到 12%，并不能自动说明改版贡献了两个百分点。同期可能发生了促销、渠道变化、季节波动，用户结构也可能已经不同。当缺少对照条件时，这类结果仍然可以作为证据，但结论应该和证据强度保持一致，不能把“变化同时发生”写成已经确认的因果关系。

实验方法的选择最终可以收敛成两个问题：现在最需要排除哪一个不确定性；什么是获得这个答案成本最低、同时又足够可信的方式。这两个问题明确之后，实验才不会因为工具本身变得越来越重。

5.2 MVP#

MVP 最容易被误解成“功能少一点的产品”。用于验证的 MVP，并不关心产品看起来够不够完整，它关心的是：能不能用尽量少的资源，让最关键的假设进入真实环境，并获得足以支持下一步判断的结果。假设一个零售业务认为，更符合用户场景的商品推荐能够提高购买意愿，完整方案可能涉及推荐算法、标签体系、数据平台和新的前端页面，但如果当前连“场景化推荐有没有价值”都不知道，直接建设整套系统成本太高。可以先选择一小批目标用户，由运营人工完成商品组合，再通过现有触点展示。如果用户行为没有出现预期变化，至少避免了把大量资源投入一个尚未成立的机制；如果出现稳定信号，再决定是否值得产品化和规模化。

这类 MVP 一点都不“高科技”，验证的却是最要紧的东西。产品功能可以通过原型、轻量页面或人工服务验证，运营策略可以先在少量用户和渠道中运行，复杂流程也可以先通过人工串起关键环节。采用什么形式并不重要，只要它仍然能让用户面对足够真实的选择，并产生与假设有关的行为。

MVP 有两个相反的陷阱。一个是做得太完整。团队总觉得“既然要试，就顺便把正式版做了”，结果验证尚未开始，大量资源已经沉没。另一个是做得太假。一个原型如果完全不能还原真实决策场景，用户的反馈再积极，也未必代表上线后的真实行为。所谓“最小”，不是尽可能粗糙，而是删掉所有对验证关键假设没有必要的部分；所谓“可行”，则意味着留下来的部分仍然足以触发真实行为。因此，设计 MVP 时与其问“最少要做哪些功能”，不如问：如果只能保留一个能够证明或反驳当前判断的场景，它应该是什么？这个问题比功能清单更容易让验证变小。

5.3 A/B 测试#

当假设已经足够具体，变化可以被控制，目标行为能够稳定记录，同时业务拥有足够的实验流量，A/B 测试才开始发挥价值。它的基本结构并不复杂：一部分符合条件的用户继续看到原来的版本，另一部分用户看到包含实验变化的版本，两组在同一时期运行，通过随机分配尽量保证其他条件相近。这样观察到的差异，才更有机会归因于实验本身，而不是用户结构、市场环境或者时间变化。最简单的结构是：对照组保持原方案，实验组只引入当前需要验证的关键变化。这里的“只改变一个变量”，更准确地说，是关键差异需要足够清楚。如果同时改变页面结构、价格展示、内容、按钮和权益，即使实验组明显更好，也很难判断哪种机制起了作用。实验最终验证的会变成“整套新方案是否更好”，而不是原来的具体假设。因此，关键变量要尽量清楚，对照关系和随机分配也需要在实验开始之前确定。

A/B 测试也不是越多越好。它比较适合满足几个条件的场景：目标用户可以被稳定识别，实验版本能够并行存在，用户之间不会轻易互相污染，核心行为可以被准确记录，同时样本规模足以支持比较。只要其中几个条件明显缺失，强行使用 A/B 测试，最后得到的往往只是一个形式上很“科学”的数字。例如一个低频 B2B 产品，一个月只有几十个目标客户，每个客户的决策又受到销售、合同、实施和组织关系影响，这种情况下把十几个客户硬拆成 A、B 两组，随机误差可能远大于实验变化。相比之下，小范围试点、客户观察和更长周期的业务结果可能更有意义。反过来，高流量线上交易场景中，一个相对独立的页面机制变化，如果不用同期对照，而选择上线前后比较，又主动放弃了本来可以获得的更强证据。

所以 A/B 测试的价值，不在于它看起来专业，而在于它能够创造一个条件：除了我们主动改变的部分，两组用户尽可能相似。指标、版本和分流的设计，都是在维护这个条件。

5.4 实验指标#

实验上线之前，指标就应该确定。如果先看完结果，再决定哪些数字最重要，很容易出现一种情况：核心指标没有变化，于是从几十个辅助数据中找出一个上涨的数字，最后宣布实验“还是有价值”。这样做不是在分析结果，而是在结果发生以后重新定义成功。实验指标通常可以分成核心指标、辅助指标和护栏指标：

核心指标最好尽量集中。一个实验同时有五六个“核心指标”，往往意味着团队自己也不知道什么结果最重要。假设如果针对详情到加购的决策阻力，加购率自然应该成为主要判断对象；页面停留时间、评价浏览率可以帮助解释用户行为，却不能因为这些指标上涨就替代最终目标。

辅助指标的意义也不是“多看几个数”，而是帮助判断链路有没有沿着预期机制发生变化。假设增加商品决策信息是为了降低用户判断成本，实验后加购率提高，同时用户在无关区域的反复浏览减少，这些行为可以增强对机制的理解；如果加购提高，但其他行为完全和预期相反，就值得重新检查究竟是什么产生了效果。

护栏指标负责限制局部最优。提高支付率不能以退款大幅增加为代价，提高注册量不能依赖大量低质量用户，提高点击也不能建立在误导信息之上。它的作用，是让实验在追求核心结果的同时明确哪些代价不能接受，避免一个局部指标改善，却让更重要的业务结果变差。

指标还有一个很实际的要求：统计口径必须和实验受众对应。如果实验只面向首次进入的新用户，却拿全站所有用户的转化率判断效果，实验变化很可能被大量未参与实验的用户稀释。分母是谁、曝光如何定义、用户什么时候算进入实验，这些不是无关紧要的数据细节，会直接决定最终结果是否可信。

5.5 实验受众与版本#

实验并不是把全站用户随机切一半就结束了，谁应该进入实验，本身就由假设决定。如果策略针对的是第一次购买的新用户，那么老用户没有必要进入；如果问题只发生在某个渠道，把所有渠道混在一起可能反而稀释效果。实验受众需要和已经确认的问题范围一致，否则最终比较回答的就不是原来的问题。受众确定以后，版本设计也要围绕同一个假设展开。

但受众也不能因为结果不好而不断往下切。实验前认为所有新用户都应该受影响，结果出来以后发现整体不显著，再从几十个标签中找到一个显著上涨的小人群，然后把它解释成“精准洞察”，这种做法很容易把随机波动包装成结论。有业务理由的分群，可以在实验设计阶段提前确定；实验结束后的探索性发现也有价值，但它更适合作为新的假设，而不是回头改变原实验的成功标准。

版本设计则要忠实于假设。如果想验证“更清晰的使用场景能不能帮助用户理解商品价值”，实验版本的主要变化应该围绕场景表达，而不是同时改价格、布局和促销机制，变化越混杂，最后越难知道结果到底支持了什么。

版本数量也受到流量限制，两个版本需要两份样本，三个、四个版本会继续分散有限流量。实验想法很多时，很容易希望一次把所有方案都测完，但版本越多，单个版本积累足够样本所需的时间通常越长。如果业务日均可实验流量有限，少量、差异清楚的版本往往比一次塞进很多变体更容易得到可靠结论。

在实验开始之前，还需要确认版本之间除了实验变量之外，没有其他非预期差异。加载速度、埋点、库存、优惠资格、页面异常，如果只发生在某个版本，都可能变成隐藏变量。一个设计看起来非常标准的实验，也可能因为实施细节失去可比性。

5.6 样本、分流与显著性#

很多实验的问题，并不是假设不好，而是在开始之前就没有认真算过自己有没有能力得到答案。假设原来的购买转化率是 10%，团队希望知道一个方案能不能带来至少 20% 的相对提升，和希望检测 1% 的相对提升，需要的样本完全不同。通常来说，希望识别的变化越小，需要的样本越大；基线转化越低，样本要求也会随之提高。对结果可靠性的要求越严格，同样意味着更高的实验成本。样本量因此需要结合基线、希望识别的最小变化以及显著性和统计功效要求提前估算，而不是实验跑起来以后根据结果临时决定。实验周期也由样本决定，一个简单的粗略估算是：实验所需时间 ≈ 每个版本所需样本 × 版本数 ÷ 每天可进入实验的有效用户量。实际还需要考虑实验只开放部分流量、不同日期的用户结构差异以及业务自身周期，但这个估算至少能够提前暴露一个问题：如果需要几十万样本，而每天只有几千有效用户，设计五个版本本身就不现实。

样本进入实验以后，分流要尽可能保持随机、稳定和隔离。同一类目标用户应当有相近概率进入不同版本，同一个用户在实验周期内保持固定版本，避免今天看到 A、明天又进入 B；如果多个实验同时运行，还要检查它们是否会修改同一条用户路径，否则两个实验可能互相影响。“随机”也不意味着两组数据在每一个维度上必须完全一样。样本本来就会存在自然波动，真正需要的是分组方式没有系统性偏向。实验组如果恰好全部来自高价值渠道，对照组主要来自低质量渠道，即使最后转化明显不同，也很难再把这种差异归因到实验版本。

统计显著性解决的是另一个问题：我们看到的差异，有多大可能只是随机波动。增长实验中通常把 p < 0.05 作为显著性门槛，但达到这个条件并不意味着一个实验在业务上就值得推广。除了统计显著，还要看效果量：如果一个超大样本把转化率从 10.00% 推到 10.05%，即使统计上能够识别差异，实际收益可能仍然覆盖不了开发、运营和长期维护成本。反过来，没有达到显著性也不能直接证明“方案无效”。可能真实效果很小，也可能样本不足，或者实验本身噪音太大。怎样区分这些情况，需要结合样本、效果幅度和实验条件进一步判断，而不能只看一个显著或不显著的标签。

实验过程中还有一个很容易制造误判的动作：每天不断查看数据，一看到结果显著就提前停止。实验原本按照某个样本和周期设计，如果根据中间波动不断决定“今天停不停”，原来的统计条件已经发生变化。更稳妥的做法，是在实验开始之前确定主要指标、所需样本和基本周期。除非出现明显风险或护栏指标异常，不要因为短期数据好看就临时改变结束条件，否则中间的随机波动很容易被误判成稳定结果。

样本量、随机分流和统计显著性是实验里最技术的一部分，但它们保护的东西很简单：当两个版本出现差异时，我们有没有足够理由相信，差异主要来自自己主动改变的那个因素。实验结束以后，数据只是结果。接下来需要判断的是：这些结果究竟支持了什么，没有支持什么，以及我们原来对用户、变量和策略的理解是否需要因此改变。