計測を仕込む ── Tracking Plan の考え方
メトリクスが決まった。次は、そのメトリクスを計算するための生データをどう集めるかである。
ここで多くのチームが躓く。「とりあえずイベントを投げておこう」「Amplitude にデフォルトで入ってるから良いだろう」── こうした計測の場当たり対応が、半年後に「このイベント、何を意味してるんだっけ？」という断絶を生む。
本章では、計測の設計図である Tracking Plan の考え方を掘る。ツールの設定方法ではなく、どう考えれば後悔しない計測になるかに徹する。
計測の不可逆性
最初に、この章を貫く最も重要な原則を置く。
計測の不可逆性：
過去に遡って測ることはできない
↓ だから
✅ 今から測るものは、今のうちに仕込む
✅ 「後で必要になるかも」を先読みする
✅ ただし、過剰に仕込むと別の問題が起きる（後述）プロダクトの他の要素 ── コード、UI、DB スキーマ ── は間違えても修正できる。だが計測は間違えると過去が失われる。昨日まで仕込んでいなかったイベントを、明日から集計しても、ないデータは永遠に戻ってこない。
この非対称性が、Tracking Plan を「軽く決めてはいけない」最大の理由である。
Tracking Plan とは何か
Tracking Plan は、「何を、いつ、どの属性で記録するか」の設計書である。Spreadsheet でも、Notion でも、専用ツール（Avo、RudderStack など）でも形式は問わない。重要なのは以下が列挙されていることだ。
Tracking Plan に最低限載せるもの：
① イベント名
② イベントの意味（日本語・英語）
③ 発火タイミング（いつ記録されるか）
④ 属性（Properties）一覧と型
⑤ ユーザーに紐付くか、匿名か
⑥ 送信先（Amplitude / BigQuery / ...）
⑦ PII 含有の有無
⑧ 誰が定義し、誰が実装し、誰が検証したかTracking Plan の本質は仕様書であって、計測は仕様通りに実装される必要がある。「なんとなく送っている」データは、半年後には誰も読めなくなる。
イベント設計の二つの流派
イベント設計には大別して二つの流派がある。
流派 ①：イベント駆動（何が起きたか）
ユーザーの行動を時系列で記録する。
例：
Signed Up
Viewed Product
Added to Cart
Purchased
Cancelled Subscriptionほとんどのプロダクトアナリティクス（Amplitude、Mixpanel、Heap、PostHog）はこの流派を前提にしている。メリットは行動の順序と頻度が素直に分析できること。
流派 ②：状態駆動（今どうなっているか）
ユーザーの状態を記録する。
例：
User Table:
user_id: 123
plan: premium
signup_date: 2026-01-15
is_active: true
last_login: 2026-04-20DB やマスタ情報に近い。今の状態を見るなら素直だが、「2月時点ではどうだったか」を取るには別途スナップショットが要る。
両者の組み合わせ
実務では両方を組み合わせる。
graph LR
A[イベントログ<br/>何が起きたか] -->|集計| C[状態スナップショット<br/>時点での状態]
D[ユーザー属性<br/>User Traits] -->|結合| C
C --> E[分析]
A --> Eイベントログ：Segment, Amplitude, BigQuery の events テーブル
状態スナップショット：定期バッチで user_snapshot テーブルを生成
ユーザー属性：Identify イベント or CRM 連携イベント命名規則
Tracking Plan の見た目を決めるのは命名規則である。ここが荒れていると、半年後に似た名前のイベントが乱立して何が何だか分からなくなる。
命名規則の原則
原則 ①：動詞 + 名詞の過去形
✅ Product Viewed
✅ Cart Updated
✅ Subscription Cancelled
原則 ②：名詞は具体的な「オブジェクト」
✅ Article Liked
❌ Like Clicked （何を Like したか不明）
原則 ③：Pascal Case or Title Case で統一
✅ "Product Viewed" or "product_viewed"
❌ "ProductViewed" と "product_view" が混在
原則 ④：命名規則を決めたら Tracking Plan に明記
→ 新しいイベントを追加するとき、既存の規則を参照できる動詞の選び方：過去形 vs 現在形
過去形（Segment の推奨）：
Product Viewed, User Signed Up
→ 「何が起きたか」を明示、最も一般的
現在形：
View Product, Sign Up User
→ 命令形に近い、古い GA の流儀
本書の推奨：過去形で統一
→ 「既に起きた事実」を記録するという性質と整合イベント名だけでは表現しきれない情報
同じ「Product Viewed」でも、どの商品を見たか、どこから来たかは属性（Properties）で表現する。
イベント： Product Viewed
属性：
product_id: "SKU-12345"
product_name: "コーヒーミル"
category: "kitchen"
price: 5980
source: "search_result" ← どこから来たか
position: 3 ← 検索結果の何番目か「同じ事象 vs 別の事象」の線引きがイベント設計の腕の見せ所。以下のように考える。
分析の軸として使う情報 → 属性（Properties）
例：商品カテゴリ、流入元、ABテストの割当
全く違う事象 → 別イベント
例：Product Viewed と Product Purchased は別
迷ったら：
「同じ名前で集計したときに意味があるか」で判断
集計して意味があるなら属性、ないなら別イベント「後から足せない」情報の先読み
Tracking Plan の罠は、リリース直後は不要に見えるが、半年後に必要になる属性がよくあることだ。
典型例：ABテスト割当情報
リリース時：「ABテストはやらない予定」
→ experiment 属性は送らない
→ 3 ヶ月後：「過去の施策の影響を切り分けたい」
→ 過去に遡れない
教訓：experiment_id, variant_id は最初から全イベントに付ける典型例：ユーザーセグメント情報
リリース時：「全ユーザー共通の画面」
→ セグメント属性は送らない
→ 6 ヶ月後：「B2B と B2C で挙動が違う」
→ 切り分けられない
教訓：account_type, plan, cohort_month は User Traits で持つ典型例：デバイス・環境情報
リリース時：「モバイル中心なので OS は Amplitude が自動で入れてくれる」
→ アプリバージョン詳細は送らない
→ 1 年後：「特定バージョンでバグっている疑惑」
→ 集計できない
教訓：app_version, build_number, device_model, os_version は明示的に送る先読みのチェックリスト
リリース前に確認する「後から困る」属性：
✅ user_id（ログイン前後の紐付け）
✅ anonymous_id（匿名トラッキング）
✅ session_id（セッション集計）
✅ timestamp（タイムゾーン付き）
✅ app_version / build_number
✅ device_type / os / browser
✅ locale / timezone
✅ plan / account_type
✅ experiment_id / variant_id（ABテスト予定なくても）
✅ referrer / utm_params（流入元）迷ったら付けるが原則。後からは付けられない。
過剰計測の罠
ただし、「何でも測る」は別の問題を生む。
症状
過剰計測の症状：
- Tracking Plan が数百行になる
- イベント名が長大化（Button A Clicked In Dashboard Of Admin）
- 誰も使わないイベントが 80%
- 送信コスト増、ストレージ増
- Amplitude / Mixpanel の月額が跳ねる
- 分析時に「使える」イベントを選別する作業が増える防衛策：計測の目的を先に決める
Before ：「何でも測っておこう」
After ：「Ch.3 で決めたメトリクスを計算するために必要なイベントだけ」
判断基準：
① そのイベントは、既に決めたメトリクスの計算に使うか？
② 使わないなら、具体的にどんな将来の分析で使うか？
③ 答えられないなら、今は送らない（後から足せる場合）「後から足せない情報」と「後から足せる情報」の区別がここで効く。
✅ 後から足しにくい情報 → 迷ったら送る
- 全イベント共通の属性（experiment_id, plan 等）
- 一度きりの出来事（Signed Up, Subscribed 等）
✅ 後から足せる情報 → 必要になってから送る
- 詳細なマイクロインタラクション
- UI 要素の位置情報（最初はマクロな行動だけで十分）PII と同意設計
2026 年の現在、計測を設計するとき、PII（個人情報）と同意管理は後回しにすると事故る領域になった。
PII の基本分類
絶対に計測してはいけない：
❌ パスワード、クレジットカード番号、マイナンバー
❌ 同意なしの位置情報
原則として計測しない（必要なら慎重に）：
⚠️ メールアドレス、電話番号、フルネーム
⚠️ 住所、生年月日
計測してよいが扱いに注意：
✅ user_id（内部 ID）
✅ 行動ログ（ハッシュ化・集計済み）間違ってよくやる事故
事故例 1：イベント属性にメールアドレスをそのまま入れる
→ Segment や Amplitude のログに個人情報が流れる
→ 委託先ベンダーに PII を渡している状態
事故例 2：フォーム入力値を「デバッグ用に」イベントで送る
→ 本番で不注意に個人情報が流れる
→ イベントログに検索可能な形で残る
事故例 3：URL をそのまま referrer として送る
→ URL に個人情報が含まれていると漏れる
→ 検索クエリ、セッション ID などがそのまま同意管理（Consent Management）
EU の GDPR、日本の改正個人情報保護法、Apple の ATT、Google の Consent Mode ── ユーザーの同意なしに取れる計測の範囲は年々狭くなっている。
同意設計の考え方：
① Essential（必須）：プロダクト動作に必要な計測
→ 同意なしで取得可。認証ログ、セキュリティ関連
② Analytics（分析）：プロダクト改善目的
→ 地域によっては同意必須。DAU、機能利用など
③ Marketing（広告）：広告配信・トラッキング
→ 多くの地域で同意必須。第三者への送信は慎重に
④ Personalization（個人化）：パーソナライズ目的
→ 同意が要る場合が多い同意しなかったユーザーの計測をどうするかを先に決めておく。多くのプロダクトは「Analytics は同意ありのみ集計、ただし集計結果の歪みを認識」というスタンスに落ち着く。
Tracking Plan の運用
作って終わりではない。運用が本番。
誰が書き、誰がレビューするか
理想的な運用：
① 新機能企画時に PM が草案を書く
② アナリストがメトリクス計算可能性をレビュー
③ エンジニアが実装可能性をレビュー
④ データガバナンス担当（いれば）が PII をレビュー
⑤ 実装後、QA がイベント送信を検証
多くのスタートアップの現実：
PM がエンジニアに「こんな感じで」と口頭で伝える
→ 半年後に崩壊継続的な健全性チェック
毎月〜四半期に一度：
✅ 実際に送られているイベントと Tracking Plan の乖離
✅ 誰も使っていないイベントの洗い出し
✅ 属性の型不一致（string のはずが number が混ざってる等）
✅ PII 漏れのチェック
✅ 命名規則から逸脱した新イベントこれを怠ると、ダッシュボードの数字が静かに嘘になる。「先週の DAU が急に減った」と思ったら、アプリ側のバグで App Opened イベントが送られなくなっていた、のような事故は日常茶飯事である。
計測の検証（Validation）
最後に、実装後の検証。「イベントが送られている」と「正しく送られている」は違う。
三段階の検証
① 送信されているか
→ Amplitude / Segment の Debugger で実際にイベントが届くか確認
→ ユーザー 1 人で手動確認
② 正しい属性で送られているか
→ 仕様どおりの値が入っているか
→ null、undefined、空文字の混入チェック
③ 量が期待通りか
→ 1日あたり何件来るはずで、何件来ているか
→ リリース翌日のバーンチャート確認本番環境での検証
開発環境で動いていても、本番環境で送られているとは限らない。典型的な落とし穴：
開発 → 本番で壊れる典型例：
⚠️ 環境変数の差（API キー・トークン）
⚠️ CDN / プロキシでイベントがブロックされる
⚠️ アドブロッカーで送信が止まる
⚠️ SPA のルーティングで二重送信・未送信
⚠️ iOS の ATT で許可されないイベントリリース後 1 週間は、Tracking Plan のイベントが本番で正しく来ているか、ダッシュボードで確認する文化を作る。
本章のまとめ
✅ 計測は不可逆。後から遡れない
→ 今のうちに仕込む、ただし過剰にならない
✅ Tracking Plan は仕様書
イベント名、意味、発火タイミング、属性、送信先、PII を明記
✅ イベント駆動 vs 状態駆動を組み合わせて使う
✅ 命名規則：動詞 + 名詞の過去形で統一
✅ 「後から足せない」属性は先読み：
experiment_id, plan, app_version, device_type, session_id など
✅ 過剰計測も別の問題を生む
メトリクス目的に紐付いたイベントに絞る
✅ PII と同意設計は最初から考える
Essential / Analytics / Marketing / Personalization の 4 層
✅ 運用フェーズの健全性チェックを月次〜四半期で
実送信と仕様の乖離、PII 漏れ、誰も使わないイベント
✅ 実装後は送信 / 属性 / 量 の三段階で検証計測が仕込まれ、データが集まり始めた。いよいよ数字を見る段階に入る。次章では、統計的リテラシー ── 平均の嘘、分布の形、サンプルサイズの揺れ、Simpson のパラドックス ── 現場で実際に役立つ「数字の読み方」を扱う。