トラッキングプラン（計測設計書）とは？意味と作り方

トラッキングプラン（計測設計書）とは

トラッキングプランとは、Webサイトやアプリで計測するイベントやデータ項目について、名前・意味・送信される条件・付随する情報などを一覧にまとめた設計書です。

平たく言えば「何を、どんな名前で、いつ記録するか」を決めた計測のルールブックです。開発者はこれを見て計測を実装し、分析担当者はこれを見てデータの意味を理解します。関係者が同じ文書を見ることで、「このイベントは何を数えているのか」という食い違いを防げます。

英語の Tracking Plan をそのまま使った言葉で、日本語では計測設計書、イベント設計書などと呼ばれます。

書くべき項目

トラッキングプランは、スプレッドシートで管理されることが多く、一般に次のような列を持ちます。

あわせて、文書の冒頭に次のような共通ルールを書いておきます。

• 命名規則（小文字とアンダースコア、「対象＋過去形の動作」など）
• ユーザーIDとアカウントIDの扱い、ログイン前後のID統合の方法
• 全イベントに共通で付けるプロパティ（端末、アプリのバージョンなど）
• 個人情報を送らないなどの禁止事項

実務での使い方・具体例

架空の飲食店向け予約サービスで、トラッキングプランを作る流れを見てみます。

1. 目的と指標を決める：「予約完了数を増やす」を目的とし、検索→店舗詳細閲覧→日時選択→予約完了のファネルと、再予約率を見ることにする
2. 必要なイベントを洗い出す：search_performed、shop_viewed、slot_selected、reservation_completed、reservation_cancelled
3. プロパティを決める：検索条件のエリアや人数、店舗のジャンル、予約日までの日数など、分析で切り口にしたい項目を決める
4. 開発者とすり合わせる：「予約完了」は画面表示時ではなくサーバーで確定した時点で送る、など実装の詳細を詰める
5. 実装後に検証する：テスト環境で一連の操作を行い、全イベントが一度ずつ、正しいプロパティ付きで届くかを確認する
6. 変更履歴を残す：イベントを追加・変更したら日付と理由を記録する

この手順を踏むと、公開後すぐにファネルの各段階の数字が見られる状態になり、「どこで予約をやめる人が多いのか」を議論できるようになります。

運用ルールの例

• 新しい機能を作るときは、仕様書と同時にトラッキングプランの追記を必須にする
• イベント名の変更は原則禁止し、必要な場合は新しいイベントを作って古いものを廃止扱いにする
• 四半期に一度、使われていないイベントを棚卸しする
• 計測の不具合を見つけた人が報告する窓口と、修正の優先度の決め方を決めておく

ルールは細かく作り込むより、関係者が守れる数に絞る方が定着します。最初は命名規則と更新の責任者だけを決め、運用しながら足していく形でも十分です。

よくある誤解と注意点

• 一度作って終わりではない：機能が増えるたびに更新しないと、実装とずれて誰も信用しない文書になります。開発の流れに組み込むことが重要です。
• 項目を増やしすぎない：「念のため」で増やしたイベントは保守の負担になります。どの指標の計算や分析に使うかが書けないイベントは、いったん保留にします。
• ツールの設定画面だけで管理しない：分析ツールの中にも定義を書けますが、ツールを変えると失われます。ツールの外に正本を持っておくと安心です。
• 事業側と開発側の共同作業にする：開発者だけで作ると事業の問いに答えられず、事業側だけで作ると実装できない設計になりがちです。

関連用語

• イベントログ：トラッキングプランに沿って記録されるデータ
• プロダクトアナリティクス：計測したデータでプロダクトを改善する取り組み
• Googleタグマネージャー（GTM）：Webの計測タグを管理するツール
• KPIツリー：計測すべき指標を洗い出す土台になる指標の分解図

関連記事：計測設計書（トラッキングプラン）の作り方と運用ルールの決め方

Otsumuに相談できること

トラッキングプランは、KPIの構造が決まっていると迷わずに作れます。OtsumuのKPI改善コンサルティングでは、KPIツリーの整理から計測設計書の作成、実装後の検証と分析の運用までを支援します。新規サービスの場合は、爆速MVPシステム開発の中で設計段階から計測を組み込めます。

計測の設計に自信がない、既存の計測を整理し直したいといった段階でも、30分の無料相談でお気軽にご相談ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01