サーバーサイドGTMの「クライアント」という部品を理解する｜未経験から100日後にGTMのプロになる話【Day 68】

サーバーサイドGTMの構築方法（自動プロビジョニング・Cloud Run・実際にかかるコスト）はDay29で詳しく扱いました。手動でGoogle CloudのApp Engineを組み立てる説明を見かけたら、それは古い、あるいは不正確な情報だと考えてください。今日は、構築の話ではなく、サーバーサイドGTM特有の内部構造――「クライアント」という概念――を扱います。

サーバーコンテナには「クライアント」という部品がある

クライアントサイドのGTM（これまでこの連載で扱ってきた通常のGTM）では、タグ・トリガー・変数の3つで構成が完結していました。サーバーサイドGTMには、これに加えて「クライアント」という新しい部品が登場します。

ブラウザ側のGTMやgtag.jsから送られてきたリクエストは、まずサーバーコンテナの「クライアント」が受け取り、そのリクエストがどの種類のデータ（GA4形式なのか、測定プロトコルなのか等）かを解釈します。クライアントが解釈した結果を、これまでどおりのタグ（GA4行き、広告行きなど）に振り分けて配信する、という流れです。つまりサーバーサイドGTMは「タグ・トリガー・変数」に「クライアント」が加わった4つの部品で動いている、と理解してください。標準では「GA4」クライアントや「測定プロトコル」クライアントなどがあらかじめ用意されており、多くの場合はそれをそのまま使うだけで動きます。

なぜこの区別が重要なのか

サーバーサイドGTMのプレビューモードでタグが発火しない場合、まずタグの設定を疑いがちですが、実際にはクライアント側でリクエストが正しく解釈されていないケースがあります。「サーバーコンテナにリクエストは届いているのに、どのタグも発火しない」という症状のときは、クライアントの一覧と、そのリクエストがどのクライアントに拾われているかをまず確認してください。タグの設定ミスと勘違いして時間を浪費しないための切り分けポイントです。

今日のまとめ

サーバーサイドGTMの構築自体はDay29の方法で難しくありませんが、実際に運用する際は「クライアント」というクライアントサイドには無い部品の存在を意識してください。トラブルシューティングの第一歩は、タグではなくクライアントの確認からです。次回は、GTMの応用テクニックをさらに扱います。