イベントトラッキングとは何か、そして本当に計測すべきイベント

イベントとは、起きたことではなく、あなたが下した判断である

どんな製品も、起きたこと自体は無限に発生させます。クリック、スクロール、ホバー、画面遷移。イベントとは、そのうち名前を付ける価値があるとあなたが判断した小さな部分集合です。判断の材料になるからこそ名前を与えるのであり、計測の実装ではなく、この判断こそが仕事の中身です。

実務的な帰結として、計測計画はエンジニアリングの文書である前にプロダクトの文書です。あるイベントが発火するかどうかで自分の行動が何も変わらないなら、そのイベントはまだ存在する必要がありません。

イベントは画面ではなく結果に基づいて命名する

clicked_blue_button は、デザインが改修を出した瞬間に正しくなくなります。report_exported は生き残ります。ユーザーが何に触れたかではなく、何を成し遂げたかを表しているからです。

規則を一つ決めて守ってください。対象を先に、動作は過去形、小文字とアンダースコア — invite_sent、project_created、payment_failed。どの規則を選んだかより一貫していることのほうが重要です。二四半期も経つとイベント一覧を検索不能にするのは、揺らいだ命名だからです。

そのまま使える命名規則

ほとんどのチームに必要なのは、規則を発明することではなく、書き留めることです。次の規則は覚えられるほど短く、イベント一覧を検索可能に保てるほど厳密です。

この規則を計測計画の冒頭に置き、コードをスタイルガイドに照らしてレビューするのと同じように、新しいイベントをこの規則に照らしてレビューしてください。悪い名前のコストは、誰かがそのイベントを検索して見つけられないたびに支払われます。

イベントは10〜20個であって、200個ではない

よくある失敗は、後で役に立つかもしれないという理屈ですべてを計測することです。その結果できあがるのは、誰も辿れない一覧と、ほぼ同じ意味の三つのイベントと、どれが正なのかについての合意の欠如です。

すでに定例で問うている質問 — 立ち上げまで到達しているか、戻ってきているか、どこで諦めているか — から出発し、それに答えるものだけを実装してください。一画面に収まる計測計画は維持されます。表計算に収まる規模のものは維持されません。

実例：B2B SaaSアプリの計測計画

チームで使う典型的なSaaS製品なら、12個のイベントはこうなります。どれも、誰かがすでに週次レビューで問うている質問に答えるために存在します。

注目すべき点が二つあります。多くはクリックではなく結果で発火します。招待ボタンが押されても、招待自体は失敗することがあります。そして課金イベントは、そもそもブラウザでは起きません。決済プロバイダーのWebhookから届くため、ブラウザだけを見る分析ツールには決して見えません。「アップグレード」のクリックを売上として扱わない限り、それで問題ありません。

アクティベーションは通常、どれか一つではなくこれらの組み合わせです。たとえば「最初の一週間以内にワークスペースを作成し、チームメンバーを招待した」といった定義です。この定義は意図して選んでください。方法はアクティベーションファネルのベンチマークで解説しています。

詳細はプロパティが担い、イベントは動詞を担う

種類ごとにイベントを分けたくなるのを避けてください。report_exported_csv、report_exported_pdf、report_exported_xlsx は、format プロパティを持つ一つのイベント report_exported にすべきです。目安は単純で、合算して見たくなる可能性が少しでもあるなら、それはプロパティ付きの単一イベントです。

プロパティの値はカーディナリティを低く、安定させておきます。生のURLや自由記述を格納したプロパティは、グループ化できない列であり、データではなく装飾になってしまいます。

レポートを静かに壊すイベントトラッキングの失敗

• 結果ではなくクリックで発火させる。「エクスポート」のクリックはエクスポートではありません。リクエストが失敗すれば、イベントはすでに嘘をついたことになります。結果のイベントは、実際に成功してから送りましょう。
• シングルページアプリでの二重発火。再レンダリングされるコンポーネントや二度マウントされるルートは、同じイベントを二回送ることがあります。件数を信じる前に、いくつかのセッションを手で確認してください。
• プロパティに含まれる個人情報。メールアドレス、氏名、クエリ文字列にトークンを含むURLは、すべてのレポートとエクスポートに残ります。代わりにIDやカテゴリを送りましょう。
• 同意の前に計測する。GDPRが適用される場合、訪問者が同意するまで分析を始めてはいけません。これは個々のイベントではなく設定全体の問題なので、同意まで計測を保留するクッキー同意管理で一度に解決してください。
• 名前を変えずにイベントの意味を変える。project_created が複製されたプロジェクトまで数え始めると、変更前後のすべてのグラフが食い違い、誰にも理由がわかりません。新しい意味には新しい名前を与えるか、両者を区別するプロパティを付けてください。
• 担当者のいないイベント。計画のすべてのイベントには、発火が止まったときに気づく人が必要です。担当者のいないイベントは最初に壊れ、最も長く信用されます。

オートキャプチャと明示的イベントは、別の問いに答える

オートキャプチャは計画を求めずに画面上の操作を記録します。これは初期には本当に有用で、まだ思いついていない問いに対するデータがすでに存在し、確認のたびにデプロイを挟まずに済みます。できないのは、あなたの業務領域を理解することです。クリックの記録のどこにも、サブスクリプションが上位プランに変更されたという事実はありません。

現実的な構成は両方を使うことです。探索と、まだ立てていない問いのためのオートキャプチャ。そして、報告と目標設定に使う数値のための、よく名付けられた少数の明示的なドメインイベント。

後からイベントを定義する

オートキャプチャは、問いを「これを計測し忘れていなかったか？」から「取得済みのデータの中から見つけられるか？」に変えます。PulsePandaはすべてのクリックを、要素のid、クラス、表示テキスト、タグ、ページ内の位置とともに記録します。そのため、イベントはそれらを使って後から定義でき、その定義は定義前に記録されたクリックにも適用されます。木曜日に浮かんだ問いに、月曜日のデータで答えられます。

これを信頼できるものにするのは、マークアップ内の安定した目印です。クラスはデザイン改修のたびに、表示テキストは文言修正や翻訳のたびに変わります。重要な数個の操作部品に付けた id は、誰かが変えると決めたときにしか変わりません。

<button id="export-report">Export</button>
<button id="invite-teammate">Invite</button>
<a id="upgrade-plan" href="/ja/billing">Upgrade</a>

#export-report のクリックとして定義したイベントはデザイン改修を越えて生き残り、ボタン内のアイコンやラベルのクリックも数えられます。記録された要素の経路が、idを持つ最も近い要素までさかのぼるからです。

定義したイベントもクリックであることに変わりはなく、前述の限界があります。誰かが試みたことはわかっても、それが成功したことはわかりません。結果については、成功した後に到達するページのほうが正直な指標であることが多いです。「/signup に到達」の次に「/onboarding に到達」というファネルステップは、イベントを一つも使わずに完了した登録を数えます。

イベントを信用する前に確認する方法

1. 自分で発火させ、自分のセッションを探します。イベントは一度だけ、すべてのプロパティが埋まった状態で現れるはずです。
2. 信頼できる元データと件数を比べます。データベースでは先週140件のプロジェクトが作られたのに、分析ツールでは95件なら、誰かがその上にグラフを作る前に差を突き止めてください。広告ブロッカー、同意、失敗したリクエストはいずれも、ブラウザでの件数をサーバー側の件数より少なくします。差は想定外ではなく、一定であるべきです。
3. 発火したセッションリプレイを見ます。数値はそれが起きたことを、録画はそれがあなたの考えたタイミングで起きたことを教えてくれます。
4. ファネルに入れます。必ず先に来るはずのステップなしに現れるイベントは、間違った場所から発火しています。

今週どこから始めるか

製品の中で最も重要な五つの瞬間を書き出し、上の規則で命名し、それだけを実装します。そして一週間後に、それぞれが期待どおりに発火し、プロパティが埋まっていることを確認してください。誰も通らないコードパスで発火するイベントは、イベントがないより悪い状態です。信用されてしまうからです。

追加する前に、すでに送っているイベントの挙動を確認したい場合は、PulsePandaのイベントトラッキングがすべてのイベントとその量、プロパティを一か所に表示し、同じデータをそのままファネルとパスに流し込みます。