サーバーサイドGTMとは
サーバーサイドGTM（Server-side Google Tag Manager、以下sGTM）は、従来ブラウザ上で実行していたタグの処理を、自社管理のサーバー上で実行する仕組みです。
通常のGTM（クライアントサイドGTM）では、ユーザーのブラウザが各計測サービスのエンドポイントに直接データを送信します。sGTMでは、ブラウザからのデータをまず自社のサーバーコンテナが受け取り、そこから各サービスにデータを転送する中継構造になります。
この構造により、広告ブロッカーやITP（Intelligent Tracking Prevention）の影響を軽減し、計測精度を向上させることが主なメリットです。
導入のメリット
sGTMの導入による主なメリットは、計測精度・表示速度・データ制御の3つの領域に集約されます。
計測精度の向上
ブラウザベースの計測は、以下の要因でデータの欠落が生じます。
- 広告ブロッカーによるタグの読み込みブロック
- SafariのITPによるCookieの有効期限短縮（7日間→24時間）
- ブラウザの離脱やネットワーク断によるリクエスト未送信
sGTMでは、計測データが自社ドメインのサーバーを経由するため、広告ブロッカーの対象になりにくくなります。また、ファーストパーティCookieをサーバーサイドで設定することで、ITPの制限を受けにくいCookie（HTTP Only、Secure属性付き）を利用できます。
ページ表示速度の改善
クライアントサイドGTMでは、多数のタグをブラウザ上で実行するため、ページ表示速度に影響を与えます。特にタグが増えるほどJavaScriptの実行負荷が高まり、Core Web Vitalsのスコアにも影響します。
sGTMでは、ブラウザから送信するリクエストは1つ（自社サーバーへのリクエスト）で済み、各サービスへのデータ転送はサーバー側で処理されます。結果として、ブラウザ上のJavaScript実行量が減り、ページの表示速度が改善します。
データの制御
サーバーを経由するため、各サービスに送信するデータを細かく制御できます。PII（個人識別情報）を含むデータをサーバー側でフィルタリングしてから送信する、特定のパラメータを除去するといった処理が可能です。
プライバシー規制への対応として、送信データの管理を強化したい場合にも有効です。
運用メモ sGTMは「導入すれば計測の問題がすべて解決する」魔法のツールではありません。最大の効果は「ファーストパーティCookieの有効期限延長によるSafariでの計測精度向上」と「広告ブロッカーの回避」です。自社の課題がこれに該当するかを確認してから導入を判断しましょう。
アーキテクチャの概要
sGTMの仕組みを理解するには、クライアントサイドGTMとの違いを押さえることが近道です。
構成要素
sGTMは以下の3つの要素で構成されます。
クライアント（Client）: ブラウザからのリクエストを受け取り、イベントデータに変換する処理です。GA4クライアントが標準で用意されており、GA4の計測データをそのまま受け取れます。
タグ（Tag）: 変換されたイベントデータを各サービス（Google広告、Meta、GA4等）に送信する処理です。クライアントサイドGTMと同様の概念です。
トリガー・変数: クライアントサイドGTMと同じ仕組みで、条件に基づいてタグの発火を制御します。
データフローの全体像
ユーザーのブラウザからGA4の計測リクエストが自社のsGTMサーバーに送信されます。sGTMサーバーがリクエストを受け取り、設定されたタグに基づいてGoogle広告、Meta CAPI、GA4などの各エンドポイントにデータを転送します。
このフローにより、ブラウザから直接各サービスに通信する必要がなくなります。
構築方法
sGTMの構築は、ホスティング先の選択からカスタムドメインの設定までいくつかのステップで進めます。
ホスティングの選択肢
sGTMサーバーのホスティングには主に3つの選択肢があります。
| 選択肢 | 特徴 | 月額コスト目安 |
|---|---|---|
| Google Cloud Run | Google公式推奨。自動スケーリング対応 | 月数千円〜（トラフィック次第） |
| Stape.io | sGTM特化のマネージドサービス。管理画面あり | 月$20〜 |
| AWS / その他クラウド | Docker対応のクラウドサービスで運用 | 環境次第 |
小〜中規模のサイトであれば、Stape.ioが最も導入ハードルが低い選択肢です。大規模サイトやすでにGCPを利用している場合は、Google Cloud Runが推奨されます。
Google Cloud Runでの構築手順
- Google Cloud Platformでプロジェクトを作成する
- GTMの管理画面で「サーバーコンテナ」を新規作成する
- コンテナの設定画面で「自動プロビジョニング」を選択し、GCPプロジェクトを連携する
- Cloud RunにsGTMのコンテナがデプロイされる
- カスタムドメイン（例: sgtm.example.com）をCloud Runにマッピングする
- クライアントサイドGTMのGA4タグで、送信先をsGTMのカスタムドメインに変更する
カスタムドメインの設定
sGTMの効果を最大化するには、自社ドメインのサブドメイン（例: sgtm.example.com, data.example.com）をsGTMサーバーに割り当てることが重要です。
自社ドメインを使うことで、sGTMサーバーが設定するCookieがファーストパーティCookieとして扱われ、ITPの影響を受けにくくなります。
広告計測への具体的な影響
sGTMを経由することで、主要な広告媒体の計測がどう変わるかを整理します。
Google広告の拡張コンバージョン
sGTMを経由することで、拡張コンバージョンのデータ送信がサーバーサイドで完結します。ブラウザからの送信と比べて、ネットワーク断やページ離脱によるデータ欠落を防げます。
Meta Conversions API（CAPI）
sGTMはMeta CAPIとの連携に対応しています。sGTMのGA4クライアントが受け取ったデータを、Meta CAPIタグでFacebookのエンドポイントに転送する設定が可能です。
これにより、別途サーバーサイドでCAPIの実装を行う必要がなくなり、sGTM上で一元管理できます。
GA4
GA4のデータ送信先をsGTMに変更することで、GA4のデータもサーバー経由で送信されます。広告ブロッカーによるGA4のデータ欠落を軽減できます。
導入判断の基準
sGTMはすべてのサイトに必要なわけではありません。投資対効果が出やすいケースとそうでないケースを整理します。
導入を推奨するケース
- Safariユーザーの比率が高い（日本のモバイルサイトでは50%前後を占めることが多い）
- 広告ブロッカーの影響でコンバージョンデータの欠落が疑われる
- 多数の計測タグがページ速度に影響を与えている
- プライバシー規制対応のためにデータ送信の制御を強化したい
導入が時期尚早なケース
- サーバーの運用・管理に対応できるエンジニアリソースがない
- 月間のコンバージョン数が少なく、計測精度の向上が成果に直結しにくい
- まだクライアントサイドGTMの基本設定が整っていない
コスト感
サーバーのホスティング費用は、月間数万PV程度のサイトであれば月額数千円〜1万円程度です。トラフィックが大きいサイトではサーバーのスケーリングに応じてコストが増加します。