/validate-data - 分析を共有する前に検証する

不慣れなプレースホルダーがある場合や接続されているツールを確認する必要がある場合は、CONNECTORS.md を参照してください。

分析を共有する前に、正確性、方法論、および潜在的なバイアスについてレビューします。信頼性評価と改善提案を生成します。

使用方法

/validate-data <analysis to review>

分析は以下のいずれでも構いません：

• 会話内のドキュメントまたはレポート
• ファイル (markdown、notebook、spreadsheet)
• SQL クエリとその結果
• グラフとその基になるデータ
• 方法論と結果の説明

ワークフロー

1. 方法論と仮定をレビューする

以下を検証します：

• 質問のフレーミング: 分析は正しい質問に答えているか？質問は異なる方法で解釈される可能性があるか？
• データ選択: 正しいテーブル/データセットが使用されているか？時間範囲は適切か？
• 母集団の定義: 分析母集団は正しく定義されているか？意図しない除外がないか？
• メトリクス定義: メトリクスは明確かつ一貫して定義されているか？ステークホルダーの理解と一致しているか？
• ベースラインと比較: 比較は公正か？時間期間、コホートサイズ、および背景は比較可能か？

2. 配信前 QA チェックリストを実行する

以下のチェックリストを進めます — データ品質、計算、妥当性、およびプレゼンテーション確認。

3. 一般的な分析上の落とし穴をチェックする

以下の詳細なピットフォール カタログに対して体系的にレビューします (結合による爆発、サバイバーシップバイアス、不完全な期間比較、分母の変化、平均の平均、タイムゾーン不一致、選択バイアス)。

4. 計算と集約を検証する

可能な場合、スポットチェックします：

• 主要な数字をいくつか独立して再計算
• 小計が合計に合計されることを確認
• パーセンテージが予期される場所で 100% に合計されることを確認
• YoY/MoM 比較が正しいベース期間を使用していることを確認
• すべてのメトリクス全体でフィルタが一貫して適用されていることを検証

以下の結果の妥当性チェック手法を適用します (数値の大きさチェック、相互検証、赤旗検出)。

5. ビジュアライゼーションを評価する

分析にグラフが含まれている場合：

• 軸は適切な値で開始しているか (棒グラフの場合ゼロ)？
• 比較グラフ全体でスケールは一貫しているか？
• グラフのタイトルは表示されている内容を正確に説明しているか？
• ビジュアライゼーションは素早い読者を誤解させる可能性があるか？
• 切り詰められた軸、不一貫な間隔、または認識を歪ませる 3D 効果があるか？

6. ナレーティブと結論を評価する

以下かどうかをレビューします：

• 結論は表示されたデータによって裏付けられているか
• 代替説明が認識されているか
• 不確実性が適切に伝えられているか
• 推奨事項は調査結果から論理的に従っているか
• 信頼レベルが証拠の強度と一致しているか

7. 改善を提案する

具体的で実行可能な提案を提供します：

• 結論を強化する追加分析
• 注記する必要がある注意事項または制限事項
• 主要なポイントのより良いビジュアライゼーションまたはフレーミング
• ステークホルダーが望むであろう欠けているコンテキスト

8. 信頼性評価を生成する

分析を 3 段階スケールで評価します：

共有可能 -- 分析は方法論的に健全で、計算が検証され、注意事項が記載されている。改善のための小さな提案がありますが、ブロッキング要因はありません。

注意事項を添えて共有 -- 分析は大部分が正しいですが、ステークホルダーに伝える必要がある特定の制限事項または仮定があります。必要な注意事項を列挙してください。

改定が必要 -- 共有する前に対処する必要がある特定のエラー、方法論の問題、または欠落した分析が見つかった。優先順位順に必要な変更を列挙してください。

出力形式

## Validation Report

### Overall Assessment: [Ready to share | Share with caveats | Needs revision]

### Methodology Review
[Findings about approach, data selection, definitions]

### Issues Found
1. [Severity: High/Medium/Low] [Issue description and impact]
2. ...

### Calculation Spot-Checks
- [Metric]: [Verified / Discrepancy found]
- ...

### Visualization Review
[Any issues with charts or visual presentation]

### Suggested Improvements
1. [Improvement and why it matters]
2. ...

### Required Caveats for Stakeholders
- [Caveat that must be communicated]
- ...

---

配信前 QA チェックリスト

ステークホルダーと分析を共有する前に、このチェックリストを実行します。

データ品質チェック

• ソース検証: どのテーブル/データソースが使用されたかを確認した。これはこの質問に適切なものか？
• 鮮度: データは分析に十分に最新である。「～現在」の日付が記載されている。
• 完全性: 時系列に予期しないギャップや欠落セグメントがない。
• Null 処理: 主要列の Null レートをチェックした。Null は適切に処理されている (除外、補完、またはフラグ)。
• 重複排除: 不正な結合または重複ソース レコードからのダブルカウントがないことを確認した。
• フィルタ検証: すべての WHERE 句とフィルタが正しい。意図しない除外がない。

計算チェック

• 集約ロジック: GROUP BY はすべての非集約列を含む。集約レベルは分析の粒度と一致する。
• 分母の正確性: レートとパーセンテージ計算は正しい分母を使用する。分母はゼロ以外である。
• 日付の位置合わせ: 比較は同じ時間期間の長さを使用する。部分期間は除外または記載されている。
• 結合の正確性: JOIN タイプは適切である (INNER vs LEFT)。多対多結合は数を水増ししていない。
• メトリクス定義: メトリクスはステークホルダーがそれらをどのように定義するかと一致する。偏差は記載されている。
• 小計の合計: 予想される場合、部分は全体に合計される。合計されない場合、理由を説明 (例：重複)。

妥当性チェック

• 大きさ: 数値は妥当な範囲にある。収益は負ではない。パーセンテージは 0-100% である。
• トレンド連続性: 時系列に説明のないジャンプまたは低下がない。
• 相互参照: 主要な数値は他の既知ソース (ダッシュボード、前のレポート、財務データ) と一致する。
• 桁数: 合計収益は適切な範囲にある。ユーザー数は既知の数値と一致する。
• エッジケース: 境界での動作は？ 空のセグメント、ゼロアクティビティ期間、新しいエンティティ。

プレゼンテーションチェック

• グラフの正確性: 棒グラフはゼロで開始する。軸にラベルが付いている。パネル全体でスケールが一貫している。
• 数値フォーマット: 適切な精度。一貫した通貨/パーセンテージ形式。必要に応じて千の位区切り。
• タイトルの明確性: タイトルはメトリクスだけでなく、インサイトを述べている。日付範囲が指定されている。
• 注意事項の透明性: 既知の制限事項と仮定が明示的に述べられている。
• 再現性: 提供されたドキュメンテーションからこの分析を再作成できる。

一般的なデータ分析上の落とし穴

結合による爆発

問題: 多対多結合が行を無言で乗算し、カウントと合計を水増しする。

検出方法:

-- 結合の前後で行数を確認
SELECT COUNT(*) FROM table_a;  -- 1,000
SELECT COUNT(*) FROM table_a a JOIN table_b b ON a.id = b.a_id;  -- 3,500 (問題)

予防方法:

• 結合後は常に行数をチェック
• カウントが増加した場合、結合関係を調査 (本当に 1:1 または 1:many か？)
• 結合を通じてエンティティをカウントするときは COUNT(*) の代わりに COUNT(DISTINCT a.id) を使用

サバイバーシップバイアス

問題: 削除、チャーン、または失敗したエンティティを無視して、今日存在するエンティティのみを分析する。

例:

• 「現在のユーザー」のユーザー行動を分析するとチャーンしたユーザーを見落とす
• 「当社製品を使用している企業」を見ることで、評価して去った企業は無視される
• 「成功した」結果のプロパティを研究するが「成功していない」結果がない

予防方法: 結論を引き出す前に「このデータセットに含まれていない人は誰か？」と尋ねる。

不完全な期間比較

問題: 部分期間を完全期間と比較する。

例:

• 「1月の収益は $500K vs 12月の $800K」 -- しかし1月はまだ終わっていない
• 「今週のサインアップは減少している」 -- 水曜日にチェックし、完全な前週と比較

予防方法: 常に完全な期間にフィルタするか、同じ日付/同じ日数を比較する。

分母の変化

問題: 分母が期間間で変わり、レートが比較不可能になる。

例:

• 「適格」ユーザーの数え方を変更したため、コンバージョン率が向上した
• 「アクティブ」の定義が更新されたため、チャーン率が変わった

予防方法: 比較されたすべての期間で一貫した定義を使用。定義の変更を記載。

平均の平均

問題: グループサイズが異なる場合、事前計算された平均を平均すると間違った結果が得られる。

例:

• グループ A: 100 ユーザー、平均収益 $50
• グループ B: 10 ユーザー、平均収益 $200
• 間違い: 平均の平均 = ($50 + $200) / 2 = $125
• 正解: 加重平均 = (100*$50 + 10*$200) / 110 = $63.64

予防方法: 常に生データから集約。事前集約された平均を決して平均しない。

タイムゾーン不一致

問題: 異なるデータソースが異なるタイムゾーンを使用し、位置合わせずれが発生する。

例:

• イベント タイムスタンプは UTC、ユーザー向け日付はローカル時間
• 異なるカットオフ時間を使用する毎日のロールアップ

予防方法: 分析前にすべてのタイムスタンプを単一のタイムゾーン (UTC 推奨) に標準化。使用されたタイムゾーンを文書化。

セグメンテーションにおける選択バイアス

問題: セグメントは測定している結果によって定義され、循環論理が作成される。

例:

• 「オンボーディングを完了したユーザーはリテンション率が高い」 -- 明らかに、自己選別された
• 「パワーユーザーはより多くの収益を生成する」 -- 彼らは収益を生成することによってパワーユーザーになった

予防方法: 結果ではなく、治療前の特性に基づいてセグメントを定義。

その他の統計的罠

• シンプソンのパラドックス: データが集約対セグメント化のときにトレンドが逆転する
• 相関が因果関係として提示される (裏付ける証拠なし)
• 小規模なサンプルサイズ により信頼できない結論につながる
• 外れ値が平均に過度に影響 (代わりに中央値を使用すべきか？)
• 複数のテスト/チェリーピック 有意な結果
• 先見バイアス: 過去のイベントを説明するために将来の情報を使用
• チェリーピックされた時間範囲 特定のナレーティブを支持する

結果の妥当性チェック

大きさのチェック

分析内の主要な数値について、それが「におい テスト」に合格することを確認します：

メトリクスタイプ	妥当性チェック
ユーザー数	これは既知の MAU/DAU 数値と一致するか？
収益	これは既知の ARR と比べて適切な桁数か？
コンバージョン率	これは 0% ～ 100% の間か？ ダッシュボード数値と一致するか？
成長率	50%+ MoM 成長は現実的か、またはデータの問題があるか？
平均	分布について知っていることを考えると、平均は合理的か？
パーセンテージ	セグメント パーセンテージの合計は ~100% か？

相互検証手法

1. 同じメトリクスを 2 つの異なる方法で計算 し、一致することを確認
2. 個別レコードをスポットチェック -- 特定の実体をいくつか選び、手動でデータをトレース
3. 既知のベンチマークと比較 -- 公開されたダッシュボード、財務レポート、または前の分析と一致
4. 逆エンジニアリング -- 総収益が X の場合、ユーザー当たりの収益 × ユーザー数はおおよそ X に等しいか？
5. 境界チェック -- 1 日、1 ユーザー、または 1 カテゴリにフィルタするとどうなる？ これらのマイクロ結果は合理的か？

調査が必要な赤旗

• 明らかな原因なしに期間比較で 50% 以上変更されたメトリクス
• 正確な丸い数値のカウントまたは合計 (フィルタまたはデフォルト値の問題を示唆)
• 正確に 0% または 100% のレート (不完全なデータを示す場合があります)
• 仮説を完璧に確認する結果 (現実は通常、より複雑)
• 時間期間またはセグメント全体で同じ値 (クエリが次元を無視していることを示唆)

再現性のためのドキュメンテーション標準

分析ドキュメンテーション テンプレート

すべての重要な分析には以下を含める必要があります：

## Analysis: [Title]

### Question
[The specific question being answered]

### Data Sources
- Table: [schema.table_name] (as of [date])
- Table: [schema.other_table] (as of [date])
- File: [filename] (source: [where it came from])

### Definitions
- [Metric A]: [Exactly how it's calculated]
- [Segment X]: [Exactly how membership is determined]
- [Time period]: [Start date] to [end date], [timezone]

### Methodology
1. [Step 1 of the analysis approach]
2. [Step 2]
3. [Step 3]

### Assumptions and Limitations
- [Assumption 1 and why it's reasonable]
- [Limitation 1 and its potential impact on conclusions]

### Key Findings
1. [Finding 1 with supporting evidence]
2. [Finding 2 with supporting evidence]

### SQL Queries
[All queries used, with comments]

### Caveats
- [Things the reader should know before acting on this]

コード ドキュメンテーション

再利用される可能性があるコード (SQL、Python) については：

"""
Analysis: Monthly Cohort Retention
Author: [Name]
Date: [Date]
Data Source: events table, users table
Last Validated: [Date] -- results matched dashboard within 2%

Purpose:
    Calculate monthly user retention cohorts based on first activity date.

Assumptions:
    - "Active" means at least one event in the month
    - Excludes test/internal accounts (user_type != 'internal')
    - Uses UTC dates throughout

Output:
    Cohort retention matrix with cohort_month rows and months_since_signup columns.
    Values are retention rates (0-100%).
"""

分析のバージョン管理

• クエリとコードをバージョン管理 (git) または共有ドキュメント システムに保存
• 使用されたデータスナップショットの日付を記載
• 更新されたデータで分析を再実行する場合は、何が変わったか、なぜかを文書化
• 繰り返しの分析の前のバージョンへのリンク トレンド比較用

例

/validate-data Review this quarterly revenue analysis before I send it to the exec team: [analysis]

/validate-data Check my churn analysis -- I'm comparing Q4 churn rates to Q3 but Q4 has a shorter measurement window

/validate-data Here's a SQL query and its results for our conversion funnel. Does the logic look right? [query + results]

ヒント

• 高リスクなプレゼンテーションまたは決定の前に /validate-data を実行
• 簡単な分析であっても妥当性チェックから利益を得られます -- 1 分で実施でき、信頼性を保つことができます
• 検証がイシューを検出した場合、それを修正して再検証する
• 検証出力を分析と一緒に共有し、ステークホルダーの信頼を構築