計測設計（トラッキングプラン）とは？｜「何を、いつ、どう記録するか」を先に決める理由

あとからタグを増やせばいいでは通用しない理由

新しい機能をリリースするたびに、ひとまずボタンにイベントタグだけ足しておこう、と考えたことがある人は多いはずです。その場しのぎの計測は、最初の数週間はそれなりに動いてしまいます。

ところが半年後には、似たような目的のクリックイベントが5個も6個も並び、どれがどのボタンを指しているのか誰も正確に説明できない、という状態にたどり着くチームが少なくありません。イベント名が click、btn_click、buttonClicked のように担当者ごとにばらばらになり、集計のたびにSQLで名寄せする羽目になるのは典型的な失敗パターンです。

こうした事態を防ぐために、計測を始める前に何を、いつ、どういう名前とプロパティで記録するかを文書として先に決めておく手法があります。トラッキングプラン（計測設計書）と呼ばれるこの手法の考え方と作り方、そして運用の中で壊れやすいポイントを、この記事では順番に整理します。

トラッキングプランとは何か

一覧表としての実体

トラッキングプランの実体は、難しいものではありません。記録するイベントを一行ずつ並べた、計測の仕様書です。

行にイベント名、列に発生条件・付随するプロパティ・発火する画面や機能を並べておくと、エンジニアはコードを書く前に何を送ればよいかがわかり、分析側は後からイベントの意味を推測せずに済みます。仕様がドキュメント化されているだけで、実装と分析の間の翻訳コストが大きく下がります。

なぜ後付けでは品質が落ちるのか

計測を実装が終わった後に足す運用だと、担当したエンジニアの主観でイベント名や粒度が決まりがちです。同じ資料請求という行動でも、あるページでは download_click、別のページでは cv_click と呼ばれてしまうと、後から集計する人はその違いを知る手段がありません。

先にプランを作っておけば、実装は決められた仕様を満たす作業になり、命名のばらつきという属人性そのものを構造的に減らせます。これは新しいツールを導入する話ではなく、計測を設計してから実装する、という順番の話です。

小規模なチームほど、この順番の効果は大きくなります。人手が少ないほど後からの棚卸しに割ける時間はなく、最初の設計の質がそのままデータの寿命を決めるからです。

計測設計の担当は、必ずしも専任のアナリティクスエンジニアである必要はありません。小さなチームではプロダクトマネージャーやマーケターがこの役割を兼ねることも珍しくなく、重要なのは肩書きではなく、誰か一人が最終的な仕様に責任を持つと決まっていることです。責任の所在が曖昧なまま複数人が思い思いに命名すると、結局は最初に戻って作り直す羽目になります。

イベント設計の基本方針

オブジェクトとアクションで名づける

計測ツールの業界では、対象（オブジェクト）と動作（アクション）を組み合わせてイベント名を決める、という命名の型が広く使われています。フォームに対する送信なら form_submitted、動画に対する再生なら video_played という具合です。

この型に従うだけで、click のような動詞だけの曖昧な名前や、画面名を無理やり詰め込んだ長すぎる名前を避けられます。名前を見ただけで対象と行動がわかることが、良いイベント名の最低条件です。

プロパティで粒度を後から調整できるようにする

イベント名は何が起きたかを表し、粒度の細かい情報はプロパティとして付随させるのが基本方針です。ボタンごとに別々のイベント名を作るのではなく、button_clicked というひとつのイベントに label や position というプロパティを添える設計にしておくと、後から集計の切り口を増やしても新しいイベントを追加する必要がありません。

この考え方はマイクロコンバージョンの設計とも相性がよく、小さな行動をイベントとして粗く割り切りすぎず、しかしイベントの数を無限に増やさない、というバランスを取りやすくなります。

共通して使えるプロパティをあらかじめ決めておくのも効果的です。ページの種類やユーザーの契約プランのように、多くのイベントで使い回せるプロパティを共通プロパティとして最初に定義しておくと、イベントごとに毎回同じ議論を繰り返さずに済みます。

ページビューとイベントの役割分担

画面が切り替わる行動はページビュー、画面の中で起きる行動はイベント、という役割分担を最初に決めておくと、後々の混乱を防げます。次の表は、この2つの違いを整理したものです。

よくあるのは、ページ遷移を伴わないタブ切り替えやモーダル表示をページビューとして送ってしまい、PVの数字が実態より水増しされるケースです。こうした線引きの曖昧さは、滞在時間・エンゲージメントの正しい測り方のように、1画面内での行動の密度を見たい分析ほど致命的に効いてきます。

「何を計測するか」を決める逆算のプロセス

ビジネス上の問いから始める

計測できることを全部計測しようとすると、プロパティだらけの巨大なイベントが量産され、誰も使わないデータの倉庫ができあがります。避けるべきは計測できるから計測するという発想であり、目指すべきは答えたい問いがあるから計測するという発想です。

プロダクト指標の設計で扱ったような北極星指標やKPIツリーが先にあれば、その指標を構成する行動から逆算して、必要なイベントだけを絞り込めます。問いが先、計測が後、という順番を守るだけで、無駄なイベントの数はかなり減ります。

ファネルのステップから逆算する

もうひとつの逆算の起点は、コンバージョンに至るまでの導線です。ファネル分析の基本で整理したように、ファネルの各ステップを先に定義しておけば、そのステップを判定するために最低限必要なイベントが自動的に決まります。

計測設計を始める前に、次のような問いに答えを出しておくと後工程がぐっと楽になります。

• この行動を追う目的は何か（どんな意思決定に使うか）
• どのステップ・画面で発生するか
• 誰が発火の実装に責任を持つか
• どのプロパティが後で切り口として必要になりそうか
• 似た既存イベントと統合できないか

仮に、命名の統一を怠ったために月1回・2時間のSQL名寄せ作業が発生しているとします（数値は説明用の仮定です）。これを1年続けると、年間で24時間、丸3営業日ぶんの工数が、ドキュメント1枚あれば防げたはずの作業に消えている計算になります。

過剰計測にもコストがある

計測は多いほど安心というものではありません。イベントの数が増えるほど、命名の一貫性を保つコストと、分析する側が全体像を把握するコストの両方が増えていきます。

新しいイベントを追加する前に、既存のイベントとプロパティの組み合わせで代替できないかを一度疑ってみる習慣が、長期的にはプランをきれいに保ちます。足すのは簡単で、減らすのは難しいという非対称性を、常に念頭に置いておく価値があります。

イベントが数百種類に膨らんだ状態では、新しく加わったメンバーがプラン全体を把握するだけで数日かかることも珍しくありません。プランの見通しの良さそのものが、チームのオンボーディング速度を左右するという側面も見逃せません。

命名規則と壊れやすいポイント

表記ゆれが起きる典型パターン

命名規則を決めても、運用の中で自然と崩れていくポイントにはある程度の共通パターンがあります。次の表は、崩れやすい観点と、崩れたときに起きる実害を整理したものです。

レビューの仕組みを作る

命名規則そのものは一度決めればよいのですが、それを守り続ける仕組みがないと、時間の経過とともに必ず崩れていきます。新しいイベントを追加するときに既存のプランと照らし合わせてレビューする担当を決めておくだけで、崩れる速度はかなり遅くなります。

大がかりな承認フローを作る必要はありません。プランをスプレッドシートやドキュメントで一箇所に置き、追加時に必ずそこへ書き足すという運用ルールだけでも効果は十分にあります。ドキュメントが存在しないチームでは、まずこの一箇所化から始めるのが現実的です。

AIがデータに触れる時代ほど命名が重くなる

近年は、ダッシュボードを人が毎回開く代わりに、AIエージェントに自然言語で数字を尋ねる使い方が広がりつつあります。MonaLensもMCP（AIが自然言語で分析を呼び出す仕組み）に対応していますが、こうした仕組みは結局、裏側にあるイベント名とプロパティの一貫性にそのまま依存します。

イベント名が担当者ごとにばらついていれば、AIに問い合わせても答えは揺れます。人が読み替えて補正していた表記ゆれを、AIは律儀にそのまま拾ってしまうためです。命名規則を整えておくことは、これからの分析基盤にとって、人の作業を楽にするだけでなく、AIが正しく答えるための前提条件にもなっていきます。

言い換えると、トラッキングプランはもはや人間向けのドキュメントだけではなく、AIエージェントが参照する仕様でもある、という捉え方をしておくと投資判断がしやすくなります。整備にかける時間は、目先の分析画面のためだけでなく、将来どんな聞き方をしても崩れない土台への投資でもあります。

導入時によくある落とし穴

計測設計に取り組み始めたチームがつまずきやすい点を、ここで3つほど具体的に見ておきます。

ひとつ目は、最初から完璧な設計を目指してしまうことです。すべてのイベントを網羅した完全なプランを作ろうとすると着手が遅れ、結局は手つかずのまま実装が先行してしまいます。最初は主要なコンバージョン経路に絞り、あとから広げていく方が現実的です。

ふたつ目は、プランを作った後に誰も更新しないことです。ドキュメントと実装が乖離した瞬間、そのプランは信頼されなくなり、次第に誰も参照しなくなります。実装のプルリクエストにプラン更新を含めるなど、更新のタイミングを開発フローに組み込む工夫が要ります。

みっつ目は、分析側の意見を聞かずにエンジニア主導だけで決めてしまうことです。技術的に送りやすい形と、分析するときに使いやすい形は必ずしも一致しません。設計の段階から、実際にその数字を使う人を巻き込んでおくことが遠回りに見えて確実です。

以下は、実装前に埋めておきたいイベント定義の記入例です。仮の例として、料金ページのCTAボタンを想定しています。

event: "signup_button_clicked"
trigger: "料金ページのプライマリCTAクリック時"
properties:
  plan: "pro" | "scale"
  position: "hero" | "footer"
owner: "フロントエンドチーム"
purpose: "プラン別のCTAクリック率を比較する"

こうした最低限の項目さえ埋まっていれば、実装者と分析者の間で解釈のズレはほとんど起きなくなります。項目自体を増やしすぎないことも、プランを長続きさせるコツです。プランを埋める際に、次の3点だけは省略しないようにしてください。

• なぜこのイベントが必要かという目的
• 誰が実装と維持に責任を持つかという所有者
• どこまでを1つのイベントにまとめるかという粒度の基準

なお、使われなくなったイベントは、プランから即座に削除するのではなく廃止予定と明記して残しておく方が安全です。過去データを参照する分析が突然壊れることを防げますし、同じ名前のイベントを別の意味で誤って再利用してしまう事故も避けられます。廃止の理由と最終確認日をひとことメモしておくだけでも、半年後に見返したときの判断材料になります。

まとめ：計測設計は一度作って終わりではない

トラッキングプランは、一度作れば永久に安泰という性質のものではありません。プロダクトが変わり続ける以上、計測の対象も継続的に見直す必要があります。

大切なのは、完璧な計測を最初から目指すことではなく、何を、なぜ計測するのかを言語化し、変更のたびに立ち戻れる場所を作っておくことです。ファネルやN1分析のような機能がどれだけ高性能でも、土台になるイベント設計が粗いままでは意味のある数字は出てきません。

計測設計に完成形はなく、プロダクトの成長に合わせて何度も見直すものだと捉えておくと気が楽になります。最初の一歩は、今ある主要なイベントをひとつの表に書き出してみることだけで十分です。そこから、命名規則を1つ決め、レビューする人を1人決める、という小さな積み重ねが、半年後のデータの質を大きく変えます。