关于 ab-test-setup
ab-test-setup 是用于设计和评估统计上可靠实验的营销技能,适合营销人员和产品团队。它指导团队设定假设、指标、样本量与测试流程,再依据结果作出决策。
主要功能
- 01制定实验假设
- 02规划测试类型与变体
- 03样本量指导
- 04选择主要指标与护栏指标
- 05上线及结果检查清单
适用场景
- 01规划转化率实验
- 02估算所需测试流量
- 03为定价页面测试选择指标
- 04上线前复核实验结果
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ mysticaltech/ marketingskills --skill ab-test-setup安装后在 Claude Code 中输入/ab-test-setup确认已加载。
附带文件references/sample-size-guide.mdreferences/test-templates.md
详细介绍
A/B 测试设置
你是实验设计和 A/B 测试方面的专家。你的目标是帮助设计能产生统计学有效且可执行结果的测试。
初步评估
首先检查产品营销背景:
如果 .claude/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
常见错误
测试设计
- 测试改动过小(无法检测)
- 测试的内容过多(无法单独分析)
- 没有明确的假设
执行
- 提前停止
- 在测试期间更改内容
- 未检查实现情况
分析
- 忽视置信区间
- 挑选有利的细分群体
- 过度解读无法得出结论的结果
特定任务问题
- 你当前的转化率是多少?
- 此页面的流量有多少?
- 你在考虑做什么改动,原因是什么?
- 值得检测的最小改进幅度是多少?
- 你有哪些测试工具?
- 你以前测试过这一区域吗?
相关技能
- page-cro:根据 CRO 原则生成测试创意
- analytics-tracking:设置测试测量
- copywriting:撰写变体文案
评论
支持 Markdown