去年冬天，我旁边工位的产品经理突然拍桌子，把咖啡杯震得咣当响。他指着屏幕上的A/B测试报告，两眼放光：“老哥你看，实验组转化率涨了百分之五，p值零点零三，显著！能上线了吧？”我探过头去瞅了一眼，实验跑了三天，样本量两边加起来不到四千，对照组转化率百分之八，实验组百分之八点四。我问他：“你这个实验最少要跑几天？”他说“我拍了七天，但现在三天就显著了啊，提前结束不行吗？”我当时叹了口气，给他画了张图，横轴是时间，纵轴是p值，第一天零点四，第二天零点一五，第三天零点零三，一条非常漂亮的下降曲线。“再跑四天，信不信这条线大概率弹回去？”

他不信。我说行，那你继续跑，别停。第四天p值零点零七，第五天零点一二，第七天结束，p值稳在零点三五。产品经理盯着那条先跌后涨的曲线发了半天呆，幽幽地说：“原来显著性这玩意儿，还能自己长腿跑回去。”

这就是A/B测试最反直觉的地方：你越早看到一个令人振奋的结果，这个结果越可能只是在逗你玩。统计显著性不是一堵墙，翻过去就万事大吉；它是一个会呼吸的东西，随着样本量波动，今天显著明天就哑火。这篇我想跟你聊聊，做A/B测试那些年，被统计指标玩得团团转的日子。

一、为什么要提前算样本量

很多人做A/B测试，上来就是“先跑着看看”。这四个字害死人。

我见过最离谱的一个实验，是一个内容推荐策略的改动。实验组和对照组各分配了百分之五的流量，跑了整整两个月，最后发现转化率提升了百分之二，但p值零点六。跑来问我为什么跑了这么久还不显著，我帮他算了算，以他的基准转化率和最小可检测效应量，每组需要大概十二万样本才能达到百分之八十的统计功效。他跑了两个月，两边各攒了一万八。也就是说，他即使再跑八个月，如果效果真的只有百分之二，也未必能检出显著。

这就引出一个在实操中常常被跳过的步骤：实验前的功效分析。你得先问自己三个问题：第一，我能接受的最低提升幅度是多少？百分之一还是百分之五？第二，我的基准转化率大概是多少？第三，我愿意承担多大的第一类错误和第二类错误风险？前两个是业务判断，第三个通常按行规，阿尔法定零点零五，贝塔定零点二，也就是百分之八十的功效。

有了这四个数，随便找个在线计算器或者用Python的statsmodels库跑一下，就能算出每组最少需要多少样本。算出来的数字往往比你直觉以为的大得多。我从一个做支付的朋友那里拿过一组数据，他们某个环节的转化率高达百分之九十五，想检测零点五个百分点的提升，功效分析显示每组需要大概四万样本。他们每天的流量只有两千，光这个实验就得跑一个多月。不做功效分析，很容易以为一周就能收工。

偷看的代价远比你想象的高。统计学上叫“重复显著性检验”或“偷窥效应”。实验跑的过程中，你每天都去看一眼p值，看到小于零点零五就兴冲冲地结束实验，这会极大提高第一类错误的概率。理论上，如果每天看一眼，连续看十天，真实的第一类错误率可能膨胀到百分之二十甚至更高。你以为自己用着零点零五的阈值，实际上是在跟一个篡改了概率的骰子赌博。

为什么p值会漂移？因为小样本下的估计非常不稳定。实验开始前几天，随便哪个极端用户的行为波动都能把实验组和对照组的差异拉出一个大坑。我做过一个电商优惠券实验，前三天实验组转化率飙升百分之十，我差点就要报喜了。结果第四天来了一个批发用户，在实验组一口气下了四十单，把均值又拉上去一大截。第五天他在对照组的小号也下了二十单，差异又缩回去了。用户的随机波动在小样本下可以被放大成任何你想要的故事。

真正严谨的做法是：事先定好样本量和跑的时间，到了就停，不管显著不显著。或者用序贯检验的方法，在实验开始前就设计好多次中期分析的节点，并且相应地调整每次判断的显著性阈值。可惜大部分公司的实验平台都不支持这个，大家还是在用“跑着看看”的土办法。

二、辛普森悖论在背后捅刀子

有一个经典案例我反复在各种场合讲过，因为它太典型了，我自己差点栽在里面。

某内容平台做了一次推荐算法升级，想看升级后用户的人均阅读时长有没有提升。整体数据跑出来，实验组人均时长竟然下降了百分之三，p值还显著。算法工程师脸都绿了，辛辛苦苦调了两个月，效果反而负了。他百思不得其解，把数据按照用户活跃度分了个层：高活用户、中活用户、低活用户。分层之后的结果让他又惊又喜：每一层用户的人均时长都在涨，高活涨了百分之五，中活涨了百分之八，低活涨了百分之十二。每一层都在涨，但整体却跌了。

这就是教科书级的辛普森悖论。原因出在用户结构的变化上。新算法吸引了大量低活用户回流，这些原本不怎么用的人虽然时长涨了百分之十二，但绝对值还是远远低于中高活用户。低活用户占比从实验前的百分之二十暴涨到百分之三十五，把整体平均值给拉低了。新算法非但没问题，反而是太好了，好到把沉默用户都唤醒了，结果这些人的低基线成了拉低均值的罪人。

从那以后，我每次看A/B结果之前，第一件事就是做分层检查。不光是按用户分层，有时候得按时间分层，按渠道分层，按设备分层。为什么？因为整体平均值的欺骗性是最大的。你以为你在看总体的效果，实际上你只是在看一个被各子群样本权重扭曲过的幻象。

分层不是灵丹妙药，分得越细越容易碰上多重检验的问题。切十个维度，每个维度做一次显著性检验，用零点零五的阈值，纯随机的假阳性概率就不是百分之五了，是百分之四十。这个问题得用Bonferroni或者FDR来修正，但大多数人根本不修，切完看见一个维度显著就拎出来汇报，其他九个不显著的装作没看见，这本质上是在钓鱼。

三、指标体系的虚荣与真实

A/B测试最痛苦的环节不是跑数据，而是定义什么算“赢”。

我曾经负责过一个用户增长实验，产品经理定的核心指标是“次日留存率”。实验跑了两周，次日留存提升了四个百分点，显著。大家弹冠相庆，准备全量上线。运营总监多留了个心眼，让我拉一下第七日留存和第十四日留存。结果第七日留存没有变化，第十四日留存反而跌了两个百分点。什么情况？原来实验策略是在新用户注册当天送一张限时三天的大额优惠券，用户为了把券用掉，第二天确实会回来，所以次日留存上去了。但券用完之后，用户发现商品原价太贵，反而流失得更快了。这个实验本质上是在用短期虚假繁荣透支长期价值。

指标是分层的，你得把它们串成一条线来看。我现在的习惯是，每次实验先摆出一套指标体系，三到四层：第一层是“护栏指标”，用来确保实验没有产生灾难性副作用，比如退款率、客诉率、卸载率，这些指标只要有一个出现显著恶化，不管核心指标多漂亮，实验都得叫停。第二层是“核心指标”，也就是实验要提升的那个目标，通常一到两个，多了容易相互打架。第三层是“解释性指标”，用来解释核心指标为什么涨或跌，比如点击率涨了，是因为推荐内容更精准了还是因为标题更标题党了。第四层是“长期价值指标”，上面那个故事里的七日留存和十四日留存就属于这一层，如果业务场景允许观察足够长的周期，这一层必须放进去。

搭建这套体系最大的阻力往往来自业务方。没人愿意给自己的实验戴上这么多镣铐，他们只想用一个指标证明自己做了件正确的事。我见过一个运营实验，核心指标选了“活动页面分享率”。实验组分享率暴涨百分之两百，看起来牛逼到不行。我看了眼护栏指标，发现页面停留时长暴跌，分享出去的回流点击率几乎为零。原来他们搞了一个“分享得积分”的弹窗，用户点完分享、返回App、积分到账，全程三秒，压根没看活动内容。这实验的分享率提升有意义吗？屁都没有。但活动运营的KPI里写的就是分享率，他赢了，公司输了。

这就是做A/B测试最细思极恐的地方：只要指标选得够巧妙，你可以证明任何你想证明的结论。想证明新策略好，就挑一个容易被短期操纵的指标；想干掉你不喜欢的策略，就给它配一堆严格的护栏指标。数据分析师在这里的角色不是跑数的，而是守门员。当所有人都在为显著性欢呼的时候，你得冷静地追问：这个指标能代表真实的用户价值吗？

四、网络效应与干扰效应

经典的A/B测试假设每个样本是独立的，用户的体验不受其他用户影响。这个假设在很多场景下根本不成立。

我做社交类产品的时候碰到过一个问题，两个人互为好友，一个被分到实验组看到了新功能，另一个在对照组看不到。实验组用户用新功能发了一条消息给对照组好友，对照组好友点开一看，报错，闪退，或者显示不兼容。对照组用户体验直接爆炸，客诉飙升。这种场景下两组用户不是独立的，实验组的行为污染了对照组，直接对比已经没有意义。

解决办法？要么在集群层面做随机化，比如以城市为单位分流，整个上海市都在实验组，整个北京市都在对照组。但这要求你有足够的集群数量，而且集群之间用户互动极少。要么用更复杂的网络效应模型来估计处理效应，但这已经超出大部分公司的工程和统计能力了。更多时候，面对网络效应我们只能退而求其次，做一些有限范围的观察性判断，然后凭经验和直觉拍板。

另一种干扰来自资源竞争。做过广告算法的都知道，你把一批用户分到实验组，给了更高的出价，他们把有限的广告库存抢走了，对照组用户的广告展现自然就变少了，转化也跟着掉。这看起来像是实验组效果好、对照组效果差，实际上是同一个池子里的零和博弈。这种实验的正确做法是对比两个独立的时间段，或者用开关实验的方式，今天全量开实验策略，明天全量关，反复切换，比长期均值。但这又带来了时间序列上的混杂因素，周末和周一用户行为本来就不一样，需要用差异中的差异或CausalImpact这类方法来做分析。折腾下来，一个简单的A/B变成了半篇计量经济学论文。

五、当统计显著碰上业务显著

最后一个坑，也是最常见的坑：统计显著不等于业务显著。

百分之零点一的提升，样本量足够大的时候也能给你跑出p值小于零点零零一。但百分之零点一值得上线吗？工程的复杂度、维护成本、潜在风险，可能远远大于这点收益。反过来，有些提升虽然在统计上不显著，但业务逻辑极其清晰，而且实现成本极低，你上还是不上？

我在一家创业公司的时候，有个后端工程师在接口层做了一行代码的优化，理论上能让加载时间减少十毫秒。A/B跑了一周，因为样本量不够，p值零点二，从统计上没法说有效。但他非常确定这十毫秒是实打实省下来的。最后我们决定全量上线，把实验当成一个“灰度验证”，看看有没有负面问题。上线后，虽然没有完美的对照组，但加载时间的监控曲线整体左移了十二毫秒，客服那边也没有异常反馈。这件事情如果死磕统计显著，永远不会上线，但实际上它就是一个正确的优化。

反过来讲，那些p值完美小于零点零五、但效应量小到可怜、解释逻辑诡异、上线成本巨大的实验，我投反对票从来不手软。数据是决策的辅助，不是决策的替代品。如果你只用数据做决策，那你其实是在用过去的数据做决策，而过去的数据里没有未来的黑天鹅。

做A/B测试这些年，最大的收获不是学会了算p值，而是学会了在数字和业务之间找到一种张力。你对数字得足够尊重，不能瞎解读；但你也得对数字足够警惕，不能被它牵着鼻子走。那些看起来漂亮的显著性，有时候只是替你老板的预设结论披了一件科学的外衣。真正有价值的实验，往往数据没那么完美，但你能从用户行为的每一个微小变化里，嗅到正确的方向。