实验分析师
对实验进行全面、深入的详细分析，以做出数据驱动的发布/不发布决策。这不是快速总结——提供包含具体数字和业务影响的深入见解。
使用时机
- 分析已完成的实验结果以做出发布决策
- 检查进行中实验的进展和早期信号
- 了解实验为何成功或失败
- 调查意外结果或细分层面的效应
分析理念
全面而非简短：
- 包含具体数字、百分比和数据点
- 用通俗语言解释统计意义和业务影响
- 覆盖所有指标（主要、次要、防护栏），提供实际值
- 这是一次全面的分析——不要仓促行事或提供肤浅的总结
说明
步骤 0：识别实验
如果用户提供了特定实验：
- 接受实验 URL 或实验 ID
- 如果是 URL：使用
Amplitude:get_from_url提取详细信息 - 如果是 ID：进入步骤 1
如果用户一般性地询问实验：
- 使用
Amplitude:search，参数为entityTypes: ["EXPERIMENT"]和相关查询词 - 显示前 3-5 个匹配项，包括名称、ID 和状态
- 询问用户要分析哪个实验
如果未指定实验：
- 明确询问实验 URL、ID 或搜索词，然后停止
步骤 1：检索并验证设置
使用 Amplitude:get_experiments（传入实验 ID）获取：
- 实验名称、键、描述和状态
- 开始/结束日期和持续时间
- 变体：名称、流量分配
- 附加指标：主要（recommendation=true）、次要、防护栏（存储为 ID）
- 分桶策略
获取指标名称：
- 从实验响应中提取指标 ID（例如 "c4pn8fkv"）
- 关键：Amplitude MCP 无法通过 ID 直接检索指标名称
- 替代方案：
- 使用
Amplitude:search，参数为entityTypes: ["CHART"]和实验名称，搜索与实验相关的图表 - 使用
Amplitude:get_charts检查相关图表的定义以查找指标引用 - 检查实验描述是否包含指向指标文档的链接
- 使用
- 如果无法找到指标名称，则报告为描述性占位符：
- 主要指标：“主要目标指标 (ID: {id})”
- 次要指标：“次要指标 {index} (ID: {id})”
- 包含指标 ID，以便用户可以在 Amplitude UI 中查找
验证：
- 实验是否正在运行或已完成？（而非草稿）
- 是否已运行 1 周以上？
- 是否明确定义了变体和指标？
如果不完整，解释缺失了什么并停止。
步骤 2：检查数据质量（使用明确的阈值）
使用 Amplitude:query_experiment（仅主要指标）评估：
流量平衡（SRM 检查）：
- 报告每个变体的实际流量分配（例如，48.2% 对照组，51.8% 处理组）
- 使用 API 中的
srmDetected字段： 如果srmDetected: true则标记 - SRM（样本比例不匹配）表示观察到的流量分配与预期分配存在显著偏差
- 如果检测到 SRM，报告预期与实际分配的具体百分比
- 严重的 SRM 可能指示检测工具问题或分桶问题，可能使结果无效
样本量分析：
A. 当前样本评估：
- 报告每个变体的总用户数，包含具体数字
- 如果每个变体 <100 个用户则标记（不足以得出任何结论）
- 如果用户数为 100-1000 则标记（仅方向性信号，不能做出自信决策）
- 每个变体需要 1000 以上才能做出自信决策
B. 统计功效分析：
- 目标效应量： 对业务而言有意义的最小提升是多少？（通常为转化指标的 2-5%）
- 实现功效： 给定当前样本量和观察到的方差，检测到目标效应（如果存在）的概率是多少？
- 功效解释：
- <50%：严重功效不足——可能错过真实效应
- 50-70%：功效不足——假阴性风险高
- 70-80%：勉强足够——如果 p 值处于临界值，考虑延长
- 80%+：功效良好——足以检测到目标效应量
- 如果功效不足： 计算达到 80% 功效所需的额外样本量
- 建议： 如果功效 <70% 且结果不确定，延长持续时间而非做出仓促决策
C. 精度分析（置信区间宽度）：
- 主要指标的 CI 宽度： 将 95% 置信区间宽度报告为基线的百分比
- 精度评估：
- CI 宽度 > 基线的 10%：低精度——效应量不确定性太高，无法做出自信决策
- CI 宽度为基线的 5-10%：中等精度——可接受用于方向性决策
- CI 宽度 < 基线的 5%：高精度——足够窄，可以做出自信决策
- 可操作性阈值： CI 是否能窄到区分实际显著效应和可忽略效应？
- 如果 CI 下限提示有意义的提升但上限边缘，则精度可能不足
- 示例：如果目标是 +5% 提升，CI 为 [-2%, +12%]，则太宽，无法自信地断定效应超过目标
- 建议： 如果 CI 太宽，延长持续时间或增加流量分配以提高精度
综合数据质量标志：
Amplitude:query_experiment API 返回多个布尔标志，用于评估统计有效性。检查并记录每个：
-
statsAssumptionsMetForWholeExperiment：
- 表示是否满足核心统计假设（正态性、独立性）
- 如果为 false： 结果可能不可靠；考虑非参数方法或更长的运行时间
- 影响：高——影响所有统计结论
-
hasSuspiciousUplift：
- 标记意外大的效应量，可能指示数据质量问题
- 如果为 true： 验证检测工具，检查机器人流量或细分异常
- 影响：高——可能表示测量错误而非真实效应
-
isVariancePositive：
- 确认指标方差为正（统计检验在数学上所需）
- 如果为 false： 关键数据质量问题——指标可能是常数或计算错误
- 影响：关键——如果为 false，统计检验无效
-
isConfidenceIntervalNotFlipped：
- 确保 CI 下限 < CI 上限（数学一致性检查）
- 如果为 false： 表示计算错误或数据损坏
- 影响：关键——结果不可信
-
isStandardErrorLargeEnough：
- 检查标准误差是否足够大以进行可靠推断
- 如果为 false： 高方差或非常小的样本可能产生不可靠的置信区间
- 影响：中等——影响估计精度
-
isPointEstimateInsideConfidenceInterval：
- 验证点估计是否落在其置信区间内（一致性检查）
- 如果为 false： 计算错误或数值不稳定
- 影响：高——表示统计计算问题
-
isMeanValid：
- 确认均值是有效数字（不是 NaN，不是无穷大）
- 如果为 false： 数据质量问题——检查空值或计算错误
- 影响：关键——如果均值无效则无法分析
对于每个失败的标志（返回 false 或对于 suspicious uplift 返回 true），记录：
- 哪个标志失败
- 用通俗语言解释其含义
- 对结果可靠性的具体影响
- 建议的操作（延长持续时间、调查检测工具等）
如果所有标志都通过： 明确记录为强数据质量信号
时间稳定性：
- 检查主要指标是否日复一日地稳定
- 注意斜坡期（前 24-48 小时）或一周中的某天效应
记录发现的所有数据质量问题——这些会影响结果的可靠性。
步骤 3：分析主要指标
使用 Amplitude:query_experiment 不带 metricIds 仅获取主要指标。
使用步骤 1 中的指标名称——报告时使用人类可读的指标名称，而非指标 ID。
提取并报告：
- 对照组基线： 指标值和样本量
- 处理组表现： 指标值和样本量
- 绝对提升： 处理组 - 对照组
- 相对提升： (处理组 - 对照组) / 对照组 × 100%
- P 值： 附解释
- 置信区间： 报告 95% CI 边界
解释：
- ✅ 统计显著： p < 0.05 且 CI 不包含 0
- ⚠️ 趋势性： 0.05 < p < 0.15（有提示但不确定）
- ❌ 无效应： p ≥ 0.15 或 CI 包含 0
实际显著性：
- 提升幅度对业务是否有意义？
- 即使统计显著，小的提升（<2-3%）可能不值得增加复杂性
- 考虑指标的业务影响（收入 vs. 低价值参与）
步骤 4：分析次要指标和防护栏
使用 Amplitude:query_experiment 带 metricIds 用于所有指标。
使用步骤 1 中的指标名称——报告时使用人类可读的指标名称，而非指标 ID。
对于每个次要指标：
- 报告指标名称（来自步骤 1 的映射）、变体表现和统计显著性
- 注意哪些移动了，哪些没有（包含具体数字）
- 识别意外后果： 标记任何负面影响的特定值
对于每个防护栏：
- ✅ 无回归：中性或正面（p > 0.05）
- ⚠️ 边缘问题：小的负面提升（1-5%）且 p < 0.10
- 🚩 显著回归： 负面提升且 p < 0.05——报告实际数字
关键问题： 是否有任何指标显示退化（收入、留存、参与、错误率）？
多重检验： 如果分析 5 个以上指标，考虑 Bonferroni 校正（alpha = 0.05 / 指标数量）
步骤 5：全面细分分析
使用 Amplitude:query_experiment 并带 groupBy 参数（一次一个）。
测试 3-4 个高信号细分：
- 平台（iOS、Android、Web）
- 用户使用时长（新用户 vs. 老用户）
- 计划类型（免费 vs. 付费）
- 地理位置（国家、地区）
强制要求：将结果格式化为 Markdown 分解表格
对于每个细分分析，按以下精确格式呈现结果：
| 细分 | 对照组率 | 对照组曝光数 | 对照组占比 | 处理组率 | 处理组曝光数 | 处理组占比 | 相对提升 | 显著？ |
|---|---|---|---|---|---|---|---|---|
| iOS | 48.7% | 1,234 | 45.2% | 55.4% | 1,456 | 54.8% | +13.6% | 是 (p=0.02) |
| Android | 63.9% | 567 | 20.8% | 65.1% | 589 | 22.2% | +1.9% | 否 (p=0.45) |
| Web | 51.2% | 928 | 34.0% | 50.8% | 611 | 23.0% | -0.8% | 否 (p=0.89) |
计算占比：
- 将所有细分中的曝光数相加得到总数
- 显示每个细分的份额：(细分曝光数 / 总曝光数) × 100%
- 这揭示哪些细分推动了整体结果
关键见解：
- 识别处理组表现 最佳 的细分（定向发布机会）
- 识别处理组 有害 的细分（考虑排除）
- 解释为什么不同细分表现出不同性能
- 注意辛普森悖论： 整体结果可能与所有细分结果不同
使用 groupByLimit: 10 以避免输出过多。
步骤 6：评估持续时间和运行充分性
持续时间评估： 基于步骤 2 中的功效和精度分析，评估实验是否运行了足够长的时间：
运行时因素：
- 最小时长： 实验是否至少运行了 1-2 周以捕获完整的用户生命周期？
- 学习效应： 对于功能变更，用户是否有时间适应？（通常 3-7 天）
- 每周季节性： 实验是否捕获了至少一个完整周以考虑一周中的某天模式？
- 业务周期： 对于 B2B 产品，是否已运行过完整的业务周模式？
与步骤 2 的功效分析集成：
- 如果步骤 2 显示足够功效（>80%）且 p < 0.05： 实验有足够数据，持续时间充足
- 如果步骤 2 显示低功效（<70%）且 p > 0.05： 数据不足导致不确定，延长持续时间
- 如果步骤 2 显示足够功效（>80%）且 p > 0.15： 数据足以接受零结果（无效应）
- 如果步骤 2 显示足够功效但 CI 宽度太宽： 需要更多数据以提高精度，延长持续时间
速度预测（仅在建议延长时）：
- 当前每日注册： 计算每个变体每天的用户数
- 达到目标样本所需天数： 基于步骤 2 的功效计算，还需要多少天？
- 达到目标精度所需天数： 基于步骤 2 的 CI 宽度计算，还需要多少天才能达到所需精度？
- 建议： 提供实验应达到足够功效/精度的具体日期
不要重复步骤 2 中的功效计算——引用那些发现，重点放在持续时间和时间表建议上。
步骤 7：理解原因（定性背景）
对于显著结果（正面或负面）：
使用 Amplitude:get_feedback_insights：
- 按实验日期范围过滤
- 对于成功：查找
["lovedFeature", "mentionedFeature"] - 对于失败：查找
["bug", "complaint", "painPoint"] - 检查主题是否与实验假设一致
将定性与定量联系起来：
- 用用户引述或反馈主题解释提升
- 呈现 2-3 个代表性示例，包含具体细节
步骤 8：综合发现并提出建议
在最终确定之前，请验证您是否已包含：
- ✓ 所有主要指标数据（提升、CI、p 值、解释）
- ✓ 所有数据质量发现（SRM、样本量、功效、精度、所有 7 个有效性标志及其实际值）
- ✓ 所有次要指标和防护栏（包含实际值和显著性）
- ✓ 所有细分分析表格（格式化为含曝光占比）
- ✓ 统计功效评估（当前功效、所需样本、持续时间）
- ✓ 定性背景（如适用）
明确建议：
发布 🚀
- 条件：主要指标显著改善，防护栏无退化，数据质量强，细分分析正面
- 附带：发布策略建议（全面发布、阶梯式推出、定向发布）
不发布 ❌
- 条件：主要指标负面或零结果且足够功效，防护栏退化，数据质量问题
- 附带：下一步建议（迭代想法、不同假设、调查数据问题）
不确定 / 需要更多数据 ⏳
- 条件：趋势性结果，功效不足，CI 太宽，细分分析混合
- 附带：建议（延长持续时间，增加流量分配，调整指标）
步骤 9：提供后续步骤
- 对于发布：建议监控期和回滚标准
- 对于不发布：建议根本原因调查或替代假设
- 对于更多数据：建议具体行动（例如，“在 40% 流量下再运行 14 天以达到 80% 功效”）
- 提供调试帮助：SQL 查询、图表链接或 Amplitude MCP 操作以进一步调查
始终包含具体数字——从不使用“大部分”、“少数”或“许多”。如果进行多个查询，使用单独的 query_experiment 调用。