AB测试流量规划指南：样本量、实验单元与分层互斥设计

1. 一张公式背后的流量账：先算清楚实验到底需要多少人

先说个我上个月遇到的真实场景。一位做增长的朋友找我吐槽，说他们的AB实验跑了两周，核心指标p值始终在0.2到0.4之间晃悠，产品天天催、研发不敢动，团队里已经有人开始怀疑实验设计是不是有硬伤。我让他把后台配置发我看一眼，第一行就找到了问题——流量只分了5%。

这不是个例。我见过太多团队，把精力全部压在实验假设、指标定义、显著性水平上，却忽略了最前置、也最容易被一带而过的问题：这个实验到底需要多少流量，才能在你预期的周期内得到可信结论？流量规划不是“从大蛋糕上切一块下来”那么简单，它直接决定了实验是两周出结果还是两个月出结果，甚至决定了实验结论本身可不可信。

1.1 最小样本量的账，其实只需要一次加减乘除

要回答“需要多少流量”，绕不开最小样本量。我平时给团队做估算，基本不会去翻统计教材，用的就是一个简化到不能再简化的版本。

对于比率类指标，比如支付转化率、点击率，估算公式是：

n = [16 × p × (1 - p)] / δ²

这里n是每个组需要的用户数，p是基线转化率（对照组的历史均值），δ是你希望检出的最小提升幅度（MDE，Minimum Detectable Effect）。16这个常数，对应的是显著性水平α=0.05、统计功效80%的标准组合。

举个例子。你的支付转化率基线是3%，你想验证新版是否能把它提升到3.5%，那δ就是0.005（0.5个百分点）。代入公式：

n = 16 × 0.03 × 0.97 / (0.005²) ≈ 18624

也就是每组需要大约1.86万个用户，两组加起来接近3.7万。如果你的产品日活是10万，按每天10%的流量进实验来算，每天能积累1万用户，大约4天就能满足一个周期的样本需求。但如果只分5%的流量，每天5000用户，两组各2500，需要一周半以上才能攒够一个最小样本量。再考虑到实验要跑完一个完整业务周期（比如7天），时间就更加紧张了。

很多人看到16这个常数会产生一个疑问：为什么功效取80%而不是90%或者95%？答案是成本。从80%提升到90%，常数会从16涨到21左右，样本量直接增加三成。对于大多数业务实验来说，80%已经是“用合理成本换取可接受风险”的平衡点。除非你做的是一次性重决策（比如全站改版），否则提高功效所换来的额外精度，远不如把省下来的流量多跑两个实验来得划算。

1.2 均值类指标要用方差的账，而不是均值的账

比率类指标的公式基本够用，但遇到均值类指标——人均时长、客单价、单次会话页面数——就得换一个思路。均值类指标的关键在于方差σ²，公式是：

n = [16 × (σ₁² + σ₂²)] / δ²

这里的σ是指标的标准差，δ是你期望检出的均值差异。麻烦在于，很多业务指标的方差大得惊人。我曾经帮团队评估过一个“人均浏览时长”的实验，基线均值是30分钟，标准差却高达60分钟——也就是说，不同用户之间时长的波动比均值本身还大一倍。想检出1分钟的提升，需要的样本量是：

n = 16 × (60² + 60²) / 1² = 115200

每组11.5万用户，两组23万。如果是日活50万的产品，全量跑一天都攒不够。这种时候，硬着头皮跑均值指标只会让自己陷入“跑两个月也不显著”的泥潭。

我的经验是，遇到这种高方差指标，优先考虑两个变通方案：一是把指标降维，比如把“人均时长”改成“人均时长超过10分钟的用户比例”，变成比率类指标来算；二是更换统计推断的方式，用bootstrap或方差缩减技术来压低有效方差。这些方法虽然不能完全解决问题，但至少能把样本需求拉回到可执行的范围。

1.3 别忘了“正在增长的业务”会让样本量的账越来越难算

还有一个经常被忽略的变量：业务本身在涨。如果你做实验的这段时间恰好赶上产品的高速增长期，新用户持续涌入，整个大盘的转化率、人均时长可能每周都在爬升。这意味着两件事。

第一，你用来估算样本量的基线p是“过去的p”，实验期间的基线可能已经变了，按旧基线算出来的样本量会偏小。第二，增长期用户的构成也在变——新用户比例从10%涨到20%，对照组和实验组的用户结构如果出现时间上的差异，就会引入混杂。所以业务增长期做实验，我一般会要求把预估样本量至少乘以1.2到1.3的冗余系数，并且在分流时严格保证每日进组人数稳定，避免某一组的流量在前几天被“优先塞满”。

算完这一笔账，你可能会发现，自己原本打算只给5%流量的实验，其实需要20%甚至30%才能在一周内出结果。这就是流量规划的第一层作用：先让实验“跑得动”。

2. 实验单元定错了，流量规划就是空中楼阁

样本量算清楚了，接下来要面对一个更隐蔽的问题：这波流量是按什么“单元”来算的？我在团队内部经常说一句话：实验单元定错了，后面所有流量分析都是白搭。

实验单元（也叫“随机单元”），就是你在分流时对什么做随机化。最常见的三个粒度是用户、设备和会话（session）。这三个粒度对流量规划的影响可以说是天壤之别。

2.1 用户粒度：最稳，但也最“慢”

用户粒度是大多数产品的默认选择。每个用户只会被hash到实验组或对照组，理论上不会出现同一个人同时体验两种版本的情况。对于留存、渗透率、人均价值这类用户级指标，用户粒度是唯一正确选择。

但用户粒度的代价是“慢”。假设日活100万，实验分了10%流量，每天进组的干净用户是10万。如果用用户粒度跑一个需要每组5万样本的实验，一天就能攒够。听起来不错，但如果你只需要验证一个页面上的按钮文案，用用户粒度就会显得很浪费——因为每个用户只有一次进入实验的机会，你能拿到的样本数上限就是“去重后的用户数”。

2.2 会话粒度：快，但方差账很难算

会话粒度（或者PV粒度）是按每次访问来随机化。同一个用户今天访问三次，可能三次都进入不同组，看到不同版本。这种设计的优势非常明显：样本量可以做到用户粒度的几倍甚至十几倍，实验周期大幅缩短。

但代价是统计假设被破坏了。经典显著性检验要求样本相互独立，可在会话粒度下，同一个用户的多次访问并不是独立的——用户在自己熟悉的产品里，点击习惯会高度一致。这个相关性会让你的方差被系统性低估，p值偏小，假阳性率升高。你看到的“显著提升”，可能只是同一个用户在不同会话里的自相关在作祟。

我一般会建议团队：如果一定要用会话粒度，那就同时做两件事。一是用聚集稳健方差（clustered robust variance）重新计算标准误，二是把显著性水平从0.05收紧到0.01，给自相关留出缓冲。但这已经属于“有条件使用”的范畴，绝不能默认套用。

2.3 设备粒度：ID映射率里藏着雷

还有些产品登录率不高，用户级数据不全，只能退而求其次用设备ID做随机单元。这里的问题在于“一人多设备”。一个用户手机、平板、电脑三端都有设备ID，三端各自可能被分到不同的实验组，这个用户其实同时接触到了对照组和实验组的版本。

流量规划时，我起码会做一次“ID映射率”检查：有多少活跃用户已经做了跨设备ID归一？如果映射率低于70%，设备级实验结论会非常脆弱；如果近90%，设备粒度还是可以凑合用的。但没有映射的用户，你只能在后台标记为“匿名流量”，要么排除出分析集，要么单独分层。

2.4 随机单元与分析单元错配：最常见的隐性错误

比粒度选择更隐蔽的坑，是随机单元和分析单元不一致。比如你用会话粒度做了随机化，但最后统计的指标是“人均点击次数”——人均口径需要按用户去重，可分流时并没有在用户级做分组，这个“人均”就成了一个混合口径，两组的用户重合度可能很高，结果就是指标的差异被稀释。典型的表现就是实验组提升了1.5%，但p值始终在0.4左右徘徊。

所以在流量规划阶段，有一件事必须落在纸面上：随机单元是什么，分析单元是什么，两者如果不一致，用什么方法修正方差。这三个问题想不清楚，后面所有数据都只能“仅供参考”。

3. 分层与互斥：流量结构设计的两条主线

样本量算明白了，实验单元也确认了，下一步是决定这波流量怎么“叠”进现有体系。这里必须分清两个概念：分层（orthogonal layer）和互斥（mutual exclusion）。我见过太多人把这两个词混着用，导致线上实验互相污染还不自知。

3.1 互斥：同层实验的老死不相往来

互斥是解决“两个实验同时影响一个用户”的最直接手段。两个实验放在同一层，用户被切分成几个互不重叠的桶，同一个桶里的用户只能进入其中某一个实验。比如A实验占40%流量，B实验占30%，剩下30%是空白对照，三个桶之间没有任何交集。

互斥适合用在“强相关”的实验之间——比如同一个弹窗的不同文案版本、同一个推荐算法的参数调优。这种场景下，如果用户同时进入了A、B两个实验，你根本说不清最终效果是哪个改动带来的。

但互斥的代价是流量利用率低。同一层同时只能跑有限个实验，所以生产环境的层不能设置得太少，太少了大家排队，效率感人。

3.2 分层：同一用户在不同层可以被“重复利用”

分层（正交）才是流量规划里真正有技术含量的部分。核心思路是：对同一个用户ID，用不同的随机盐（盐值）做hash，进入不同的层。因为hash算法和盐值的组合不同，用户在各个层的分组结果是独立的——他可能在“首页推荐层”进了实验组，同时在“弹窗层”进了对照组。这样每一层都能拿到全量流量，实验之间并行不悖。

用生活化的类比，分层就像给同一批人发不同颜色的牌：第一层按红蓝牌分组，第二层按方片梅花分组，虽然都是同一批人，但每一层的分组方式互相独立，互不干扰。

3.3 分层设计里最容易犯的错误：把“层”当“流量池”

我在不少团队看到过一种误解：把层理解成“把100%用户切成五块，每块20%”。这是完全错误的。正确的分层设计下，每层都有100%用户，只是每一层的分组方式不同。层数设置不需要太多，按业务功能模块划分5到10层完全够用。比如：

• 全局用户体验层（弹窗、引导、UI改动）
• 推荐算法层（信息流、商品推荐）
• 交易流程层（下单、支付、优惠券）
• 触达策略层（push、邮件、短信）
• 新用户专属层（注册流程、新手任务）

层数也不是越多越好。每层虽然都有全量流量，但用户可能同时命中多个实验，如果这些实验都影响同一个核心指标，归因就变得异常困难。所以层与层之间还要设计“优先级”：核心体验层比其他层有更高的流量调度优先级，一旦核心层需要大量流量验证一个关键实验，其他层的新实验要主动让路。

3.4 层内流量碎片化：看起来很忙，实验效率反而更低

碎片化是流量规划里最容易被忽视的慢性病。我有一个长期合作的平台团队，主层曾经同时挂着8个实验，每个实验分走5%到10%流量，剩下的流量几乎无法再支撑任何新实验。结果就是：每个实验都在跑，但每个实验都因为样本量不足而迟迟不能收敛，整个团队陷入“实验便秘”状态。

解法不是增加层数，而是建立“流量申请-审批-释放”机制。一个新实验进入主层前，必须回答一个问题：你打算看什么指标，这个指标会不会和现运行实验的指标重叠？如果重叠，你需要等前一个实验出结论，而不是直接切流量进来。

4. 多实验并行时的流量分配与排期：一次真实的“抢流量”冲突复盘

前面讲的都是“单实验如何规划流量”，但真实业务里流量规划的最大难题从来不是单个实验，而是多个实验、多个团队之间的动态博弈。分享一个我自己复盘过很多次的案例。

4.1 冲突现场：两个团队都在做首页，互相“看不见”

有一次，公司首页信息流团队和商品推荐团队分别上了一个实验。信息流团队改的是信息流的内容排序策略，切了20%流量；推荐团队改的是商品卡片算法，也切了20%。两个实验按流程分属两个不同层，理论上正交，可以并行。

两周后，信息流团队发现实验组的人均点击提升了8%，但核心的UV价值（用户人均成交金额）没有变化。推荐团队更懵，他们第一周数据明明涨了5%，第二周却慢慢回落到不显著。两边都觉得自己的实验没问题，于是开始互相怀疑对方的改动在干扰自己的数据。

4.2 复盘路径：与其猜，不如交叉分析

排查的第一步是打开实验台账，把两个实验的目标指标写在一起。这一写，问题就暴露了：两个实验的指标虽然名字不同，但都指向同一个用户行为链路——用户在首页的点击概率和后续成交。改动路径重叠度太高。

第二步做交叉分析：把同时进入两个实验组的用户单独拎出来，和只进其中一个实验的用户对比。发现交叉组的用户人均点击不但没有提升，反而显著下降。这个负交互效应，是单看任何一个实验都看不出来的。

第三步就是重构流量排期。信息流实验优先级高，保留20%流量继续跑；推荐实验暂停一周，等信息流实验出结论后再重启。这里有一个原则：当两个实验的“潜在影响路径”重叠时，宁可串行也不强行正交，因为正交只是保证“用户不冲突”，不能保证“改动效应不冲突”。

4.3 团队协作层：流量排期表必须是一张“实时的账”

这次冲突之后，我们定了一个制度：每周五开一次流量排期会，所有准备上线和正在运行的实验都要登记。台账字段包括：

• 实验名称和所属团队
• 分层归属
• 目标指标
• 影响页面/功能路径
• 预期MDE和最小样本量
• 开始时间、预计结束时间
• 灰度白名单情况

这张表解决了两个问题。一是“抢流量”变得有据可查，新增实验上线前，先看表里有没有强相关实验在运行；二是实验到期不自动释放，必须有人来确认结论并回收流量。很多时候流量不够用，不是因为总流量少，而是因为大量实验已经跑完结论却不释放，白白占着池子。

5. 流量规划里最常见的六个坑，我逐个踩过

讲了这么多正向的方法论，最后把这些年实际工作中遇到的高频坑集中复盘一遍。这六个坑基本覆盖了流量规划里“看似小事、实际致命”的六类问题。

5.1 上线第一天就把100%流量全部切成新版

做实验验证完效果不错，进入推广期，有人图省事直接全量切。这个动作的问题在于彻底消灭了对照组，之后任何指标波动都无法归因到版本。我见过最可惜的场景：新版全量上线后核心指标下滑，团队花了三周排查是版本问题还是市场变化，最后因为没有对照，只能“重跑一个已上线的实验”，浪费了一个月的迭代周期。正确的做法是任何时候保留至少5%的对照组，哪怕后面要全量，也要先留后路。

5.2 只看累计数据，忽略了新奇效应和学习效应

很多实验的流量规划只算“样本量够了没有”，却忘了给“业务效应稳定”留时间。新功能上线初期，用户可能因为新鲜感而点击率虚高；算法类改动则需要时间让系统“学习”用户行为，前期效果可能反而变差。如果在新奇期就下结论，很容易把“虚假提升”当成确定结论。我一般建议：实验周期至少覆盖“新奇期（3到5天）+稳定期（5到7天）”，并且看趋势图判断数据什么时候进入平台期，而不是只看累计p值。

5.3 层间正交设计正确，却忘了指标重叠等于隐性互斥

正交只能保证“用户不重叠”，不能保证“改动效应不重叠”。两个不同层的实验如果影响同一个核心指标，即使分流完全独立，实验结果也会相互干扰。这种问题在台账上几乎看不出来，必须靠“影响路径自查”来拦截。我们团队后来的硬性要求是：新实验上线前，必须列出这个实验会直接影响哪些指标，再去台账里搜这些指标有没有被其他运行实验命中，有就直接冲突预警。

5.4 只有10%流量却强行分五个组

有的实验天然需要多组对比，比如三个文案加一个对照，四个版本。但如果总流量只有10%，再切成四份，每组只剩2.5%，样本量不够是大概率事件。更糟的是，组数太多会让“多重比较”问题变得严重，即使没有真实差异，也可能有一组因为随机波动表现突出。这里的建议是：除非有明确的序贯测试计划，否则默认“实验组数越少越好”；如果确实要多组对比，优先考虑两阶段设计——先少量流量做筛选，选出有希望的版本后再扩量验证。

5.5 大促和运营活动期间照常跑实验

大促期间全站行为基线被彻底改变。你的对照组和实验组虽然分流比例不变，但转化率、客单价整体抬升，实验效果会被“活动效应”覆盖或放大。更麻烦的是，如果活动只覆盖部分用户（比如只有领了券的用户参与），筛选机制和活动参与行为混杂在一起，实验结果几乎无法解释。我现在遇到大促，基本规则是：大促前一周停止新实验上量，已有实验进入“观察不决策”模式，大促结束后再看趋势是否回归正常。这不是不跑实验，而是把实验周期和业务周期对齐。

5.6 上线后从不验证分流均匀性

这是最基础、也最容易被跳过的动作。分流算法再成熟，也要在实验上线后检查两组的基本盘是否均匀。我每次上线实验，48小时内必看三个数：两组用户量比例是否接近预设（比如50/50是否有偏差）、新老用户占比是否一致、客户端版本分布是否一致。可以用一个简单的卡方检验，也可以直接看比例偏差。曾经真有过一次，因为hash取模的参数配错，实验组分到了52.3%的流量，而且新用户占比明显偏高，如果不查，这个实验跑完的结论必然不可信。

6. 一张流量规划卡：上线前必须填完的七个要素

前面讲完原理、案例和坑，沉淀成工具才是最有用的。我在团队内部推行过一张“流量规划卡”，所有实验上线前必须填完。填完它，流量规划已经完成了一大半，剩下的事情就是按卡执行。

流量规划卡的核心字段如下：

每张卡片还附带上线前的检查清单，我按自己的习惯列七个：

1. 是否基于历史数据完成了最小样本量计算？
2. 实验单元和分析单元是否明确？错配时有没有修正方案？
3. 是否确认了所在层没有强相关实验在运行？
4. 是否保留了至少5%的对照组？
5. 是否验证过两组流量的用户量比例和关键特征均匀？
6. 是否考虑过新奇效应和学习效应，把周期预留到位？
7. 是否查过未来两周有没有大促或运营活动会干扰基线？

写完这张卡，我通常还会补一个执行层面的提醒：实验开始后不要反复调流量比例。中途加量或减量会打破原有的随机化节奏，让整个实验的统计推断失效。如果确实发现流量不足，尽量一次性把比例加到目标档位，而不是每天加1%。实验结束后，按时把流量归还给层，不要占着位置不放。

到现在为止，我复盘过的所有流量问题，几乎没有一张规划卡解决不了的。这七个要素看似枯燥，但每一项背后都是真金白银的时间和数据成本。你可以在下次实验上线前，把这张卡片打印出来放在旁边，逐项打勾。它没办法保证实验一定成功，但至少能保证，当实验结果不显著时，你怀疑的不会再是流量规划本身。