“群里又有人在问下季度 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_α/21.96Z_β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_relative0.10, alpha0.05, power0.8): 计算用户级二值指标下每组所需最小样本量。 p: 基线转化率比如 0.10 mde_relative: 相对最小可检测提升比如 0.10 表示 10% alpha: 显著性水平默认 0.05 power: 统计功效默认 0.80 z_alpha 1.96 # 双侧 alpha0.05 z_beta 0.84 # 单侧 power0.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(p0.10, mde_relative0.05) print(f每组需要 {n} 个用户两组共 {n * 2} 个用户)运行结果大概是每组需要 57600 个用户。如果你每天能进实验的新独立用户只有 1 万人那这个实验至少要跑 6 天才够。这里的核心变量是基线转化率它决定了你的方差基准相对 MDE 决定了你要分辨的差异多小。很多人把 MDE 理解成绝对值但在业务沟通中它通常是相对值比如“我们希望检测出 5% 的提升”所以换算成绝对差值时要乘以基线。2.3 基线转化率对样本量的影响有多大流量规划中最容易犯的错是“一刀切”。不同指标基线的方差差异非常大同样检测 10% 相对提升低基线和中等基线的样本量需求能差一个数量级。我整理了一张常用表假设 α0.05、功效0.8基线转化率相对 MDE绝对提升 δ每组需要样本量5%10%0.5pp3040010%10%1pp1440020%10%2pp640030%10%3pp373350%10%5pp1600看到了吗同样检测 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 万日活层名称建议哈希维度层内桶数用途建议最小申请流量用户层用户 ID100用户策略、账号体系、商业化10%会话层会话 ID100信息流排序、首页内容5%界面层用户 ID100UI/UX 改版10%内容层内容 ID100内容池/商品池策略视对象量级为什么会话层可以用 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 倍也就是一周到两周比较合理。每个实验都这样算完以后表格会变成类似这样实验层候选基线指标相对 MDE每组样本量申请流量预估周期首页按钮改版界面层12%8%1833310%7 天推荐排序模型 V2会话层次均时长 8 分钟5%视方差20%14 天会员续费策略用户层次月续费率 30%10%37335%5 天这个表格就是流量规划的“实物产出”后面所有分层和排期都以它为准。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% 的新实验。流量规划的价值很多时候就是靠这类执行层面的收口实现的。现象可能原因排查与解决样本量够了但 p0.05有效流量被高估、统计单位用错核对实验口径、用 SRM 做体检实验组人数低于预设分流 bug、埋点丢失、客户端兼容性暂停实验先查分流与日志同层两个实验互相影响公共对照组或干预链路重叠关闭公共对照组配置层间互斥实验排期总是延误流量被僵尸实验占用建立周度下线机制和异常提醒对应指标波动极大基线数据取错区间至少取两周历史数据并预留方差保险系数最后说几个我踩过很多次坑之后总结出来的体会。第一流量规划一定不是纯数学它是在有限的统计资源下排优先级的产品决策。第二永远给“突发实验”留出一部分流量缓冲尤其不要把一个层占满因为一旦有一个紧急且优先级高的实验插进来你会发现自己没有任何腾挪空间。第三做流量规划时最好把“实验失败”也当成正常产出很多实验跑完不显著但这本身就是可以指导下一步的信息这类实验不该觉得“浪费流量”反而给了团队排除错误方向的机会。把这些想清楚之后流量规划就不再是统计公式和报表而是一个团队用数据做决策的运行机制。
