analytics-strategy

アナリティクス戦略

ダッシュボードを作るだけでなく、意思決定につながる測定フレームワークを設計します。特定の技術スタックやツールに依存しません。

このスキルは測定計画の策定に使用します。コンバージョン最適化には cro-optimization を使用してください。SEO測定に特化した場合は、seo-onpage と関連するSEOスキルを使用してください。

---

使用する場面

• 新しいプロダクトやサイトでアナリティクスを設定する
• 既存のアナリティクス設定を監査する
• チームやビジネス向けのダッシュボードを設計する
• KPIとノーススターメトリックを定義する
• プロダクトアナリティクスのイベント分類体系を構築する
• マーケティングのアトリビューションモデルを設計する
• ビジネス上の問いを測定計画に落とし込む

使用しない場面

• コンバージョンテストや最適化（cro-optimization を使用してください）
• SEOパフォーマンスの測定（SEOスキルを使用してください）
• 純粋なデータインフラストラクチャに関する意思決定（別の領域です）

---

必要な入力

• ビジネスまたはプロダクトの背景（成功とはどのような状態か）
• アナリティクスの対象者（誰が、どのような意思決定をする必要があるか）
• 現在の測定状況（既存のツール、トラッキング、ギャップ）
• チームが答える必要のある問い

---

フレームワーク：4つのレイヤー

完全な測定戦略では、4つすべてのレイヤーを網羅します。各レイヤーの内容は次のレイヤーにつながります。

1. ノーススターとKPIの階層

最も重要な成果を表す単一の指標と、それを支える指標です。

ノーススターメトリック：

• 指標は1つだけです。
• 顧客が感じる価値を捉えます。
• 収益につながるものの、収益そのものではありません（収益は下流すぎる指標です）。
• 例：週間アクティブユーザー数、完了したジョブ数、収益を生み出すセッション数、提供した価値の時間数。

ノーススターメトリックの下に置くKPIの階層：

North star metric
├── Acquisition KPI (how new users enter)
├── Activation KPI (when new users get value)
├── Engagement KPI (how often users return)
├── Retention KPI (how many stick over time)
└── Monetization KPI (how value translates to revenue)

これは「AARRR」または「パイレーツメトリクス」のフレームワークです。ライフサイクル全体を網羅しているため、効果的です。

2. イベント分類体系

ユーザーの行動を記述するために、プロダクトが使用する語彙です。

イベント設計の原則：

• 動詞＋名詞。 signed_up、created_project、completed_checkout。過去形のスネークケースを使用します。
• 個別のアクションごとにイベントを1つ設定します。 「interacted_with_modal」では曖昧すぎます。具体的に opened_modal_X、closed_modal_X、confirmed_in_modal_X とします。
• プロパティでコンテキストを記録します。 各イベントには、コンテキストを示すプロパティ（キーと値のペア）があります。signed_up には、signup_method、referrer、plan などのプロパティがあります。
• プロパティ名を統一します。 ある箇所では userId、別の箇所では id とするのではなく、どこでも user_id を使用します。
• すべてを文書化します。 どこにもないトラッキング計画は、誰も従わないトラッキング計画です。

イベントの網羅性：

• 重要なユーザーアクションをすべてトラッキングする
• すべてのコンバージョンポイントをトラッキングする
• すべてのエラーをトラッキングする
• すべてのページビューを一貫したプロパティとともにトラッキングする
• 重要なボタンのクリックをすべてトラッキングする（すべてのボタンのクリックではありません。それではノイズになります）

アンチパターン：

• ドキュメント化されていない500件以上のイベント
• 一貫性のない命名（buttonClicked、Button Clicked、clicked_button）
• イベントによって異なるプロパティキー
• サーバー側で発火すべきイベントをクライアント側で発火する（またはその逆）
• イベントプロパティにPIIを含める（プライバシーとツール運用上の問題）

3. ダッシュボードとレポート

データと意思決定をつなぐインターフェースです。

ダッシュボード設計の原則：

• ダッシュボードごとに対象者は1つ。 経営陣向けダッシュボード != プロダクトチーム向けダッシュボードです。指標も確認頻度も異なります。
• グラフごとに問いは1つ。 グラフは1つの問いに答えるものであり、3つの問いに答えるものではありません。
• 注釈が重要です。 リリース、実験、祝日、障害を記録します。文脈がなければ、急増しても意味がありません。
• 比較対象を示します。 「今月の登録者数は10,000人」——何と比べているのでしょうか？ 先月、昨年、目標でしょうか？
• アクションを先に示します。 このダッシュボードは、どのような意思決定に役立つのでしょうか？

一般的なダッシュボードの種類：

ダッシュボード	対象者	指標	確認頻度
経営陣向け	経営陣	ノーススターメトリック、主要なKPI 3つ、全体的な傾向	週次レビュー
プロダクト	プロダクトチーム	ファネル指標、機能の利用状況、継続率	毎日／毎週
マーケティング	マーケティングチーム	チャネル別の獲得数、CAC、アトリビューション	毎日／毎週
オペレーション	運用／オンコール担当	パフォーマンス、エラー、キャパシティ	リアルタイム
カスタム（チーム別）	特定のチーム	そのチーム固有のKPI	チームごとの頻度

4. アトリビューションとセグメンテーション

原因と結果を結び付ける方法です。

アトリビューションモデル：

• ファーストタッチ。 最初のインタラクションに貢献度を割り当てます。認知度を理解するのに役立ちます。
• ラストタッチ。 コンバージョン直前の最後のインタラクションに貢献度を割り当てます。多くのツールでデフォルトになっていますが、誤解を招くことがよくあります。
• 線形。 貢献度を各タッチポイントに均等に配分します。特定のチャネルに過剰な貢献度を割り当てることを避けられます。
• 減衰型。 直近のタッチポイントほど多くの貢献度を割り当てます。妥当な折衷案です。
• ポジションベース。 最初と最後のタッチポイントには多く、途中のタッチポイントには少ない貢献度を割り当てます。
• データドリブン（アルゴリズム型）。 Google Analytics 4 などのツールではMLが使われています。ブラックボックスですが、デフォルトとして使われることが増えています。

多くのビジネスでは、主要なアトリビューションモデルを1つ選び、検証用に複数の補助モデルを使います。

セグメンテーションの原則：

• 追跡しやすさではなく、行動の違いを生み出す要因でセグメント化します
• 有用なセグメント：流入元／チャネル、プランのティア、地域、デバイス、コホート（登録日）
• あまり有用でないもの：行動による検証のない、推測に基づく人口統計情報

---

トラッキング計画書

分析戦略の成果物となる、継続的に更新するドキュメントです。

構成：

1. 目標とKPI。 ビジネス目標、ノーススターメトリック、KPIの階層。
2. イベントカタログ。 すべてのイベントと、そのプロパティ、発火するタイミング、追跡する理由。
3. ユーザープロパティ。 永続的な属性（plan、signup_date、role）。
4. ページ分類体系。 ページのカテゴリ、ページプロパティ。
5. 命名規則。 スネークケース、動詞_名詞など。
6. 実装に関する注意事項。 クライアントサイドとサーバーサイドの違い、SDKの詳細、サンプリング。
7. プライバシーとコンプライアンス。 PIIのルール、同意の処理、データの保持期間。
8. ガバナンス。 イベントを追加できる人、レビュープロセス、変更履歴。

---

ワークフロー

1. 問いを定義します。 チームは何を明らかにする必要があるでしょうか？ 指標から始めるより、問いを起点にさかのぼって指標を定義するほうが効果的です。
2. ノーススターメトリックを定義します。 指標を1つ選びます。上記の基準に照らして検証します。
3. KPIの階層を構築します。 獲得、活性化、エンゲージメント、継続、収益化です。
4. 既存のトラッキングを監査します。 何があるでしょうか？ 何が壊れているでしょうか？ 何が不足しているでしょうか？
5. イベントの分類体系を設計します。 ユーザージャーニーを網羅します。すべてをドキュメント化します。
6. 慎重に実装します。 各イベントをテストします。プロパティを検証します。ステージング環境で問題を検出します。
7. ダッシュボードを作成します。 対象者ごとに1つ作成し、アクションを先に示します。
8. レビューの頻度を確立します。 週次のビジネスレビュー、月次のKPIレビュー、四半期ごとの戦略レビューを行います。
9. ガバナンスを確立します。 イベントを追加する人、レビューする人、変更を反映する方法を定めます。

---

失敗パターン

• あらゆるものを追跡する。 ノイズがシグナルを圧倒します。
• 戦略的なものを何も追跡しない。 ページビューだけで終わり、実際の疑問に答えられません。
• ドキュメントがない。 トラッキング計画が誰かの頭の中にしかありません。
• 命名に一貫性がない。 同じ概念に3つの名前が付いています。レポートの確認が謎解きのようになります。
• イベントを発火させても、確認しない。 トラッキングの負債が蓄積します。
• 誰も見ないダッシュボード。 意思決定ではなく、見栄えのために作られています。
• 単一のアトリビューションモデルを真実として扱う。 どのモデルも嘘をつきます。有用な嘘をつくものもあります。
• イベントに PII を含める。 コンプライアンスとツールに問題が生じます。
• クライアント側だけで実施する。 重要なビジネスイベントはサーバー側でも記録する必要があります。広告ブロッカー、ネットワークの問題、エッジケースによって、クライアント側のイベントが失われます。
• ビジネス成果と結び付いていない。 指標がサイロ化し、収益、リテンション、戦略的な意思決定と結び付かないままになります。

---

出力形式

デフォルトの出力：analytics-tracking-plan.md に記載する Markdown 形式のトラッキング計画とダッシュボード一覧。

トラッキング計画の構成：

# Tracking Plan

## North star metric
[Definition, calculation, target]

## KPI hierarchy
[Each KPI with definition, calculation, owner]

## Event catalog
| Event | When fired | Properties | Owner | Status |
|---|---|---|---|---|
| user_signed_up | After successful signup form submit | source, plan, referrer | Marketing | Live |
| project_created | When user clicks Create Project | project_type, template_used | Product | Live |
| ... | | | | |

## User properties
[List with definitions]

## Naming conventions
[Rules]

## Privacy and compliance
[Rules]

## Governance
[Process]

---

参照ファイル

• references/event-taxonomy-template.md - 一般的な製品タイプのパターンを含む、イベントカタログのテンプレート。