1. A/B测试到底在解决什么核心问题
A/B test，说白了就是互联网行业里最常用的一套对照实验方法。你把用户随机分成两组或多组，一组看老版本（对照组），另一组看新版本（实验组），然后比较两边核心指标有没有真实差异。它解决的是一个很朴素但极其要命的问题：这个改动到底有没有用，好用多少，值不值得全量上线。产品经理拍脑袋觉得按钮换个颜色转化会涨，运营觉得文案改一改点击会高，这些判断如果没有 A/B test 兜底，最后基本都会变成"我觉得"和"看起来"的口水战。
我第一次认真做 A/B test 是在一个电商项目上，当时团队花了三周改了一版详情页，上线前所有人都觉得转化率会涨。结果跑了两周实验，转化率不仅没涨，加购率还跌了 3 个百分点。那次经历让我彻底明白，人的直觉在数据面前有多不靠谱。A/B test 不是给结论背书的工具，它是帮你证伪的工具——它的默认立场是"这个改动没用"，只有数据强到能推翻这个默认立场，你才敢说有用。
适合谁看这篇？如果你是刚入行的数据分析师、增长产品经理、后端或前端工程师，需要自己搭一套实验平台或者独立跑一次实验，那这篇会从原理讲到落地。如果你已经做过几次实验，但每次看到 P 值、置信区间、样本量这些词还是半懂不懂，那这篇会帮你把这些概念串起来。A/B test 表面上是技术活，底层其实是统计学和产品判断的结合，两样缺一不可。
2. 底层逻辑：随机化、对照与统计推断
2.1 为什么随机化是整个实验的命根子
A/B test 的科学性完全建立在随机化和对照这两个支柱上。随机化指的是每个进入实验的用户，被分到 A 组还是 B 组的概率是固定且已知的（通常是 50/50）。这样做的目的是让两组在所有维度上——年龄、地域、设备、历史行为、甚至当时的心情——在期望上都一致。只有两组"起点相同"，最后观察到的指标差异才有可能归因于你改动的那一个变量。
这里有个很多人忽略的点：随机化要发生在用户粒度上，而不是请求粒度上。假设你按请求维度分流，同一个用户第一次访问看到 A 版，第二次刷新看到 B 版，他的体验是割裂的，而且数据会相互污染。正确做法是给每个用户 ID 做一次哈希，哈希结果决定他这次实验看到哪个版本，并且在整个实验周期内保持不变。这就是常说的流量正交和分桶一致性，后面讲分流机制时我会展开。
注意：随机化不等于"随便分"。如果你按用户注册时间分流，比如把早期用户分到 A 组，那两组天然就有差异，这种实验从设计上就废了。
2.2 假设检验：A/B test 的统计学骨架
A/B test 的比较过程，本质是一次假设检验。我们先立一个原假设 H0：两组指标没有差异（比如转化率都是 10%）。再立一个备择假设 H1：两组有差异。然后拿到实验数据，计算"如果 H0 成立，观察到当前这种差异甚至更大差异的概率"，这个概率就是 P 值。P 值越小，说明当前差异在 H0 成立的前提下越不可能出现，于是我们越有理由拒绝 H0，认为改动有效。
这里必须澄清一个被误解烂了的点：P 值不是"改动有效的概率"，它只是"假设没差异的情况下，看到这份数据的罕见程度"。P = 0.03 不代表改动有 97% 的概率有效，它只代表如果真没差异，你有 3% 的概率会观察到这么极端的结果。很多团队把 P 值当成效果大小的度量，这是典型误用。效果大小要看绝对提升、相对提升和置信区间，P 值只负责回答"差异是否显著"。
2.3 两类错误与显著性水平怎么定
假设检验会犯两类错误。**第一类错误（α）**是原假设本来成立，你却拒绝了它，也就是"改动没用，你却上线了"，俗称假阳性。第二类错误（β）是原假设不成立，你却没拒绝，也就是"改动有用，你却错过了"，俗称假阴性。1 - β 就是统计功效（power），代表你有多大概率能检出真实存在的效果。
行业默认 α = 0.05，power = 0.8。这两个数字不是硬性规定，而是长期实践下来成本和收益的平衡点。α 调低到 0.01，你会更难拒绝 H0，假阳性少了，但需要更大样本；power 调高到 0.9，你能检出更多真实效果，但同样需要更大样本。小公司流量有限，往往只能接受较低的 power，这时候就要靠拉长实验周期或者提高 MDE 来妥协。
| 决策 | H0 为真（无差异） | H0 为假（有差异） |
|---|---|---|
| 拒绝 H0（上线新版） | 第一类错误 α（假阳性） | 正确决策，power = 1-β |
| 不拒绝 H0（保留旧版） | 正确决策 | 第二类错误 β（假阴性） |
3. 核心概念拆透：P值、置信区间与功效
3.1 P值到底怎么算出来的
拿转化率这类比率指标举例，A 组样本 nA，转化人数 cA，转化率 pA = cA/nA；B 组同理。我们要检验 pA 和 pB 是否相等。常用的方法是双样本比例检验，构造一个 Z 统计量：
p_pool = (cA + cB) / (nA + nB) # 合并转化率 SE = sqrt(p_pool * (1 - p_pool) * (1/nA + 1/nB)) # 标准误 Z = (pB - pA) / SE算出 Z 之后，查标准正态分布表得到对应的 P 值。如果做的是双尾检验，P = 2 * (1 - Φ(|Z|))，其中 Φ 是标准正态累积分布函数。实测中这些不用手算，Python 里scipy.stats.ttest_ind或者statsmodels的proportions_ztest一行就能搞定。
举个具体数字：A 组 10000 人转化 1000 人，pA = 10%；B 组 10000 人转化 1150 人，pB = 11.5%。p_pool = 0.1075，SE = sqrt(0.1075 * 0.8925 * (0.0001 + 0.0001)) ≈ 0.00438。Z = 0.015 / 0.00438 ≈ 3.42。这个 Z 对应的双尾 P 值约为 0.0006，远小于 0.05，说明差异极其显著。这个例子里 1.5 个百分点的绝对提升，在 1 万样本量下就足够被检出。
3.2 置信区间比P值更有信息量
P 值只告诉你"有没有差异"，置信区间告诉你"差异大概在什么范围"。同样上面这个例子，B 组相对 A 组的提升是 15%，95% 置信区间大概会落在 [6%, 24%] 这个区间。这个区间的意义是：如果重复做 100 次同样的实验，约 95 次算出来的区间会包含真实的提升值。
我更推荐团队汇报时优先看置信区间。原因很简单：如果置信区间是 [0.1%, 5%]，虽然统计显著，但效果小到可能覆盖不了开发成本；如果区间是 [-2%, 30%]，跨越了 0，说明结果不确定，不能直接下结论。只看 P 值很容易陷入"显著但没用"的陷阱。
3.3 统计功效与样本量必须提前算
样本量必须在实验开始前算好，这是铁律。事后补算样本量，等于给自己找借口。样本量由四个因素决定：基线指标值、你想检测的最小效应 MDE、显著性水平 α、统计功效 power。四个里定三个，第四个就能反推。
对于均值类指标，每组样本量公式是：
n = 2 * (z_{1-α/2} + z_{1-β})^2 * σ^2 / Δ^2对于比率类指标，公式变形为：
n = (z_{1-α/2} + z_{1-β})^2 * (p1(1-p1) + p2(1-p2)) / (p2 - p1)^2代入 α = 0.05（z = 1.96）、power = 0.8（z = 0.84），基线转化率 10%，想检测相对提升 20%（即 10% → 12%）：
n = (1.96 + 0.84)^2 * (0.1*0.9 + 0.12*0.88) / (0.02)^2 = 7.84 * (0.09 + 0.1056) / 0.0004 = 7.84 * 0.1956 / 0.0004 ≈ 3834也就是每组约 3834 人，总共 7668 人。如果日活只有 500，那实验至少得跑 16 天。这就是为什么很多小流量产品做 A/B test 特别吃力——流量限制了你能检测的最小效应。想检测 5% 的相对提升，样本量要翻好几倍。
4. 指标设计与分流机制怎么落地
4.1 指标分三层：北极星、护栏、诊断
A/B test 最容易翻车的地方不是统计学，而是指标选错。我的经验是把指标分成三层。第一层是北极星指标，也就是这次改动最想影响的那个核心指标，比如下单转化率、次日留存率。一个实验最好只锁定一到两个北极星指标，指标太多会导致多重比较问题，假阳性概率飙升。
第二层是护栏指标，用来防止你为了涨北极星指标而伤害其他东西。比如你优化了推荐算法让点击率大涨，但用户停留时长暴跌，那这个改动就是有害的。常见的护栏指标包括页面加载时间、退款率、投诉率、崩溃率。护栏指标一旦显著恶化，哪怕北极星指标再好看，也不能上线。
第三层是诊断指标，用来解释"为什么涨"或"为什么跌"。比如漏斗各环节的转化率、各入口的点击分布。诊断指标一般不参与显著性的强判定，主要帮你定位原因。我见过太多团队只盯北极星，结果指标涨了却不知道涨在哪，下次想复制都无从下手。
提示：指标定义一定要在实验前冻结。实验跑起来之后改口径、改分母，等于把数据往自己想要的方向凑，这是数据造假的边缘。
4.2 分流机制与一致性哈希
分流是 A/B test 的工程核心。最常见的做法是哈希分流：拿用户的唯一标识（比如 user_id）加一个实验的盐值（salt），做一次哈希运算，比如 MD5 或者 MurmurHash，然后把哈希结果对 100 取模，得到 0 到 99 的一个数。0 到 49 进 A 组，50 到 99 进 B 组，这样就实现了稳定且均匀的分流。
为什么要加盐值？因为同一个用户在不同实验里需要被分到不同桶。如果所有实验都直接用 user_id 取模，那高活跃用户可能永远在 A 组，导致实验之间相互干扰。加不同的 salt，能让用户在实验 A 里是 A 组、在实验 B 里是 B 组，实验之间就正交了。对于需要多个实验叠加的场景，还会用到**分层（layer）**概念，不同层之间流量复用但互不干扰。
分完之后必须做样本比例校验（SRM，Sample Ratio Mismatch）。预期 50/50 分流，实际拿到 A 组 48.2%、B 组 51.8%，这就叫 SRM。SRM 意味着分流系统出了问题，实验结论全部作废。检测方法是用卡方检验比较观测比例和预期比例，P 值小于 0.001 就认为存在 SRM。
4.3 AA测试：上线前的照妖镜
AA 测试是正式实验前必做的动作：把流量随机分成两组，但两组看到完全相同的版本，然后跑同样的指标对比。理想情况下，AA 测试应该得到大量不显著的结果（约 95% 的指标不显著）。如果你做 AA 测试，发现有一堆指标显著，那说明你的分流、埋点或者统计逻辑有系统性问题。
AA 测试能帮你抓出很多隐蔽 bug，比如埋点上报有延迟导致两组数据不对齐、分流键选择不当导致某些用户群被系统性偏向某一组、或者实验平台本身有偏差。我现在的习惯是每个新功能上线前，先跑一天 AA 测试。这一天流量不浪费，还能换来后面实验结论的可信度。
5. 实操流程与关键计算演示
5.1 一个完整实验的标准流程
一次规范的 A/B test，从立项到下线大概分七步。第一步定假设：明确"改了什么""预期影响哪个指标""预期变化方向和幅度"。假设要写成可证伪的形式，比如"把结算页按钮从灰色改成橙色，结算转化率相对提升 8% 以上"。
第二步算样本量：用上面讲的公式，或者用现成的在线工具，确定每组需要多少人、实验要跑多久。第三步埋点与分流校验：确认埋点数据能正确上报到实验平台，跑一次 AA 测试验证分流无偏。第四步启动实验，同时监控护栏指标，一旦恶化立即暂停。第五步跑满周期：不要中途偷看结果做决策，这点下面会重点讲。
第六步分析结果：看北极星指标是否显著、影响区间多大、护栏指标是否受损、诊断指标变化是否符合预期。第七步做决策：全量、灰度、回滚还是再迭代。每个实验无论成败都要沉淀成文档，包括假设、数据、结论和后续动作，这是团队最宝贵的资产。
5.2 样本量与实验周期计算实操
假设某 App 首页推荐改版，基线点击率 8%，产品期望检测到相对提升 15%（即 8% → 9.2%），日活 6000，A/B 各分一半即每天每组 3000 人。
p1 = 0.08, p2 = 0.092 p1(1-p1) = 0.08 * 0.92 = 0.0736 p2(1-p2) = 0.092 * 0.908 = 0.083536 和 = 0.157136 Δ = 0.012, Δ^2 = 0.000144 n = (1.96 + 0.84)^2 * 0.157136 / 0.000144 = 7.84 * 0.157136 / 0.000144 ≈ 8554每组需要约 8554 人，总共约 17108 人。日活 6000，大约需要 17108 / 6000 ≈ 2.85 天。但这里有个关键点：实验周期不能少于 7 天。为什么？因为用户行为有周内周期性，周中用户和周末用户的行为模式差异很大。如果只跑三天，很可能全落在工作日，结论无法代表全周。所以我一般会把算出来的天数和 7 天取最大值，这个例子里最终跑 7 天。
5.3 方差缩减：让实验更快出结论
小流量产品常常等不起长周期，这时候方差缩减技术就派上用场了。最经典的是CUPED（Controlled-experiment Using Pre-Experiment Data）。核心思路是用实验前的一段用户行为数据作为协变量 X，用它对实验期的指标 Y 做回归校正：
θ = Cov(Y, X) / Var(X) Y_cuped = Y - θ * (X - E[X])校正后的 Y_cuped 方差比原始 Y 小得多，因为实验前数据里的用户个体差异被剥离掉了。实践里 CUPED 通常能减少 30% 到 50% 的方差，等价于把有效样本量提升一半以上，变相缩短了实验周期。
另一个常被忽视的是指标截尾（Winsorization）。像"人均消费金额"这种长尾指标，少数极端大额用户会把方差拉得极大。把指标按 99.5 分位截尾，能显著降低方差，对结论影响却很小。这些技巧几乎是所有成熟实验平台的标配。
6. 常见翻车问题与排查实录
6.1 高频问题速查表
做实验久了会发现，翻车的地方基本就那么几个，我把它们整理成一张表，方便随时排查。
| 问题现象 | 可能原因 | 排查与解决 |
|---|---|---|
| 分流比例严重偏离预期 | 哈希函数不均匀、分流键不稳定、缓存导致跨组 | 卡方检验查 SRM；检查分流键是否用户粒度且持久 |
| 指标波动巨大无法收敛 | 样本量不足、指标方差过大、混入异常流量 | 提前算样本量；对指标截尾；过滤机器人和爬虫 |
| 实验初期效果好后期衰减 | 新奇效应 | 延长实验周期；分析首访与老用户分层结果 |
| 整体和一个子群体结论相反 | 辛普森悖论 | 分层分析；检查子群体基线和流量占比 |
| 多个指标同时显著 | 多重比较未校正 | Bonferroni 或 FDR 校正；控制指标数量 |
| 结果反复横跳 | 提前偷看数据（peeking） | 固定周期；使用序贯检验 |
6.2 提前偷看的坑为什么这么致命
Peeking 问题是新手最容易犯、后果最严重的错误。假设真实情况是两组没差异，但你在实验期间每天看一次结果，只要有一次 P 值小于 0.05 就停，那你的假阳性率会从 5% 飙升到 20% 甚至 30% 以上。因为 P 值在实验过程中是波动的，多次偷看等于多次抽奖，总会抽到"显著"的那一次。
解决办法有三个：一是固定 horizon，实验开始前就定好跑几天，跑满再分析，中途绝不看指标；二是序贯检验，使用 alpha spending 函数把总的 α 分摊到每次检验，保证整体第一类错误率仍为 0.05；三是贝叶斯方法，它天然允许中途观察，但需要设置合理的先验和损失函数。小团队最简单可靠的做法还是第一种。
6.3 辛普森悖论：整体和局部打架
辛普森悖论是分层分析里最反直觉的现象。举个真实例子：新版在移动端转化提升 5%，在桌面端也提升 5%，但合起来看总转化却下降了。原因是移动端用户占比在实验期间发生了变化——实验组正好赶上一波移动端流量高峰，而移动端整体转化率低于桌面端，导致实验组虽然各端都赢，但被更多低转化的移动用户拖累，整体反而输了。
排查辛普森悖论的方法是按关键维度做分层分析，比如设备、新老用户、地域、渠道。如果发现整体结论和大多数分层结论相悖，那一定要搞清楚流量结构是不是发生了变化。成熟平台会做方差加权处理，或者直接在关键维度上做无偏的加权计算。
6.4 我踩过的几个真实坑
分享几个我印象深刻的坑。第一个是时区没对齐：实验平台按 UTC 切分，但业务数据按北京时间切分，导致两边的"同一天"对不上，实验组数据少算了几小时，差点得出假阳性结论。后来统一成业务时区才解决。
第二个是新用户刷新导致分组漂移：早期分流键用了设备 ID，但新用户还没登录时设备 ID 是临时的，登录后 ID 变了，用户就换了组。这个问题很隐蔽，AA 测试跑久了才暴露出来，最后改成"登录前用设备 ID、登录后用 user_id，并做一次映射迁移"才搞定。
第三个是指标口径漂移：实验跑了一周，产品中途说北星指标的定义要改，把"下单成功"改成"支付成功"。这一改等于换了指标，前面的数据全废。从那以后我就立了规矩：实验期间的指标口径冻结，谁都不许改。这些教训听起来琐碎，但每一个都能让一次实验白跑。
6.5 结果显著但业务没起色怎么办
最后说一个高频困惑：统计上显著，但业务上没感觉。常见原因有几个。一是效果太小，比如转化率提升了 0.1 个百分点，统计显著但覆盖不了开发和维护成本，这时候要看置信区间上界和下界，判断这个提升是否值得投入。二是指标和业务目标脱节，比如你优化了某个按钮点击率，但那个点击对最终营收贡献很小，属于无效优化。三是实验环境和线上环境不同，实验期间可能有特殊活动、特殊流量，全量后效果会衰减。
遇到这种情况，我的建议是别急着全量，先小范围灰度，观察一到两周真实数据，同时把实验放宽到更多维度重新验证。统计显著是必要条件，不是充分条件。真正决定上不上线的，是效果的业务价值和可复现性。A/B test 给你的是决策依据，不是决策本身，这一点想清楚了，你就不会再被一个漂亮的 P 值牵着鼻子走。
