analysis-qa

レビューチェックリスト

関係者に調査結果を提示する前に、以下の各セクションをすべて確認してください。

データ基盤

• 適切なデータソース：この問いに適したテーブルとデータセットを使用していることを確認しました
• 最新性：データの鮮度が十分であり、「データの基準日」を明記しています
• 網羅性：データセットに予期しない期間の欠落やセグメントの不足がありません
• NULL の処理：重要な列の NULL 率を確認し、NULL を除外、補完、または明示的に記録しています
• 重複の管理：行数を確認し、不適切な JOIN やソースレコードの重複による二重計上がないことを確認しました
• フィルターの正確性：すべての WHERE 句とフィルター条件を検証し、誤って除外または追加されたデータがないことを確認しました

計算の整合性

• GROUP BY の正確性：集計されていない列がすべて GROUP BY に含まれており、集計粒度が分析上の問いに合致しています
• 分母の妥当性：率やパーセンテージに意図した母集団を使用し、ゼロ除算を防いでいます
• 期間の整合性：比較対象の期間が同じ長さであり、期間の一部だけを含む場合は除外するか、その旨を明記しています
• JOIN の挙動：JOIN の種類（INNER と LEFT）が意図的に選択されており、多対多の関係によって合計が気づかないうちに膨らんでいません
• 指標の忠実性：計算した指標がビジネス上の定義に合致しており、相違点があれば記録しています
• 加算の整合性：小計が想定どおり報告合計に一致しており、加算できないケース（重複、二重計上）は説明しています

妥当性の評価

• 桁の妥当性：主要な数値が信頼できる範囲内にあり、売上が負の値ではなく、パーセンテージが 0～100％の範囲内です
• 傾向の一貫性：時系列に説明のつかない急増や急減がありません
• 外部データとの一致：主要な数値がダッシュボード、財務レポート、または過去の分析と一致しています
• 概算の妥当性：総売上がおおむねユーザーあたり売上とユーザー数の積になるなど、概算が合っています
• 境界条件での挙動：1 日、1 ユーザー、1 カテゴリなどのエッジケースでも結果に無理がありません

提示資料の品質

• 正確な可視化：棒グラフの軸が 0 から始まり、軸にラベルが付いており、パネル間でスケールが統一されています
• 明瞭な書式：数値の精度、通貨・パーセンテージ表記、桁区切りが適切かつ一貫しています
• 内容を示すタイトル：見出しが単なる指標名ではなく、示唆する内容を伝えており、日付範囲も含まれています
• 制約の明示：制約と前提条件を冒頭で明示しています
• 再現性：別のアナリストが提供されたドキュメントをもとに、分析を再現できます

よくある間違いを見つける

多対多 JOIN による件数の水増し

問題点：多対多の関係にある 2 つのテーブルを JOIN すると、行が気づかないうちに増殖し、件数や合計が膨らみます。

検出方法：

-- Compare row counts before and after the join
SELECT COUNT(*) FROM orders;          -- 1,000
SELECT COUNT(*) FROM orders o
JOIN line_items li ON o.id = li.order_id;  -- 3,500 (unexpected inflation)

防止策：

• JOIN 前後の行数を必ず比較する
• JOIN の関係の実際の多重度を確認する
• 複数行にまたがる JOIN でエンティティを正確に数えるには、COUNT(DISTINCT o.id) を使用する

生存者バイアス

問題点：分析が現在も存在するエンティティのみを対象とし、削除されたもの、離脱したもの、失敗したものを無視しています。

よくある例：

• 離脱した人を無視して、「アクティブユーザー」の行動を調べる
• 評価した後に利用を見送った企業を除外して、「自社プラットフォームを利用している企業」と比較する
• 「成功した」事例の特徴を、「失敗した」事例との比較なしに分析する

防止策：結論を導く前に、「このデータセットに含まれていないのは誰か、その人たちが含まれていたら結論は変わるだろうか」と問いかけてください。

不完全な期間の比較

問題点：進行中の月、週、四半期を、終了済みの期間と比較してしまいます。

典型的なシナリオ：

• 1月がまだ半分しか経過していないのに、「1月の売上は50万ドルで、12月の80万ドルを下回っています」とする
• 火曜日に前週全体と比較して、「今週は登録数が減っています」とする

防止策：終了済みの期間のみを比較するか、経過日数をそろえて正規化します。

分母の変化

問題点：分母として使われる母集団が期間ごとに変化し、率の比較が無効になります。

典型的なシナリオ：

• 「対象となる訪問者」の定義が狭められたため、コンバージョン率が改善したように見える
• 分析の途中で「アクティブユーザー」の定義が変更されたため、解約率が変動する

防止策：比較するすべての期間で一貫した定義を固定します。定義の変更があれば明示します。

事前に計算された平均の平均

問題点：グループごとの平均値を平均すると、グループの規模の違いが無視され、全体の値が不正確になります。

例：

• セグメント A：顧客100人、平均注文額50ドル
• セグメント B：顧客10人、平均注文額200ドル
• 誤った全体平均：（50ドル + 200ドル）/ 2 = 125ドル
• 正しい加重平均：（100 * 50ドル + 10 * 200ドル）/ 110 = 63.64ドル

防止策：平均は必ず個々のレコードから計算します。集計済みの平均値をさらに平均してはいけません。

タイムゾーンの不整合

問題点：ソースシステムによって異なるタイムゾーンでタイムスタンプが記録されるため、日次集計のずれや結合時の不一致が生じます。

典型的なシナリオ：

• バックエンドのイベントは UTC で記録されている一方、レポートレイヤーは米国太平洋時間を使用している
• 2つのテーブルで「今日」の締め時刻が異なる

防止策：分析の前に、すべてのタイムスタンプを単一の基準タイムゾーン（最も安全な既定値は UTC）に変換します。成果物にはタイムゾーンを明記します。

循環的なセグメンテーション

問題点：測定対象そのものを使ってセグメントを定義するため、同語反復的な結果になります。

典型的なシナリオ：

• 「オンボーディングを完了したユーザーは定着率が高い」——オンボーディングの完了自体が、定着を示す指標です
• 「パワーユーザーはより多くの収益を生み出す」——収益を生み出すことが、パワーユーザーと見なされる理由です

防止策：セグメントの定義には、結果の期間より前に測定された特性を使い、結果そのものは使いません。

結果の妥当性チェック

大まかな値のクイックテスト

指標の分類	検証方法
ユーザー数	既知の DAU／MAU ベンチマークと照合する
総売上高	既知の ARR または直近の財務レポートと比較する
コンバージョン率	0〜100%の範囲内であることを確認し、ダッシュボードの基準値と比較する
成長率	月次成長率が50%以上というのは現実的か、それともデータの問題を示しているか
平均値	分布を考慮して、この数値は妥当か
セグメントの構成比	パーセンテージの内訳の合計がおよそ100%になるか

相互検証の方法

1. 二重計算：同じ指標を独立した2つのクエリ経路から算出し、一致することを確認する
2. レコードレベルの抜き取り確認：特定のエンティティをいくつか選び、その数値を最初から最後まで手作業で追跡する
3. ベンチマークとの比較：公開済みのダッシュボード、財務システム、または過去の分析結果と照合する
4. 算術による逆算：総売上高が X でユーザー数が N の場合、X / N は報告されたユーザーあたりの数値とおおむね一致するか
5. 細分化テスト：1日、1ユーザー、または1カテゴリに絞り込み、細分化した結果が妥当であることを確認する

調査が必要な兆候

• 明確な説明がないまま、期間ごとに50％を超えて変動する指標
• 不自然なほど切りのよい数値になる合計値や総和（フィルターやデフォルト値によるアーティファクトの可能性）
• ちょうど0％または100％に固定された率（完璧な結果ではなく、データ欠損を示している可能性があります）
• 仮説にあまりにも都合よく合致する結果（実データはほとんどの場合、複雑です）
• 異なる期間やセグメントで同じ値が現れる（ディメンションが無視されていることを示唆します）

再現性の確保

分析レポートのテンプレート

重要な分析には、以下のドキュメントを必ず添付してください。

## Analysis: [Title]

### Business Question
[The precise question this work answers]

### Sources
- Table: [schema.table_name] (snapshot date: [date])
- Table: [schema.other_table] (snapshot date: [date])
- External file: [filename] (origin: [description])

### Metric and Segment Definitions
- [Metric A]: [Precise calculation formula]
- [Segment X]: [Exact inclusion/exclusion criteria]
- [Time window]: [Start] through [end], [timezone]

### Analytical Approach
1. [First step and its purpose]
2. [Second step]
3. [Third step]

### Assumptions and Known Limitations
- [Assumption and why it holds]
- [Limitation and its potential effect on conclusions]

### Results
1. [Finding with supporting evidence]
2. [Finding with supporting evidence]

### Queries
[All SQL and code used, annotated with comments]

### Warnings for the Reader
- [Anything the audience should weigh before acting on these results]

分析コードへの注釈

他の人が再利用する可能性のあるSQLやPythonには、以下を適用してください。

"""
Title: Monthly Cohort Retention
Author: [Name]
Created: [Date]
Sources: events, users
Last cross-checked: [Date] — matched dashboard within 2%

Objective:
    Build monthly retention cohorts anchored on each user's first event date.

Assumptions:
    - "Active" = at least one recorded event in the calendar month
    - Internal and test accounts excluded (user_type != 'internal')
    - All timestamps normalized to UTC

Output:
    Retention grid: rows are cohort months, columns are months since first event.
    Cell values are retention percentages (0-100).
"""

監査証跡の維持

• すべてのクエリとスクリプトを、バージョン管理または共有ナレッジベースに保存します
• 各分析の実行に使用したデータのスナップショットの日付を正確に記録します
• 定期的に実行する分析を更新する際は、何を変更したのか、またその理由を記録します
• 現在の結果を以前のバージョンにリンクし、分析自体の傾向を追跡できるようにします