計測と広告をブラウザに邪魔させない - サーバーサイドGTMとUsercentrics SSTを使ってファーストパーティ計測環境を構築してみた

計測と広告をブラウザに邪魔させない - サーバーサイドGTMとUsercentrics SSTを使ってファーストパーティ計測環境を構築してみた

ブラウザの制約が強まるなか、GA4やGoogle Adsの計測タグが正しく動かないケースが増えています。この課題を解決するサーバーサイドGTM(sGTM)について、実際にUsercentrics SSTを使ってセットアップしてみました。
2026.07.08

ベルリンオフィスの小西です。

GA4やGoogle Adsの計測タグ、ちゃんと動いていますか。ブラウザ側の制約が年々きつくなっていて、タグを埋めているのにデータが取れていない、というケースが普通に起きるようになっています。

サーバーサイドGTM(以下 sGTM)を使えばこのあたりを改善できるという話は前から聞いていたものの、触ったことがなかったので実際に試してみました。

背景や課題の詳細は以下の記事にまとまっていますので、あわせてどうぞ。

https://dev.classmethod.jp/articles/how-usercentrics-sst-solve-broken-marketing-measurement/

サーバーサイドGTM(sGTM)とは

通常のGTMでは、ブラウザが google-analytics.comfacebook.com といった各プラットフォームのエンドポイントに直接データを送信します。送信先のドメインが既知のトラッキングドメインなので、ブラウザやその拡張機能によって通信ごと遮断されることがあります。

sGTMでは、ブラウザからのリクエストをまず自社ドメインのサーバーで受け取り、そこからGA4やGoogle Ads、Metaなどに転送します。個別に届け先へ直送するのではなく、一度自社の配送センターに集約してから各所に配るイメージ。

ただし、sGTMのサーバー環境は通常Google Cloud Platform(GCP)上などに自前で構築する必要があり、インフラコストがかかります。

ユーザー同意との関係

sGTMはデータの経路をサーバー側に移すだけ、それ自体が同意管理をしてくれるわけではありません。GDPRやePrivacy指令の下では、計測データを送る前にユーザーの同意を取る必要があり、同意していないユーザーのデータはGA4などに転送しないよう制御する仕組みが別途必要です。

そのために必要なのがCMP(同意管理プラットフォーム)です。CMPがブラウザ側で同意を取得し、その同意シグナルをsGTMに渡すことで、サーバーコンテナ側で「同意済みならGA4に転送、未同意なら止める」判定ができるようになります。

Usercentrics SSTとは

Usercentrics SST は、sGTMの実行環境をマネージドで提供してくれるサービスです。

同社はCookiebotというCMP(同意管理プラットフォーム)も提供しているため、同意の取得・収集・タグ配信を一気通貫で提供します。

Starterプランは無料で、月2万リクエストまで利用可能。クレジットカードの登録も不要です。ただしカスタムドメインは1つまでという制約があります。

実際にセットアップしてみた

構成

今回は以下の構成で試しました。

  • テストサイト: sst-webapp.example.com(静的HTML=同意バナーを表示するサイト)
  • sGTMカスタムドメイン: sst-server.example.com(データ収集レイヤー)
  • GTM Webコンテナ(GTM-XXXXXXX)+ GA4(G-XXXXXXXXXX
  • Usercentrics SST(Starterプラン)
  • Cookiebot CMP(同意バナー)

1. GTMサーバーコンテナの作成

GTM管理画面で新しいサーバーコンテナを作成します。プロビジョニングは「手動設定」を選択します。

Screenshot 2026-06-25 at 15.05.28

コンテナを手動設定にすると設定IDが発行されます。後ほどUsercentrics側に入力するのでコピーしておきます。

Screenshot 2026-07-07 at 18.56.04

2. Usercentrics SSTでsGTMホスティングを作成

https://sst.usercentrics.eu/ からUsercentricsのアカウントを作成し、SST管理画面からsGTMコンテナを作成します。

Screenshot 2026-07-07 at 18.58.50

コンテナ管理画面で、status=activeになっていればOKです。
Screenshot 2026-07-07 at 19.01.21

カスタムドメイン(DNS)の設定

sGTMはデフォルトだと xxxxx.server.usercentrics-sst.io というドメインでホストされます。このままでも使えるのですが、ブラウザからは3rd-partyリクエスト扱いになり、sGTMのメリットを活かせません。

DNSにCNAMEレコードを追加して、自社サブドメイン(今回は sst-server.example.com)をsGTMサーバーに向けます。これによりファーストパーティドメインからのリクエストとして扱われるようになります。

カスタムドメインを設定し、指定されたCNAMEをDNS側にも追加します。
Screenshot 2026-07-07 at 19.03.32

DNS含め設定完了してしばらくするとactiveになります。
Screenshot 2026-07-07 at 19.05.44

3. GTM Webコンテナ側の設定

GTM管理画面で新しいWebコンテナを作成します。(先程のサーバーコンテナとは別で作成)

Webコンテナ内のGA4タグ(Googleタグ)の設定パラメータに server_container_url を追加し、値に https://sst-server.example.com を設定します。

これでブラウザからのGA4計測リクエストが、Googleのサーバーではなく自社ドメインのsGTMに送信されるようになります。

Screenshot 2026-07-07 at 19.07.45

4. GTMサーバーコンテナ側の設定

GTMサーバーコンテナに戻り、受け取ったデータをGA4に転送するための設定を行います。

クライアント: GA4クライアントを追加(Webコンテナからのリクエストを受け取る)

サーバーコンテナに届くリクエストは、そのままでは生のHTTPリクエストです。クライアントはこれを解析して、GTMが扱えるイベントデータに変換する役割を持っています。

Screenshot 2026-07-07 at 19.13.15

タグ: Google アナリティクス: GA4タグを作成し、測定IDを設定

サーバーコンテナ側では x-ga-gcs 変数を使って、ユーザーの同意状態を判定できます。未同意時にGA4タグを発火させない除外トリガーを設定します。

Screenshot 2026-07-07 at 19.12.30

5. Cookiebot CMP(同意バナー)の設定

テストサイトにCookiebot CMPを導入し、同意バナー(下記)を表示します。

Screenshot 2026-07-07 at 19.10.35

Cookiebotについてはすでにたくさん記事があるので、細かい方法は割愛します。

以上で設定は完了です。

動作確認

リクエストの確認

テストサイト sst-webapp.example.com にアクセスし、挙動を見てみます。初回訪問時に同意バナー
Screenshot 2026-07-07 at 19.21.23

ブラウザのDevTools(Networkタブ)を開くと、GA4の collect リクエストの宛先がGoogleのサーバーではなく、自社ドメイン(この例ではsst-server.classmethod.live)を経由していることが確認できます。

Untitled(20)

GA4のリアルタイムレポートでも、イベントが正常に届いていることを確認できました。

Screenshot 2026-07-07 at 18.00.19

同意前のリクエストについて

なお、CMPで同意する前から collect リクエストが飛んでいるのがわかると思います。

これは設定ミスではなく、Google Consent Mode v2の仕様です。同意前のリクエストには gcs=G100 というパラメータが付与されています。G1 はConsent Modeが有効であること、00ad_storageanalytics_storage がともにdenied(未同意)であることを示しています。

この状態ではCookieは設定されず、個人を識別できるデータは含まれません。Googleはこのデータをモデリング(統計的推定)用にのみ使用します。

ちなみに同意すると gcs=G111 (granted=同意済み)に変わります。

sGTMの旨み

sGTMのメリットを整理します。

1. 広告ブロッカーによるブロック回避

クライアントサイドGA4のリクエスト先は google-analytics.com で、これはほぼすべてのフィルタリストに載っています。sGTM経由にすると宛先が sst-server.example.com に変わるので、サイト自体へのリクエストと区別がつきにくくなります。

ただし万能ではありません。AdGuardやEasyPrivacyなどのフィルタリストは、sGTM用サブドメインのパターンを検知対象に追加し始めています。

2. ITP(Safari)の影響軽減

SafariのITPは、JavaScriptで設定されたファーストパーティCookieを最短7日で失効させます。sGTMではサーバー側で Set-Cookie ヘッダーを使ってCookieを設定するため、ファーストパーティCookieとして本来の有効期限が維持され、リピーターの識別精度が向上します。

ただしSafari 16.4以降、sGTMサーバーのIPプレフィックスがWebサイトサーバーと一致しない場合は、サーバー設定Cookieでも7日に制限されるルール(IP-matching rule)があります。

3. PIIのサーバー側フィルタリング

sGTMのサーバーコンテナには「変換(Transformation)」機能があり、GA4やMetaに転送する前にIPアドレスやメールアドレスなどのPIIを落としたりハッシュ化したりできます。

クライアントサイドだとブラウザから各ベンダーに直接データが飛ぶので、出ていったデータを後から引っ込めることはできません。sGTMはその手前にゲートを置ける、というのがGDPR対応で効いてきます。

まとめ

Usercentrics SSTを使って、sGTMによるファーストパーティ計測環境を構築してみました。

  • フルマネージドでsGTMを始められる手軽さ
  • CMP(同意バナー)連携がワンセットになっているのは、GDPR対応が求められる環境で強み

広告を回している環境だと、取れていないコンバージョンがある=入札の最適化データが欠けている、ということなので、放置するほど損が積み上がります。sGTMの導入を検討しているなら、Usercentrics SSTのStarterプランで一度お試しいただくのはありだと思います。

参考ドキュメント

この記事をシェアする

関連記事