サーバーサイド計測とは？｜Cookie制限が強まる中でファーストパーティ計測基盤を作る理由

広告の管理画面と自社の解析ツールで、コンバージョン数がなぜか一致しない。そんな経験はありませんか。

原因を探っていくと、たいてい同じところに行き着きます。ブラウザの中だけで完結する計測タグが、送るはずだったデータの一部を途中で取りこぼしているのです。

この取りこぼしに正面から向き合う考え方が、サーバーサイド計測です。特定の企業名や派手な数字がなくても、仕組みだけで十分に理解できる話なので、順番に整理していきます。

この記事では、ブラウザ側の計測がなぜ弱くなっているのかという背景から、サーバー経由でデータを送る仕組み、そして自社にはどこまで必要かを判断する基準までをたどります。

なぜ今、計測基盤の話が必要なのか

まずは背景から押さえましょう。ブラウザという土台そのものが、ここ数年でかなり変わってきています。

ブラウザ側で何が起きているか

Appleのブラウザ標準機能であるITP（Intelligent Tracking Prevention）は、既定でサードパーティCookieをブロックしています。SafariでWeb広告のクリック計測がうまく機能しないという相談は、この機能が原因であるケースが大半です。

FirefoxもEnhanced Tracking Protectionという仕組みで、同じ方向の制限をかけています。加えて、広告ブロッカーや一部のセキュリティ拡張機能は、外部ドメインへ送られる計測用の通信そのものを止めてしまいます。

Cookie同意バナーの存在も無視できません。 同意しなかった訪問者の行動は、多くの実装で丸ごと計測から抜け落ちます。この歪みについてはCookieレスでウェブ解析はどこまでできる？同意バナーが要らない理由で数字を使って詳しく扱いました。

方針が変わっても、流れは変わらない

Googleは2024年、Chromeにおけるサードパーティ Cookie廃止の方針を撤回すると発表しました。数年越しの計画が覆った、業界では大きなニュースです。

ただ、ここで安心してしまうのは早計です。Safariは既にサードパーティ Cookieを規定でブロックしていますし、広告ブロッカーの普及も止まっていません。

一社の方針が変わっても、ブラウザ全体としての制限が緩む方向に戻ったわけではないのです。だからこそ、Cookieに依存しない計測の考え方を持っておく価値は、以前より下がっていません。

ファーストパーティ計測とサードパーティ計測の違い

用語の整理から始めます。この区別を曖昧にしたまま話を進めると、あとで必ず混乱します。

発行者による違い

自社のドメインが発行し、自社のためだけに使われるのがファーストパーティです。外部のドメインが発行し、サイトをまたいで同じ人を追跡できてしまうのがサードパーティ、という整理でした。

この定義そのものはCookieレスでウェブ解析はどこまでできる？同意バナーが要らない理由で扱った通りです。今回はその先、通信の経路に焦点を当てます。

誰が受け取り、誰が転送するのか

一般的な計測タグは、訪問者のブラウザから広告プラットフォームや解析ツールのドメインへ、直接データを送ります。これがクライアントサイド計測です。

一方、サーバーサイド計測では、ブラウザはまず自社が管理するサーバーへデータを送ります。外部プラットフォームへの転送は、その自社サーバーが担当します。

図にすると違いがはっきりします。

[クライアントサイド]
訪問者のブラウザ → 広告プラットフォームのドメインへ直接送信

[サーバーサイド]
訪問者のブラウザ → 自社ドメイン（計測用サーバー）→ 各プラットフォームのAPIへ転送

自社ドメイン宛のリクエストは、外部の広告ドメイン宛のリクエストに比べてブロックの対象にされにくいという性質があります。ここが、サーバーサイド計測がわざわざ経由地を増やす理由そのものです。

見た目の違いは経由地が増えるだけですが、この一手間が計測の安定性を大きく左右します。

サーバーサイドタグ管理とは何か

この考え方を体系立てて提供する仕組みが、サーバーサイドタグ管理です。国内では「サーバーサイドGTM」という呼び方も定着しています。

何が変わるのか

Googleはタグマネージャーの機能として、クラウド上で動くサーバーコンテナを提供しています。従来のブラウザ上で動くコンテナと役割は同じで、動く場所だけがサーバー側に移ります。

訪問者のブラウザからは、自社ドメイン宛のリクエストが1本届くだけに見えます。そこから先、どの広告プラットフォームへ何を送るかは、サーバー側の設定がすべて引き受けます。

比較すると、両者の違いがより具体的につかめます。

得られる効果と、それに見合う代償

得られる効果は主に三つです。自社ドメインへのリクエストはサードパーティ判定を受けにくく、ITPの影響を受けにくくなります。ブラウザ側で動くスクリプトの量が減るぶん、ページの表示速度にもプラスに働きます。

さらに、外部へ何を送るかを自社サーバー側でコントロールできるようになるため、個人情報の取り扱いを見直す機会にもなります。

一方で、代償もはっきりしています。サーバーを構築し、動かし続ける役割が新たに発生します。タグの設定ミスがそのままサーバーの障害になり得るという運用リスクも増えます。

サーバーコンテナのコストという現実

具体的なイメージを持つために、仮の数字で考えてみます。ここでの金額はあくまで説明用の仮定であり、実在の料金ではありません。

クラウド上でサーバーコンテナを常時稼働させると、アクセス量にもよりますが、月あたり数千円から数万円のインフラ費用がかかるとします。これに加えて、初期構築とその後の保守にあたる担当者の工数が発生します。

金額そのものより、継続的に見続ける人が必要になるという点のほうが本質的な負担です。担当者が異動すれば、設定の意図が引き継がれないまま放置されるリスクが残ります。

小さなチームであれば、この運用コストが実利を上回ることも珍しくありません。導入は「できるかどうか」ではなく「割に合うかどうか」で判断すべき性質のものです。

広告プラットフォームへのサーバー間送信という考え方

サーバーサイド計測の中でも、特に広告の効果測定を目的にした仕組みを見ていきます。

なぜ必要とされているのか

主要な広告プラットフォームは、ブラウザ上で動くピクセルタグに加えて、広告主のサーバーから直接イベントを送るAPIを用意しています。ピクセルだけでは取りこぼす成果を、サーバー経由の送信で補う狙いです。

考え方はシンプルです。ブラウザからの通信がブロックされても、サーバー同士の通信であれば、ブラウザ側の制限をそもそも経由しません。広告の自動入札は、届いた成果データを学習材料にして次の配信先を決めています。

つまりここで送る先は自社の分析ではなく、広告プラットフォームの最適化エンジンです。この違いを混同すると、次の判断を誤ります。

何のためのものではないか

ここで注意したいのは、この仕組みが向いている先です。あくまで広告プラットフォームの学習データを補うためのものであり、自社サイトの導線分析そのものを高度化する仕組みではありません。

導線の中のどこで離脱しているかを知りたい場合に必要なのは、広告APIとの連携ではなく、セッション単位でファネルを追える解析基盤です。目的を取り違えると、投資の優先順位そのものを間違えます。

使うときに気をつけたいこと

まず、ピクセルとサーバーの両方から同じ成果を送ると、二重計上が起こります。プラットフォーム側で同じイベントだと判定させるための識別子を、両方の送信で一致させておく必要があります。

次に、送る中身です。メールアドレスなどの個人情報をハッシュ化して送る運用が一般的ですが、そもそも何を誰に送るのかは、同意管理の方針と矛盾しない形に揃えておく必要があります。

広告効果の考え方そのものは広告のROIを上げる｜LPとファネルで「無駄打ち」を減らすでも扱いました。サーバー間送信は、そこで前提にしていた「正確な成果データ」を確保するための土台にあたります。

自社の導線分析には、どこまで必要か

ここまでの話は、主に広告プラットフォーム側を向いた施策でした。では、自社サイトの中の導線分析にはどこまで必要なのでしょうか。

広告最適化目的と自社分析目的を分けて考える

広告の自動入札を最適化したいなら、サーバー間送信はほぼ必須です。学習データが欠ければ、入札の精度そのものが落ちてしまうからです。

一方、自社サイトのどこで離脱が起きているかを知りたいだけなら、話は変わってきます。Cookieに依存せずセッション単位で導線を追う解析ツールであれば、そもそもブラウザ側のCookie制限の影響を受けにくい設計になっています。

MonaLensはこの立ち位置の解析ツールで、Cookieを使わずにファネルやN1分析を成立させています。広告プラットフォームへの成果連携が主目的でない限り、サーバーサイドの大掛かりな基盤を組む前に検討する価値がある選択肢です。

どちらが正解ということではなく、目的によって必要な仕組みが変わる、というだけの話です。ここを混同すると、社内で「なぜ両方の仕組みが要るのか」といった不毛な議論が起きがちです。

小規模サイトがまずやるべきこと

いきなりサーバーを構築する前に、確かめておくべき手順があります。

• 広告管理画面が報告する成果件数と、自社解析が記録した成果件数を並べて比べる
• その差が予算配分の判断に実際に影響しているかどうかを確認する
• 影響が小さければ、サーバーサイド計測の優先度は下げてよいと判断する
• 影響が大きければ、まず広告費の大きい媒体ひとつに絞って試してみる

解析ツールそのものの選び方はGA4は難しい？「導線計測」に絞るという選択肢でも整理しました。基盤を足す前に、まず今のツールで何が測れていないのかを明確にする作業が近道です。

導入するかどうかの判断基準

判断に迷ったときの目安を、状況別に整理しました。自社がどこに当てはまるかを考えながら読んでみてください。

アトリビューションの限界そのものはアトリビューションの実務｜完璧を諦めて意思決定に使うで扱った通りで、サーバーサイド計測はその限界を減らす手段のひとつに過ぎません。万能ではないと分かった上で使うと、期待値を見誤らずに済みます。

数字で見る判断材料（説明用の仮定です）

イメージをつかむため、仮の数字で考えてみましょう。以下はあくまで説明用の仮定であり、実在の統計ではありません。

月間広告費が300万円、目標CPA（1件あたりの獲得コスト）が1万円のアカウントを想定します。ブラウザ側の計測だけで成果が2割少なく記録されると、システム上は300件の獲得を240件としか認識しません。

この状態が続くと、自動入札は本来伸ばすべき配信先を過小評価し、逆に成果の薄い配信先へ予算を寄せてしまうことがあります。欠損が金額そのものではなく意思決定の質に効いてくる、という点が実務上の急所です。

よくある落とし穴

導入した後につまずきやすいポイントは、だいたい決まっています。

• ピクセルとサーバーの両方から同じイベントを送り、成果が二重に計上される
• 個人情報の送信範囲が、社内の同意管理ルールと食い違ったまま運用される
• 導入した担当者が異動し、設定の意図が誰にも分からないまま放置される
• 効果を検証しないまま「入れたら終わり」で振り返りが行われない

いずれも技術的な難易度というより、運用体制の問題です。導入前に、誰が継続して見るのかを決めておくだけで、多くは防げます。

まとめ

サーバーサイド計測は、ブラウザ側の制限が強まる中で、広告プラットフォームに正確な成果データを届けるための土台です。Googleの方針転換のような揺り戻しがあっても、ブラウザが訪問者を保護する方向自体は変わっていません。

大切なのは、目的を混同しないことです。広告の自動入札を支えたいのか、自社の導線を理解したいのか。前者ならサーバー間送信の価値は大きく、後者ならCookieに依存しない解析ツールで足りることも多いはずです。

導入するかどうかを決める前に、まずは今の数字がどれだけズレているかを測ることから始めてください。仕組みを足すかどうかは、そのズレの大きさが答えを教えてくれます。

大掛かりな基盤より先に、小さな検証から。この順番を守るだけで、無駄な投資を避けやすくなります。

半年に一度は、広告管理画面と自社解析の数字のズレを測り直す機会を作ってください。広告費の規模や事業のフェーズが変われば、今日の判断がそのまま正解であり続けるとは限りません。