トラッキングプランとは
トラッキングプランは、プロダクトが記録するすべてのイベント、それぞれに付くプロパティ、発火する正確なタイミング、責任者を1つにまとめた文書です。データを送るコードと、それを読むダッシュボードとの間の契約にあたります。一度書いて忘れる文書ではなく、プロダクトとともに変わる生きた仕様書として扱ってください。一言の定義はトラッキングプランの用語解説にあります。このガイドでは、そのつくり方を解説します。
- イベント
- ユーザーやシステムが行う個別の行動。発生するたびに1回記録されます。たとえばsignup_completedやsubscription_started。
- プロパティ
- イベントに付けるキーと値の組で、その文脈を表します。plan_name、referrer、amount_usdなど。プロパティは「どれか」「いくらか」に答えます。
- 命名規則
- イベントとプロパティの名前の付け方を定めた固定のルール。たとえばスネークケースのobject_action形式。1つ選んで、どこでも同じように使います。
- トラッキングプラン
- すべてのイベント、そのプロパティ、発火のタイミング、担当者をまとめた生きた仕様書。コードと分析の両方が参照する、信頼できる唯一の情報源です。
場当たり的なトラッキングよりプランが優れている理由
プランがないと、トラッキングは無秩序に積み重なります。あるエンジニアはsignupを送り、別のエンジニアはSign Upを送り、3人目はuser_registeredを送ります。1つの行動に3つの名前が付き、登録に関わるすべてのファネルが、気づかないうちに分裂するか壊れます。これが表記の揺れで、分析が信頼されなくなる一番の原因です。プランはコードをリリースする前に用語を固めるため、半年後に取り出す数字も、想定どおりの意味を保ちます。きれいで一貫したイベントは、実験ロードマップの土台でもあります。3通りの方法で記録している指標では、テストを測れません。
イベント名はobject_action形式にして、崩さない
多くの分析ツールが推奨する規則はobject_action形式です。対象を先に、そこで起きたことを後に書きます。subscription_started、invite_sent、checkout_completedのように。Segment、Amplitude、PostHogはそれぞれ少しずつ違う形を示しています（Segmentは「Object Action」、PostHogは小文字のスネークケース、Amplitudeは名詞と過去形の動詞）。大文字小文字の細かな違いより、1つを選んで決して崩さないことのほうがはるかに重要です。価値の大半は2つのルールで得られます。動詞の時制をそろえること、そしてイベント名を動的に組み立てないことです。plan_${name}_upgradedのようなイベントは顧客ごとに別のイベントを生み、クエリできなくなります。
ファネルをたどる8〜10個のイベント
何でも記録したくなる気持ちを抑えてください。最初の接点から支払いまで（登録、アクティベーション、売上）ユーザーをたどる少数のイベントから始め、深掘りする前にそれらをしっかり計測します。以下は一般的なB2B SaaS向けの最初のセットです。自社プロダクトの名詞に合わせて名前を変えてください。それぞれがプランの1行になり、全体で最初のファーストパーティデータになります。これからつくるすべてのファネル、コホート、リテンションカーブの素材です。各イベントをブラウザーとサーバーのどちらで計測するかは別の判断で、サーバーサイドとクライアントサイドのトラッキングで使い分けを解説しています。
| イベント | 発火するタイミング | 重要な理由 |
|---|
| account_created | ユーザーが登録を終え、レコードが作成されたとき | ファネルの入口。すべてのコンバージョン率の分母 |
| onboarding_started | ユーザーが初回利用のフローに入ったとき | セットアップを始めた登録者と、離脱した登録者を分ける |
| activation_reached | ユーザーが定義したアハモーメントに到達したとき（例：最初のプロジェクトを共有） | 最も予測力のある初期イベント。思い込まずに検証する |
| feature_used | 中心となる機能が使われたとき（feature_nameプロパティ付き） | エンゲージメントの深さ。セグメントとリテンションの入力 |
| invite_sent | ユーザーがチームメンバーを招待したとき | B2Bでのアップセルと定着度の先行指標 |
| trial_started | トライアルまたはフリープランが始まったとき | 売上ファネルの起点。トライアルからの有料化率の基準 |
| subscription_started | ユーザーが有料プランに転換したとき | 売上が生まれる瞬間。グロースの取り組みをお金に結びつける |
| subscription_cancelled | ユーザーが有料プランを解約したとき | 解約のシグナル。掘り起こしとリテンション分析の材料 |
詳細はプロパティに、品質は担当者に
イベントは少なく汎用的に保ち、具体的な情報はプロパティに入れます。プランごとに別のイベントをつくるのではなく、plan_nameとamount_usdのプロパティを付けたsubscription_startedを1つ送ります。豊かに記述された1つのイベントなら、クエリしやすいままです。各イベントのプロパティも絞ってください。使わない数十個より、実際にクエリする数個のほうが役立ちます。次に担当者を決めます。小さなチームの多くではグロースエンジニアか計測を実装する人が担い、新しいイベントはすべてその人を通すことで、プランとコードがずれないようにします。最後に、イベントがどこに届くかを把握してください。ホスト型の分析ツールやCDPに送れば手早く始められますが、行動データは他社のサーバーに置かれます。ファーストパーティのまま（セルフホストのPostgresや自社のデータウェアハウスに）置けば、データは自社のものであり続けます。これが、エンゲージメントツールにおけるオープンソースとSaaSのトレードオフの核心です。