谷歌前实习生花3年踩坑：90%A/B测试都在自欺欺人|实验|样本量|知名企业|算法|计算|谷歌|随机化

第一次跑A/B测试时，Arnav能写出任何他想要的SQL查询，把数据仓库切得稀碎。但结果解读环节，他懵了——数字前后矛盾，一个看似+10%的提升，一周后随着流量稳定，凭空消失。这是他在谷歌实习期间的真实经历，也是他决定从零造一套实验框架的起点。

三年后，这套框架已经历了数百次实验。Arnav在Medium上完整复盘了搭建过程，核心结论很扎心：大多数团队以为自己在做数据驱动决策，实际上只是用数字给直觉贴金。

第一步：指标定义不清，实验还没开始就已经死了

Arnav见过太多"测转化率"却不定义具体动作的实验。有人追踪收入，却不区分新客和老客；有人看点击数，却不问点击后发生了什么。这种模糊性会让结果自相矛盾——A组在某个维度赢了，B组在另一个维度反超，团队陷入无休止的争论。

他的解决方案是强制三段式指标结构：主指标（Primary）、副指标（Secondary）、护栏指标（Guardrail）。主指标决定实验成败，副指标提供上下文，护栏指标则用来踩刹车——如果用户留存率或页面加载时间出现异常，即使主指标漂亮，实验也必须终止。

一个具体案例：某次推荐算法改版，点击率飙升15%，但护栏指标显示平均会话时长下降了8%。深入分析后发现，新算法诱导用户点击了大量低质量内容。如果没有护栏机制，这个"成功"实验上线后会直接伤害长期用户价值。

第二步：样本量计算不是形式主义，是防骗底线

很多团队跑实验的方式是：上线，等几天，看哪个组数字高。Arnav把这叫"观光式测试"——样本量不足时，随机波动会制造虚假的胜负信号。他早期踩过的坑是，一个实验在第3天显示显著正向结果，团队急于庆祝并全量发布，两周后回滚。

他的框架强制要求预实验样本量计算。输入基准转化率、预期提升幅度、统计功效（Power，通常80%）和显著性水平（Alpha，通常5%），系统输出所需样本量和预计实验时长。在达到这个门槛之前，结果对非技术人员不可见，防止过早解读。

一个反直觉的发现：预期提升设得越激进，所需样本量反而越小。这解释了为什么有些团队喜欢"大胆假设"——不是真的相信，只是想快点拿到结论。Arnav的做法是反向操作，把预期提升压到保守水平，换取更稳健的检测能力。

第三步：分层随机化，让实验组和对照组真正可比

简单的随机分配在样本量小时会翻车。Arnav遇到过极端情况：对照组恰好涌入了一批高价值用户，实验组被误判为失败。他的框架引入了分层随机化（Stratified Randomization）——按用户历史价值、地域、设备类型等维度预先分层，确保每组在各维度上的分布一致。

实现方式是在用户ID哈希前，先将其归入预设分层桶，再在每个桶内随机分配。这增加了工程复杂度，但把组间差异的方差降低了30-50%，相当于用更少的样本量达到同等统计效力。

更隐蔽的问题是"网络效应"。如果实验涉及社交功能（如好友推荐），对照组用户可能通过实验组用户间接受到影响，污染结果。Arnav的解法是在这类实验中采用用户簇随机化（Cluster Randomization）——以社交图谱中的连通分量为单位分配，而非单个用户。代价是样本效率下降，但结论可信度大幅提升。