Digital Marketing Academy · レッスン

サーバーサイドタグ設定

Q: 「サーバーサイドタグ設定」で何を学びますか？

タグをサーバーへ移行します。 ブラウザで直接実行するハンズオンコードでDigital Marketing Academyを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

タグをサーバーへ移行します。

「サーバーサイドタグ設定」はCoddyKit上の無料Digital Marketing Academyレッスンです。これはレッスン2/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはDigital Marketing Academy学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Digital Marketing Academyコースには全4レッスンが含まれています。

サーバーサイドタギングとは

サーバーサイドタギングでは、タグの実行場所をユーザーのブラウザから、管理下にあるサーバーへ移します。ページからGoogleやMetaにピクセルを直接送信する代わりに、自社のタギングエンドポイントへ1つのリクエストを送信します。

そのサーバーが、何を、誰に、どのような形式で転送するかを決定します。ブラウザは自社のファーストパーティドメインとのみ通信します。

クライアントとサーバーの処理フロー

従来のモデルでは、各ベンダーのピクセルがブラウザ上で実行され、それぞれが独自にサードパーティリクエストを送信します。サーバーサイドでは、ブラウザがタギングサーバーに1つのイベントを送信し、タギングサーバーがそれを複数の送信先に振り分けます。

これにより、データを管理できるようになり、ブロックされるリクエストが減り、ページの速度を低下させるクライアントサイドコードの量も削減できます。

CLIENT-SIDE (old)
  Browser --> google-analytics.com
  Browser --> facebook.com/tr
  Browser --> tiktok.com/pixel
   (each blockable, leaks data)

SERVER-SIDE (new)
  Browser --> sgtm.yoursite.com  (1 request)
                   |
        +----------+----------+
        v          v          v
      GA4        Meta CAPI   TikTok
   (server-to-server, controlled)

タギングサーバー（sGTM）

GoogleのServer-Side Google Tag Manager（sGTM）は、最も一般的な実装です。Cloud Run、App Engine、その他のホスト上で実行されるコンテナで、リクエストを受け取り、クライアントとタグを通じて処理します。

「client」は受信したリクエストをイベントとして解析し、「tags」はそのイベントを送信先へ転送します。ページではなくサーバー上で実行されるGTMだと考えるとよいでしょう。

ファーストパーティサブドメイン

信頼性を大きく高めるポイントは、DNSのAレコードまたはCNAMEレコードを使い、sgtm.example.comのようにタギングサーバーを自社サイトのサブドメインに割り当てることです。

リクエストの送信先が自社ドメインになるため、レスポンスで設定されるCookieはファーストパーティかつHttpOnlyになります。最も厳しいITPの制限を回避でき、広告ブロッカーによってブロックされる可能性も大幅に低くなります。

DNS + cookie setup
--------------------------------------
sgtm.example.com  ->  Cloud Run host

Response header from server:
Set-Cookie: FPID=abc123; Domain=.example.com;
            HttpOnly; Secure; SameSite=Lax;
            Max-Age=63072000

=> first-party, server-set, long-lived
=> survives ITP better than JS cookies

イベントの送信経路

ページ上で購入が発生します。ウェブコンテナ（またはgtag）がsgtm.example.comにイベントを送信します。そこでGA4クライアントがヒットを再構成して拡充し、GA4タグがGoogleの収集エンドポイントに転送します。

同じイベントで、Meta Conversions APIタグ、サーバーサイドのGoogle Adsコンバージョンなどを同時に起動することもできます。すべて1つの受信リクエストから実行できます。

Event payload sketch (purchase)
--------------------------------------
{
  "event_name": "purchase",
  "client_id": "FPID.abc123",
  "value": 89.90,
  "currency": "EUR",
  "transaction_id": "T-10482",
  "items": [{"id":"SKU1","qty":2}],
  "consent": {"ad_user_data":"granted"},
  "user_data": {"em_hashed":"<sha256>"}
}

Conversions API（CAPI）

MetaのConversions API、GoogleのEnhanced Conversions、TikTokのEvents APIは、いずれもサーバー間のエンドポイントです。ブラウザのピクセルを完全に介さず、サーバーからイベントを直接受け取ります。

これにより、広告ブロッカーやITPによって失われたコンバージョンを回復でき、同意がある場合は、照合精度を高めるためにハッシュ化したファーストパーティ識別子（メールアドレス、電話番号）を送信できます。

データの拡充と管理

サーバーは元のイベントを確認できるため、データベースから正確な注文額を付加したり、共有したくないPIIを削除したり、サーバー側のタイムスタンプを追加したり、クライアントイベントとの重複を除去したりできます。

各プラットフォームに必要最小限のフィールドだけを送信し、自社データの編集者になるのです。これは単なる方針ではなく、実際にデータを最小化する取り組みです。

Server-side transform rules
--------------------------------------
INCOMING -> TRANSFORM -> OUTBOUND

- hash email (SHA-256) before send
- drop raw IP for non-consented users
- overwrite value w/ DB net revenue
- add event_id for dedup w/ pixel
- block forwarding if consent=denied

イベントの重複除去

同じコンバージョンに対してブラウザのピクセルとサーバーイベントの両方を実行する場合、プラットフォームが二重にカウントしないようにする必要があります。重複除去には共有識別子を使用します。

クライアントのピクセルとサーバーのCAPI呼び出しの両方から、同じevent_id（およびevent_name）を送信します。Metaなどのプラットフォームがそれらを照合して1つだけを保持するため、数値を水増しせずに冗長性を確保できます。

Dedup with event_id
--------------------------------------
Browser pixel:
  fbq('track','Purchase',{...},
      {eventID:'evt_T-10482'})

Server CAPI:
  event_id: 'evt_T-10482'
  event_name: 'Purchase'

Meta sees same id+name -> counts once

ホスティングとコスト

タギングサーバーは実際のインフラストラクチャです。Google Cloud Runではトラフィックに応じて自動的にスケールし、コンピューティングとエグレスに対して料金が発生します。小規模なサイトなら数個のインスタンスで運用でき、大規模なサイトでは多数のインスタンスが必要になる場合があります。

タギングサーバーが停止すると計測も停止するため、モニタリング、デバッグ用のプレビューサーバー、可用性を計画してください。これは単なるスニペットではなく、今や本番サービスです。

限界と注意点

サーバーサイドタギングは同意を回避する手段ではありません。法的根拠は引き続き必要であり、どこで実行するかにかかわらず、同意なしにデータを送信することは違法です。

また、確定的なクロスサイトトラッキングを魔法のように復元するものでもありません。同意を得たファーストパーティデータの信頼性と照合精度を高めるレジリエンス層であり、抜け道ではありません。

実装チェックリスト

実際の導入は、決まった順序で行います。サーバーを構築し、サブドメインを割り当て、ウェブコンテナを接続し、クライアントとタグを設定してから、CAPIの送信先を接続します。

プレビュー/デバッグビューで検証し、重複除去が機能することと同意による制御を確認してから、トラフィックを切り替えます。通常のバックエンドサービスをデプロイする場合と同じように扱ってください。

Rollout checklist
--------------------------------------
[ ] Deploy sGTM (Cloud Run)
[ ] Map sgtm.example.com (CNAME)
[ ] Web container -> send to sGTM
[ ] GA4 client + GA4 tag configured
[ ] Meta CAPI tag + event_id dedup
[ ] Consent checks on every tag
[ ] Preview/debug verified
[ ] Monitoring + alerts on uptime

理解度チェック

サーバーサイドタギングについての理解度を確認しましょう。

まとめ

サーバーサイドタギングでは、ブラウザのイベントを自社サブドメイン上のタギングサーバーにルーティングします。このサーバーがファーストパーティ Cookieを設定し、Meta CAPIのようなサーバー間APIを介して、同意を得たデータをプラットフォームに転送します。

メリットは、ブロックされるリクエストの削減、ITPの影響を受けにくいCookie、データの拡充と最小化、イベントの重複除去です。これは信頼性と管理のための層ですが、運用が必要な実インフラストラクチャであり、同意の代わりには決してなりません。

よくある質問