トラッキングプラン

トラッキングプランには何を含めますか？

最低限、1イベントにつき1行です。イベント名、付随するプロパティ、発火する正確なタイミング、担当者。優れたプランは、どのツールがそのイベントを受け取るか、そのイベントが答えるべき問いは何かも記録します。誰も検索しないイベントは、見返りのない保守作業です。形式よりも習慣が大切です。スプレッドシートでも、リポジトリ内のバージョン管理されたファイルでも、Segment ProtocolsやAmplitude Dataのようなスキーマツールでもかまいません。トラッキングのコードと同じプルリクエストでプランを更新している限り、どれでも機能します。

イベントにはどう名前を付けるべきですか？

規則を1つ選び、あらゆる場所で徹底します。最も一般的なのは、スネークケースのobject_actionです。subscription_started、invoice_paid、report_exported。関連するイベントが並ぶように対象を先に、イベントは起きたことを記録するので行動は過去形にします。どの規則を選ぶかより、統一されていることのほうが重要です。1つのデータセットに「Sign Up」「signup」「user_signed_up」があれば、分析ツールはそれを互いに無関係な3つのイベントとして扱い、その上につくったグラフはすべて誤りになります。

トラッキングのずれとは何か、なぜ分析を台無しにするのか？

ずれとは、プランとコードが実際に送るものとの間に生じる差です。プランを更新せずにイベント名が変わる、プロパティの型が変わる、重複したイベントが別の名前で現れる、といった具合です。一つひとつの変化は小さくても、積み重なるとファネルの数値は実際より少なくなり、動的セグメントは本来合致すべきユーザーを拾わなくなり、ダッシュボードは作り話に近づきます。そうなると、チームはデータをまったく信用しなくなります。治し方は技術ではなく手順です。プランへの記載なしにイベントをリリースしない、そしてその記載のレビューをコードレビューの一部にすることです。

2人のチームにとってなぜ重要か

小さなチームがプランを省くのは、まだなっていない規模の会社のための手続きのように感じるからです。理屈は逆です。2人しかいなければ、10月にはcheckout_completedとorder_completedがなぜ両方あるのか、誰も覚えていません。最初のイベントの前に書く1ページのプランにかかるのは半日です。グロースエンジニアが最初にやる仕事でもあります。SDKから同意まで、完全なセットアップの中でプランがどう位置づけられるかは、ファーストパーティデータとトラッキングのガイドをご覧ください。