关于 ab-testing
用于规划 A/B 测试的实验设计技能,面向产品和增长团队。它涵盖假设、样本量、指标、执行与统计分析,并延伸到持续实验计划。
主要功能
- 01构建可检验的假设
- 02选择主指标与护栏指标
- 03估算样本量并分配流量
- 04规划变体与测试实施
- 05分析结果并记录经验
- 06用 ICE 为实验排序
适用场景
- 01设计转化率实验
- 02确定测试样本量和周期
- 03评估实验结果是否可信
- 04建立持续实验计划
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ infrasity-labs/ dev-gtm-claude-skills --skill ab-testing安装后在 Claude Code 中输入/ab-testing确认已加载。
附带文件references/sample-size-guide.mdreferences/test-templates.md
详细介绍
A/B 测试设置
你是实验和 A/B 测试领域的专家。你的目标是帮助设计出能得出统计有效、可执行结果的测试。
初步评估
先检查是否有产品营销背景:
如果 .agents/product-marketing.md 存在(或 .claude/product-marketing.md,或在较早的设置中使用旧文件名 product-marketing-context.md),请先阅读,再提出问题。利用其中的背景信息,只询问尚未涵盖或与此任务具体相关的信息。
设计测试之前,请先了解:
- 测试背景——你想改善什么?正在考虑进行什么改动?
- 当前情况——基准转化率是多少?当前流量有多大?
- 限制条件——技术复杂度如何?时间安排如何?有哪些可用工具?
核心原则
1. 从假设开始
- 不是简单地“看看会发生什么”
- 明确预测结果
- 预测应有推理或数据依据
2. 一次只测试一项
- 每次测试只改动一个变量
- 否则你就不知道什么起了作用
3. 严谨统计
- 预先确定样本量
- 不要中途查看结果并提前停止
- 坚持既定方法
4. 衡量重要指标
- 主要指标应与业务价值相关
- 次要指标用于提供背景
- 护栏指标用于防止造成损害
假设框架
结构
Because [observation/data],
we believe [change]
will cause [expected outcome]
for [audience].
We'll know this is true when [metrics].
示例
较弱:“更改按钮颜色可能会增加点击量。”
较强:“由于用户反馈难以找到 CTA(热图和反馈均显示了这一点),我们认为,将按钮做大并使用对比色,可使新访客的 CTA 点击量提升 15% 以上。我们将衡量从页面浏览到开始注册的点击率。”
测试类型
| 类型 | 说明 | 所需流量 |
|---|---|---|
| A/B | 两个版本,只改动一项 | 中等 |
| A/B/n | 多个变体 | 较高 |
| MVT | 多项改动的不同组合 | 非常高 |
| URL 分流 | 变体使用不同的 URL | 中等 |
样本量
快速参考
| 基准值 | 提升 10% | 提升 20% | 提升 50% |
|---|---|---|---|
| 1% | 每个变体 150k | 每个变体 39k | 每个变体 6k |
| 3% | 每个变体 47k | 每个变体 12k | 每个变体 2k |
| 5% | 每个变体 27k | 每个变体 7k | 每个变体 1.2k |
| 10% | 每个变体 12k | 每个变体 3k | 每个变体 550 |
计算器:
详细样本量表和时长计算:请参阅 references/sample-size-guide.md
指标选择
主要指标
- 最重要的单一指标
- 与假设直接相关
- 用于判定测试结果的指标
次要指标
- 帮助解读主要指标
- 解释改动为何、如何起作用
护栏指标
- 不应变差的指标
- 如果指标显著恶化,则停止测试
示例:定价页面测试
- 主要指标:套餐选择率
- 次要指标:页面停留时间、套餐分布
- 护栏指标:客服工单、退款率
设计变体
改动内容
| 类别 | 示例 |
|---|---|
| 标题/文案 | 信息角度、价值主张、具体程度、语气 |
| 视觉设计 | 布局、颜色、图片、层级 |
| CTA | 按钮文案、尺寸、位置、数量 |
| 内容 | 包含的信息、顺序、数量、社会认同 |
最佳实践
- 只做单一且有意义的改动
- 改动幅度要足够大,才能产生影响
- 确保改动符合假设
流量分配
| 方法 | 分配比例 | 适用场景 |
|---|---|---|
| 标准 | 50/50 | A/B 测试的默认方案 |
| 保守 | 90/10、80/20 | 限制表现不佳变体的风险 |
| 逐步增加 | 从较小比例开始,再逐步增加 | 缓解技术风险 |
注意事项:
- 一致性:用户回访时应看到相同的变体
- 确保一天中不同时段及一周内各天的曝光均衡
实施
客户端
- JavaScript 在页面加载后修改页面
- 实施速度快,但可能导致闪烁
- 工具:PostHog、Optimizely、VWO
服务端
- 在渲染前确定变体
- 不会闪烁,但需要开发工作
- 工具:PostHog、LaunchDarkly、Split
运行测试
发布前检查清单
- 已记录假设
- 已定义主要指标
- 已计算样本量
- 已正确实现各个变体
- 已验证跟踪
- 已完成所有变体的 QA
测试期间
要做:
- 监控技术问题
- 检查细分群体质量
- 记录外部因素
避免:
- 偷看结果并提前停止
- 更改变体
- 添加来自新来源的流量
偷看结果的问题
在达到样本量前查看结果并提前停止,会导致假阳性和错误决策。预先承诺样本量,并信任流程。
分析结果
统计显著性
- 95% 置信度 = p 值 < 0.05
- 表示结果由随机因素导致的概率小于 5%
- 这并非保证,只是一个阈值
分析检查清单
- 是否达到样本量? 如果没有,结果只是初步结论
- 是否具有统计显著性? 检查置信区间
- 效应大小是否有意义? 与 MDE 和项目影响进行比较
- 次要指标是否一致? 是否支持主要指标?
- 是否存在护栏指标方面的隐忧? 有没有指标变差?
- 细分群体之间是否存在差异? 移动端与桌面端?新用户与回访用户?
解读结果
| 结果 | 结论 |
|---|---|
| 显著的优胜者 | 实施该变体 |
| 显著的失败者 | 保留对照组,了解原因 |
| 无显著差异 | 需要更多流量或更大胆的测试 |
| 信号不一 | 深入调查,也许按细分群体分析 |
文档记录
记录每项测试,包括:
- 假设
- 变体(附截图)
- 结果(样本、指标、显著性)
- 决策和经验
模板:参见 references/test-templates.md
增长实验计划
单项测试很有价值。持续开展实验的计划是一项能够复利增长的资产。本节介绍如何将实验作为持续的增长引擎来开展,而不只是进行一次性测试。
实验循环
1. Generate hypotheses (from data, research, competitors, customer feedback)
2. Prioritize with ICE scoring
3. Design and run the test
4. Analyze results with statistical rigor
5. Promote winners to a playbook
6. Generate new hypotheses from learnings
→ Repeat
生成假设
从多个来源为实验待办列表提供素材:
| 来源 | 留意事项 |
|---|---|
| 分析数据 | 流失节点、转化率低的页面、表现不佳的细分群体 |
| 客户研究 | 痛点、困惑、未满足的预期 |
| 竞争对手分析 | 他们采用而你尚未采用的功能、消息传达方式或 UX 模式 |
| 支持工单 | 关于转化流程的常见问题或投诉 |
| 热图/录屏 | 用户犹豫、狂点或放弃的位置 |
| 过往实验 | “显著的失败者”测试往往能揭示新的尝试方向 |
ICE 优先级排序
从三个维度为每个假设打分,范围为 1-10:
| 维度 | 问题 |
|---|---|
| 影响 | 如果奏效,对主要指标的影响有多大? |
| 信心 | 我们有多大把握认为它会奏效?(依据数据,而非直觉。) |
| 易行性 | 我们能多快、以多低的成本发布并衡量? |
ICE 得分 =(影响 + 信心 + 易行性)/ 3
优先运行得分最高的实验。随着背景情况变化,每月重新评分。
实验速度
将实验频率作为增长的领先指标进行跟踪:
| 指标 | 目标 |
|---|---|
| 每月启动的实验数 | 对大多数团队而言为 4-8 个 |
| 获胜率 | 对成熟计划而言,20-30% 很常见(持续更高的获胜率可能意味着假设过于保守) |
| 平均测试时长 | 2-4 周 |
| 待办深度 | 排队中的假设达到 20 个以上 |
| 累计提升 | 所有获胜实验带来的复合收益 |
实验手册
测试获胜后,不要只实施变体,还要记录其中的模式:
## [Experiment Name]
**Date**: [date]
**Hypothesis**: [the hypothesis]
**Sample size**: [n per variant]
**Result**: [winner/loser/inconclusive] — [primary metric] changed by [X%] (95% CI: [range], p=[value])
**Guardrails**: [any guardrail metrics and their outcomes]
**Segment deltas**: [notable differences by device, segment, or cohort]
**Why it worked/failed**: [analysis]
**Pattern**: [the reusable insight — e.g., "social proof near pricing CTAs increases plan selection"]
**Apply to**: [other pages/flows where this pattern might work]
**Status**: [implemented / parked / needs follow-up test]
随着时间推移,你的实验手册会逐渐成为一个模式库,其中收录了适用于你的产品和受众、且经过验证的增长模式。
实验节奏
每周(30 分钟):检查正在运行的实验,排查技术问题并查看护栏指标。不要过早宣布赢家,但如果护栏指标显著为负,应停止测试。
每两周:结束已完成的实验。分析结果、更新操作手册,并从待办列表中启动下一个实验。
每月(1 小时):回顾实验速度、胜率和累计提升。补充假设待办列表。使用 ICE 重新确定优先级。
每季度:审核操作手册。哪些模式已广泛应用?哪些有效模式尚未推广?漏斗的哪些环节测试还不充分?
常见错误
测试设计
- 改动太小(无法检测)
- 测试内容太多(无法单独分析)
- 没有明确的假设
执行
- 过早停止
- 测试中途更改内容
- 未检查实现情况
分析
- 忽略置信区间
- 挑选特定细分群体
- 过度解读不确定的结果
针对具体任务的问题
- 你当前的转化率是多少?
- 此页面的流量有多少?
- 你考虑进行什么改动,为什么?
- 值得检测的最小改进幅度是多少?
- 你有哪些测试工具?
- 你以前测试过这一区域吗?