sGTMを試してみた【前編】

こんにちは、データアナリストの左海です。

mediba Adventカレンダー16日目ということで、私からはサーバーサイドGTM(以下sGTM)を試してみたお話についてです。

はじめに

私自身、過去にsGTMを利用したことがなく、理解を深めるためにプライベート環境へ導入してみることにしました。

sGTMに触れる上で切り離せない話題としてApple社のSafariのITP制限が挙げられます。

そのため、今回はsGTMの導入だけでなく、ITP制限がGoogle Analytics4(以下GA4)のログにどう影響しているのかまで観察していきます。

※本投稿は「sGTMを導入したお話」と「ITP制限のGA4ログへの影響を観察したお話」(明日17日投稿予定)の2部構成となっています。

sGTMとは

初めに、sGTMとはGoogle Tag Manager(以下GTM)のコンテナ種別の「Server」のことを指します。

従来のGTMはタグの処理をクライアント(ブラウザ)側で処理していたのに対し、sGTMを利用することでWebサイト管理者が管理するサーバー上で処理することが可能になります。

今回、タグを処理するためのサーバーはGoogle Cloud Platform(以下GCP)のApp Engineで設置します。

sGTMとApple社のSafariのITP制限の関係

ITPとは、Apple社がSafariに搭載したユーザーの行動データの収集を規制するための機能です。2022/12/11時点でSafariでは主にCookieに対して以下の制限が設けられています。

参考 - Cookie Status

GA4のCookie(_ga)はJavaScriptで設定された1st Party Cookieとなるため、Cookieの有効期限は7日となります。
(ここでは、参照元URLに、Appleが定義したトラッカーのURLパラメータが含まれる場合は触れません。)

そのため、アクセス解析においては8日以上の間隔を空けて再訪問したユーザーは新規ユーザー扱いとなり、同一ユーザーとしてカウントされません。

上記問題を緩和するのがsGTMで、サーバーサイドでCookieを発行するため、GA4のCookieの有効期限はデフォルトの有効期限に緩和することが可能です。

ただ、ITPがプライバシー守るという取り組みであるのでこの方法を継続的に利用するのは難しいかもしれません。現にWebKitは、 「サードパーティ」と判定したIPアドレス経由で設定されたクッキーの有効期間を7日間に制限するようです。

参考 - Steven Englehardt氏

sGTM導入手順

それでは早速、私の個人ブログにsGTMを導入していきます。導入手順は以下の通りです。

1. サーバーコンテナの作成
2. GCP(App Engine)とのプロビショニングとカスタムドメイン設定(GTM/GCP/DNS)
3. ウェブ用コンテナ側でのトランスポートURL設定(GTM)
4. サーバー用コンテナ側での初期タグ設定(GTM)

参考 - サーバー用GTMコンテナの初期導入方法まとめ | アユダンテ株式会社

サーバーコンテナの作成(GTM)

GTMのコンテナ一覧画面 > コンテナを作成する > Serverでサーバー用コンテナの作成を行います。

なお、通常のウェブ用コンテナも必要ですので準備しておきます。

GCP(App Engine)とのプロビショニングとカスタムドメイン設定(GTM/GCP/DNS)

次にサーバー用コンテナを動かすためのサーバーを準備し、サーバー側のエンドポイントのURLに対してカスタムドメイン設定を行います。

本工程はアユダンテさんのコラムに分かりやすく記載されているので参考にしてみてください。

なお、プロビショニングは設定内容を確認したく「手動設定」で行いました。

添付画像の通り、無事にサーバのデプロイが完了しました。

カスタムドメインの設定も完了しました。

補足ですが、カスタムドメインの設定では、私のサイトドメインを管理しているレジストラの管理画面で「ドメインの所有権の証明」と「サブドメインのDNS設定」の際にDNSのレコード登録が必要になりました。

私はムームーDNSを利用していたのでコントロールパネル > ドメイン管理 > ドメイン操作 > ムームーDNSから設定しました。

ウェブ用コンテナ側でのトランスポートURL設定(GTM)

事前に準備したウェブ用コンテナで計測に必要なタグの作成を行います。今回はGA4のpage_viewイベントを計測することにします。

添付画像の通りにGA4設定タグを作成し、All Pagesトリガーを紐付けます。

sGTMを利用する場合、赤枠箇所の「サーバーコンテナに送信」にチェックを入れ、サーバー側のエンドポイントのURLを入力します。

すると、GA4ログの送り先はデフォルトのGAサーバではなく、指定のサーバーに変更されます。

サーバー用コンテナ側での初期タグ設定(GTM)

サーバー用コンテナでは、ウェブ用コンテナから受信したデータを本来送信すべきツールサーバー(GA)へ飛ばすための設定を行います。

具体的にはウェブ用コンテナに「対応するクライアントが登録されているかの確認」/「対応するGA計測タグの登録」の2つです。

私の場合、対応するクライアントが登録されていなかったので新規作成しました。

詳細設定の「Cookieとクライアントの識別」ではサーバー用コンテナでのGA4計測タグのクライアントIDの保存場所を指定します。サーバー用コンテナが発行するCookieを使用したいため、サーバー管理を選択します。

「JavaScript 管理クライアント IDから移行」にもチェックを入れます。チェックを入れないと、ページ側でJavaScript管理のCookie(_ga)を保持していたとしても、特に気にせず、サーバー管理CookieではクライアントIDが生成されるようです。

次に、サーバー用コンテナでもウェブ用コンテナ同様にGA4のpage_viewイベントタグを作成します。

トリガーはウェブ用コンテナとは異なり、カスタムトリガーでトリガーの発生場所を先ほど作成したクライアントを設定するため、Clinent NameがGoogle Analytics 4に等しいを選択します。

以上の設定が完了すれば、ウェブ用コンテナからのデータ受信後、サーバー用コンテナで登録されたクライアントが反応してGA4イベントタグが発火され、GA4のログが送信できるようになります。

GA4ログの確認

ウェブ/サーバー用の両コンテナを公開後、想定通りにGA4のpage_viewイベントが飛んでいるのが確認できました。

これでsGTMの導入は完了です。明日17日も引き続き私からITP制限のGA4ログへの影響を観察したお話についてです。

ぜひご覧ください。