プロダクトアナリティクス

「何を計測するか」を先に設計する。全部のクリックを記録するのではなく、意味のあるイベントに絞る。

必須イベント:

• アカウント関連: サインアップ、ログイン、プロフィール設定
• コアアクション: プロダクトの中核的な操作（メッセージ送信、ファイルアップロード等）
• コンバージョン: 有料転換、プラン変更、アップグレード
• エンゲージメント: セッション開始・終了、機能ごとの利用

イベント設計のルール:

• 各イベントに**プロパティ（属性）**を付ける（例: 「ファイルアップロード」→ ファイル種別、サイズ）
• 命名規則を統一する（例: action_object形式 → upload_file, send_message）
• イベントスプレッドシートを作成し、チーム全体で管理する

ツール: Amplitude、Mixpanel、PostHog等。

毎日見るべきコアダッシュボードを作成する。

必須ダッシュボード項目:

• DAU / WAU / MAU: アクティブユーザー数の推移
• リテンションカーブ: コホート別の継続率
• コアアクション実行率: プロダクトの核となる操作をした人の割合
• ファネル: サインアップ → アクティベーション → 有料転換の転換率
• 機能別利用率: どの機能が使われていてどの機能が放置されているか

ダッシュボードのコツ:

• 指標は10個以内に絞る。多すぎると何も見なくなる
• 「上がると良い指標」と「下がると良い指標」を色分けする
• 週次レビューの習慣をつける（月曜朝に15分チームで確認等）

ダッシュボードで異変に気づいたら、深掘り分析で原因を特定する。

代表的な分析手法:

• ファネル分析: 各ステップの転換率と離脱ポイントを特定
• コホート分析: ユーザーグループ別のリテンションを比較
• セグメント分析: プラン別、流入元別、デバイス別に行動を比較
• パス分析: ユーザーがプロダクト内でどの順番で機能を使っているか
• 相関分析: 「この行動をしたユーザーはリテンションが高い」を特定

分析のフレームワーク:

1. 観察: ダッシュボードで異常値を発見（「先週からDay 7リテンションが5%下がった」）
2. 仮説: なぜそうなったか仮説を立てる（「新しいオンボーディングフローが悪影響？」）
3. 検証: セグメントを切って比較（新フロー経験者 vs 旧フロー経験者のリテンション）
4. 行動: 検証結果に基づいてアクションを決める

分析ツールを導入しただけではデータドリブンにはならない。文化として定着させる。

実践方法:

• 機能リリース時に必ず成功指標を定義 — 「この機能の成功 = 利用率30%以上」
• リリース2週間後に振り返り — 実際の数値を確認し、期待とのギャップを分析
• 全員がダッシュボードにアクセスできる — PMだけでなくエンジニア・デザイナーも
• 「データで語る」を会議のルールに — 「ユーザーはこう思うはず」ではなく「データによると◯%のユーザーが〜」

注意: データは万能ではない。「なぜ」は定量データだけではわからない。定性調査（インタビュー）とセットで使う。