Analytics kpi

データ分析・KPI設計

目的

プロダクトが届けている価値を数値で把握し、意思決定の質を上げる。 計測設計・実装・ダッシュボード・A/Bテストを一気通貫でカバーする。

使うタイミング

• 新機能リリース前に「何を計測すべきか」を整理したい
• KPIが多すぎて何を見ればいいか分からない
• 「使われているか分からない」まま開発が続いている
• A/Bテストを始めたいが設計方法が不明
• データはあるが意思決定に活かせていない

進め方

1. 北極星指標(NSM)を1つ決める プロダクトがユーザーに届けている核心的価値を最もよく表す指標を1つ選ぶ。 売上・収益は遅行指標なので北極星には使わない。 例: 週次アクティブ作成者数(創作ツール)、週次学習完了セッション数(EdTech)

2. KPIツリーを構築する 北極星を構成要素に分解し、施策との紐付けを可視化する。 例: WAU = 新規ユーザー数 × 活性化率 + 既存ユーザー数 × 継続率 各施策が「どの枝を動かすか」を明示する。

3. AARRRファネルと対応させる [[growth-launch]] のAARRRファネルと照合し、どのステージに注力するかを決める。 ファネル分析で離脱ポイントを特定し、リテンションカーブでプロダクトの健全性を把握する。

4. イベント設計を先に行う 実装前に計測計画書(後述テンプレート参照)を作成する。 命名規約・プロパティ・発火タイミングを合意してから開発に入る。

5. 実装をリリースと同時に行う 後付けすると初期データが永遠に欠ける。 発火検証をテストに含め([[testing]])、QAで計測の正確性を担保する。

6. ダッシュボードを「意思決定が変わる枚数」に絞る バニティメトリクス(累計登録数・累計PVなど必ず増える数字)は外す。 週次レビューで「このデータを見て何をするか」を言えないチャートは削除する。

7. A/Bテストを設計・判定する 仮説→サンプルサイズと期間の事前設定→実行→判定の順に進める。 トラフィックが不足する場合は無理せず定性調査([[ux-research]])で代替する。

8. プライバシーを確認する 同意管理を実装し、PII(メールアドレス・氏名等)をイベントプロパティに含めない。 [[legal-compliance]] および [[security]] のチェックを通す。

設計の要点

KPI設計

• 北極星指標は「ユーザーが価値を受け取った瞬間」を捉える指標を選ぶ
• KPIは少数精鋭。チームが毎週暗記できる数(5つ以下)に絞る
• 先行指標(Leading)と遅行指標(Lagging)を意識して混在させる
• コホート分析でセグメント別のリテンションカーブを描き、製品の健全性を評価する

イベント設計

• 命名規約は object_action 形式で統一する 例: content_created、onboarding_completed、payment_initiated
• プロパティはフィルタ・集計に必要なものだけ定義する。「とりあえず全部」は分析時に使えないデータの山になる
• 1イベントに複数の意味を持たせない。button_clicked にtype属性を詰め込まず、signup_button_clicked のように意味を名前に含める
• スキーマ変更はバージョン管理し、旧プロパティを消す際は移行期間を設ける

A/Bテスト

• 仮説: 「この変更で指標Xが Y% 向上する」と定量化して書く
• 事前にサンプルサイズ計算(検出力80%以上、有意水準5%)と期間を決める
• 期間途中で結果を見て止めない(p-hacking)。判定日を守る
• 複数バリアントを同時に走らせる場合はボンフェローニ補正を適用する
• MAU/DAUが少ない初期プロダクトはA/Bテストに必要なサンプルが集まらない。定性調査で仮説検証を優先する

成果物テンプレート

# 計測計画書

## 北極星指標
- 指標名:
- 定義(分子/分母):
- 計測ツール・テーブル名:
- 現在値 / 目標値 / 期限:

## KPIツリー
北極星指標
├── 新規貢献
│   ├── 新規登録数
│   └── 活性化率(初回コア体験完了率)
└── 継続貢献
    ├── WAUリテンション率
    └── 機能別エンゲージメント率

## イベント定義表

| イベント名           | 発火タイミング             | 主要プロパティ                        | 関連KPI         |
|----------------------|----------------------------|---------------------------------------|-----------------|
| content_created      | 投稿ボタン押下・保存完了時 | content_type, char_count, is_first    | 北極星(WAC)     |
| onboarding_completed | チュートリアル最終ステップ | duration_sec, steps_skipped           | 活性化率        |
| session_started      | アプリフォアグラウンド移行 | platform, is_returning                | DAU/WAU         |
| payment_initiated    | 決済フロー開始             | plan_id, source_screen                | 収益(遅行)      |

## ダッシュボード構成

| チャート名             | 指標                    | 更新頻度 | 意思決定例                   |
|------------------------|-------------------------|----------|------------------------------|
| 週次NSMトレンド         | WAC(週次アクティブ作成) | 週次     | 施策の効果判定               |
| AARRRファネル           | 各ステージ転換率         | 週次     | 優先施策ステージの特定       |
| コホート別リテンション  | N週リテンション率        | 月次     | プロダクト改善の優先順位     |
| A/Bテスト進捗           | 各バリアント指標         | 日次     | テスト終了・判定判断         |

## レビュー周期
- 日次: アラート確認(異常値・計測断絶)
- 週次: NSM・ファネル・進行中A/Bテスト
- 月次: コホート分析・KPIツリー全体レビュー・指標の見直し

チェックリスト

• 北極星指標が1つ決まっており、チーム全員が説明できる
• KPIツリーで北極星の構成要素が分解されている
• 各施策がKPIツリーのどの枝を動かすか明示されている
• イベント命名規約が文書化されている
• 計測計画書がリリース前にレビューされている
• 発火検証がテストスイートに含まれている
• PIIをイベントプロパティに含めていない
• ダッシュボードのチャートごとに「何を意思決定するか」が書かれている
• A/Bテストのサンプルサイズと期間が事前に計算されている
• バニティメトリクスがメインダッシュボードから除外されている

アンチパターン

• 計測なしリリース: 「使われているか分からない」状態で開発が続く。リリースと同時に計測を実装する
• バニティ指標での自己満足: 累計登録者数・累計PVは必ず増える。活性化率・リテンション率など割り算の指標を重視する
• p-hacking: 有意差が出るまでA/Bテストを延長する行為。判定日を事前に設定し守る
• イベント名のバラバラ命名: ButtonClick、button_click、btn_clicked が混在して集計不能になる。命名規約を先に決める
• データを見るだけで動かない: ダッシュボードを眺めるだけで施策に繋げない。毎回「このデータで何をするか」をアジェンダに含める
• 計測の後付け: 初期データが欠けるだけでなく、「今さら直せない」技術的負債になる
• 過剰なイベント定義: 「とりあえず全部計測」はノイズが多くて使えないデータの山になる。計測目的から逆算して設計する

モデル委譲ガイド

共通原則は [[orchestration]] を参照。

役割	担当タスク
司令塔(メインモデル)	北極星指標の選定・KPIツリーの構造判断・計測計画書の最終レビュー・施策とKPIの紐付け確認
Opus相当	A/Bテスト設計のレビュー・統計的解釈(サンプルサイズ計算・有意水準・検出力)・コホート分析の解釈
Sonnet相当	イベント定義表の作成・計測実装コードの生成・ダッシュボード構築・計測計画書ドラフト作成
Haiku相当	既存計測の棚卸し(現在のイベント一覧抽出・命名揺れの検出)・プロパティ一覧の整理

関連スキル

• [[orchestration]] - マルチモデル連携の共通原則
• [[growth-launch]] - AARRRファネル・グロース施策との接続
• [[ux-research]] - 定量計測を補完する定性調査
• [[testing]] - 計測実装の発火検証をテストに含める方法
• [[legal-compliance]] - 同意管理・プライバシー法令対応
• [[security]] - PIIの取り扱い・データセキュリティ
• [[mvp-development]] - MVP段階での最小限の計測設計
• [[requirements-definition]] - KPIを要件定義と連携させる
• [[monitoring-operations]] - 本番環境での計測監視・アラート設定
• [[database-design]] - 分析用データモデルの設計