フレームワーク活用ガイドひとことで言うと#
計装計画は、プロダクト内のユーザー行動を「どのイベントを・どの名前で・どのプロパティ付きで記録するか」を事前に設計し、分析可能なデータ収集を仕組み化する方法論です。
用語の定義#
押さえておきたい用語
- イベント（Event）：ユーザーの特定の行動や状態変化を1レコードとして記録したもの。「ボタンクリック」「ページ閲覧」「購入完了」など
- プロパティ（Property）：イベントに付随する属性情報。「商品ID」「流入元」「デバイス種別」など、分析の切り口になるデータ
- タクソノミー（Taxonomy）：イベント名とプロパティ名の命名規則体系。object_action形式（例: cart_viewed）が一般的に使われる
- トラッキングプラン（Tracking Plan）：全イベントの定義・プロパティ・トリガー条件・実装箇所をまとめたドキュメント
- データコントラクト（Data Contract）：イベントのスキーマ（型・必須/任意・許容値）をプロダクトチームとデータチームで合意した仕様
全体像#
分析要件定義
KPIから逆算
→KPIから逆算
イベント設計
命名規則・プロパティ定義
→命名規則・プロパティ定義
実装・QA
SDK組込み・検証
→SDK組込み・検証
運用・棚卸し
未使用イベント削除
未使用イベント削除
こんな悩みに効く#
- 同じ機能のクリックイベントが「click_buy」「purchase_click」「btn_purchase」と3種類あり、分析のたびに名寄せが必要になる
- 新機能リリース後に「あのデータ取ってなかった」と気づき、数週間分の行動データが失われた
- イベント数が500を超えて管理不能になり、どのイベントが現在のプロダクトで有効なのか誰もわからない
基本の使い方#
分析要件をKPIから逆算する
「ファネルの離脱ポイントを特定したい」「機能Xの利用率を測りたい」など、答えるべき問いを先に決めます。問いが明確になれば、必要なイベントは自然に絞り込まれます。優先度の高いKPIに関連するイベントから着手してください。
タクソノミーを定義する
イベント名は object_action 形式（例: product_viewed, cart_item_added）で統一します。プロパティ名はスネークケースに揃え、型（string / int / boolean）と許容値を決めます。この段階で命名規則ドキュメントを作成し、チーム全体で合意を取ります。
トラッキングプランをスプレッドシートに整理する
イベント名・トリガー条件・プロパティ一覧・データ型・実装対象画面をスプレッドシートにまとめます。各行に「なぜこのイベントが必要か」を記載すると、後から不要なイベントを判別する手がかりになります。
実装→QA→運用サイクルを回す
開発チームがSDKにイベントコードを組み込み、ステージング環境でイベント発火を確認します。本番リリース後は、イベント発火数の異常検知アラートを設定し、計装の抜け漏れを早期に検出します。四半期ごとに未使用イベントを棚卸しし、不要なものは廃止します。
具体例#
フィンテックアプリのファネル計装
個人向け投資アプリが、口座開設ファネルの離脱分析のために計装計画を策定。「signup_started → kyc_submitted → bank_linked → first_deposit」の4イベントと、各ステップに12個のプロパティ（デバイス、OS、流入元、入力所要時間など）を定義した。導入前は離脱ポイントが「KYCのどこか」としか分からなかったが、計装後は本人確認書類アップロードで**38%が離脱していることが判明。UIを改修した結果、ファネル完遂率が22%から34%**に向上した。
B2B SaaSのプロダクト利用分析
プロジェクト管理ツールを提供するSaaS企業が、機能利用状況を把握するために87イベントのトラッキングプランを作成。object_action形式で命名を統一し、全イベントにteam_size、plan_type、user_roleのプロパティを共通付与した。分析の結果、有料プランへの転換率が高いユーザーは「ガントチャート機能を週3回以上使う」という行動パターンを持ち、無料トライアル中のガントチャート利用率が**11%しかないことが発覚。オンボーディングにガントチャート体験を組み込み、トライアル→有料転換率が8.5%から13.2%**に改善された。
小売チェーンのPOSデータ計装刷新
全国120店舗の小売チェーンが、POSレジのイベント送信を再設計。従来は「売上金額」のみの集計だったが、新計装では「商品スキャン → クーポン適用 → 支払方法選択 → 決済完了」を個別イベントとして記録し、各イベントに**店舗ID・レジ番号・顧客区分（会員/非会員）を付与。クーポン適用率が店舗間で14%〜47%と大きく異なることが判明し、適用率の低い店舗のレジオペレーション研修を実施した結果、全店平均の適用率が28%から39%**に改善。販促効果の正確な測定にもつながった。
やりがちな失敗パターン#
| 失敗 | 原因 | 対策 |
|---|---|---|
| イベント名が人によってバラバラ | タクソノミーを決めずに各自が実装した | 命名規則ドキュメントを作り、CIでスキーマバリデーションを入れる |
| 必要なプロパティが後から足りない | 分析要件を先に整理せず、思いつきでイベントを設計した | KPIから逆算して「この分析に何が必要か」をイベント設計前に洗い出す |
| イベント数が膨大で管理不能 | ページ遷移すべてをイベント化するなど過剰計装した | 「このイベントで何を判断するか」を各行に書き、用途不明のイベントは追加しない |
| ステージングと本番でデータが違う | 環境差異（URLやフラグ）を考慮せずにイベント発火条件を設定した | 環境ごとのイベント検証チェックリストを作り、リリース前に実データを目視確認する |
まとめ#
計装計画の本質は「データを使う前に、データの設計をする」という発想の転換にあります。分析要件からイベントを逆算し、命名規則を統一し、スプレッドシートで一元管理する。この3つを実行するだけで、分析のたびに名寄せや欠損に苦しむ時間が大幅に減ります。新機能のリリース前に「トラッキングプランは更新したか」をチェックリストに入れることが、データドリブンな組織への最初の一歩になるでしょう。