很多团队把数据分析里的A/B测试看成一套“跑流量、看P值”的标准流程，但我在亲手搭建过多个增长实验体系、复盘过上百次实验之后，得出一个核心判断：A/B测试的成败，60%以上由实验设计阶段决定，统计检验只是最后一道防线。绝大多数所谓“统计不显著”或“结果不可复现”的实验，根源往往不是样本量不够，也不是P值算错，而是从一开始就埋下了假设不清晰、指标错位、分流机制粗糙、实验时长拍脑袋等设计问题。
这篇文章不是A/B测试的百科式教程，而是基于我真实踩坑经验的方法论复盘。我会先讲结论，再用场景和案例拆解误区，给出我自己使用的一整套实验设计逻辑，最后针对不同业务阶段给出可落地的行动建议和取舍标准。如果你正在为“实验跑了一堆，但业务增长依然靠猜”而困惑，这篇文章应该能帮你从根本上改变做实验的方式。
A/B测试的完整链路包括：业务问题定义、可证伪假设、指标分级、最小可检测效应（MDE）设定、样本量计算、分流设计、实验时长、停止规则、统计检验、结果解读和上线跟踪。绝大多数团队把注意力集中在最后一两个环节，导致统计检验承担了原本属于实验设计的责任。
我见过一个团队花了三周跑一个优惠券实验，结果显示“实验组转化率提升12%，p=0.04”，看起来非常漂亮。但复盘时发现，这个实验只在周末流量上跑，而周末用户的付费意愿本身就比工作日高15%。也就是说，即使不发放优惠券，实验组也会“自然获胜”。这不是统计学能解决的问题，而是实验设计阶段没有覆盖完整业务周期。
所以我的核心结论很简单：统计显著性只是一个“结果信号”，实验设计才决定这个信号是否真实。信号失真时，再精确的检验都只是给错误结论披上科学外衣。
我每评审一个新实验，都会用下面五条标准逐一检查，任何一条不满足，实验都不会启动：
在我管理的实验体系中，约有40%的实验最终没有达到统计显著。但这其中有相当一部分在业务上是有价值的：效应量为正、置信区间上限超过MDE、方向与长期目标一致。把这类实验简单归档为“失败”，等于放弃了累积改进的机会。
真正失败的不是“结果不显著”，而是“实验设计无法支持任何结论”。如果样本量严重不足，导致置信区间宽到无法判断方向，那才是浪费流量和资源。因此，我评价一个实验团队的水平，不是看他们赢了多少次，而是看他们是否能在实验结束后清晰回答三个问题：效应量是多少？置信区间多宽？业务上是否值得行动？
下面这张图来自我对多个实验项目的复盘观察，它展示了实验结论失效的主要归因分布，可以看出实验设计问题高居首位。
2022年，我帮助一家内容社区产品优化推荐策略。产品经理同时上线了两个实验：功能A是新的推荐算法，功能B是新的信息流卡片样式。两个实验被跑在同一个流量池里，用户ID哈希后随机进入各自的实验组和控制组。首周数据显示，功能A的点击率提升6.4%，p=0.03，团队准备全量发布。
我在上线前的最后一步检查中发现了一个严重问题：有79%的功能A实验组用户，同时进入了功能B实验组。也就是说，这两个实验的样本高度重叠，功能A观察到的“提升”实际上混合了功能B带来的视觉变化效应。随后我们将两个实验拆分到独立流量层重新跑了两周，功能A的真实点击率提升只有1.2%，p=0.41。
这个案例让我意识到一个残酷的现实：当实验之间存在用户重叠时，实验报告里的显著性水平完全不可信。污染样本会向任一方向扭曲效应量，而且你根本不知道扭曲了多少。
为了向团队解释这个问题，我做过一次情景模拟：在单实验池、双实验池重叠、三实验池重叠下分别测量某个已知真实效应量为+2%的改动，观察估算效应量偏离真实值的程度。模拟结果显示：双实验池重叠时，效应量估算偏差可能扩大到真实值的4倍以上；三实验池重叠时，偏差进一步放大。
这一场景在快速迭代的团队里极度常见。为了追求实验吞吐量，多个实验并行跑在同一批用户上，又没有建立互斥层和可重叠层的分流机制。结果不是“实验加速”，而是“实验互相污染”，最终得到一堆无法解释的数据。
很多团队的默认心态是：与其花两周时间设计实验，不如先把代码上线，用真实数据说话。但真实数据只有在“干净”的实验环境下才具有决策价值。一次污染实验带来的危害不只是浪费了两周开发资源，更危险的是：它会让团队对错误的方向建立信心，把资源投入到并不真实存在的洞察上。
我在复盘会上说过一句话：一个设计糟糕的实验，比不做实验更危险，因为它把“猜测”包装成了“证据”。从那以后，我的团队定了两条铁律：上线实验前必须进行AA测试；不同业务线的实验必须进入独立的流量层。
最常见的错误开口方式是：“我们把按钮改成了绿色，看看点击率能不能提升。”这是一个想法，不是一个可检验的假设。可检验的假设必须包含用户、场景、改动、预期指标和预期影响方向。
我要求团队把假设写成标准句式：“如果[某类用户]在[某场景]看到[某改动]，那么[某指标]会相比基线提升[某幅度]。”写不出这个句子的实验需求，一律退回重新思考。
有的实验报告密密麻麻列了20个指标，从点击率到留存，从人均时长到NPS，只要有一个指标p<0.05就宣称实验有效。这种行为本质上是“数据钓鱼”。当你在多个指标上反复观测时，假阳性概率会显著上升。
我给一套清晰的指标分级规则：主指标1个，是业务最终关心的结果指标；护栏指标1-2个，用于监控负面效应；探索指标不超过3个，用于发现意外洞察。如果一个实验的结论需要靠探索性指标来支撑，那说明主指标并没有被改善。
下面这张图展示了“同时看N个指标时至少出现一个假阳性的概率”，指标越多，虚假发现的风险越不可控。
样本量计算器里有一个关键参数叫“最小可检测效应”。很多人在计算器里填1%或0.5%，理由是“我们想检测出任何细微的差异”。但MDE越小，所需样本量越大。在流量有限的情况下，强行追求超高灵敏度只会让实验无限期延长。
MDE本质上是一个业务决策，不是统计参数。你必须先回答：这个改动至少要带来多大的收益，才值得承担开发和上线风险？如果把支付转化率从10%提升到10.1%，每年多赚不到一万元，那这个实验就不值得为了检测0.1%的差异而跑三个月。
当一个产品同时有多个团队在跑实验时，如果没有统一的实验分层机制，就会发生我在前面案例中提到的样本污染问题。正确的做法是建立“互斥层”和“可重叠层”：互斥层用于放置可能相互影响的实验，可重叠层用于放置相互正交的实验。
例如：UI实验和推送文案实验通常可以放在可重叠层，因为UI改动与推送触达发生时间不同；但推荐算法实验与信息流卡片样式实验必须放在互斥层，因为两者共同作用于同一个用户决策界面。
我见过一个团队用样本量计算器算出“需要5000个用户”，结果流量充足，两天就达标了，于是第三天就结束实验。但他们忽略了一个关键问题：实验覆盖的业务周期不完整。对于订阅制产品，用户的续费决策周期可能是30天；对于低频B2B产品，用户的采购决策周期可能长达90天。如果实验只跑了两天，你观察到的只是早期冲动反应。
更隐蔽的问题是“新奇效应”：新功能刚上线时用户会出于好奇点击，但新鲜感消退后行为回归常态。如果实验在好奇心最旺盛的第三天结束，就会高估功能价值。因此我要求实验时长至少覆盖一个完整业务周期，并尽量包含周末和工作日。
P值本身并不能告诉我们“效果有多大”，也不能告诉我们“结果有多稳定”。我在实验报告中永远同时报告三样东西：效应量、置信区间、业务影响。比如：“转化率提升2.3%，95%置信区间[0.8%, 3.8%]，按当前月活估算，每月新增约1200个付费用户。”这比只写“p=0.04”有价值得多。
另外，很多团队习惯于“看到p<0.05就上线，看到p>0.05就下掉”。但p>0.05只说明“数据不足以证明差异”，并不说明“两者相同”。如果实验组的方向为正、置信区间大部分区域都为正，且业务影响可估算，那么即使没有达到显著性，你仍然要思考“上线是否比下线更合理”。
我拿到一个实验需求时，第一件事不是问“改什么”，而是问“我们要解决什么业务问题”。例如：“新用户首日激活率比行业基准低20%”是一个业务问题；“把注册页的第三方登录按钮放大”是一个想法。
把两者连接起来后，假设是：“如果新用户看到更醒目的第三方登录选项，那么注册流程完成率会比目前基线提升5个百分点。”这个假设可以被数据支持或否定，并且包含了明确的受众、改动和预期效果。
我用三层指标结构来约束实验评估：
MDE的设定逻辑是：计算一个改动在全量上线后带来的收益，再减去开发成本、实验流量成本、失败风险成本，得出“值得检测的最小业务收益”。例如，某SaaS产品的企业版付费转化率当前为8%，改版目标是为公司带来每年至少500万元的增量收入。按当前线索量估算，转化率需要提升1.2个百分点才能达到500万元，那么MDE就设为1.2%，而不是随便填“0.5%”。
对于二值指标，我常用这个样本量公式：
n = (Zα/2 + Zβ)^2 × [p1(1-p1) + p2(1-p2)] / (p2 – p1)^2
其中p1是基线转化率，p2=MDE对应的期望转化率，Zα/2是显著性水平对应的Z值，Zβ是统计功效对应的Z值。以p1=10%、MDE=2%、α=0.05、功效=80%为例：
Zα/2 = 1.96, Zβ = 0.84
n = (1.96 + 0.84)^2 × [0.1×0.9 + 0.12×0.88] / (0.02)^2
n = 7.84 × 0.1956 / 0.0004 ≈ 3835
这是单组样本量。两组加起来约7670个有效事件样本。注意“有效事件样本”不是“进入实验的用户数”，而是“触发目标行为的用户数”。如果你的目标行为的触发率只有5%，那么你需要约15万用户进入实验，才能获得7670个有效行为样本。
分流策略我首选“分层随机化”。分层随机化与简单随机化的区别在于：前者先按预测能力较强的特征（新老用户、渠道、设备、地域）分层，再在每一层内部随机分组。这样能保证关键特征在实验组和控制组之间的分布高度一致，从而减少基线差异。
我还要求每次新实验开启前，必须跑一次AA测试：让两个组都接受完全相同的版本，验证关键指标在两组之间是否存在显著差异。如果AA测试中某个指标的差异超过我们设定的容忍阈值，说明分流系统存在故障，需要排查后才能开启正式实验。
实验时长由三个因素共同决定：样本量目标所需时间、完整业务周期、季节性覆盖要求。取三者最大值，而不是“样本量够了就停”。
举例：样本量计算需要7天，订阅续费周期30天，业务旺季在月中，那么最短实验时长应为30天。我给自己团队定的规则是：实验开始后固定观察期至少7天，期间不做上线决策；观察期结束后，如果置信区间下限仍高于MDE，才可进入发布评审。这个规则虽然保守，但能有效过滤早期噪音导致的假阳性。
某订阅制SaaS产品计划把付费按钮文案从“立即订阅”改为“开始30天免费试用”。产品团队期望通过降低首次付费的心理门槛，提升注册到付费的转化率。实验跑起来之后，第三天数据表现喜人。
第5天我收到产品经理消息：“实验组转化率提升7.4%，p=0.03，我们可以发布吗？”我按规矩拒绝了，因为预设观察期是14天。后续数据让团队所有人都冒了冷汗：第10天效应量降到5.2%，p=0.08；第15天效应量降到3.8%，p=0.13；第30天效应量只剩2.1%，p=0.21。
为什么早期数据如此具有欺骗性？因为我们分析后意识到：实验组前5天转化的用户，大部分是本来就准备付费的高意愿用户；对照组中的高意愿用户只是还没进入转化周期，他们在第七天、第十天自然会转化。实验组只是“催化”了原本就存在的转化，而不是真正产生了增量付费用户。
有一次我们为App新用户引导页准备实验，分流采用用户ID哈希取模。实验启动前我坚持先跑48小时AA测试，结果显示实验组和对照组在留存率上的基线差异达到1.8个百分点，而我们的预期MDE只有2个百分点，基线差异几乎吃掉了一半的检测灵敏度。
排查后发现，分流哈希函数在高并发下产生了模数偏差，导致部分新用户被错误地映射到实验组。如果跳过AA测试，正式实验一启动就会得到“引导页改动有效”的错误结论，因为差异在实验开始前就已经存在了。AA测试不是流程仪式，而是检验分流系统是否健康的一种体检工具。
一个B2B产品月活只有2万人，主要转化路径是“注册试用→免费试用30天→购买”。付费转化率约1.2%。如果用经典A/B测试检测20%的相对提升，即绝对转化率提升0.24%，按α=0.05、功效=80%计算，需要约6.8万有效事件样本。以当前每月约240个付费事件计算，需要跑约28个月。几乎不可能完成。
我的解决方案是：把检测指标从“最终付费”上移为“激活事件”。例如，把“创建第一个项目并邀请成员”作为主指标，激活率大约是付费率的10倍。在相同MDE和功效下，实验时长可以压缩到2-3个月。虽然激活事件不等于付费，但它与付费高度相关，而且能更快测量。用激活指标跑出方向性结论后，再按季度跟踪最终付费数据验证。
我在多个实验中发现，C端高频产品的短期效果和长期效果往往方向一致但幅度递减；而B2B低频产品的短期效果可能是负的，长期效果却是正的。原因在于B2B用户的决策链条更长，新流程需要学习成本，初期效率下降是正常现象，一旦磨合完成后效率提升会超过旧版本。
因此，B2B实验只看首周数据就会得到“新流程伤害效率”的错误结论。我通常会把B2B实验的报告拆成两个阶段：第1周用于检测有无重大负面问题，第4周的数据才是是否上线的决策依据。
对于DAU百万级的产品，流量充足是巨大优势，但真正的瓶颈往往是“并行实验管理能力”。我建议建立三层分流结构：基础UI层、算法推荐层、推送触达层。每层拥有独立的随机单元划分，层与层之间互不干扰。
在高流量场景下，我倾向于使用“固定时长+多候选并行”的实验策略：一次同时测试5-10个候选方案，在一周内筛出表现最好的前两名，再进行第二轮确认实验。这样可以把实验周期缩短到两周一次迭代，而不是一个月一次。
当有效事件样本每月不足5000时，经典A/B测试的效率会非常低。不要硬撑随机对照实验，以下方案按优先级排序：
当一个版本的改动是全链路、多模块的组合变化时，传统A/B测试无法准确定位“哪个改动带来了哪个效果”。因为多个变量同时改变，你只能观察到组合效应，无法分解归因。我的建议是：把重大改版拆成“阶段性发布+持续监测”，每个阶段只变化一个关键变量，并使用DID方法对比新旧版本用户的行为差异。
观察一个组织是否建立了真正的实验文化，我只看三点：是否有统一的实验平台记录所有实验；是否每次实验都输出了可复用的结论库；是否有实验评审流程防止低质量实验上线。当这三个条件都满足时，实验的累积收益会呈现复利增长。
α的值取决于“犯错的代价”。探索性实验的结论主要用于内部判断方向，α可以放宽到0.1，减少样本量需求，加快迭代速度。而涉及对外承诺、财务结算、用户协议变更的实验，α应收紧到0.01，避免错误结论造成重大损失。
我的一条经验是：α的取值应与实验结果的“可逆性”挂钩。改动成本低、上线后容易回滚的实验，α=0.1没问题；改动成本高、回滚困难的实验，α=0.01也不过分。
当功效只有60%时，一个负结果无法区分“改动无效”和“检不出来”。此时如果你仍然坚持经典A/B测试，结果只会增加决策噪声。我通常做两件事：一是牺牲MDE，只检测较大效果，至少保证功效达到80%；二是改变实验单元，从“用户级”切换为“会话级”，增加有效样本量。
当然也有第三选择：接受较低功效，并把结论标注为“探索性证据”。这个选择适合低风险、高潜力的实验，但不能作为全量发布的核心依据。
序贯检验和贝叶斯方法允许“边跑边看”，在达到预定证据强度时提前结束实验。这类方法非常适合快速迭代场景，但前提是必须预先设定停止边界，并且不要频繁观测未到边界的中间结果。没有边界的持续观测本质上是另一种P-hacking。
我如果使用序贯检验，会设定三个检查点：第1/3时长、第2/3时长、第3/3时长。每个检查点根据当时的样本量和效应量计算新的显著阈值，而不是用固定的p<0.05。
A/B测试的统计模型默认“一个用户的转化不受另一个用户是否在实验组的影响”。但在社交产品和企业协同工具中，这个假设经常不成立。例如，一个团队成员看到新功能，会主动邀请同事使用，导致控制组用户的转化率也被实验组“感染”。
当产品存在强社交传播或网络效应时，我建议按“群体”而不是“用户”作为随机单元，例如以公司、班级、社区为单元分组。这会对样本量和实验时长产生较大影响，但能保证结论有效。
最经典的情况是：一个弹窗式优惠活动让短期转化率提升20%，但用户对品牌的信任感下降，次月留存率下降5%。这就是短期主指标与长期健康的冲突。
我要求每个实验的上线评审必须同时回答：这个实验对LTV是正贡献还是负贡献？如果不确定，就继续追踪；如果明显为负，哪怕短期指标再好也不得上线。短视的实验决策能带来一次漂亮的周报，却会透支产品长期增长空间。
我在这篇文章里反复强调一个观点：A/B测试的本质不是在制造一个“科学证明”，而是在降低决策风险。统计显著只是“差异不是偶然”的证据，而你真正需要回答的是“这个差异是否值得行动”。后者涉及业务价值、成本风险和长期目标，远不止一次检验能覆盖。
如果你正在准备自己的第一个关键实验，我建议按下面这个清单逐步执行：
一套可靠的实验设计方法，不会让每次实验都赢，但会让每一次实验都输得明明白白、赢得清清楚楚。把精力从“P值是多少”转移到“实验设计是否经得起推敲”上来，你会发现，A/B测试真正带给团队的不是某种“统计学魔法”，而是一套持续收敛不确定性、让每一步产品迭代都有据可依的决策系统。
我以前做首页注册按钮实验时，第一版只看了两天数据，发现实验组转化率高出 11%，团队马上准备上线。后来我把数据按天拆开，才发现提升主要来自周末流量，工作日结果几乎没有差异。我想知道，A/B 测试到底应该用什么方法确定样本量和周期，才能避免被短期波动误导？
样本量不能从“每天大概有多少访问量”倒推，而要先明确三个数字：基线转化率、最小可接受提升幅度，以及显著性水平和统计功效。最容易被忽略的是第三个数字，如果你希望识别 2% 的相对提升，所需样本可能是识别 15% 提升的数倍。
我复盘过一个注册页按钮颜色实验：基线转化率为 8%，团队希望识别至少 10% 的相对提升，也就是实验组达到 8.8%。在显著性水平 5%、统计功效 80% 的条件下，单组大约需要 1.4 万名用户。团队当时每天每组只有 1800 名用户，却只跑了 3 天，这个结果在统计上远未达到稳健结论。
目标相对提升基线转化率单组所需样本量（约）适合的实验判断 20%8%约 3500适合验证明显改版 10%8%约 14000适合验证常规优化 5%8%约 55000需要较大流量和较高执行纪律 实验周期也不能只按样本量计算。
至少要覆盖完整的业务周期，通常包括两个完整周，电商或内容业务还要覆盖一次促销、发薪日或周末高峰。我的判断标准是：样本量达标、预先设定的周期结束、各主要用户分层没有严重偏斜，这三项同时满足后再看结论。不要每天刷新显著性并在某天达到阈值后停止，这会显著增加误判概率。
如果业务必须连续监控，应使用序贯检验或预先规定中期检查节点，而不是把普通固定样本量检验反复使用。
我做过一次支付页文案实验，实验组的支付按钮点击率提升了 18%，看起来非常漂亮，但最终支付成功率只提升了 1%，退款率还略有上升。后来我意识到，点击只是中间行为，不一定代表真实价值。A/B 测试应该怎样设置核心指标、护栏指标和观察指标？
一个成熟的实验不会只设一个“胜负指标”，而是把指标分成核心指标、护栏指标和诊断指标。核心指标回答“方案是否创造目标价值”，护栏指标回答“是否用其他损失换来了局部增长”，诊断指标则帮助解释结果为什么发生。
支付页案例中，按钮点击率只是诊断指标，支付成功率才是核心指标，退款率、客服投诉率和支付失败率属于护栏指标。如果只盯着点击率，实验组会被误判为成功；但从用户完成支付和后续履约的角度看，它只是让更多人进入了一个并不稳定的支付流程。
指标层级示例使用方式常见误区 核心指标支付成功率、7 日留存、有效线索率决定是否推广选择最容易被改动影响的指标 护栏指标退款率、投诉率、页面崩溃率设定不可接受的下降边界实验结束后才补看 诊断指标按钮点击、表单完成、停留时长解释行为路径把中间行为当成业务结果 我通常会在实验开始前写一张“指标契约”：核心指标是什么、统计口径是什么、观察窗口多长、护栏指标允许波动多少。
例如，支付成功率提升至少 3%，且退款率不能上升超过 0.3 个百分点。这样可以避免实验结束后临时挑选最漂亮的指标。还要区分用户级指标和事件级指标。一个用户重复点击十次，事件级点击率可能被放大，但用户级支付成功率并不会因此改善。
涉及转化、留存、复购的实验，我更倾向于以用户为分析单位，并明确去重规则和归因窗口。
我曾经遇到过一个实验，实验组和对照组的最终转化率差距很大，但检查后发现移动端流量在两组中的比例并不一致。另一次实验恰好碰上了广告投放，新增用户大量涌入，结果让旧方案看起来异常优秀。我想知道，实验过程中应该重点检查哪些数据质量问题？
在解释实验效果之前，我会先检查实验是否“可比”。统计显著并不等于实验有效，如果两组用户构成、曝光概率或数据回传存在问题，显著性检验只能精确地放大错误。最值得优先检查的是样本比例不匹配，也就是实际分流比例是否接近预设比例。
比如计划按 50%∶50% 分流，实际却是 56%∶44%，而且偏差具有统计显著性，就要先排查分流代码、缓存、登录状态和多端身份合并问题，而不是继续讨论哪个版本更好。
检查项目我会看的信号发现异常后的处理 样本比例实际分流是否偏离预设比例暂停解读，排查分流和埋点 基线平衡设备、地区、渠道、历史转化率确认随机化是否失效 曝光完整性进入实验但未真正看到方案的用户按曝光用户或意向分析重新核算 数据延迟订单、退款、留存是否尚未回传延长观察窗口 外部事件投放、促销、版本发布、故障分层分析或剔除受影响时段 我还会把结果按设备、渠道、新老用户和地区拆开看，但不会因为某个分层显著就直接宣布结论。
分层越多，偶然出现“显著差异”的机会越大。分层分析的正确用途是发现机制和风险，而不是从几十个切片里挑一个最好的数字。一个实用做法是建立“实验健康检查”页面，实时展示分流比例、曝光率、埋点回传率、核心指标基线和异常告警。
过去我们把大量时间花在实验结束后的争论上，后来把这些检查前置到上线后 30 分钟，很多错误当天就能被发现，避免了连续运行一周后才返工。
我以前遇到过一个结果不显著的实验，产品团队认为“没有显著提升就等于失败”，准备直接关闭。可是进一步看数据后，实验组在新用户中表现较好，在老用户中却明显变差。我不确定不显著到底代表方案没有价值，还是实验设计和流量不足，应该怎样做最终决策？
“不显著”不等于“没有效果”，它只表示在当前样本量、波动水平和实验设计下，证据还不足以支持某个方向。最终决策需要同时看效果大小、置信区间、业务成本、风险边界和后续验证价值，而不是只看显著性标签。我会把结果放进四个决策区间：明确胜出、明确失败、方向有希望但证据不足、指标冲突。
最后一类尤其不能用平均值简单裁决。例如新用户转化提升 6%，老用户下降 4%，整体接近 0%，这不是“没有效果”，而是一个需要分人群处理的产品信号。
结果状态典型特征建议动作 明确胜出核心指标达到目标，护栏指标稳定，区间较窄分阶段放量并持续监控 明确失败核心指标下降或护栏指标越界停止方案，记录失败假设 证据不足点估计有提升，但区间跨过无差异线评估增样本是否值得，不能无限延长 指标冲突短期转化提升，长期价值下降延长观察窗口或拆分人群 我特别警惕“为了等显著而无限延长实验”。
如果实验已经运行四周，核心指标的置信区间仍然很宽，通常说明效果太小、指标噪声太大或目标用户量不足。此时更好的选择可能是改进方案、换更敏感的指标，或者承认这项优化不值得继续投入。上线也不应该是一次性切换。
我更建议采用 10%、25%、50%、100% 的分阶段放量，每个阶段至少观察一个业务周期，并持续检查核心指标和护栏指标。对于支付、推荐、风控等高风险场景，即使实验结果明确胜出，也要保留回滚开关、版本标记和异常日志。实验报告最后应记录四件事：原始假设、实际结果、未解决的不确定性、下一步动作。
真正有价值的实验不是给某个版本盖章，而是让团队知道哪类用户、在什么场景下、为什么会对方案产生反应。
读者评论
这篇文章把A/B测试的核心问题讲透了。之前我所在的团队也总把“不显著”归结为样本量不够，但复盘后常发现是实验设计阶段就有问题，比如指标选错、实验时长只覆盖了工作日。特别是“实验设计是操作系统，统计检验只是显示器”这个比喻很贴切，推荐所有做增长的同学都重新审视自己的实验流程。
读完很有启发。我以前真的以为A/B测试就是跑流量、看P值，没想到实验设计有这么多门道。文中提到的“可证伪假设”和“指标分级”让我意识到自己过去跑的实验很多都不合格。不过文章有些内容偏方法论，如果能有更多实际案例的分步拆解就更好了。
文章指出的问题很真实，特别是在并行实验增多后，流量分层和实验污染确实容易成为隐患。作为业务负责人，我认同应该从设计阶段把控实验质量，但实际执行中，多个团队之间统一实验规范并不容易，需要专门的平台或流程来保障。希望后续能有一些关于如何落地实验治理机制的建议。