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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

今週どこから始めるか

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

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