なぜ計測を自前のEdgeビーコンだけに絞ったのか — 実装の中身を見せる

1. 課題

サードパーティ製の計測ツールは導入が速い一方、Cookie同意バナーの複雑化とページ表示速度の劣化という代償を伴う。tip.co.jpでは、この両方を避けるために自前のCookieレス・ファーストパーティ計測だけを採用した。

2. 設計判断

• トラッキングはlocalStorageの匿名IDのみに依存し、Cookieを一切発行しない。
• ビーコンは3KB未満に抑え、navigator.sendBeaconでページ遷移をブロックしない。
• 収集したデータはCloudflare D1に書き込むのみで、外部のCRMや要約サービスへは一切連携しない。

3. 実際の受信側の実装

抽象的な設計方針だけでなく、実際にどう実装しているかを見せたい。本サイトのビーコンを受け取るCloudflare Workerの処理は、大きく3つのステップで構成されている。

第一に、受信データの形を厳密に検証する。 visitor_idは64文字以内の文字列、pathとreferrerは2,048文字以内、滞在時間とスクロール率は有限の数値であること――これらの条件を1つでも満たさないリクエストは、即座に処理を打ち切る。この型チェックを通過しないデータは、DBへの書き込みを一切試みない。

第二に、数値を安全な範囲に丸め込む。 例えば滞在時間は0〜86,400秒（24時間）、スクロール到達率は0〜100%の範囲に強制的にクランプしてから保存する。クライアント側のバグや悪意ある入力によって、あり得ない値（負の滞在時間や1000%のスクロール率など）がDBに紛れ込むことを防ぐための処理だ。

第三に、書き込みが失敗しても、ビーコン送信元には常に成功と同じ応答を返す。 これは「ビーコンは発火させたら結果を待たない（fire-and-forget）」という性質上、計測処理の失敗がページの表示や動作に影響を与えてはならない、という設計判断による。DB書き込みが失敗した場合はサーバー側のログにのみ記録し、訪問者のブラウザには常に空のレスポンス（ステータスコード204）を返す。

4. データベース側の構造

書き込み先のCloudflare D1データベースには、匿名の訪問者ID・初回訪問日時・最終訪問日時を持つテーブルと、個々の閲覧イベント（パス・滞在時間・スクロール率・リファラー・発生日時）を持つテーブルの、2つだけが存在する。同一の訪問者IDでの再訪問は、初回訪問記録を新規作成するのではなく、最終訪問日時のみを更新する形で処理される。氏名・メールアドレスのような個人を特定できる情報は、この構造上どこにも存在しない。

5. この設計で失っているもの、得ているもの

この構成により、「何が読まれているか」という社内リサーチの目的だけを満たしつつ、訪問者のプライバシーと表示速度のどちらも犠牲にしない構成になっている。一方で、失っているものもある。訪問者ごとの詳細な行動履歴を使った高度なパーソナライゼーションや、サードパーティCDPが提供するようなセグメント分析・A/Bテスト連携といった機能は、この最小構成では持たない。TIPにとっては、そうした機能よりも「計測の透明性とページ表示速度」を優先する、という編集方針上の選択である。