ae-experiment-insight

AE 実験のインサイトと診断

効果を解釈する前に、根拠を検証してください。実験の信頼性が十分に高く、判断を裏付けられる場合にのみ、結論を出してください。

プラットフォームと参照先の案内

AE プラットフォームとのすべてのやり取りには ae-cli を使用し、 references/platform-operations.md に従ってください。ほかのプラットフォームアクセス手段で代用してはいけません。

診断には references/diagnostic-playbook.md を参照してください。ロールアウトの判断を下す前に、 references/decision-framework.md を参照してください。

ワークフロー

1. 実験のコンテキストを復元する

対象のプロジェクトと実験を正確に特定します。以下を収集してください。

• 仮説と意図する判断；
• コントロールとトリートメントの定義；
• 割り当て単位、レイヤー、ターゲティング、トラフィック、グループ割り当て；
• Feature とグループの値；
• 主要指標、副次指標、診断指標；
• 計画した MDE、alpha、power、期間、停止ルール；
• 実際の開始・終了時刻と重要な設定変更。

当初の仮説や成功基準がない場合は、観測された効果を説明するにとどめ、成功基準を後付けで作らないでください。

2. 実行の整合性を確認する

実験の実際の状態、完全な実行期間、および実行中に発生した重要な Feature、トラフィック、オーディエンス、指標、ID の変更を確認します。設定履歴を根拠として扱ってください。割り当て、エクスポージャー、サンプルの十分性、設計の品質は、ここでルールを重複させず、診断プレイブックに沿って評価してください。

3. データ診断を実行する

因果関係の順序に従って diagnostic-playbook.md を適用し、診断チェックリストを完了してください。SRM とグループ比較には scripts/analyze_experiment.py を使用し、p 値や信頼区間を頭の中で計算してはいけません。

4. 効果を解釈する

事前登録された各指標について、診断プレイブックで検証した指標の定義を解釈し、以下を報告してください。

• 検証済みのソースイベント、集計方法、分析単位、分母または母集団、フィルター、アトリビューション期間；
• コントロールとトリートメントの値；
• 絶対差と相対差；
• 決定論的な計算または検証済みのプラットフォームレポートによる信頼区間と p 値；
• 計画したサンプル数に対する実績サンプル数；
• MDE およびビジネス上のしきい値との関係；
• 統計的有意性と実務上の有意性。

以下を区別してください。

• 統計的に有意で、実務上も価値がある；
• 統計的には有意だが、影響は小さすぎて意味がない；
• 方向としてはプラスだが、検出力が不足している；
• 現在の精度では検出可能な効果がない；
• 統計的に有意なマイナス；
• データ品質の問題により無効、または結論が出せない。

p > alpha を「効果なし」と解釈してはいけません。現在のデータでは効果が立証されていないことを述べ、データと整合する区間を説明してください。

5. 傾向とセグメントを分析する

完全で比較可能な期間を使って、傾向の安定性と異常な日を確認してください。 decision-framework.md の傾向とセグメントに関するルールを適用してください。

6. 原因を診断する

疑われる原因ごとに、以下を提示してください。

• 観測された根拠；
• 推論と不確実性；
• 競合する説明；
• それらを区別するための具体的なプラットフォームクエリまたはプロダクト確認；
• 原因が確認された場合の修正策。

根拠から切り離された一般的な原因の一覧を提示してはいけません。 最終レポートでは、原因を区別する確認方法を、ユーザー向けの簡潔な検証アクションとして記述してください。ユーザーがコマンド、監査証跡、またはデバッグの詳細を明示的に求めた場合に限り、生の ae-cli コマンドを含めてください。

7. 判断を下す

decision-framework.md を適用し、信頼性評価、主要な効果、期間、傾向、セグメント、診断結果に基づく判断を 1 つ提示してください。

ユーザーから別途プラットフォーム操作を依頼されない限り、実験の開始、一時停止、終了、トラフィック変更、削除、ロールアウトを行ってはいけません。これらの操作は解釈の範囲外であり、対象と影響について明示的な確認が必要です。

出力要件

• 明示的に指定された言語を使用し、指定がない場合はユーザーの直近の実質的なメッセージの言語を使用します。ユーザー向けの文章、見出し、ラベル、ステータス、結論、警告、制限事項、次のアクションはすべてローカライズします。この Skill のセクション名は意味上の指針として扱い、意図しない言語の混在を取り除きます。
• コード、コマンド、生の ID、イベント名・プロパティ名・指標名、Feature キー、SDK/API 名、翻訳すると技術的な意味が変わる公式の列挙値は変更しません。
• 最初に判断ステータスを示します。
• 固定の番号付きテンプレートではなく、状況に応じたレポートを作成します。ユーザー向けの標準的な階層は、結論、主要な影響、実験の判断、プロダクトの最適化または次のアクションの順に構成します。
• データの信頼性、主要指標、注目すべき指標は、主要な影響セクションに含めます。
  • データ信頼性の検証：診断チェックリストを要約し、全体の結果を「信頼できる」「限定的」「信頼できない」のいずれかで示します。問題のないチェックは簡潔にまとめ、警告、失敗、未検証のチェックのみ詳しく説明します。
  • 主要指標：主指標の対照群と処置群の値、絶対効果と相対効果、区間と p 値、MDE またはビジネス上のしきい値との関係、ビジネス上の意味を示します。信頼性の評価が裏付ける場合に限り、因果関係を示す表現を使用します。
  • 注目指標：判断に影響する、メカニズムを説明する、または重大なリスクを明らかにする場合に限り、副次指標や診断指標を示します。事後的に選んだ指標を成功基準に格上げしないでください。
• 簡潔な回答では、これらの小見出しを「主要な影響」の下の簡潔な段落にまとめ、無関係なトップレベルのセクションに分けません。
• material blockers、trust blockers、診断の深刻度名、Gate 1 や Gate 2 などのフレームワークラベルは、内部分類として扱います。レポートの見出しとして提示したり、ローカライズした見出しの後に英語表記を付けたりしないでください。必要に応じて、「データ信頼性の検証」や「現時点で結論を出せない理由」など、自然なユーザー向け表現を使用します。
• 指標の傾向と指標に関連するセグメントは、該当する主要指標または注目指標の下に配置します。より広い背景、原因の診断、前提、制限事項は、解釈に重大な影響を与える場合に限り追加します。
• 信頼できる根拠が具体的なプロダクト変更を支持する場合に限り、プロダクト最適化のセクションを設けます。それ以外の場合は、次の検証または次のアクションのセクションを使用します。
• 依頼と根拠に裏付けられた内容のみを含めます。以前のレポートにあったという理由だけでセクションを追加しないでください。
• プラットフォーム上の観測結果、決定論的な計算、推定した原因を区別します。不確実性と根拠の不足を明示します。
• 説明のない生の表を返さないでください。

失敗時の動作

• プロジェクトまたは実験が曖昧な場合：候補を提示して確認を求め、推測しないでください。
• レポート機能が不足している場合：ae-cli の不足を明記し、必要なフィールドを含むプラットフォームのエクスポートを依頼します。
• 権限エラーが発生した場合：依存するクエリを停止し、不足している権限を報告します。
• レポートの取得に成功したものの内容が空の場合：該当するデータがないと伝え、転送エラーとして扱わないでください。
• 一部のみ成功した場合：利用可能な根拠を使用し、失敗した項目を列挙します。
• データソース間で矛盾がある場合：データ品質の診断には割り当て・露出の生データを優先し、食い違いを説明します。