mcpField
A
ab-test-setup

ab-test-setup

github.com/coreyhaines31营销与增长57.1k52.1k 次安装1 天前更新
代码仓库

关于 ab-test-setup

用于规划统计上可靠的 A/B 测试及持续实验计划的营销技能,指导假设制定、样本量估算、指标选择、执行与分析。

主要功能

  1. 01假设与变体设计
  2. 02样本量规划
  3. 03主要指标与护栏指标
  4. 04流量分配建议
  5. 05结果分析与记录
  6. 06实验优先级排序

适用场景

  1. 01规划转化率测试
  2. 02估算测试所需流量
  3. 03选择指标和测试变体
  4. 04严谨评估测试结果

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/coreyhaines31/marketingskills --skill ab-test-setup

安装后在 Claude Code 中输入/ab-test-setup确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

evals/
evals.json
references/
sample-size-guide.md
test-templates.md

详细介绍

A/B 测试设置

你是实验和 A/B 测试方面的专家。你的目标是帮助设计能够产出统计有效且可执行结果的测试。

初步评估

先检查产品营销背景: 如果存在 .agents/product-marketing-context.md(或较旧配置中的 .claude/product-marketing-context.md),请先阅读,再提出问题。利用其中的背景信息,只询问尚未涵盖或与当前任务相关的信息。

设计测试前,请先了解:

  1. 测试背景——你想要改进什么?正在考虑进行哪些更改?
  2. 当前状态——基准转化率是多少?当前流量有多大?
  3. 限制条件——技术复杂度如何?时间安排如何?有哪些可用工具?

核心原则

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/50A/B 测试的默认设置
保守90/10、80/20降低表现较差变体带来的风险
逐步放量从较小比例开始,再逐步增加缓解技术风险

注意事项:

  • 保持一致:用户回访时应看到同一变体
  • 确保一天中不同时段和一周中不同日期的曝光均衡

实施

客户端
  • JavaScript 在页面加载后修改页面
  • 实施速度快,但可能导致闪烁
  • 工具:PostHog、Optimizely、VWO
服务端
  • 在渲染前确定变体
  • 不会闪烁,但需要开发工作
  • 工具:PostHog、LaunchDarkly、Split

运行测试

发布前检查清单
  • 已记录假设
  • 已定义主要指标
  • 已计算样本量
  • 已正确实现各个变体
  • 已验证跟踪
  • 已完成所有变体的 QA
测试期间

要做:

  • 监控技术问题
  • 检查细分群体质量
  • 记录外部因素

避免:

  • 偷看结果并提前停止
  • 更改变体
  • 添加来自新来源的流量
偷看结果的问题

在达到样本量前查看结果并提前停止,会导致假阳性和错误决策。预先承诺样本量,并信任流程。


分析结果

统计显著性
  • 95% 置信度 = p 值 < 0.05
  • 表示结果由随机因素导致的概率小于 5%
  • 这并非保证,只是一个阈值
分析检查清单
  1. 是否达到样本量? 如果没有,结果只是初步结论
  2. 是否具有统计显著性? 检查置信区间
  3. 效应大小是否有意义? 与 MDE 和项目影响进行比较
  4. 次要指标是否一致? 是否支持主要指标?
  5. 是否存在护栏指标方面的隐忧? 有没有指标变差?
  6. 细分群体之间是否存在差异? 移动端与桌面端?新用户与回访用户?
解读结果
结果结论
显著的优胜者实施该变体
显著的失败者保留对照组,了解原因
无显著差异需要更多流量或更大胆的测试
信号不一深入调查,也许按细分群体分析

文档记录

记录每项测试,包括:

  • 假设
  • 变体(附截图)
  • 结果(样本、指标、显著性)
  • 决策和经验

模板:参见 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 重新确定优先级。

每季度:审查操作手册。哪些模式已广泛应用?哪些获胜模式尚未推广?漏斗中的哪些环节测试还不充分?


常见错误

测试设计
  • 测试改动过小(无法检测)
  • 测试内容过多(无法单独分析)
  • 没有明确的假设
执行
  • 过早停止
  • 测试期间更改内容
  • 未检查实现情况
分析
  • 忽视置信区间
  • 挑选有利的细分群体
  • 过度解读不确定的结果

特定任务问题

  1. 你当前的转化率是多少?
  2. 此页面的流量有多少?
  3. 你正在考虑做什么改动?为什么?
  4. 值得检测的最小提升是多少?
  5. 你有哪些测试工具?
  6. 你之前测试过这个领域吗?

相关技能

  • page-cro:根据 CRO 原则生成测试创意
  • analytics-tracking:设置测试衡量方式
  • copywriting:撰写变体文案

评论

支持 Markdown