ブラウザが計測を止める時代の処方箋 ― サーバーサイド・タギング（SST）で取り戻す 「見えなくなったコンバージョン」
ベルリンのしがひです。
前回の記事「サードパーティCookieなしでもマルチタッチアトリビューションは可能か？」で、Cookie廃止時代のマーケティング計測を再構築する5つのステップを紹介しました。
そのステップ2にあたる 「サーバーサイド・タギング／トラッキング（SST）の実装」 は、本来もっと深掘りすべきテーマです。計測基盤の中核を担うにもかかわらず、「GTMがサーバー側にもあるらしい」くらいの理解で止まっている現場が多いのが実情だと感じています。
今回は、そのSSTがなぜ必要で、何を解決し、導入にあたって何に注意すべきかを、実装上の設計ポイントまで含めて整理します。 「ブラウザ側で計測が壊れていく現実に、どう対処するか」 の処方箋として読んでいただければ幸いです。
そもそも「計測が壊れる」とは何が起きているのか
マーケ計測の現場で何年も観測していることですが、この数年で 計測可能なコンバージョンの量そのものが減り続けています。原因は1つではなく、以下が重なった複合的な現象です。
- ブラウザの防御強化：Safari の ITP（Intelligent Tracking Prevention）、Firefox の ETP（Enhanced Tracking Prevention）はサードパーティCookieをデフォルトでブロック。ファーストパーティCookieも、JSで書かれたものは最短7日、ITP 2.3以降はさらに短縮される場合がある。
- 広告ブロッカーの普及：DACHや北欧では広告ブロッカー利用率が30%前後に達し、GA4やMetaピクセルなど主要タグのリクエストがそもそもネットワーク層で切断される。
- OS/ブラウザの同意・権限UX：iOS 17以降のLink Tracking Protection、Safariのプライベートリレー、Chromeのトラッキング保護など、ユーザーの明示操作なしに識別子が剥がされる実装が増えている。
- 同意制御の厳格化：GDPR、ePrivacy、CCPA、そして2026年の日本の個人情報保護法改正（詳細はこちらで書きました）により、同意なしにタグを発火できない領域が拡大。
結果として、広告配信側から見ると 「ユーザーはコンバージョンしているのに、プラットフォームにシグナルが届かない」 という状態が常態化しています。Usercentricsの調査では、サーバーサイドに切り替えた企業で 計測可能コンバージョンが +46%、ROAS が改善、CPA が最大 -57% という事例が報告されています。逆に言えば、それだけのシグナルが現時点で失われているということです。
従来のタギング（クライアントサイド）の構造的限界
話を整理するために、まず「今のタギング」がどう動いているかを図にします。
現在の多くのサイトは、ブラウザ側の GTM（Web コンテナ）に GA4 タグ、Google Ads のコンバージョンタグ、Meta ピクセル、アフィリエイトタグ…と、数十〜数百のタグが同居しています。ブラウザは画面を描画するだけでなく、広告・分析ベンダーへ直接 HTTP リクエストを吐く配信エージェント として振る舞っているわけです。
この構造には、以下の構造的な弱点があります。
- ブロッカブル：
google-analytics.comやfacebook.com/trといったドメイン名が広告ブロッカー・ブラウザのトラッキング防御リストに載っているため、リクエスト自体が発射前に止められる。 - ブラウザ制約に従わざるを得ない：Cookie の SameSite、Secure、有効期限、ストレージパーティショニング等、ブラウザが定めるルールの範囲内でしか ID が維持できない。
- 同意制御とタグ発火の責任分界が曖昧：同意カテゴリと各タグの発火条件を GTM のトリガーで個別に組まなければならず、監査証跡が作りにくい。
- パフォーマンス負荷がユーザー端末に集中：モバイル回線で数十のサードパーティタグを読み込むコストは、LCP/INPに直接響く。
- ベンダーにナマのデータが渡る：IPアドレス、User-Agent、詳細なUTMパラメータなど、本来は不要な情報まで第三者に送信される。
つまり、「ブラウザで全部やる」前提のタギングは、計測の正確性・プライバシー・パフォーマンスのすべてでトレードオフが悪化する方向にある、というのが現状認識です。
サーバーサイド・タギング（SST）で何が変わるか
SST は、ブラウザから直接 GA4 や Meta にデータを投げるのをやめ、いったん "自社管理下の" サーバー（sGTM = Server-side Google Tag Manager）に集約し、そこから広告/分析プラットフォームに配信する 仕組みです。
ブラウザ側には薄い「Web タグ」だけを残し、実際のサードパーティ送信はサーバーサイドで行います。このわずかな構造変更で、先ほど挙げた弱点の大半が解ける、というのが SST の要点です。
- ブラウザが叩くのは自社のファーストパーティドメイン（例：
sst.example.com）なので、広告ブロッカーの拒否リストに載りにくい。 - Cookie の発行主体がサーバーになるため、HTTP-only かつ長期の ファーストパーティ Cookie として管理できる。
- 同意シグナルは CMP → サーバー → 各タグへと一本化され、同意カテゴリに応じた発火ルールを サーバー側で強制 できる。
- ユーザー端末で動かす JS は最小化され、ページ表示速度が改善する。
- サードパーティに送る前に、サーバー側で PII の除去、IP の切り詰め、パラメータの正規化、重複排除 といった前処理を入れられる。
このアーキテクチャが、Cookieless 時代のマーケティング計測の「配信基盤」になる、というのが業界のコンセンサスになりつつあります。
SSTが解決する課題を整理する
「速くなります」「計測精度が上がります」というメッセージは耳障りは良いのですが、実際のマーケや情シスの現場で組み立てなければならないのは、もう少し分解された論点だと思っています。以下、SSTが解決する課題を5つの軸で整理します。
1. データ品質・計測精度
- 広告ブロッカー・ITP/ETPでデータが欠損する問題に対して、ファーストパーティドメインで受信することでブロックを回避。
- クライアント側 JS で発行する Cookie は短命化が進むが、サーバーサイド発行なら長期維持可能。
- iOS の Meta ピクセルで信号が抜け落ちる問題に対しては、Meta Conversions API（CAPI）へサーバー経由で送信することでアトリビューションを補強。
- 同一イベントをクライアントとサーバーの両方から送った場合の重複排除（deduplication）もサーバー側で一元管理できる。
2. プライバシー・コンプライアンス
- GDPR / CCPA / ePrivacy / 改正個人情報保護法などへの対応にあたって、送信前のデータをサーバー側で検閲できる のは決定的に大きい。
- Google Consent Mode v2 のシグナルをサーバーサイドで解釈し、同意カテゴリに応じたタグ発火ルールを一箇所で適用できる。
- 医療・金融・教育など機密データを扱う業種では、「何をどこに送るかを自社がコントロールできる」という論点が監査対応上も重要。
- 注意点：SST を入れただけで GDPR に自動準拠するわけではない。有効な同意取得（CMP）が前提で、そこと組み合わせて初めて実効性のあるコンプライアンスが成立する。
3. サイトパフォーマンス・UX
- サードパーティタグをサーバーにオフロードすることで、ブラウザで実行される JS が減り、LCP/INP などの Core Web Vitals が改善する。
- Google の Think With Google 事例では、SST 導入で ページロードが最大 5.6秒短縮、LCP が 11% 改善 と報告されている。
- モバイル端末・低速回線では特に効果が大きく、バウンス率とコンバージョン率の両方に効く。
- SEO ランキングへの副次的な影響も無視できない。
4. マーケティングROI・広告効果
- CAPI など "サーバー to サーバー" のファーストパーティデータ連携により、広告プラットフォームの入札最適化に使える学習データの質が上がる。
- 同意済みユーザーだけを対象に、安定した識別子（ハッシュ化メール、ログインID、ファーストパーティCookie）でコンバージョンを返せる。
- 主要プラットフォーム（Google Ads、GA4、Meta CAPI、LinkedIn Conversion API、TikTok Events API、Pinterest、Reddit、Awin など）にテンプレート連携が用意されており、マーケ側で実装ハードルが大幅に下がる。
- 事例としては、Irish Iron でコンバージョン +30% / 有料CPA -22%、New Path Digital で CPA -57%、Square で計測可能コンバージョン +46% など。
5. データガバナンス・運用
- サーバーサイドのログで「受信したリクエスト／送信したリクエスト」をすべて追跡でき、データフローの監査がやりやすい。
- 機密データや PII は送信前にフィルタ・マスキング・ハッシュ化して外部プラットフォームに渡せる。
- 「どのベンダーに何を渡しているか」が可視化され、ベンダーロックイン・データ主権の議論にも耐える。
- マネージド型の SST（Usercentrics Server-Side Tagging など）を選ぶと、GCP インフラの自前運用やオートスケール設計、料金予測の難しさといった運用負担から解放される。
採用トレンド：今どの辺にいるのか
Usercentrics / Fortune Business Insights / Awin などの調査を総合すると、SSTの普及カーブはだいたい以下のようなフェーズにあります。
（出典：Usercentrics 調査 / Fortune Business Insights / Awin ほか）
- 2021年頃：普及率は5%前後。アーリーアダプター中心で、導入していたのは自前で sGTM をGCPに立てられる体力のある企業。
- 2025年（現在）：SMB 層でも 20〜25% が導入済み。マネージドSST ベンダーの登場により、自前運用の負担が下がった。
- 2027年（予測）：データドリブン組織の標準構成として、業界全体で約70%が採用すると見込まれている。
個人的な肌感としても、ベルリンで接する中堅以上のEC・SaaS 事業者で SST を「検討中」と言う会社はもう少なく、多くは「導入済み」か「今期のロードマップに入っている」か のどちらかです。2027年には「入れているのが前提」の世界になる、という Usercentrics の予測はそこまで大げさではないと見ています。
ファーストパーティデータ戦略の中核に位置する
もう少し大きな絵で捉え直すと、SST は単体の計測ツールというより、ファーストパーティデータ戦略のハブ として機能します。
- CMP で取得した同意に基づき、
- サイト上で発行する ファーストパーティCookie・ログインID・ハッシュ化メールアドレス等の識別子を、
- サーバーサイドに集約し、
- Meta / Google Ads / GA4 / LinkedIn / TikTok など各主要チャネルへ、同意レベルに応じてフィルタリングされた形で 配信する。
前回のMTAの記事でも書いたとおり、サードパーティCookieに依存した計測は持続可能ではありません。ファーストパーティ中心に軸を移すとき、「誰が、いつ、何に同意し、どのデータがどこへ送られたか」をエンドツーエンドで統御する基盤 が必要になります。SST はそこを埋めるレイヤーです。
CMP と SST の関係 ― なぜ両方必要なのか
ここで整理しておきたいのが、CMP（Cookiebot や Usercentrics Web CMP）と SST の役割分担です。
| レイヤー | 責務 | 代表プロダクト |
|---|---|---|
| CMP | ユーザーからの同意取得、同意カテゴリ別の管理、同意ログの保全 | Cookiebot / Usercentrics Web CMP |
| タグマネージャー（Web） | ブラウザで発火する必要最小限のタグ管理（ページビュー、イベント） | Google Tag Manager Web Container |
| SST（サーバー） | ファーストパーティ識別子の発行・保持、同意シグナル適用、PII フィルタ、サードパーティへの配信 | sGTM / Usercentrics Server-Side Tagging / Stape / Jentis |
| 分析・広告プラットフォーム | データの取り込みと意思決定 | GA4, Google Ads, Meta CAPI, LinkedIn CAPI 等 |
CMP は「同意を取るレイヤー」、SST は「同意に従ってデータを流すレイヤー」。どちらか片方だけでは、法令対応とデータ品質の両立 は成立しません。CMP だけでは、せっかく取った同意シグナルが各広告タグに正しく伝わらずコンバージョンが抜ける。SST だけでは、そもそも同意を取得・記録する機構がなく課徴金リスクが残る。
Cookiebot（CMP）と Usercentrics Server-Side Tagging（SST）の組み合わせは、この2層を 同一ベンダー内でOut-of-the-Box 連携できる 点が大きな差別化要因になっています。他社の SST（Stape、Jentis 等）でも技術的には連携できますが、同意シグナルのデータモデルや更新タイミングを自前で整合させる必要があります。
日本企業にとっての示唆
ここまでの話は、欧州だけの話ではありません。むしろ日本の方が、これから一気にキャッチアップする必要があると感じています。
- 2026年の個人情報保護法改正：個人関連情報（Cookie IDを含む）の規制が強化され、課徴金制度が導入される。マーケティング目的のCookie利用は明確に「強化」の側に区分される。詳細は2026年個人情報保護法改正にともなうCookie、Trackerのマネージメントについてで解説しました。
- Google Consent Mode v2 の対応期限：Consent Mode v2に準拠していないと、EU 向け配信でGoogle Adsのリマーケティングリストが使えなくなる等の実害が発生する。日本発でも EU ユーザーがいる以上、影響は無視できない。
- Core Web Vitals のSEOランキング要因化：モバイル中心の日本市場では特にパフォーマンス影響が大きい。
- 2027年までに SST が標準構成になる見通し：今のうちに基盤を整えないと、広告プラットフォーム側の機能差で競合に後れを取る。
つまり、日本企業にとっても 「CMPの導入」と「SSTの導入」はセットで検討する時期 に来ています。個別対応で済むフェーズはもう過ぎていると考えた方が安全です。
CME としてのスタンス ― 解決策を一本に繋ぐ
Classmethod Europe（CME）では、これまで Cookiebot のプラチナムパートナーとしてCMPレイヤーのご支援をしてきましたが、このたび Usercentrics Server-Side Tagging のテクノロジーパートナー にもなります。これにより、
- 同意取得・同意ログ保全（Cookiebot）
- CMP → SST の同意シグナル連携
- sGTM 環境のマネージド提供（Usercentrics SST）
- GTM Web コンテナ側のタグ運用・改修（CME のマネージドサービス）
- Consent Mode v2、Meta CAPI、Google Ads / GA4 のサーバーサイド連携設定
までをお任せいただけるようになります。「CMPは入れたがサーバータグはこれから」「sGTM を立てたいが GCP を自社運用する体力がない」「複数サイトでバラバラに導入されているものを整理したい」といった課題に、実装できる技術で応えます。
料金面でも、Usercentrics SSTには 契約から1年間、月20,000リクエストまで無料のStarter プラン が用意されており、当面、検証環境をCMEで用意することができます。まずは1サイトだけ、最小リクエストでテスト導入 → 効果検証 → 全社展開、という段階的な進め方がやりやすくなっています。
まとめ
計測が壊れていく環境下で、マーケターが取れる選択肢は大きく3つです。
- 何もせず、シグナルが抜け落ちていくのを受け入れる
- 部分的な対応（Consent Mode v2 のみ、CAPI のみ等）で個別最適化する
- CMP × SST × ファーストパーティ戦略 で計測基盤そのものを作り直す
選択肢 1. は課徴金リスクとROI悪化が累積する一方で改善余地がなく、選択肢 2. は応急処置にはなるものの、2027年以降も通用する構造にはなりにくいと考えます。選択肢 3. は工数がかかりますが、プライバシー規制・ブラウザ動向・広告プラットフォームのいずれに対しても持続可能で、投資対効果が明確に出るアプローチです。
SSTは、その選択肢 3 の 「配信基盤」 のパート を担うレイヤーです。Cookiebot のような CMP と組み合わせることで初めて、同意を起点にした、信頼性の高い計測モデルが成立します。
「何から始めればいいか分からない」「すでに Cookiebot は入っているが、サーバーサイド側をどう設計すべきか相談したい」「複数サイト一括で整理したい」といったご相談があれば、Cookiebot のお問い合わせ窓口（cookiebot.jp）か、Classmethod Europe までお気軽にどうぞ。SST のスコーピングから設計・実装・運用まで、前回の MTA 記事で書いた5つのステップに沿って伴走します。
