実験アナライザー は何をしますか？
実験の包括的かつ詳細な深堀分析を実行し、データ駆動型の出荷/非出荷判断を下します。これは簡単な要約ではありません。具体的な数値とビジネス上の意味合いを含む、徹底的な洞察を提供します。
使用すべきケース
- 完了した実験結果を分析して出荷判断を行う
- 実行中の実験の進捗状況や初期シグナルを確認する
- 実験が成功または失敗した理由を理解する
- 予期しない結果やセグメントレベルの影響を調査する
分析哲学
簡潔ではなく、包括的に:
- 具体的な数値、パーセンテージ、データポイントを含める
- 統計的な意味とビジネス上の意味合いの両方を平易な言葉で説明する
- すべてのメトリクス（主要、副次、ガードレール）を実際の値で網羅する
- これは単一の包括的な分析です。急いだり、表面的な要約を提供したりしないでください
手順
ステップ 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})"
- ユーザーがAmplitude UIで調べられるようにメトリクスIDを含める
検証:
- 実験は実行中または完了しているか？（ドラフトではない）
- 1週間以上実行されているか？
- バリアントとメトリクスが明確に定義されているか？
不完全な場合は、不足している点を説明して停止する。
ステップ 2: データ品質を確認する（明示的なしきい値を使用）
Amplitude:query_experiment（主要メトリクスのみ）を使用して評価する:
トラフィックバランス（SRMチェック）:
- バリアントごとの実際のトラフィック分割を報告する（例: コントロール48.2%、トリートメント51.8%）
- APIの
srmDetectedフィールドを使用:srmDetected: trueの場合はフラグを立てる - SRM（Sample Ratio Mismatch）は、観測されたトラフィック分割が期待される配分から大きく乖離していることを示す
- SRMが検出された場合、期待値と実際の配分を具体的なパーセンテージで報告する
- 深刻なSRMは、結果を無効にする可能性がある計装の問題やバケット問題を示している可能性がある
サンプルサイズ分析:
A. 現在のサンプル評価:
- バリアントごとの総ユーザー数を具体的な数値で報告する
- バリアントあたり100ユーザー未満の場合にフラグを立てる（結論を出すには不十分）
- 100〜1000ユーザーの場合にフラグを立てる（方向性のあるシグナルのみ、確定的な判断はできない）
- 確定的な判断にはバリアントあたり1000+のユーザーが必要
B. 統計的検出力分析:
- 目標効果量: ビジネスにとって意味のある最小のリフトはどれくらいか？（通常、コンバージョンメトリクスでは2〜5%）
- 達成された検出力: 現在のサンプルサイズと観測された分散を考慮すると、目標効果が存在する場合にそれを検出できる確率はどれくらいか？
- 検出力の解釈:
- <50%: 深刻な検出力不足 - 実際の効果を見逃す可能性が高い
- 50〜70%: 検出力不足 - 偽陰性のリスクが高い
- 70〜80%: ぎりぎり許容範囲 - p値が境界線上にある場合は延長を検討
- 80%以上: 検出力良好 - 目標効果量を検出するのに十分
- 検出力不足の場合: 80%の検出力に達するために必要な追加サンプルサイズを計算する
- 推奨: 検出力が70%未満で結果が決定的でない場合は、時期尚早な判断を下さずに実験期間を延長する
C. 精度分析（信頼区間の幅）:
- 主要メトリクスの信頼区間幅: 95%信頼区間の幅をベースラインのパーセンテージとして報告する
- 精度の評価:
- 信頼区間幅 > ベースラインの10%: 低精度 - 効果量の不確実性が高く、確定的な判断には不十分
- 信頼区間幅がベースラインの5〜10%: 中程度の精度 - 方向性のある判断には許容可能
- 信頼区間幅 < ベースラインの5%: 高精度 - 確定的な判断に十分狭い
- 実用性のしきい値: 実質的な有意性と無視できる効果を区別するのに十分狭い信頼区間ですか？
- 信頼区間の下限が意味のあるリフトを示唆しているが、上限がわずかである場合、精度が不十分である可能性がある
- 例: 目標が+5%のリフトで、信頼区間が[-2%, +12%]の場合、効果が目標を超えると確信を持って結論付けるには幅が広すぎる
- 推奨: 信頼区間が広すぎる場合は、精度を向上させるために実験期間を延長するか、トラフィック配分を増やす
包括的なデータ品質フラグ:
Amplitude:query_experiment APIは、統計的妥当性を評価する複数のブールフラグを返す。それぞれを確認して文書化する:
-
statsAssumptionsMetForWholeExperiment:
- 中心的な統計的仮定（正規性、独立性）が満たされているかどうかを示す
- falseの場合: 結果が信頼できない可能性がある。ノンパラメトリックなアプローチや実行時間の延長を検討
- 影響: 高い - すべての統計的結論に影響を与える
-
hasSuspiciousUplift:
- データ品質の問題を示す可能性がある、予期しない大きな効果量にフラグを立てる
- trueの場合: 計装を確認し、ボットトラフィックやセグメントの異常をチェックする
- 影響: 高い - 実際の効果ではなく測定誤差を示している可能性がある
-
isVariancePositive:
- メトリクスの分散が正であることを確認する（統計的検定に数学的に必要）
- falseの場合: 重大なデータ品質の問題 - メトリクスが一定であるか、誤って計算されている可能性がある
- 影響: 重大 - このフラグがfalseの場合、統計的検定は無効
-
isConfidenceIntervalNotFlipped:
- 信頼区間の下限が上限より小さいことを保証する（数学的な整合性チェック）
- falseの場合: 計算エラーまたはデータの破損を示す
- 影響: 重大 - 結果を信頼できない
-
isStandardErrorLargeEnough:
- 信頼できる推論のために標準誤差が十分大きいかどうかをチェックする
- falseの場合: 分散が大きいか、サンプルが非常に少ないため、信頼区間が信頼できない可能性がある
- 影響: 中程度 - 推定値の精度に影響を与える
-
isPointEstimateInsideConfidenceInterval:
- 点推定値がその信頼区間内にあることを検証する（整合性チェック）
- falseの場合: 計算エラーまたは数値的不安定性
- 影響: 高い - 統計計算の問題を示す
-
isMeanValid:
- 平均値が有効な数値であることを確認する（NaN、無限大ではない）
- falseの場合: データ品質の問題 - null値または計算エラーがないか確認
- 影響: 重大 - 平均が無効な場合、分析できない
失敗した各フラグ（suspicious upliftの場合はtrueを返す）について、以下を文書化:
- どのフラグが失敗したか
- 平易な言葉で何を意味するか
- 結果の信頼性への具体的な影響
- 推奨されるアクション（期間延長、計装の調査など）
すべてのフラグが合格した場合: これを強力なデータ品質シグナルとして明示的に記載する
時間的安定性:
- 主要メトリクスが日々安定しているか確認する
- ランプアップ期間（最初の24〜48時間）や曜日効果に注意する
見つかったすべてのデータ品質の問題を文書化する - これらは結果の信頼性に影響を与える。
ステップ 3: 主要メトリクスを分析する
Amplitude:query_experiment を metricIdsなし で使用し、主要メトリクスのみを取得する。
ステップ 1 のメトリクス名を使用する - メトリクスIDではなく、人間が読めるメトリクス名を使用して報告する。
抽出して報告する:
- コントロールのベースライン: メトリクス値とサンプルサイズ
- トリートメントのパフォーマンス: メトリクス値とサンプルサイズ
- 絶対リフト: トリートメント - コントロール
- 相対リフト: (トリートメント - コントロール) / コントロール × 100%
- p値: 解釈付き
- 信頼区間: 95%信頼区間の境界を報告
解釈:
- ✅ 統計的に有意: p < 0.05 かつ信頼区間が0を含まない
- ⚠️ 傾向あり: 0.05 < p < 0.15（示唆的だが決定的ではない）
- ❌ 効果なし: p ≥ 0.15 または 信頼区間が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補正（α = 0.05 / メトリクス数）を検討する
ステップ 5: 包括的なセグメント分析
Amplitude:query_experiment を groupBy パラメータで使用する（一度に1つ）。
3〜4つのシグナルの高いセグメントをテストする:
- プラットフォーム (iOS, Android, Web)
- ユーザー継続期間 (新規 vs. 既存ユーザー)
- プランタイプ (無料 vs. 有料)
- 地域 (国、地域)
必須: 結果をマークダウンの内訳テーブルとしてフォーマットする
各セグメント分析について、この正確な形式で結果を提示する:
| セグメント | コントロール率 | コントロール露出数 | コントロール全体比率 | トリートメント率 | トリートメント露出数 | トリートメント全体比率 | 相対リフト | 有意か？ |
|---|---|---|---|---|---|---|---|---|
| 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日）
- 週次季節性: 曜日のパターンを考慮するために、実験は少なくとも1週間分を捉えていますか？
- ビジネスサイクル: B2B製品の場合、完全な週のビジネスパターンを実行していますか？
ステップ 2 の検出力分析との統合:
- ステップ 2 で十分な検出力 (>80%) と p < 0.05 を示した場合: 実験には十分なデータがあり、期間は適切である
- ステップ 2 で低い検出力 (<70%) と p > 0.05 を示した場合: データ不足のため決定的ではなく、期間を延長する
- ステップ 2 で十分な検出力 (>80%) と p > 0.15 を示した場合: 帰無仮説（効果なし）を受け入れるのに十分なデータがある
- ステップ 2 で十分な検出力を示したが信頼区間の幅が広すぎる場合: 精度のためにさらにデータが必要であり、期間を延長する
速度予測（延長が推奨される場合のみ）:
- 現在の1日あたりの登録数: バリアントごとの1日あたりのユーザー数を計算する
- 目標サンプルまでの日数: ステップ 2 の検出力計算に基づいて、あと何日必要か？
- 目標精度までの日数: ステップ 2 の信頼区間幅計算に基づいて、望ましい精度に達するまでにあと何日必要か？
- 推奨: 実験が十分な検出力/精度に達する具体的な日付を提供する
ステップ 2 の検出力計算を繰り返さないでください - それらの結果を参照し、期間とタイムラインの推奨に焦点を当ててください。
ステップ 7: 理由を理解する（定性コンテキスト）
有意な結果（ポジティブまたはネガティブ）の場合:
Amplitude:get_feedback_insights を使用:
- 実験の日付範囲でフィルタリング
- 勝利の場合:
["lovedFeature", "mentionedFeature"]を探す - 損失の場合:
["bug", "complaint", "painPoint"]を探す - テーマが実験の仮説と一致しているか確認する
定量と定性を結びつける:
- ユーザーの引用やフィードバックテーマでリフトを説明する
- 具体的な詳細を含む2〜3の代表的な例を提示する
ステップ 8: 調査結果を統合し、推奨事項を作成する
最終決定前に、以下を含めていることを確認する:
- ✓ すべての主要メトリクスデータ（リフト、信頼区間、p値、解釈）
- ✓ すべてのデータ品質調査結果（SRM、サンプルサイズ、検出力、精度、7つの妥当性フラグすべてと実際の値）
- ✓ すべての副次メトリクスとガードレール（実際の値と有意性付き）
- ✓ すべてのセグメント分析テーブル（全体露出数のパーセンテージでフォーマット）
- ✓ 統計的検出力評価（現在の検出力、必要なサンプル、期間）
- ✓ 定性コンテキスト（該当する場合）
推奨事項を提供する:
- ✅ 出荷: 結果が統計的に有意で、実務的に重要で、下流のメトリクスに悪影響がない場合
- ⚠️ 条件付き出荷: 結果が特定のセグメントでのみポジティブな場合、または軽微なガードレールの問題を許容できる場合
- 🔄 延長: 検出力が不十分、信頼区間が広すぎる、またはp値が境界線上にある場合（推奨される新しい終了日を含む）
- ❌ 非出荷: 結果がネガティブであるか、重大な悪影響を伴う場合
- 🔬 さらなる調査: データ品質の問題（SRM、suspicious uplift）、または定量結果と定性フィードバックの矛盾が検出された場合
各判断の背後にある理由を必ず説明すること。 「出荷しない」と言うだけでは不十分です。理由と、改善のために何を変更するかを説明してください。
最終出力形式:
## 実験概要
{実験名、ID、期間、ステータス}
## 1. 主要メトリクス: {メトリクス名}
- コントロール: {値}
- トリートメント: {値}
- 絶対リフト: {値}
- 相対リフト: {パーセンテージ}
- p値: {値} ({有意/傾向/効果なし})
- 95%信頼区間: [{下限}, {上限}]
## 2. データ品質
- SRM: {なし/検出}
- サンプルサイズ: {コントロール数}, {トリートメント数}
- 統計的検出力: {パーセンテージ} ({解釈})
- 精度: {信頼区間幅}% ({解釈})
- 妥当性フラグ:
- ✅ statsAssumptionsMetForWholeExperiment: true
- ✅ hasSuspiciousUplift: false
- ...（各フラグ）
## 3. 副次メトリクス
{メトリクス}: {トリートメント} vs {コントロール}, リフト {パーセンテージ}, p={値} ({有意/傾向/なし})
...
## 4. セグメント分析
| セグメント | コントロール率 | ... |
|---------|---------------|-----|
## 5. 推奨事項
**判断: {判断}**
{理由の説明}
記号
- ℃: 摂氏温度の度
- ℉: 華氏温度の度
- $: 米ドル
- €: ユーロ
- ¥: 日本円
- £: 英国ポンド
- %: パーセント
- ©: 著作権
- ®: 登録商標
- ™: 商標
パーセンテージと通貨記号は地域によってフォーマットが異なりますが、数値は一貫している必要があります