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

トラッキングプラン（計測設計書）は、「何を・どの名前で・どの条件で・誰のために計測するか」を一覧にした、開発・マーケティング・分析の三者が共有する台帳です。作り方の要点は、先に事業のKPIと知りたい問いを決め、そこから必要なイベントとプロパティを逆算し、命名規則と変更手順を決めてから実装することです。ツールの設定画面から考え始めると、計測項目が増えるだけで、肝心の判断に使えるデータが残りません。

この記事は、Webサービスやアプリの計測を任されたプロダクト担当者、マーケティング担当者、開発チームのリーダーに向けて書いています。トラッキングプランに書くべき項目、作成の手順、命名規則の決め方、実装後の検証と運用ルールまでを、テンプレートとして使える形で整理しました。

読み終えるころには、自社のサービスについて「最初の版」のトラッキングプランを作り始められ、計測漏れや名前の揺れで分析が止まる状態を避けるための運用の型が分かるはずです。

トラッキングプランとは何か：計測の「仕様書」をチームで共有する

トラッキングプランは、計測に関する仕様書です。画面に何を表示するかを決めるのが画面設計書だとすれば、ユーザーのどの行動を、どんな情報と一緒に記録するかを決めるのがトラッキングプランです。用語としての定義はトラッキングプラン（計測設計書）でも解説しています。

なぜ仕様書が必要かというと、計測は複数の人の手を通るからです。マーケティング担当者は広告からの流入と申し込みを見たい。プロダクト担当者は機能の利用状況を見たい。開発者はそれをコードやタグとして実装する。分析担当者は集計してレポートを作る。このとき、共通の台帳がないと次のようなことが起こります。

• 同じ「申し込み完了」が、ある画面では `signup_complete`、別の画面では `register_done` という名前で送られている
• 「申し込み」の定義が、フォーム送信時なのか、メール認証完了時なのか、人によって違う
• リニューアルで画面が変わったときに、計測が消えたことに誰も気づかない
• 分析したい切り口（プラン種別や流入元）が記録されておらず、後から分けられない

トラッキングプランは、こうした問題を「実装前に合意する」ことで防ぎます。後から直すには、過去データの補正や集計ロジックの分岐が必要になり、手間が何倍にもなります。

トラッキングプランに書くべき項目

最初から完璧な台帳を目指す必要はありませんが、最低限そろえておきたい列があります。スプレッドシート1枚で始め、1行を1イベントとして管理するのが扱いやすい形です。

特に重要なのは「説明」と「発火条件」です。イベント名だけでは、ボタンを押した瞬間なのか、処理が成功した瞬間なのかが分かりません。この違いは数字に直接効きます。押した数と成功した数の間には、入力エラーや通信エラーで失敗した分の差が出るからです。

「目的・使う指標」の列も省かないでください。この列が空欄のイベントは、誰も使わない計測である可能性が高く、棚卸しのときに削除候補になります。

作る前に決めること：KPIと「知りたい問い」から逆算する

トラッキングプラン作りで最もよくある失敗は、「とりあえず全部のクリックを取っておこう」という発想です。取れるものを全部取ると、データ量は増えても、知りたいことに答えられるとは限りません。必要なのは、事業の判断に使う問いから逆算することです。

逆算の出発点はKPIです。たとえば会員制サービスなら、売上を「新規登録数 × 有料転換率 × 継続期間 × 単価」のように分解し、それぞれの数字をどのイベントから計算するかを考えます。KPIの分解の仕方はKPIツリーの作り方で詳しく扱っています。

次に、KPIが動いたときに「なぜ動いたか」を調べるための問いを書き出します。

• 有料転換率が下がったとき、どの段階で離脱が増えたのか
• 流入元によって転換率に違いはあるか
• 特定の機能を使った人と使っていない人で、継続に差はあるか
• スマートフォンとPCで、申し込みの完了率に差はあるか

問いが決まれば、必要なイベントとプロパティが決まります。「流入元によって違いはあるか」という問いに答えるには、登録イベントに流入元のプロパティが必要です。「特定の機能を使ったか」に答えるには、その機能の利用イベントが必要です。問いから逆算すると、計測項目は意外と少なく済みます。

トラッキングプランの作り方：7つの手順

ここからは、最初の版を作る具体的な手順です。小さなサービスなら数日、関係者が多い場合でも数週間で最初の版はまとまります。

1. 事業のKPIと主要な問いを1枚にまとめる：経営層やプロダクトの責任者と、今期に追う指標と、それが動いたときに確認したい問いを5〜10個に絞って合意します。
2. ユーザーの主要な行動の流れを書き出す：訪問、登録、初回利用、有料化、継続利用、解約など、サービスの価値に関わる流れを段階ごとに並べます。
3. 各段階に対応するイベントを決める：段階の「完了」を表すイベントを1つずつ定義します。途中の操作は、問いに必要な場合だけ追加します。
4. プロパティを決める：問いに答えるための切り口（プラン、流入元、端末、機能の種類など）を、イベントごとに決めます。値の候補もあわせて列挙します。
5. 命名規則に沿って名前を付ける：後述する規則で名前をそろえ、既存の計測と重複がないか確認します。
6. 発火条件と実装場所を開発者と確認する：クライアント側で送るか、サーバー側で送るか、二重送信の恐れはないかを詰めます。
7. レビューして合意し、ステータスを管理する：マーケティング、プロダクト、開発、分析の担当者で読み合わせ、承認した版を「正」として扱います。

手順2で作る行動の流れは、そのままファネル分析の段階定義になります。段階の切り方についてはファネル分析のやり方もあわせて参考にしてください。

命名規則の決め方：揺れない名前を最初に決める

命名規則は、トラッキングプランの品質を左右する部分です。名前が揺れると、集計のたびに「この二つは同じものか」を確認する作業が発生し、分析の速度が落ちます。決めておきたいのは次の5点です。

単語の並びと形式

よく使われるのは「対象＋動作（過去形）」の形式です。`form_submitted`、`plan_upgraded`、`report_exported` のように、何に対して何が起きたかを表します。大文字小文字は小文字に統一し、単語の区切りはアンダースコアにそろえると、ツール間で扱いやすくなります。

動詞の語彙を限定する

「開いた」を表す動詞が `opened`、`viewed`、`displayed` と混在すると混乱します。使う動詞を一覧にして、意味を定義しておきます。たとえば「viewed は画面が表示された」「clicked はボタンが押された」「completed は一連の処理が成功した」のように決めます。

プロパティ名と値の表記

プロパティ名もイベント名と同じ規則にそろえます。値については、プラン名を `Basic` と `basic` で揺らさない、日付の形式を統一する、真偽値を文字列で送らない、といった点を決めます。値の候補を列挙しておくと、入力ミスに気づきやすくなります。

画面名・機能名の正式名称

社内で呼び方が揺れている機能は、計測上の正式名称を決めます。営業資料と画面と計測で名前が違うと、分析結果を共有するときに誤解が生まれます。

廃止と変更の扱い

イベントの意味を変えるときは、同じ名前のまま中身を変えず、新しい名前を付けるのが原則です。同じ名前で定義が変わると、変更前後の数字を比較できなくなります。GA4を使う場合の具体的な考え方はGA4のイベント設計で解説しています。

具体例：架空のオンライン学習サービスでの最初の版

ここでは、架空のオンライン学習サービスを例に、最初の版のイメージを示します。このサービスは無料登録後に講座を受講でき、一定の講座以上は有料プランが必要という仕組みだとします。

運営チームが今期に追うKPIは「有料プランへの転換数」で、主な問いは「無料登録から有料化までのどこで止まっているか」「最初の講座を最後まで見た人は有料化しやすいか」の二つでした。そこで、最初の版では次のイベントだけを定義しました。

• `account_created`：アカウント作成が成功した時点（プロパティ：流入元、端末）
• `course_started`：講座の最初のレッスンを再生した時点（プロパティ：講座ID、講座カテゴリ）
• `lesson_completed`：レッスンを最後まで視聴した時点（プロパティ：講座ID、レッスン番号）
• `paywall_viewed`：有料講座の案内画面が表示された時点（プロパティ：表示された場所）
• `subscription_started`：決済が成功し、有料プランが有効になった時点（プロパティ：プラン種別、支払い周期）

当初の案には、トップページのバナークリックや検索窓の入力など20以上の候補が並んでいました。しかし問いに照らして絞り込んだ結果、5つのイベントで最初の判断は十分にできると分かりました。検索機能の改善が議題に上がった段階で、検索関連のイベントを追加する、という順番で育てていけばよいのです。

この例のように、最初の版は小さくてかまいません。重要なのは、5つのイベントの定義が全員にとって同じ意味を持っていることです。

実装後の検証：計測が正しく動いているかを確かめる

トラッキングプランを作って実装を依頼しても、それだけで正しいデータが集まるとは限りません。実装後の検証は、計画と同じくらい重要です。検証は次の観点で行います。

特に「他の数字との整合」は欠かせません。計測ツール上の申し込み数と、業務システムに記録された申し込み数は、広告ブロッカーや同意管理の影響などで完全には一致しないものです。どの程度の差なら許容するかを決め、差が急に広がったら調べる、という運用にしておくと安心です。

検証済みのイベントだけをトラッキングプランのステータスで「検証済み」とし、分析やレポートでは検証済みのものだけを使う、というルールにすると、未確認のデータで判断を誤るリスクを減らせます。

運用ルールの決め方：トラッキングプランを生きた台帳にする

トラッキングプランは作って終わりではありません。サービスは機能追加や画面変更を繰り返すため、台帳を更新し続ける仕組みが必要です。運用ルールとして決めておきたいのは次のような項目です。

変更の申請と承認の流れ

新しいイベントの追加や定義の変更は、誰が申請し、誰が承認するかを決めます。小さなチームなら、プロダクト担当者が台帳を更新し、開発チームのレビューで確認する程度で十分です。大切なのは、台帳を通さずに計測が追加されない状態を作ることです。

開発プロセスへの組み込み

機能開発のチケットに「計測の追加・変更があるか」という確認項目を入れておくと、計測漏れを防げます。リリース前のチェックリストにも、トラッキングプランとの照合を加えます。

定期的な棚卸し

四半期に一度などの頻度で、使われていないイベントや、定義と実態がずれているイベントを洗い出します。「目的・使う指標」の列が空欄のものや、どのレポートにも登場しないものは削除や廃止の候補です。

定義の公開場所

台帳は関係者全員が見られる場所に置き、最新版がどれかを明確にします。複製されたファイルが複数存在すると、どれが正しいか分からなくなります。

よくある失敗とその避け方

トラッキングプランの運用でつまずきやすい点を、避け方とあわせて整理します。

• 全部取ろうとして、使わないイベントが大量に残る：問いから逆算し、目的の列が埋まらないイベントは追加しない、というルールにします。
• ボタンのクリックだけを計測し、処理の成功を計測していない：完了系のイベントは、可能な限りサーバー側の成功時点で送ります。
• 画面のリニューアルで計測が消える：リリース前のチェックリストに計測の確認を入れ、リリース後数日は主要イベントの件数を見守ります。
• 台帳と実装がずれていく：台帳の更新を機能開発の完了条件に含め、棚卸しで差分を定期的に直します。
• 担当者の異動で、定義の意図が分からなくなる：説明と目的の列を具体的に書き、変更履歴に「なぜ変えたか」を残します。
• 個人情報を不用意にプロパティに入れてしまう：メールアドレスや氏名など、個人を特定できる情報は送らないことを規則として明記します。扱いの判断が難しい場合は、社内の担当部署や専門家に確認してください。

トラッキングプラン作成のチェックリスト

最初の版を作り終えたら、次の項目を確認してください。

• 事業のKPIと、それを調べるための主要な問いが書かれている
• 各イベントに、日本語の説明と発火条件が書かれている
• 各イベントに、使う指標や答える問いが紐づいている
• 命名規則が文書になっていて、すべてのイベントが規則に沿っている
• プロパティの型と値の候補が定義されている
• 実装場所（Web、アプリ、サーバー）と担当者が決まっている
• 検証の方法と、業務システムの数字との突き合わせ方が決まっている
• 変更の申請・承認の流れと、棚卸しの頻度が決まっている
• 個人情報を送らないルールが明記されている

よくある質問

Q. トラッキングプランはどのツールで管理すればよいですか？

最初はスプレッドシートで十分です。関係者全員が見られて、変更履歴が残ることが重要です。イベント数が増え、複数のプロダクトや計測ツールをまたぐようになったら、計測の定義を管理できる専用の仕組みを検討すればよいでしょう。

Q. すでに計測が乱立している状態から作り直すにはどうすればよいですか？

まず現在送られているイベントを一覧に書き出し、使われているもの、重複しているもの、意味が不明なものに分類します。そのうえで、KPIから逆算した理想の一覧と照らし合わせ、新しい名前の体系に段階的に移行します。移行期間は新旧の両方を送り、数字の連続性を確認してから古いものを止めます。

Q. 誰がトラッキングプランの責任者になるべきですか？

データを使って判断する側、多くの場合はプロダクト担当者や分析担当者が責任者になるのが自然です。実装の詳細は開発者と確認しますが、「何を知りたいか」を決めるのは事業側の役割です。

Q. 小さなMVPでもトラッキングプランは必要ですか？

必要です。ただし、5〜10個程度のイベントに絞った簡単なもので構いません。検証したい仮説に関わる行動だけを確実に計測しておくことが、MVPでは特に重要です。MVPで最低限入れる計測についてはMVPに最低限入れる計測にまとめています。

Otsumuに相談できること

計測したい問いがはっきりしていて、社内に計測ツールの扱いに慣れた担当者と、実装に協力できる開発者がいる場合は、この記事の手順とチェックリストで最初の版を作り、運用を始めることができます。イベント数が少ないサービスであれば、外部の手を借りずに十分に回せるはずです。

一方で、KPIそのものがまだ定まっていない、計測が乱立していてどこから手を付けるべきか分からない、業務システムの数字と計測の数字が合わず原因が特定できない、といった状況では、事業の指標設計と実装の両方を理解した相手と進めたほうが早く整います。計測は事業の問いと技術の制約の間で決まるものなので、片方の視点だけでは設計が偏りがちです。

Otsumuは自らも事業を手がける立場から、KPIの分解、トラッキングプランの設計、実装の確認、ダッシュボードでの可視化までを一気通貫で支援しています。KPI改善コンサルティングでは、目的から逆算して必要な計測に絞り込み、数字を改善の行動につなげる運用づくりまでをお手伝いします。

いまの計測の状態を見てほしい、最初の版を一緒に作りたい、といった段階からご相談いただけます。まずは30分の無料相談で状況をお聞かせください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

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