企业官网建设流程全解析

“群里又有人在问：下季度 20 个实验流量怎么分？”“我这个实验已经占满 100% 用户了，怎么跑了一周还不显著？”说实话，这种问题我几乎每隔两周就会碰到一次。做了这么多年 AB 实验平台和流量分配，我最大的体会是：很多人把流量规划理解成“申请多少流量跑实验”，但它本质上是在统计可信度、实验周期和业务速度之间做权衡。这篇是 AB 实验关键认知系列第八篇，专门聊实验流量规划，适合实验平台负责人、数据工程师、策略产品经理和增长团队的同学看。

先说一个场景：一个日活 50 万的 App，季度立项会上同时来了 15 个实验需求，每项都想拿全流量跑两周出结论。如果你真的按这个思路做，流量根本不够用，结果就是实验排期拖到版本上线前才能出数据，既没有说服力，也耽误决策。反过来，如果你把每个实验都压到 2% 流量，实验可能跑两个月都达不到最小样本量。流量规划要解决的，就是在这两头之间找到一条可落地的路。

1.1 实验数量与单实验流量的零和关系

流量规划的第一笔账是“零和账”。在一个固定的实验平台上，你可以分配给实验的用户总量是有限的。假设平台有 100 万日活，一个实验拿到 10% 流量，意味着它每天能看到 10 万用户；如果有 10 个实验同时要 10% 流量，加起来就已经 100%，剩下的实验就只能排队。

这里有个常见误区：很多人以为实验平台有足够多的“层”，可以无限并行实验，所以流量不是问题。这话只对了一半。分层确实让同一批用户可以被多个实验复用，我后面会详细讲，但在同一个层内部、同一个流量池内部，流量依然是零和的。一个层假设有 100 个桶，你占用了 20 个桶做实验 A，那实验 B 在本层可用的桶就只剩 80 个。

我在实际做季度规划时，第一步不是讨论技术方案，而是先让各个业务线把实验清单交上来，然后统计一个数字：如果每个实验都按它申请的流量跑，总的“流量占用率”是多少。经常出现的结果是需求总量占用了规划设计流量的 300% 以上。这时候就必须分出优先级，明确哪些实验可以拿大流量快速决策，哪些实验可以用小流量慢慢跑，哪些实验干脆合并到同一批迭代里验证。

1.2 实验周期与结论时效的矛盾

第二笔账是“时间账”。很多做业务的人希望实验结果越快越好，但实际上统计上是有硬门槛的。样本量不够，你只能把实验时间拉长。可是拉长又带来两个副作用：第一是“新奇特效应”，用户刚看到新功能时会因为新鲜感产生短期行为变化，跑得越久，新鲜感消退，数据反而会向真实水平回归；第二是时间窗口拖太久，业务迭代早就往前走了，实验结论出来时对应的版本已经下线，你验证了个寂寞。

所以流量规划里有一个关键动作：给每个实验设定一个“最长可接受周期”。我一般会用两个约束去反推流量需求。一个是最小样本量，另一个是业务方期望的结论时间。比如业务说两周内必须出结论，那就根据最小样本量和这两周的有效曝光，反推出实验至少需要多少流量；如果算出来需要 30% 流量，但平台只能给 10%，那要么业务调整 MDE（最小可检测提升）接受更大的指标波动，要么干脆不要做这个实验，用其他方式验证。

这里有一个实际项目里常被低估的点：有效流量不等于日活。一个 DAU 50 万的 App，真正能进入实验的用户可能只有 30 万，因为很多用户不满足实验的定向条件，比如只面向新用户、只面向 iOS 端、只面向已登录用户。我算流量周期时会先打一个“有效流量折算系数”，通常是 0.4 到 0.8。如果实验定向条件特别长，比如“近 7 天无付费行为的男性用户”，这个系数甚至会降到 0.1。不做这一步，你的实验周期预估一定偏乐观。

1.3 统计检验力与业务速度的取舍

第三笔账是“精度账”。很多人设计实验时喜欢把 MDE 设得特别小，觉得“我要能检测出 0.1% 的提升才严谨”，但这样做的代价是样本量爆炸式增长。样本量公式里，MDE 是放在分母上的，而且是平方关系，所以当你把 MDE 从 1% 缩小到 0.5%，需要的样本量会变成原来的 4 倍。

统计学上的第一类错误（α）和第二类错误（β）也要一起权衡。α 通常固定为 5%，也就是你愿意承受 5% 的“其实没效果但你说有效果”的风险。β 通常取 20%，对应统计功效 80%，也就是真实有效时你有 80% 的概率能检测出来。如果你希望更高功效，比如 95%，样本量也会明显上升。实务中我很少看到有人把功效设为 95%，因为流量成本太高，80% 是投入产出比较合适的点。

我在规划时通常会和业务方对齐一个“决策阈值”：如果预期提升小于某个值（比如相对提升 5%），就算做了实验，结论也很难驱动资源投入；反之如果预期提升大于 20%，直接上线灰度观察就行，不一定非要跑完整 AB。真正值得占用稀缺流量去做的实验，是那些落在“不确定、但影响面大”区间里的事情。这个认知对齐了，流量规划才能从计算题变成资源策略。

2. 先把最小样本量算明白

2.1 从假设检验到“16 个样本”直觉公式

流量规划里最核心的计算是最小样本量。它的标准公式是：

n = (Z_α/2 + Z_β)² × (σ1² + σ2²) / δ²

其中 n 是每组需要的样本量，σ1² 和 σ2² 分别是对照组和实验组的方差，δ 是你想检测的最小绝对差异，Z_α/2 是显著性水平对应的分位数，Z_β 是统计功效对应的分位数。

对于转化率这类二值指标，方差 σ² = p(1-p)，假设两组近似，σ1² + σ2² ≈ 2p(1-p)。当 α=0.05（双侧）、功效=0.8 时，Z_α/2=1.96，Z_β=0.84，两者相加等于 2.8，平方约 7.84。再乘上前面的 2，就得到一个简化公式：

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

这里的 16 就是这么来的。它的意义是：在常规显著性水平和功效下，每组样本量约等于 16 倍的基线方差除以绝对检测差的平方。20% 的转化率，你想检测 1 个百分点的绝对提升，代入公式 n = 16 × 0.2 × 0.8 / 0.01² = 25600，一组就要 2.56 万人，两组就是 5.12 万人。这个数字会比你直觉上想的大很多，因为它要支撑你“拍胸脯说有效”的统计证据。

2.2 一个可以直接抄作业的计算脚本

在实际项目里，我很少手算，都是写一个函数放在实验平台的规划工具里。给你一个可以直接抄的 Python 版本：

import math def min_sample_size(p, mde_relative=0.10, alpha=0.05, power=0.8): """ 计算用户级二值指标下每组所需最小样本量。 p: 基线转化率，比如 0.10 mde_relative: 相对最小可检测提升，比如 0.10 表示 10% alpha: 显著性水平，默认 0.05 power: 统计功效，默认 0.80 """ z_alpha = 1.96 # 双侧 alpha=0.05 z_beta = 0.84 # 单侧 power=0.80 delta = p * mde_relative # 绝对提升 n = ((z_alpha + z_beta) ** 2) * 2 * p * (1 - p) / (delta ** 2) return math.ceil(n) # 示例：基线转化率 10%，想检测 5% 相对提升 n = min_sample_size(p=0.10, mde_relative=0.05) print(f"每组需要 {n} 个用户，两组共 {n * 2} 个用户")

运行结果大概是：每组需要 57600 个用户。如果你每天能进实验的新独立用户只有 1 万人，那这个实验至少要跑 6 天才够。这里的核心变量是基线转化率，它决定了你的方差基准；相对 MDE 决定了你要分辨的差异多小。很多人把 MDE 理解成绝对值，但在业务沟通中它通常是相对值，比如“我们希望检测出 5% 的提升”，所以换算成绝对差值时要乘以基线。

2.3 基线转化率对样本量的影响有多大

流量规划中最容易犯的错是“一刀切”。不同指标基线的方差差异非常大，同样检测 10% 相对提升，低基线和中等基线的样本量需求能差一个数量级。我整理了一张常用表，假设 α=0.05、功效=0.8：

看到了吗，同样检测 10% 相对提升，基线从 20% 降到 5%，样本量需求从 6400 涨到 30400，涨了接近 5 倍。原因是低基率的绝对差太小，比如 5% 提升到 5.5%，这 0.5 个百分点的波动很早就会淹没在随机噪声里。所以做低基线指标实验前，我会额外提醒业务方：要么接受 20% 以上的相对 MDE，要么把实验周期拉长到 20 天以上，要么换成用累计指标或连续指标来评估，否则实验平台会变成“垃圾进垃圾出”。

这里还要补一点：如果是连续指标（比如人均时长、客单价），公式里的 p(1-p) 换成方差 σ²，δ 换成最小可检测绝对差即可，其余思路完全一致。连续指标的好处是方差可以更小，坏处是方差预估依赖历史数据，一旦波动，样本量估算也会跟着变。所以我在规划连续指标实验时，会给方差乘以 1.2 的保险系数再估算。

3. 分层分域：让同一批用户被“重复使用”

3.1 层的本质：同一批用户的多个随机副本

流量规划之所以能支撑大量实验并行，核心机制是分层。层的本质是：对同一批用户，使用不同的哈希函数，生成多套独立的随机划分。

打个比方，你有 100 万用户，把它们理解成一个有 100 万个名字的名单。层 A 用“用户ID + 盐A”做哈希，把用户均匀分到 100 个桶；层 B 用“用户ID + 盐B”做哈希，再把用户重新均匀分到 100 个桶。同一个用户，在层 A 里可能落在 37 号桶，在层 B 里可能落在 82 号桶，这两套划分互不相关。于是层 A 的实验和层 B 的实验可以同时进行，各占各的桶，互不干扰。从概率上，每个层内的对照组和实验组仍然是随机分配的，统计推断依然成立。

这也解释了为什么成熟实验平台可以“无限”叠层：每个层就像同一批用户的一个随机副本，理论上的层数只受工程成本限制，不受流量总量限制。但注意，正交性只保证随机化独立，不保证产品干预之间没有交互。如果层 A 改了一个按钮的颜色，层 B 改了同一个按钮的位置，同一用户同时进了两个实验，页面可能变成一个“不可用”的混合状态，这时数据就全毁了。所以是否分层，还要考虑产品干预的物理属性。

3.2 域：什么时候必须物理隔离

分层解决的是“逻辑复用”，域解决的是“物理隔离”。一个域是一块完整的流量池，域和域之间用户完全不重叠。比如某 App 的主站和极速版各自是独立的域，主站的实验不会影响极速版用户，极速版的实验也不会反向污染主站数据。

哪些情况下必须分域？我自己的判断标准是：指标之间是否有强耦合、产品形态是否差异过大、团队之间是否有强隔离需求。举个例子，实验 A 想提升用户的下单转化率，实验 B 想提升用户的首页停留时长。理论上这两个层可以正交跑，但实际中订单指标和时长指标在用户行为上是耦合的，一个策略可能同时影响这两个指标。如果你不把它们放进同一个域并按业务逻辑互斥，很可能实验 A 显著正向、实验 B 显著负向，但两个实验同时站在同一批用户身上，最后你根本说不清楚到底是谁的功劳。

分域的代价也很明显：每个域的流量池变小，实验容量降低。所以我给团队的建议通常是：不要在业务初期把域切得太碎。一个业务线维持一个主域，设置 3 到 5 个层就够用，只有当两个团队的业务逻辑确实到了“互不打扰”的程度，才值得拆一个新域。

3.3 一个可落地的流量配额模板

我在这里给你一个我在实际项目中反复使用的基本模板，假设一个业务域内有 100 万日活：

为什么会话层可以用 5% 这种小流量？因为会话级实验的统计单元是“会话”而不是“用户”，一个用户一天可以产生多次会话，相当于同样的用户基数下，你能获得更多的样本量。但使用会话层也要小心：同一个用户的多条会话之间存在相关性，如果用户被分配到实验组后反复访问，他带来的多次会话并不是完全独立的。解决方法是至少按“用户级聚类”来评估方差，或者在分析阶段对用户层面的重复样本做聚合处理，否则你的 p 值会虚低，得出过于乐观的结论。

界面层和用户层为什么都建议至少 10%？因为 UI 改版通常只影响少量核心页面的指标，低流量会导致事件量太少，实验周期拉长到不可接受。同时 UI 类实验往往需要高频埋点数据，数据清洗后样本损失较大，建议在样本量计算基础上再乘系数 1.3 再决定流量。

这个模板的核心不是让照抄参数，而是理解“不同实验对象要用不同的哈希维度”，否则会出现一个尴尬场景：你做了一个以内容为单位的实验，结果把同一篇内容推给了相关的 1 万个用户，这 1 万个用户之间的行为高度相关，你的实验实际上是“伪重复”，样本量算得再足，真正独立的信息量也很少。

4. 实操：季度流量规划的五步流程

4.1 第一步：盘点实验需求与指标

季度流量规划不是从公式开始的，而是从表格开始的。我会做一个实验需求清册，字段包括：实验名称、所属团队、对应的层候选、核心主指标、守卫指标、预期提升幅度、期望出结论周期、是否必须全量。让业务方填完后，第一件事是去重和归类。

去重是指：很多业务方会对同一个功能反复申请实验，实际只需要跑一次。归类是指：判断哪些实验属于同一层、哪些实验天然互斥。我见过最夸张的一次，三个团队三个月内分别申请了同一个落地页的按钮改版实验，而且都是全流量。这就是需求盘点没做透的结果。

最后我会按“影响范围”给实验排序。这里的影响范围不是流量大小，而是策略上线后会影响多少用户。影响所有用户的核心策略优先级最高，影响单个频道的策略其次，只影响冷启动用户的策略再往后排。这个排序会直接决定后面的流量配额。

4.2 第二步：确定基线参数与有效流量池

需求清册里的核心主指标，必须从历史数据中提取基线。我建议至少取过去两周，如果业务波动大，就取一个月。不要只用上周数据，因为业务本身有周期性，实验上线前的自然波动很容易被误判成基线变化。

同时要算清楚“有效流量池”。对于每个实验，你需要判断以下三点：一是符合定向条件的用户有多少；二是这些用户中真正会看到实验页面的比例有多少（不是所有用户都会访问目标页面）；三是这些用户每天重复访问的比例有多高，如果你按用户级实验算样本量，重复访问不会增加独立样本，只会增加事件量。

实际操作中，我会把这些约束汇总成一个“每日有效样本系数”。比如 DAU 50 万，实验定向条件缩小到 30%，页面渗透率 60%，那么真正每日能看到实验页面的用户只有 9 万。如果实验分到 10% 流量，每天约 9000 人进入实验。下一步就可以用它反推实验周期。

4.3 第三步：逐实验计算样本量与占用量

有了基线和 MDE，就可以逐个实验计算最小样本量了。我以实际项目中的一个 UI 点击率实验为例：基线点击率 12%，预期相对提升 8%，即绝对提升 0.96 个百分点。带入 16 公式，n ≈ 16 × 0.12 × 0.88 / 0.0096²，算下来一组约 1.83 万人，两组共约 3.66 万人。

再回到上一步的有效流量：页面日渗透用户 9 万，如果实验分到 10% 流量，每天进入实验的用户约 9000 人，分到对照组和实验组各约 4500 人。那么理论上 4 天左右就能达到最小样本量。但实际我不会只排 4 天，因为实验初期有“新奇特效应”，前两天的数据需要丢弃或者至少单独观察；加上日志延迟、用户端异常、SRM 检测等，排期我一般会再乘 1.5 到 2 倍，也就是一周到两周比较合理。

每个实验都这样算完以后，表格会变成类似这样：

这个表格就是流量规划的“实物产出”，后面所有分层和排期都以它为准。

4.4 第四步：分层设计与流量排期

有了实验清单和样本量，接下来就是把实验“放进”不同层。我会先按实验类型分：推荐排序类实验全部放进会话层，UI 改版类放进界面层，商业化策略放进用户层，内容物实验放进内容层。

然后按每个层内的桶数做排期。比如用户层有 100 个桶，会员续费策略申请 5 个桶，另一个用户成长体系实验申请 10 个桶，剩下 85 个桶可以先留着。不要一上来就分配完所有桶，因为流量的弹性很重要，后续总有紧急实验要插队。

特别要提醒的是，两个实验如果预期会互相干扰，就必须放在同一层并设置互斥，或者通过跨层互斥来隔离。如果它们都在同一层内，你只需要占用不同的桶，互斥天然成立。如果有意让它们互相正交、独立评估，才放不同层。这个决策一定要让懂业务的人确认，否则平台配置上很容易埋雷。

还有一个常见场景：两个实验都想要 40% 流量，但同一层总共只有 100 个桶。这时候就要“错峰”：实验 A 先跑一周拿大流量快速决策，出结论后立刻释放流量给实验 B。用这个方式，20 个实验可以在 3 个月内全部完成，而如果所有实验同时申请大流量，可能只能跑 8 个。这是流量规划的另一个关键技巧：把实验设计成“流水线”而不是“矩阵”。

4.5 第五步：上线前自检与监控

最后一步是上线前的自检。我会在实验平台上确认三件事：每个实验的目标桶位是否正确、对照组和实验组是否真的只有目标变量不同、同一层里有没有漏配互斥。然后再看监控面板：每日真实进入实验的用户量是否符合预期，有没有出现样本比例失衡（SRM）预警。

还有流量监控里的“僵尸实验”问题。很多实验上线后跑两周没效果，但没人愿意下线，一直白白占着流量。我建议建立周度下线机制：超过预设周期仍未达到预期且没有明确方向性的实验，自动邮件通知负责人，超过一周无响应就强制下线并释放流量。这样你的流量规划才不会在执行过程中慢慢失效。

5. 常见问题与排查技巧实录

5.1 “明明算够样本了，怎么一周了还不显著”

这是我被问得最多的问题。每次我都会先让他们检查一下“算够”的口径是否对得上。常见情况是：算样本量用的是“独立用户”，但实际上线后的实验对象是“会话”，同一个用户在一周内贡献了 5 个会话，数据表里看起来样本量够了，真实的独立样本却不够；或者相反，按用户级做实验，却用会话级数据去计算 p 值，导致标准误被低估，置信区间看着很窄但结论不可靠。

另一个高发原因是有效流量被高估。业务方说“日活 50 万”，但登录用户只有 20 万，实验又加了“近 30 天有支付行为”的定向，可能只剩 5 万人。这种情况下就算全量跑，最低样本量也很难在一周内满足。我自己的习惯是，在样本量计算脚本里加一个“有效系数”输入框，默认 0.6，宁可多跑几天也不要做样本量不足的实验。

如果真实样本量没有问题，还不显著，那你要怀疑实验本身。此时最该做的事情是检查 SRM。SRM 是实验分流中的“体检指标”，如果实际进入两组的用户比例和预设的 50:50 明显偏离，说明分流逻辑有 bug、日志有丢失、或者实验组用户因为加载失败等原因被系统踢掉了。这种情况下的任何显著性结论都不能信。我见过一个典型案例：实验组因为新增了一个埋点 SDK，导致部分低端机白屏，用户根本加载不出来，实验组进入量只有设定的 70%，最后实验结果当然“不显著”且不可解释。

5.2 “同一层的几个实验数据互相打架”

很多实验平台允许同一个层里有多个实验并行，只要它们占用不同桶，互斥性是有保证的。但数据上“打架”的现象依然会出现。第一个排查点是公共对照组问题。有些平台为了让多个实验共享一个对照组，把所有实验和对照组都映射到同一批桶上，这会导致对照组的数据被多个实验共用，某一个实验的行为影响会传导到另一个实验的对比基准里。

如果你用的不是公共对照组，那就看产品层面是否真的隔离了。两个实验放在不同层但同时作用于同一页面同一区域的用户行为，比如一个改商品卡片样式，一个改推荐排序逻辑，这个时候它们的干预是纠缠在一起的，产生的交互效应会同时出现在双方的指标里。这种问题靠统计方法很难剥离，唯一的办法是配置跨层互斥，或者回到业务逻辑上重新梳理实验边界。

我建议在规划阶段就强制填写“本实验影响的页面和组件清单”，平台自动检测两个实验的清单是否有重叠，有重叠就提示必须放到同一层或设置互斥。这个机制比事后排查高效得多。我在实际平台里就是加了这个校验，之后“两实验互相打架”的工单量直接降了七八成。

5.3 “流量规划文档和执行总是两张皮”

静态的流量规划表格，跟随时变化的实验平台实际状态，经常会出现偏差。本周有一个实验提前下线，下周又插进来一个紧急实验，文档没更新，导致下一次规划时你看到的数据全是过期数据。

我这里分享一个我长期用的做法：把流量规划做成一页“控制面板”，不看文档，只看实时数据。面板上至少要有几个指标：每个层当前总桶数、已占用桶数、剩余桶数；各实验状态（进行中、已下线、排队中）；未来 7 天预计可释放流量。只要这个面板是真实的，季度总结会就不需要“凭经验拍脑袋”。

还要给面板加一个“异常检测”逻辑：如果某实验计划 7 天出结论，但 10 天还没有下线提醒，自动推送消息给实验负责人。这个机制能把平均实验周期从 18 天压缩到 12 天左右，释放出来的流量足够额外支撑 20% 的新实验。流量规划的价值，很多时候就是靠这类执行层面的收口实现的。

最后说几个我踩过很多次坑之后总结出来的体会。第一，流量规划一定不是纯数学，它是在有限的统计资源下排优先级的产品决策。第二，永远给“突发实验”留出一部分流量缓冲，尤其不要把一个层占满，因为一旦有一个紧急且优先级高的实验插进来，你会发现自己没有任何腾挪空间。第三，做流量规划时最好把“实验失败”也当成正常产出，很多实验跑完不显著，但这本身就是可以指导下一步的信息，这类实验不该觉得“浪费流量”，反而给了团队排除错误方向的机会。把这些想清楚之后，流量规划就不再是统计公式和报表，而是一个团队用数据做决策的运行机制。