サーバーサイドとクライアントサイドのトラッキング

違いをひとことで言うと？

クライアントサイドのトラッキングは文脈を見て、サーバーサイドのトラッキングは事実を見ます。ブラウザーは、UTMパラメーター、参照元、デバイス、ページを知っていますが、ブロッカーによってイベントを失います。バックエンドは、サブスクリプションが始まった、支払いが失敗したといった実際に起きたことを知っていますが、ユーザーがどうやってそこに来たかは何も知りません。このガイドでは、どこで計測するかを扱います。何を記録するか（命名と最初のイベントリスト）はスタートアップのためのイベントトラッキングプランを、そもそもなぜデータをファーストパーティにすべきかはファーストパーティデータとトラッキングを参照してください。どちらの側も、1つのトラッキングプランにまとめます。

クライアントサイドのトラッキングが捉えるもの、取りこぼすものは？

文脈があるのはクライアントサイドです。ブラウザーのSDKは、UTMパラメーター、参照元、ランディングページ、デバイス、セッション中の行動を捉えます。アトリビューションとファネル分析に必要なものすべてです。取りこぼすのは、ユーザーまるごとです。Backlinkoが集計したGWIのデータによると、2025年第2四半期に、世界のインターネットユーザーの29.5%が少なくとも時々は広告ブロッカーを使っていました。約17億7,000万人にあたります。多くのブロッカーは広告と一緒に分析スクリプトも止めるため、クライアントサイドのイベントの一定の割合が、そもそも送信されません。

ブロッカーがなくても、Safariではクライアントサイドのトラッキングでデータが欠けます。WebKitのITPのドキュメントによると、SafariはJavaScriptで設定したCookieの有効期限を7日に制限し、サイトでの操作がないままSafariを7日間使うと、スクリプトから書き込めるそれ以外のストレージ（localStorage、IndexedDB）をすべて削除します。この7日間の利用期間を過ぎると、再訪した訪問者はまったくの新規に見え、ユーザーの識別が途切れます。欠損は測定できます。Plausibleが2021年8月下旬のテストで、Hacker NewsとRedditで話題になったサイトについて自社の数値をGoogle Analyticsと比べたところ、Google Analyticsは訪問者の58.67%を取りこぼしていました。これは技術系の読者が多い極端な例です。Plausibleは、ライフスタイル系のサイトではブロック率が10%未満、技術系のサイトでは25%を超えるとする以前の調査も引用しています。

サーバーサイドのトラッキングが捉えるもの、取りこぼすものは？

サーバーサイドのトラッキングとは、バックエンドが状態の変化をイベントAPIに報告することです。subscription_started、payment_failed、plan_changedなど。これらのイベントはブラウザーではなく自社のサーバーで発生します。そこで記録するのは回避策ではなく、正直な情報源です。経路にブロッカーはなく、ストレージの上限で消えることもなく、件数はデータベースと一致します。データベースから来ているからです。サーバーサイドのイベントが正確なのは、ブラウザーがなんとか報告できたことではなく、システムが実際に行ったことを記録しているからです。死角は文脈です。どのキャンペーン、参照元、デバイスからユーザーが来たのか、バックエンドにはわかりません。その文脈は、クライアントサイドにしか存在しないのです。

クライアントとサーバー、どのイベントをどちらで記録しますか？

小さなチームはどう分ければよいですか？

• お金に関わるもの（トライアル、サブスクリプション、支払い、返金）はすべてサーバーサイドに置きます。解約率やMRRを正確に出す必要があるとき、信頼できる情報源はサーバーです。
• アトリビューションに関わるもの（ページビュー、キャンペーン、参照元）はクライアントサイドに残します。その文脈は後から再構成できません。
• 両方の経路で同じユーザーIDを使って識別します。そうすればファネルがつながり、トラフィックが少ないときのA/Bテストでも、デバイスをまたいで各ユーザーを1つの案に割り当てられます。
• 差は受け入れます。クライアントの数字は構造上少なめに出ます。方向性を見るのに使い、報告する数字にはサーバーのイベントを使ってください。

2つの数字が決して一致しないのはなぜですか？

両方を運用すると、件数は食い違います。それも恒久的にです。クライアントの数字は、ブロッカーとITPがイベントを削るため少なめに出ます。サーバーの数字には、ユーザーがどこから来たかを示す文脈がありません。これは直すべきバグではなく、そういう性質だと認識すべきものです。クライアントの分析とサーバーの事実の間には差が残り続けると想定し、自社のユーザー層でのおおよその大きさを把握し、それ以上追いかけるのはやめてください。それぞれの数字は、正直な側から報告します。アトリビューションとファネルの方向性はクライアントのデータから。投資家向け資料や請求書に載るもの（解約率、MRR、有効なサブスクリプション数）はサーバーのイベントから計算します。IterableやOrttoのようなエンゲージメントプラットフォームが両方のデータソースを受け付けるのも、同じ理由です。

fromHelloではどう扱いますか？

fromHelloは、この使い分けを前提にしています。JS/TS SDKはクライアントサイドで記録し、localStorageを使ったオフラインキューを持ちます。接続が切れている間に発生したイベントは保持され、ブラウザーがオンラインに戻ると再送されます。同じイベントAPIはサーバーサイドからの送信も受け付けるため、subscription_startedはAPIキーを使ってバックエンドから直接送れます。どちらの経路も1つのプロファイルに書き込まれます。SDKが捉えたアトリビューションと、サーバーが送った売上のイベントは、同じ人物を表します。セグメント、ジャーニー、分析はその1つのプロファイルを読みます。分けるのは計測であって、人の識別ではありません。