サーバーサイド計測

何が移り、その代償は何か

ブラウザサイド計測では、訪問者のブラウザがイベントをそのままベンダーへ送ります。サーバーサイド計測では、ブラウザが自社バックエンドに知らせるか、あるいは何も知らせません。バックエンドはすでにその出来事を知っているからです。そしてイベントを次へ送るのはバックエンドです。同じイベント、送り手だけが違う。その送り手こそが違いのすべてです。

• 得られるもの：訪問者の端末から一度も出ないリクエストを拡張機能は落とせません。送信に失敗しても再試行でき、送る前に中身を検証でき、API キーは自分側の内側に留まります。
• 失うもの：ブラウザが知っていて自社のデータベースが知らないものすべて。リファラー、画面の大きさ、どの要素が押されたか、どこまでスクロールされたか、そしてセッションを縫い合わせていた匿名の識別子です。
• 難しくなるもの：時刻と本人性。ブラウザは*特定の訪問者に、特定のページで、その瞬間に*起きたと知っていました。バックエンドが知っているのは、行がひとつ変わったという事実だけです。残りを組み立て直すことこそが本当の作業になります。

誰も警告してくれない本人性の問題

ブラウザのイベントは最初から文脈を抱えて届きます。どのページか、どのリファラーか、どの匿名 ID か、URL にどんなキャンペーン用のラベルが載っていたか。サーバーのイベントが運ぶのは、保存しておくことを覚えていた分だけです。サーバーサイドへ移す本当の作業はここにあり、それは送信ではありません。誰かが着地したその瞬間に、五分後には消えてしまうから自社のデータベースへ写しておくべきものは何か、と決めることです。

UTMパラメータと広告のクリック ID がもっとも鋭い例です。ちょうど最初の一度きり、ひとつの URL の上にしか存在しないからです。登録時にクリック ID をアカウントに紐づけて残していなければ、三週間後にアップロードするコンバージョンには結びつく先がありません。丁寧に守り抜いた数値が、それを作った目的の問いにもう答えられない、ということになります。その問いこそマーケティングアトリビューションであり、勝負は着地時点で決まっていて、コンバージョン時点ではありません。

自社のコンバージョンをサーバーから送って学んだこと

AgentCeres（agentceres.com の AI Growth Officer）は、見込み度の高いリードのコンバージョンを、誰かのブラウザからではなく自社のデータベースから広告プラットフォームへ送っています。鍵にするのは、その人が最初に着地したときに取得したクリック ID です。意外だったのは送信そのものではありませんでした。HTTP の成功応答は受領証ではない、という点です。アップロードは 200 で返ってくるのに、その中身の行は拒否されており、本当の結果は後から別途行う状態確認でしか見えませんでした。最初に使おうとしたエンドポイントは新規の統合に対して閉じられてもいましたが、それも 200 は教えてくれませんでした。

この形は一般化できます。ブラウザ側では、失われたイベントはある意味で騒がしい失敗です。数値が単純に欠け、穴として見えます。サーバー側では、失敗は自社のログが成功として記録したリクエストなので、穴が事実の顔をします。サーバーへ移すものには、その場の応答を信じるのではなく、ベンダーに「実際に何を保存したのか」と尋ねる検証の一段が要ります。この話の受け取り側の半分、つまりそもそもブラウザのデータがどれだけ失われるのか、そしてなぜ有料で獲得していた層でその欠落がもっとも大きかったのかは、PostHog のページにあります。

同意を回避する手段ではない

サーバーサイド計測は、広告ブロッカーを打ち破れる点を売りにされがちで、仕組みとしては確かにそうです。それが何を意味するのかは正直に言うべきです。ブロッカーは、好みを表明した人が自分で入れたものであり、書き込みを自社サーバーへ移したところで、もともと無かった法的根拠が生まれるわけでも、自社ドメインを経由して他所へ渡ったというだけでそのデータが自社のものになるわけでもありません。

• 同意が支配するのは目的であって、経路ではありません。ブラウザが送るときに同意が要るイベントは、サーバーが送るときにも同意が要ります。
• 自社ドメイン上のプロキシでも、宛先が第三者なら提供は提供です。分類し直すのではなく、プライバシーポリシーにそう書いてください。
• 正直な範囲でたいてい足ります。小さなスタートアップがサーバー側で本当に必要とするものの大半は、登録・プラン・支払いといった自社のプロダクトデータであり、もともとブラウザが送るべきものではありませんでした。