Marketing

A/B 测试样本量:别再拍脑袋了——这是我每次开测前都会跑的 Gemini 提示词

A/B 测试样本量:别再拍脑袋了——这是我每次开测前都会跑的 Gemini 提示词
目录

周二的下午 2:47,一位初级 PM (Product Manager,产品经理) 给我发消息,她觉得自己赢了:"变体 B 在 1,200 个用户后领先 A 28%。能全量上线吗?"

她每小时都在刷数据看板。实际跑到预设样本量时,真实提升只有 1.4%,而且 B 还输了。"28%" 这种数字,正是 1,200 用户量级、真实效果接近零时最常见的噪声。我们没有上线,让测试继续跑,两周后 B 依然落后。

那位 PM 并不马虎。她只是和所有 PM 一样,觉得用计算器太麻烦:瞄一眼看板,看到一个像赢家的数字,就直接拍板。解法不是"更有耐心",而是把样本量计算压到 30 秒,在测试上线前就完成,让"每组跑到 9,000 用户再停手"这句话白纸黑字地写在文档里。

下面是我用的 Gemini 提示词原文、背后的公式,以及它真正能避免的两种失败。

拍脑袋的代价

两种失败,都很贵。

统计功效不足的测试 (under-powered tests) 会悄悄骗你。你开了一个测试,在 1,200 用户时看到"赢家",全量上线,六周后才发现真实提升是负的。代价是一个更差的产品上线、几周的无效投入,以及一支再也不信 A/B 测试的团队。2024 年 Optimizely 的一份基准里(我对这份数据信任度一般,但大方向是这么回事),提前宣布获胜的"赢家"测试里,有 60–70% 在完整样本量下无法复现。

过度测试 (over-powered tests) 更隐蔽。你开了测试,第 6 天已经达到显著性,但因为 SOP 上写"跑满两周",就继续让它转。你烧掉的流量本可以投入到下一个实验。一个日均 5 万 UV 的网站,每多等一天就是 $15K–$50K 的机会成本——每场测试都这样,积累起来很吓人。

测试开始前先把样本量算清楚,两种问题都能解决。功效不足的测试直接不会上线——流量不够,就不开。过度测试也会变得可见——第 6 天达到目标 N,就知道可以收。

公式(看一段就够,以后不用再翻)

对两比例 z 检验 (two-proportion z-test)——也就是最常见的"对照组 vs 变体转化率"测试——每组样本量公式是:

n = 2 * ((z_(α/2) + z_β)^2) * p * (1 - p) / MDE^2

其中:

  • p = 基线转化率
  • MDE (Minimum Detectable Effect,最小可检测效应) = 你想检出的绝对提升,单位与 p 一致(比如 0.01 表示 1 个百分点)
  • z_(α/2) = 双尾显著性对应的临界值(α=0.05 时为 1.96)
  • z_β = 统计功效对应的临界值(power=0.80 时为 0.84)

就这些。默认值(α=0.05、power=0.80、双尾)能覆盖 95% 的产品内 A/B 测试,你几乎不需要改。

有一个假设值得知道:这个公式把 p 当作两组的方差估计——是一种近似(真实方差应该是 p_control 和 p_variant 的合并估计),但差异在小数点后第三位,基本可以忽略。

为什么不用在线计算器

2024 年我试过的每一个"免费" A/B 样本量计算器,要么要邮箱注册,要么把公式藏在"了解更多"链接后面,要么把数字四舍五入得离谱。计算本身不是秘密,关键在输入。如果我得切到浏览器、粘贴数字、截图结果、裁掉水印,流程跑三次就死。换成 Gemini 后,提示词在 Notion 里,输入填进去,输出直接整理成测试简报格式。整个回路 30 秒,而不是 4 分钟——能在一个季度里被坚持下来的,是 30 秒那个版本。

提示词

这条提示词我放在名为 "Stats Prompts" 的 Notion 文档里。我所有测试流程的第一步都是这条提示词,最后把结果贴回测试简报。

You are my AB test sample size calculator.

Compute the per-arm sample size using the two-proportion z-test formula:

  n = 2 * ((z_(α/2) + z_β)^2) * p_baseline * (1 - p_baseline) / MDE^2

Defaults (use unless I override):
- Two-tailed test
- α = 0.05  →  z_(α/2) = 1.96
- Power = 0.80  →  z_β = 0.84

Then:
1. Use python_exec to compute n numerically. Print per-arm and total.
2. Sanity check: recompute n for MDE × 0.8 and MDE × 1.2. Result should scale as 1/MDE². If it doesn't, the math is wrong — fix it.
3. Estimate test duration in days given my daily traffic per arm. Round up.
4. Flag red flags:
   - MDE < 0.2 percentage points absolute is almost never worth a test (variance too high)
   - Required n > 10× current weekly traffic per arm = test will take >10 weeks. Rethink the MDE or pick a different KPI
   - Baseline < 1% = variance dominates. Consider a 2-week ramp-up to confirm baseline is stable

Inputs:
- Baseline conversion rate: __%
- Minimum detectable effect (absolute): __ percentage points
- Daily traffic per arm: __ visitors/day

Return:
- n per arm, total n
- Days to significance
- Red flags (if any)
- One-line caveat about the assumptions you made

python_exec 步骤很关键。Gemini 2.5 Flash 拿到工具能做数学验证时算得很准——但让它纯心算、把结果编成自然语言时,准确度明显下滑。我踩过这个坑:早期版本的提示词只让 Gemini"算一遍并展示过程",它会一脸淡定地返回比真实值高 30% 的数字,过程还看起来很整洁。

一个真实例子

输入:

  • 基线转化率: 结算页 3%
  • MDE (Minimum Detectable Effect,最小可检测效应): 1 个百分点绝对值(3% → 4%,相对提升 33%)
  • 每组日流量: 600 访客/天(合计 1,200/天)

Gemini 返回:

n per arm = 4,563
Total n = 9,126
Days to significance = ceil(4,563 / 600) = 8 天
Red flags: none
Caveat: 假设基线全程稳定在 3%;
  任何新变体引入的"新奇效应 / primacy effect"
  都会让早期数字失真

最后那条 caveat 是我贴进测试简报前会手动补的。新奇效应 (novelty effect)——新变体上线初期的虚高提升、随用户适应而消失——真实存在,8 天时间根本不够确认它是否褪去。运行时长不到 14 天的测试,我通常会给到 1.5× 的计算时长预算,让噪声充分释放。

提示词失灵的三个场景

公式不适用、Gemini 也救不了的三个场景:

  1. 极低流量页面。 日均 50 UV 的页面,任何统计方法都没法在合理周期内给你答案。正确做法是把测试预算挪到高流量页面,或者接受大得多的 MDE、跑上几个月。
  2. 定性 / 探索性测试。 "这 5 张主图哪张让人觉得最可信"不是样本量问题,是用户研究问题。换工具。
  3. 频繁偷看 (peeking)。 这是连有纪律的团队都会踩的坑。上面那个公式假设你只在预设 N 处看一次结果。如果你每小时刷一次看板,每次刷的假阳性率就是 5%,累积起来极快。如果偷看不可避免,改用序贯检验框架 (sequential testing,比如 AGILE、mSPRT),它会动态调整阈值——总样本量会略大,但你可以随时看。

收尾

解锁的关键不是数学。是把计算压到足够便宜,让它在每次有人想拍板"赢了"之前真的发生。文初那位 PM 现在已经在测试 idea 进简报的那一刻就跑这条提示词。上个季度,她的团队把平均测试时长从 19 天砍到 11 天,方法很简单:提示词标记为"要等 8 周以上"的测试,直接砍掉——那些测试本来就不会跑完。

把提示词贴进 Gemini,填上三个输入,30 秒出样本量。能复利的是这个 30 秒。