A/B 实验分析：显著不等于值得上线

A/B 实验分析显著不等于值得上线A/B 实验最容易被误用的一句话是结果显著。显著当然重要但显著不等于值得上线。一个按钮颜色让点击率提升 0.3%样本很大所以显著可是对核心转化没有帮助甚至增加投诉这样的实验不该只凭 p 值拍板。实验分析要同时看统计结果、业务收益、负向指标和长期影响。数据分析师的价值不是宣布谁赢了而是解释赢在哪里、代价是什么、是否值得推广。一、先明确主指标和护栏指标实验设计阶段就要写清主指标。比如支付转化率是主指标退款率、投诉率、页面加载时间是护栏指标。不要实验结束后才到处找一个好看的数字。flowchart TD A[实验方案] -- B[主指标] A -- C[护栏指标] A -- D[样本量估算] B -- E[实验分析] C -- E D -- E E -- F[上线决策]没有护栏指标的实验很容易只看局部收益。业务不是单指标游戏实验也不是。为什么护栏指标缺位的实验就像一个只看利润不看风险的交易员。某次实验把支付转化率提升了 5%结果退款率从 2% 飙升到 8%——算下来净收益反而是负的。护栏指标不是装饰品它卡的是实验可能带来的副作用。一个实验组只有主指标显著提升、护栏指标没有恶化才算是健康的胜出。我在实际项目中见过太多这样的案例改版后点击率涨了但页面加载时间多出 300ms能耗直接劝退了一批中低端机型用户整体活跃反而下降。不看护栏指标的实验就像开着远光灯加速——前面看得清两边全是盲区。二、SQL 要先保证分组干净实验数据第一步是检查分组是否均衡、是否串组、是否有重复曝光。否则后面的统计检验都是空中楼阁。SELECT experiment_group, COUNT(DISTINCT user_id) AS users, COUNT(*) AS exposure_rows FROM dwd_ab_exposure_di WHERE dt BETWEEN 2026-07-01 AND 2026-07-02 AND experiment_id checkout_button_v2 GROUP BY experiment_group;如果某个用户同时进入 A 和 B必须排除或按实验规则处理。串组会污染结果不能装作没看见。为什么A/B 实验的统计推断建立在两组用户独立同分布的假设上。一个用户如果同时进了 A 组和 B 组他的行为就不是独立观测而是自身偏好的双重表达。这种污染在数学上会系统地拉偏效果估计——因为一个用户在 A 组和 B 组的转化状态高度相关相当于把同一个人的选择算了两次。更隐蔽的伤害是串组用户往往不是随机分布的比如某个产品功能灰度期间 iOS 用户更容易被重复曝光那么 iOS 占比高的 B 组天然会显得表现更好但实际上只是渠道结构偏差。干净的实验分组是地基地基歪了上面的统计大厦盖得再高也没意义。三、显著性要配合效应量p 值回答的是差异是否可能来自随机波动不回答差异有多大、值不值得。所以报告里要同时给出提升幅度、置信区间和业务换算。def lift(treatment_rate, control_rate): return (treatment_rate - control_rate) / control_rate control 0.082 treatment 0.085 print(round(lift(treatment, control) * 100, 2))如果提升 3.66%还要换算到订单量、收入和成本。只有这样产品和运营才知道这个实验是否值得上线。为什么p 值本质上回答的是假设两组真没差异观察到当前数据的概率有多大它不回答差异有多大。在一个亿级用户的 App 上做实验哪怕两个按钮颜色只差一个像素只要样本够大也能达到 p0.001 的显著性。但 3.66% 的 CVR 提升如果只对应每天多 10 个订单、收入增加 200 块而改版开发和维护成本是 5 个工程师两周的工作量——这买卖就不划算。统计显著是数学门槛效应量乘以业务价值才是商业门槛。数据分析师最容易犯的错误就是把统计上靠谱等同于商业上值钱。四、分层分析要防止挑结果实验结果整体不显著但某个城市显著某个渠道显著某个设备显著。分层分析很有用但也最容易挑结果。分层应该来自实验前假设而不是结束后漫无目的地挖。为什么分层分析本质上是在做多重比较。如果你把数据按城市、渠道、设备、性别、年龄段全拆一遍就算实验组和对照组真没差异纯靠随机也会有某个子集碰巧显著。这就是多重比较谬误——检验的维度越多假阳性的概率越高。更糟的是实验结束后才去各个维度翻显著结果的人实际上是在做数据挖掘而不是假设检验。一个正规的实验分层分析应该在实验设计阶段就写在分析计划里并且用 Bonferroni 或 FDR 校正置信水平。先开枪再画靶子枪枪都是十环。如果确实发现局部机会可以作为新实验假设而不是直接上线。数据分析要诚实不能把探索当验证。实验还要看运行过程是否健康。流量分配是否稳定实验组是否有埋点缺失是否中途改过策略是否出现样本污染。很多实验结论不可信不是统计方法错而是实验执行过程已经歪了。为什么实验执行过程的扭曲比分析方法的选择更致命。比如实验跑了一周发现流量分配变成 60%/40%大概率是某个缓存层没清理干净实验中途产品经理临时调整了优惠券策略等于在实验画布上又画了一笔埋点团队改了一个事件定义但只通知了一半人。这些问题在统计检验里根本不会报错——p 值照算不误显著性照出不误但它们算的根本不是事先设计的东西。我在一个支付实验里见过最离谱的情况支付成功埋点实际上在 iOS 端上报了两遍导致 B 组支付成功率比 A 组高了 15%——不是功能好是埋点炸了。实验健康检查不是锦上添花它是防止你在垃圾数据上做出漂亮结论的最后一道防线。experiment_health: traffic_split: 50.2% / 49.8% exposure_missing_rate: 0.3% cross_group_users: 12 mid_change: false这些检查应该放在结果页前面。实验健康不过关就不要急着讨论谁赢。踩坑提醒别用 p0.05 一刀切大样本下几乎所有差异都显著p 值单独存在的意义约等于今天有太阳。必须搭配效应量和置信区间一起看否则你会把一个 0.01% 的提升当成大发现去汇报。实验中途不要动策略哪怕产品经理觉得小调整不影响任何改动都会打破组间可比性。正确的做法是把这次调整作为一个新实验的假设而不是在当前实验里修修补补。分层结论和整体结论不要混用整体不显著但某个子集显著说明的是这个子集值得进一步探索而不是这个功能对整体有效。把分层结论当作整体结论上线是 A/B 实验滥用的头号来源。五、总结A/B 实验分析不能只看显著性。主指标、护栏指标、分组质量、效应量、业务换算和分层假设都要一起看。显著只是统计门槛值得上线才是业务结论。分析师要把这两句话分清楚。