ab-test-setup

A/B 测试设置 - 实验设计与分析

类别： 产品团队 标签： A/B 测试、实验、统计显著性、样本量、功能标记、假设检验

概述

A/B 测试设置提供了一套完整的框架，用于设计能够得出统计上有效且可采取行动的结果的实验。大多数 A/B 测试失败，并不是因为变体不对，而是因为测试设计不佳：样本量错误、指标选错，或有人偷看结果并提前停止测试。此技能可避免这些错误。

---

首先明确

设计实验前，请确认以下输入。如果有任何一项未知或含糊不清，请提问——不要自行假设：

• 主要指标 + 最小可检测效果 — 一项成功指标，以及值得检测的最小提升（决定样本量、测试时长和指标选择）
• 基线转化率 — 主要指标当前的转化率（决定每个变体所需的样本量）
• 测试页面的可用流量 — 每日符合条件的访问者数量（决定测试是否可行，或是否需要更大胆的改动／定性方法）
• 改动及其依据 — 哪些内容会发生变化，以及相关数据（决定假设和变体设计）

停止规则：只询问最可能显著影响结果的 2–3 个问题。如果用户说“直接起草”，就继续，并在文档开头列出你的假设。

实验生命周期

1. HYPOTHESIZE  →  2. DESIGN  →  3. CALCULATE  →  4. IMPLEMENT
       ↑                                                    │
       │                                                    ▼
7. ITERATE  ←  6. DOCUMENT  ←  5. ANALYZE  ←  [Run to completion]

---

步骤 1：形成假设

假设模板

Because [observation or data point],
we believe [specific change]
will cause [measurable outcome]
for [defined audience segment].

We'll know this is true when [primary metric] changes by [minimum detectable effect].
We'll watch [guardrail metrics] to ensure no negative impact.

好假设与坏假设

质量	假设	问题
差	“更改按钮颜色可能会增加点击量”	没有数据依据、目标或衡量计划
一般	“绿色按钮会比蓝色按钮获得更多点击”	没有说明“为什么”，没有目标幅度，也没有护栏指标
好	“由于热图显示 40% 的用户没有注意到我们的 CTA，将按钮放大 2 倍并使用对比色，会使新访客的 CTA 点击量提升 15% 以上。护栏指标：页面加载时间保持在 2 秒以内。”	有数据支持、改动具体、结果可衡量、受众明确，并设有护栏指标

假设来源（测试创意从何而来）

来源	关注内容	示例
分析数据	流失节点、表现不佳的页面	“80% 的用户在引导流程第 3 步流失”
用户研究	困惑、挫败感、未满足的需求	“用户无法从首页了解产品的用途”
热图／会话录制	被忽略的元素、愤怒点击	“在定价页面上，没有人会滚动查看首屏以下的内容”
支持工单	反复出现的投诉、对功能的困惑	“用户总是在问如何邀请团队成员”
竞品分析	针对同一问题的不同做法	“竞品使用向导，而我们使用表单”
销售异议	潜在客户未转化的常见原因	“潜在客户希望先查看价格再注册”

---

步骤 2：测试设计

测试类型

类型	变体	流量需求	最适合
A/B	2 个（对照组 + 1 个变体）	中等	验证单项改动
A/B/n	3 个以上变体	高	比较多种方案
多变量测试（MVT）	多项改动的组合	很高	优化多个元素
分流 URL	不同页面	中等	大幅改版
多臂老虎机	动态分配	低至中等	优化营收

默认建议： 使用标准 A/B 测试。只有在流量充足且有明确需求时，才使用 A/B/n 或 MVT。

测试内容（按影响程度）

类别	高影响	中等影响	低影响
文案	标题／价值主张、CTA 文本	正文文案、社会认同	微文案、标签
设计	页面布局、首屏内容	视觉层次、图片	颜色、字号
用户体验	步骤数量、表单字段	按钮位置、导航	动画、过渡效果
定价	价格点、套餐名称	功能打包、价格锚定	计费频率的显示方式
社会认同	客户评价与无评价对比、徽标	客户评价格式、位置	客户评价数量

指标选择

每项测试都需要三类指标：

主要指标（仅 1 项）

• 用于判定测试是否成功的唯一指标
• 与假设直接相关
• 必须能在测试时长内测量
• 示例：注册率、点击率、购买率

次要指标（2-3 项）

• 解释主要指标发生变化的原因
• 为决策提供背景信息
• 示例：页面停留时间、滚动深度、功能采用率

护栏指标（1-3 项）

• 绝不能变差的指标
• 如果出现显著负面变化，则停止测试
• 示例：错误率、支持工单量、页面加载时间、退款率

---

第 3 步：样本量计算

快速参考表

每个变体所需的最少访客数（95% 置信度、80% 检验效能）：

基准转化率	提升 5%	提升 10%	提升 15%	提升 20%	提升 50%
1%	620,000	156,000	70,000	39,000	6,400
2%	305,000	77,000	34,000	19,500	3,200
3%	200,000	51,000	23,000	12,800	2,100
5%	116,000	29,500	13,200	7,500	1,250
10%	54,000	13,800	6,200	3,500	600
20%	24,000	6,200	2,800	1,600	280
50%	6,100	1,600	720	410	75

时长计算

Duration (days) = (Sample size per variant * Number of variants) / Daily traffic to test page

**最短时长：**7 天（以纳入星期几的影响） **建议最长时长：**6 周（超过此时长，外部因素会干扰结果）

流量不足怎么办？

情况	解决方案
需要 100K 访客，每周只有 5K	提高最小可检测效果（测试幅度更大的改动）
流量非常低（<1K/周）	改用定性测试（用户测试、问卷调查）
流量中等（5-20K/周）	运行 4-6 周，只测试重大改动
流量很高（50K+/周）	可以测试细微改动，也可以同时运行多项测试

---

第 4 步：实施

客户端实施

JavaScript 会在初始渲染后修改页面。

**优点：**实现快速，无需部署 **缺点：**可能导致闪烁（短暂显示原始内容），会被广告拦截器屏蔽 **工具：**PostHog、Optimizely、VWO、Google Optimize

防闪烁模式：

// Add to <head> before any rendering
<style>.ab-test-hide { opacity: 0 !important; }</style>
<script>document.documentElement.classList.add('ab-test-hide');</script>

// In your test script (runs after variant assignment):
document.documentElement.classList.remove('ab-test-hide');

服务端实施

在页面渲染前确定变体。不会闪烁，也不依赖客户端。

**优点：**不会闪烁，不会被广告拦截器屏蔽，适用于已登录用户的功能 **缺点：**需要工程开发工作，需要部署 **工具：**PostHog、LaunchDarkly、Split、Unleash、自定义功能标志

基础功能标志模式：

# Server-side variant assignment
def get_variant(user_id: str, experiment: str) -> str:
    # Deterministic hash ensures same user always sees same variant
    hash_input = f"{user_id}:{experiment}"
    hash_value = hashlib.md5(hash_input.encode()).hexdigest()
    bucket = int(hash_value[:8], 16) % 100

    if bucket < 50:
        return "control"
    else:
        return "variant"

流量分配

策略	比例	适用场景
标准	50/50	默认设置。统计效能最高。
保守	90/10 或 80/20	高风险改动、影响收入的测试
逐步增加	从 95/5 开始，逐步提高到 50/50	新基础设施、技术风险

重要规则：

• 用户每次访问都必须看到相同的变体（通过用户 ID 或 Cookie 固定分配）
• 分配必须在一天中的不同时段和一周中的不同日期保持均衡
• 测试过程中绝不要更改分配比例

---

第 5 步：运行测试

上线前检查清单

• 记录假设、主要指标和最小可检测效应
• 计算样本量，估算预期测试时长
• 在所有设备类型上实现两个变体并完成 QA
• 验证跟踪功能（两个变体的事件均能正确触发）
• 同一页面／功能上没有其他测试正在运行
• 告知利益相关者测试时长和“不得提前查看结果”规则
• 检查外部因素日历（没有重大上线、节假日或新闻发布）

测试期间

应该做：

• 监控技术错误（变体未能呈现、跟踪功能故障）
• 每天检查流量分配是否均衡
• 记录可能影响结果的任何外部事件

不应该做：

• 未达到样本量前查看结果（“偷看问题”）
• 更改任一变体
• 在测试中途引入新的流量来源
• 因为某个变体“看起来要赢了”而提前停止测试

偷看问题（关键）

在达到计划样本量之前查看结果，并因某个变体看起来更好而停止测试，会导致25–40% 的假阳性率（而预期值为 5%）。

原因：小样本下，统计显著性会剧烈波动。某个变体在达到计划样本量的 20% 时可能显示 p < 0.05，而在达到完整样本量时则可能变为 p > 0.30。

解决方案：

1. 预先承诺样本量，在达到该样本量之前不要查看结果
2. 如果必须监控：使用序贯检验方法（组序贯设计、始终有效的 p 值）
3. 为预计完成日期设置日历提醒——到那时再查看

---

第 6 步：分析

分析检查清单

1. 是否达到计划样本量？ 如果没有，结果仅供初步参考。
2. 结果是否具有统计显著性？ p < 0.05 = 有 95% 的把握认为差异是真实的。
3. 置信区间是多少？ 它告诉你真实效应可能所在的范围。
4. 效应大小是否有意义？ 0.1% 的提升即使“显著”，也可能不值得实施。
5. 次要指标是否一致？ 它们是否支持主要结果？
6. 是否违反任何护栏指标？ 是否有指标变差？
7. 分群分析： 移动端与桌面端、新用户与回访用户的结果是否不同？

解读结果

结果	主要指标	置信度	行动
明确胜出	变体 +15%，p < 0.01	高	实施该变体
小幅胜出	变体 +5%，p < 0.05	中	如果容易实施就实施，否则延长测试时间
持平	差异 < 2%，p > 0.20	高（无效应）	保留对照组，测试更大胆的方案
落败	变体 -10%，p < 0.05	高	保留对照组，调查原因
结论不明	差异 5%，p = 0.08	低	需要更多流量或更大胆的测试
信号不一	主要指标上升，护栏指标下降	需调查	深入分析各分群，不要盲目上线

常见分析错误

错误	后果	预防措施
首次达到显著性时就停止	25–40% 的假阳性率	承诺达到计划样本量
挑选有利分群	找到无法复现的“胜出者”	预先登记关注的分群
忽略置信区间	高估效应大小	始终同时报告 CI 和 p 值
多重比较	第一类错误率膨胀	对 A/B/n 测试使用 Bonferroni 校正
幸存者偏差	只分析完成流程的用户	纳入从分配时点起的所有用户
辛普森悖论	汇总结果掩盖分群结果反转	始终检查关键分群

---

第 7 步：文档记录

每项测试都必须记录，无论结果如何。

测试文档模板

EXPERIMENT: [Name]
DATE: [Start] to [End]
OWNER: [Name]

HYPOTHESIS:
Because [observation], we believed [change] would cause [outcome] for [audience].

VARIANTS:
- Control: [description]
- Variant: [description + screenshot]

METRICS:
- Primary: [metric] (baseline: [X]%, MDE: [Y]%)
- Secondary: [metrics]
- Guardrails: [metrics]

RESULTS:
- Sample size: [actual] / [planned]
- Duration: [X] days
- Primary metric: Control [X]% vs Variant [Y]% (p = [Z], CI: [range])
- Secondary metrics: [results]
- Guardrails: [all clear / violation noted]

DECISION: [Ship variant / Keep control / Iterate]

LEARNINGS:
- [What we learned about our users]
- [What we'd do differently next time]

---

实验优先级排序框架

ICE 评分

因素	评分（1-10）	问题
影响	这会对指标产生多大影响？	对主要 KPI 产生重大影响 = 10
信心	我们有多确定它会奏效？	有强有力的数据支持假设 = 10
易度	实施和衡量有多容易？	一天内即可上线 = 10

ICE 评分 =（影响 + 信心 + 易度）/ 3

按 ICE 评分为所有测试创意排序。优先开展评分最高的测试。

测试待办模板

#	假设	主要指标	ICE	预计时长	状态
1	更大的 CTA 能提高注册量	注册率	8.3	2 周	就绪
2	在定价页面加入社会认同能提高转化率	方案选择率	7.0	3 周	需要设计
3	缩短引导流程能提高激活率	功能激活率	6.7	4 周	在待办列表中

---

主动触发条件

• 有人正在两个设计方案之间犹豫：建议进行 A/B 测试，而不是发表主观意见
• 提到转化率表现不佳：主动提出设计测试，而不是猜测解决方案
• 讨论定价页面变更：始终使用防护指标测试定价变更
• 功能发布后：建议开展后续实验进行优化
• “先试试再看”：在实施前引导对方制定结构化假设

---

相关技能

技能	适用场景
analytics-tracking	设置用于实验指标的事件追踪
campaign-analytics	将实验结果纳入更广泛的归因分析
launch-strategy	在产品发布流程中进行测试
prompt-engineer-toolkit	对生产环境中的 AI 提示词进行 A/B 测试

---

工具参考

sample_size_calculator.py

使用双比例 z 检验的正态近似法，计算每个变体所需的样本量。支持对多变体测试进行 Bonferroni 校正，并估算所需时长。

标志	类型	默认值	说明
--baseline、-b	float	（必填）	基线转化率（例如，0.05 表示 5%）
--mde、-m	float	（必填）	以相对提升表示的最小可检测效果（例如，0.10 表示 10%）
--alpha、-a	float	0.05	显著性水平
--power、-p	float	0.80	统计功效
--variants、-v	int	2	变体数量，包含对照组
--daily-traffic、-d	int	0	用于估算时长的每日符合条件流量
--one-tailed	标志	False	使用单尾检验，而不是双尾检验
--json	标志	False	以 JSON 格式输出

python scripts/sample_size_calculator.py --baseline 0.05 --mde 0.10
python scripts/sample_size_calculator.py --baseline 0.12 --mde 0.15 --power 0.9 --daily-traffic 5000
python scripts/sample_size_calculator.py --baseline 0.05 --mde 0.10 --variants 3 --json

experiment_analyzer.py

使用双比例 z 检验分析 A/B 测试结果，并提供置信区间和细分群体分析。

标志	类型	默认值	说明
input	位置参数	（必填）	包含结果的 CSV 文件，或输入 "sample" 以创建示例
--alpha、-a	float	0.05	显著性水平
--json	标志	False	以 JSON 格式输出

CSV 格式： variant,visitors,conversions,segment

python scripts/experiment_analyzer.py sample
python scripts/experiment_analyzer.py results.csv
python scripts/experiment_analyzer.py results.csv --alpha 0.01 --json

experiment_planner.py

根据假设文本生成结构化实验计划，包括指标选择、样本量、时间线、风险和文档模板。

标志	类型	默认值	说明
--hypothesis、-H	string	（必填）	实验假设文本
--baseline、-b	float	0.05	基线转化率
--mde、-m	float	0.10	以相对提升表示的最小可检测效果
--daily-traffic、-d	int	0	每日符合条件流量
--variants、-v	int	2	变体数量，包含对照组
--json	标志	False	以 JSON 格式输出

python scripts/experiment_planner.py --hypothesis "Larger CTA will increase signups by 15%"
python scripts/experiment_planner.py -H "Simplified checkout boosts conversions" -b 0.08 -m 0.15 -d 3000
python scripts/experiment_planner.py -H "New pricing page" --json

---

故障排查

问题	原因	解决方案
样本量大得不切实际	MDE 太小或基线过低	提高 MDE（测试幅度更大的改动），或选择流量更高的页面
测试时长超过 6 周	每日流量不足	考虑采用定性方法、测试幅度更大的改动，或合并多个页面的流量
p 值徘徊在 0.05 左右	显著性处于临界状态	不要提前停止；运行至计划样本量，或延长 20%
结果显著，但提升幅度很小（<1%）	测试效能过高	除统计显著性外，也要检查实际意义
细分群体的结果与整体结果相矛盾	辛普森悖论	调查细分群体的构成；同时报告整体结果和细分结果
变体在移动设备和桌面设备上的表现不同	设备特定的 UX 问题	设计针对不同设备的变体；增加每个细分群体的样本量
计算器得出负的 CI	样本量过小或比率极端	确保样本量充足；检查数据完整性

---

成功标准

标准	目标	衡量方法
测试达到计划样本量	100% 的测试	在测试结束时比较实际样本量与计划样本量
假阳性率	<5%	跟踪实施后的提升幅度与测试预测的对比
测试速度	每个团队每月 2 项以上测试	统计每个冲刺中记录的实验数量
文档完整度	100% 的测试均有文档记录	每季度审查实验记录
平均测试时长	<4 周	统计从开始到结束的日历天数
决策质量	上线的变体中，超过 80% 在 90 天后仍保持提升	上线后的指标跟踪

---

范围与限制

范围内：

• 假设的制定与验证
• 样本量和检验效能计算
• 频率学派双比例 z 检验
• A/B、A/B/n 和拆分 URL 测试规划
• 细分群体级别的分析
• 测试前后文档记录

范围外：

• 贝叶斯 A/B 测试方法（使用专用贝叶斯工具）
• 多臂老虎机算法（需要实时流量分配基础设施）
• 多变量测试（MVT）分析（组合数量爆炸，需要专用工具）
• 服务端功能开关实现（参见工程技能）
• 需要交易级数据的收入指标
• 序贯测试／始终有效的 p 值（使用 Optimizely Stats Engine 或类似工具）

---

集成点

工具／平台	集成方法	用例
PostHog / Amplitude	从 experiment_analyzer 导出 JSON	将结果输入产品分析工具
Jira / Linear	experiment_planner 的 JSON 输出	创建包含元数据的实验工单
Google Sheets	从 experiment_analyzer 导出 CSV	与非技术相关方分享结果
LaunchDarkly / Unleash	experiment_planner 检查清单	在功能开关推出前进行验证
Slack / Notion	复制易读的输出	异步更新实验状态
CI/CD 管道	所有脚本均使用 --json 标志	自动检查实验运行状况