9.7 サーバーサイド計測の概要

サーバーサイド GTM と Measurement Protocol の考え方を紹介します。
実践書籍換算約 8 ページ

この章で学ぶこと

サーバーサイド計測（サーバーサイド GTM）の仕組み
サーバーサイド計測のメリットとコスト
Measurement Protocol でサーバーから GA4 にデータを送る方法
サーバーサイド計測を導入するかどうかの判断の目安

サーバーサイド計測とは

ここまでの GTM（ウェブコンテナ）は、ユーザーの ブラウザの中 でタグを動かし、ブラウザから直接、GA4 や広告媒体のサーバーにデータを送っていました。

サーバーサイド計測 では、ブラウザからのデータを、いったん 自社が管理するサーバー（サーバーサイド GTM の サーバーコンテナ）に送り、そこから GA4 や広告媒体に送ります。

【従来（クライアントサイド）】
ブラウザ ──→ GA4
        ──→ Google 広告
        ──→ Meta
        ──→ その他のツール

【サーバーサイド】
ブラウザ ──→ 自社のサーバー（サーバー コンテナ） ──→ GA4
                                                ──→ Google 広告
                                                ──→ Meta（Conversions API）

サーバーコンテナの仕組み

部品	役割
クライアント	ブラウザから届いたリクエストを受け取り、データ（イベント）に変換する
タグ	変換されたデータを、GA4 や広告媒体などに送る
トリガー・変数	ウェブコンテナと同様に、タグの発火の条件や値を決める

サーバーコンテナは、Google Cloud などのクラウドの上で動かします。通常、自社のドメインのサブドメイン（例：sgtm.example.co.jp）を割り当てて、ブラウザからは 自社のドメイン にデータが送られるようにします。

メリットとコスト

メリット

メリット	内容
データの管理	外部に送る前に、自社のサーバーでデータを確認・加工できる。不要な情報（IP アドレスや個人情報など）を取り除いてから送れる
ページの軽量化	ブラウザで動くタグを減らせるため、ページの表示が速くなることがある
計測の安定	自社のドメインにデータを送るため、ブラウザのトラッキング防止機能や広告ブロッカーの影響を受けにくくなる場合がある
Cookie の有効期間	サーバーから設定する自社ドメインの Cookie は、ブラウザの制限の影響を受けにくい場合がある
データの統合	サーバー側で、社内のデータ（会員情報、在庫など）を付け加えて送れる

注意「広告ブロッカーやトラッキング防止を回避できる」ことは、技術的には可能な場合がありますが、ユーザーの意思に反する計測 にならないよう注意が必要です。同意モードや Cookie バナーでユーザーが拒否した場合は、サーバーサイドでも、その意思を尊重する設定にしましょう（第 11 部）。

コストと課題

コスト・課題	内容
サーバーの費用	クラウドのサーバーの利用料が、毎月かかる（アクセス数に応じて増える）
構築の技術	クラウドの設定、ドメインの設定、サーバーコンテナの設定に、専門の知識が必要
運用の手間	サーバーの監視、障害の対応、バージョンの更新
両方のコンテナの管理	ウェブコンテナとサーバーコンテナの両方を管理する必要がある

Measurement Protocol

Measurement Protocol は、ブラウザやアプリではなく、サーバーから直接 GA4 にイベントを送るための仕組みです。サーバーサイド GTM とは別の仕組みで、自社のシステムのプログラムから、HTTP のリクエストでデータを送ります。

使いどころ

使いどころ	例
オフラインの成果	問い合わせから数週間後に、営業の担当者が成約した。CRM から成約のイベントを送る
サーバー側でしか確定しない出来事	決済の確定、定期購入の自動更新、返金
ブラウザ以外の接点	店舗の POS、コールセンター、IoT 機器

送り方の例

POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXXXXX&api_secret=XXXXXXXX

{
    "client_id": "123456789.1700000000",
    "events": [
        {
            "name": "close_convert_lead",
            "params": {
                "value": 1200000,
                "currency": "JPY"
            }
        }
    ]
}

項目	内容
`measurement_id`	GA4 の測定 ID
`api_secret`	GA4 の管理画面（データストリームの設定）で発行する、送信用の秘密の値
`client_id`	どのユーザー（ブラウザ）のイベントかを示す ID。ブラウザで計測したときの `_ga` Cookie の値など
`user_id`	ログインしているユーザーの ID（使っている場合）
`events`	送るイベントの名前とパラメータ

Measurement Protocol の注意点

client_id の保存：サーバーから送るイベントを、ブラウザでの行動と結びつけるには、問い合わせのときなどに、ブラウザの client_id を取得して、CRM などに保存しておく必要がある
ブラウザのイベントの補完が目的：Measurement Protocol は、ブラウザでの計測を置き換えるものではなく、ブラウザで取れないイベントを補うためのもの
流入元の情報：サーバーから送ったイベントには、ブラウザの情報（ページの URL、リファラーなど）が自動では付かない
api_secret の管理：api_secret は外部に漏れないよう、ブラウザの JavaScript に書かず、サーバーの中で管理する

ポイント Measurement Protocol で送ったイベントは、送信前に 検証用のエンドポイント（/debug/mp/collect）に送ると、形式に誤りがないかを確認できます。本番に送る前に、必ず検証しましょう。

導入判断の目安

サーバーサイド計測は強力ですが、すべてのサイトに必要なわけではありません。

導入を検討したほうがよいケース

ケース	理由
広告の費用が大きく、計測の精度が利益に直結する	計測の精度が少し上がるだけでも、広告の最適化の効果が大きい
多くの広告のタグを設置していて、ページが重い	ブラウザのタグを減らせる
外部に送るデータを厳密に管理したい（金融、医療など）	サーバーでデータを確認・加工してから送れる
社内のデータと組み合わせて送りたい	サーバー側でデータを付け加えられる
開発やクラウドの知識を持つ担当者がいる	構築と運用ができる

まだ必要ないことが多いケース

ケース	理由
中小規模のサイトで、広告の費用が少ない	費用と手間に見合う効果が得にくい
基本の計測（キーイベントの設定など）がまだ整っていない	まず、ウェブコンテナでの基本の計測を整えるのが先
運用できる担当者がいない	障害が起きたときに、計測が止まってしまう

段階的に進める

ステップ 1：ウェブ コンテナで、基本の計測（GA4、キーイベント、広告のタグ）を整える
ステップ 2：オフラインの成果を、Measurement Protocol やデータのインポートで補う
ステップ 3：広告媒体のサーバー連携（Meta の Conversions API など）を、媒体の提供する方法で導入する
ステップ 4：必要に応じて、サーバーサイド GTM を導入する

まとめ

サーバーサイド計測では、ブラウザのデータをいったん自社のサーバーコンテナに送り、そこから各ツールに送る
データの管理、ページの軽量化、計測の安定などのメリットがある一方、サーバーの費用と構築・運用の技術が必要
Measurement Protocol を使うと、CRM の成約やオフラインの出来事を、サーバーから GA4 に送れる
同意の拒否は、サーバーサイドでも尊重する
基本の計測が整ってから、規模や体制に応じて、段階的に導入を検討する

これで第 9 部は終わりです。理解度クイズで確認してみましょう。次の第 10 部では、Looker Studio でのダッシュボード作りと、BigQuery を使った生データの分析を学びます。