关于 cro-optimization
cro-optimization 是面向现有页面和流程的转化率优化技能，适合通过数据和实验改进转化的团队。它采用审计、假设、测试、决策的结构化流程。
主要功能
- 01结合定量、定性与启发式审计
- 02提出并排序可验证假设
- 03设计样本量与测试指标
- 04按预设标准分析测试结果
- 05记录决策与实验结论
适用场景
- 01排查漏斗环节的高流失
- 02优化高流量页面的转化表现
- 03判断 A/B 测试的样本量与结果
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/cro-optimization确认已加载。
附带文件README.mdreferences/hypothesis-library.md
详细介绍
CRO 优化
将转化率优化作为一项系统化工作来开展：审计 → 提出假设 → 测试 → 决策。与技术栈无关，与工具无关。
此技能适用于针对现有页面和流程开展测试。如需从头撰写落地页文案，请使用 landing-page-copy。如需配置实现 CRO 所需的分析功能，请使用 analytics-strategy。
适用场景
- 转化率低于预期
- 漏斗中的某个步骤流失率较高
- 高流量页面，优化后可能带来显著效果
- 已有 A/B 测试基础设施（或可以搭建）
- 对统计显著性和样本量有疑问
不适用场景
- 流量不足以开展测试（每个变体每月转化量不到约 5,000）
- 产品尚未上线（还没有用户可供测试）
- 需要先进行定性研究的策略或信息传达问题
- 定义品牌的选择（CRO 无法优化从根本上定位错误的品牌）
必需输入
- 要优化的页面或流程
- 当前转化率和流量
- 分析数据访问权限（事件跟踪、漏斗数据）
- A/B 测试工具（或搭建此类工具的意愿）
- 测试所需的时间和预算（每项测试通常为 2 到 8 周）
框架：4 个阶段
1. 审计
先诊断，再处理。
定量审计：
- 漏斗数据。 用户在哪些环节流失？流失最多的环节就是最大的机会。
- 细分分析。 漏斗表现是否因来源、设备、地理位置或受众类型而异？
- 性能数据。 页面加载缓慢是否拉低了转化率？
- Search Console / 站内搜索。 用户在找什么，却找不到？
定性审计：
- 会话回放。 观看 20 段以上用户在目标流程中的会话。记录阻碍、困惑和犹豫之处。
- 热图。 用户在哪里点击？滚动到哪里？又没有滚动到哪里？
- 用户访谈 / 调查。 用户为何没有转化？调查开始流程但中途放弃的人。
- 表单分析。 哪些字段导致用户放弃？哪些字段会引发错误？
- 客户支持工单。 用户提出了哪些与转化相关的问题？
启发式审计：
- 根据 CRO 启发式原则检查流程：
- 用户能否在 5 秒内理解价值主张？
- 每个页面是否只有一个主要 CTA？
- 表单长度是否与所提供的内容相匹配？
- 是否具备信任信号 / 社会认同？
- 是否解决了用户的顾虑？
- 页面是否易于访问？（无障碍问题会悄无声息地损害转化率。）
审计会产出一份疑似阻碍因素清单。每个因素都可以成为一个假设候选项。
2. 提出假设
提出可测试的陈述。
假设结构：
由于[审计发现]，我们认为[改动]会为[用户群体]带来[预期结果]，因为[原因]。
示例：
由于会话回放显示用户在配送步骤放弃了流程（审计发现），我们认为在产品页面显示配送费用（改动），能让桌面端用户的加入购物车转化率提升 5％（预期结果），因为用户对配送费用感到意外并因此放弃购买（原因）。
假设质量标准：
- 改动具体（而非“改进设计”）
- 结果可衡量（包含目标）
- 有证据支撑（审计、研究或先前测试）
- 与已知机制相关（为何此改动会奏效？）
假设优先级排序（ICE 或 PIE）：
- 影响： 对指标的影响可能有多大？
- 信心： 假设成立的可能性有多大？
- 易行性： 测试起来有多容易？（时间、复杂度、风险）
每项按 1 到 10 打分。综合得分最高的优先测试。
3. 测试设计
能够得出明确答案的测试。
样本量和时长：
启动测试前，使用样本量计算器（大多数 A/B 工具都提供此功能）。输入：
- 基准转化率
- 最小可检测效果（你认为值得关注的最小提升幅度）
- 统计功效（通常为 80%）
- 显著性水平（通常为 95%）
计算器会得出每个变体所需的样本量。测试应持续到达到该样本量，或至少运行足够长的时间以覆盖完整的业务周期（通常至少 2 周，以涵盖周末和每周规律）。
常见的测试设置错误：
- 一达到显著性就停止测试（窥探数据）
- 测试时间过短，未能覆盖完整的业务周期
- 在同一流程中运行多个相互重叠的测试
- 在非典型时期进行测试（黑色星期五、节假日、大型营销活动）
- 当 50% 以上的流量来自移动端时排除移动端（或反之）
- 只对过小一部分流量进行测试（统计功效不足）
- 未细分分析（整体提升可能掩盖某个细分群体的负面影响）
启动前需定义的测试参数：
- 主要指标（一个）
- 护栏指标（不得下降）
- 样本量
- 时长（最短和最长）
- 决策标准（何时发布、何时停止、何时延长）
- 除整体结果外要分析的细分群体
4. 做出决定
测试结束后。
决策框架：
| 结果 | 决策 |
|---|---|
| 变体明显胜出（显著性 >95%，且超过最小效果） | 发布该变体。记录结果。继续测试。 |
| 变体明显落败 | 停止测试。总结经验。迭代假设。 |
| 结果不明确（均未达到显著性） | 扩大测试规模、尝试不同方向，或转向其他方案。不要发布“打平”的变体。 |
| 提升幅度小，波动很大 | 可能不值得发布。即使“胜出”，也可能无法复现。 |
| 整体胜出，但在重要细分群体中落败 | 调查该细分群体。考虑针对该群体制定解决方案。 |
反模式：
- 尚未达到显著性就说“看起来要赢了，发布吧”
- 团队想发布某个变体就发布（HiPPO——薪酬最高者的意见）
- 因为结果看起来不理想就过早停止测试
- 反复重跑测试，直到“胜出”（存在假阳性风险）
- 测试失败后不总结经验
统计学基础
显著性和置信度
95% 的显著性水平意味着：如果变体之间确实没有差异，那么偶然出现如此极端结果的概率只有 5%。
这不等于“变体有 95% 的获胜概率”。
大多数 CRO 工具会报告贝叶斯概率（“成为最佳方案的概率为 95%”）。请了解所用工具采用的方法。
样本量
转化率测试所需的样本量比人们想象的更大。快速参考：
| 基准转化率 | 最小可检测效果 | 每个变体的样本量 |
|---|---|---|
| 2% | 相对提升 10% | ~75,000 |
| 2% | 相对提升 20% | ~19,000 |
| 5% | 相对提升 10% | ~30,000 |
| 5% | 相对提升 20% | ~7,500 |
| 10% | 相对提升 10% | ~14,000 |
| 10% | 相对提升 20% | ~3,500 |
（近似值。请使用计算器。）
如果每个变体每月的转化次数达不到这些数字，A/B 测试就无法得出可靠结果。请改用设计迭代和定性研究。
多重检验
同时测试的变体和指标越多，假阳性就越多。针对多重比较调整显著性阈值（例如使用 Bonferroni 校正或类似方法）。
工作流
- 审计。 定量 + 定性 + 启发式分析。
- 提出假设。 根据审计发现提出。采用假设结构。
- 确定优先级。 使用 ICE 或 PIE。选出接下来要测试的 3 到 5 个优先项。
- 设计测试。 确定样本量、时长、主要指标和护栏指标，以及决策标准。
- 实施。 构建不同版本。仔细进行 QA（有缺陷的版本会使测试结果无效）。
- 运行。 不要提前查看结果，也不要提前停止。
- 分析。 分析总体情况和各细分群体。无论是否显著，都要记录值得关注的模式。
- 决策。 发布、终止或延长测试。
- 记录。 记录假设、设计、结果、决策和经验。
- 积累。 将经验用于下一轮假设。
常见失败模式
- 未经审计就测试。 随机改动，结果也随机。
- 假设含糊。 “让它变得更好”不是假设。
- 提前查看并停止。 容易产生假阳性偏差。
- 测试效能不足。 样本不够，无法得出可靠结论。
- HiPPO 越权。 薪酬最高者的意见凌驾于数据之上。
- 在非典型时段测试。 节假日会扭曲结果。
- 只关注单一指标。 转化率上升，但平均订单金额暴跌。得不偿失。
- 没有护栏指标。 只测试一种结果，却忽视对其他指标的损害。
- 文档缺失。 只记录成功，忘记失败。同一假设被重复测试 3 次。
- 将每次测试孤立看待。 在测试间积累经验，才是 CRO 项目真正取得成效的关键。
输出格式
默认输出：每项测试生成一份 Markdown 测试计划，保存为 cro-test-[hypothesis-slug].md。测试运行后，在文档末尾追加结果部分。
结构：
# Test: [Hypothesis short name]
## Hypothesis
Because [observation], we believe that [change] will produce [outcome] for [segment], because [reason].
## Audit evidence
[What evidence supports this hypothesis]
## Test design
- Primary metric:
- Guardrail metrics:
- Sample size required:
- Duration: minimum X, maximum Y
- Variant traffic split:
- Segments to analyze:
## Decision criteria
- Ship if: [conditions]
- Kill if: [conditions]
- Extend if: [conditions]
## Results (filled after test)
- Sample reached:
- Duration actual:
- Primary metric: [variant vs control + significance]
- Guardrail metrics: [results]
- Segment analysis: [findings]
## Decision
[Ship / Kill / Extend / Iterate] - [Why]
## Lesson
[What this teaches us, regardless of outcome]
如果所需数据不可用
此技能的输出依赖于它无法自行生成的数据、测量结果或工具结果。如果所需的输入、工具或数据源不可用或无法验证，获准的输出是交付物，并注明存在的缺口：需要什么、实际获得或验证了什么，以及哪些部分受到影响。不得为了完成交付物而捏造、估算或插值任何必需数值。说明缺口本身就是完整答复。
参考文件
references/hypothesis-library.md- 按漏斗阶段分类的常见高影响假设模式。