実装例(CloudRunを使う場合)
概要
- GAEよりCloudRunのほうがよりモダン・低遅延・低コスト・高スケーラビリティーらしい
- Google社内でもCloudRunのほうを推奨していることが多い
- ただ、自動プロビジョニングの場合は未だにGAEでSetupされる
- 基本的な考え方や手順はGAEもCloudRunも変わらない
- 以下はデータ本部のテストサイトでsGTM化を実験したもの
環境セットアップ
sGTMのコンテナを作成
GTM→コンテナを作成→Serverコンテナを新規作成
CloudRunは自動プロビジョニング非対応のため、手動プロビジョニングを選択 コンテナ設定の文字列は管理→Googleタグマネージャーをインストールの画面で後から確認可能
コンテナ設定IDは以下の手順で利用するため控えておく
GCP CloudRunでサービスを2つ作成
以下はGCP Projectで作成したもの
Cloud Runのコンソールから以下2つのサービスを作成
1つ目：プレビュー実行時のサービス（プレビューサーバー）を作成 環境変数に前述のコンテナ設定IDを入れる必要あり、Region設定にも注意 理論上WEBサーバーとRegionが近ければ7日以上Cookieが保持される可能性あり プレビューサーバー作成後にサービスにアクセスすると右上にURLが出現 これは以下「タグ設定サーバー」の環境変数に利用するため控えておく
2つ目：本番実行用のサービス（タグ設定サーバー）を作成 タグ設定サーバーの環境変数：PREVIEW_SERVER_URLにプレビュータグのURLを入力 他はプレビューサーバーと基本同じ。インスタンス数などは場合によって変わるかも （キャプチャはプレビューサーバーとほぼ同じなので省略、リファレンス見てください）
gcloud run deploy "server-side-tagging" \
--region NEW_REGION \
--image gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable \
--platform managed \
--ingress all \
--min-instances 2 \
--max-instances 10 \
--timeout 60 \
--allow-unauthenticated \
--no-cpu-throttling \
--update-env-vars PREVIEW_SERVER_URL="$(
gcloud run services describe server-side-tagging-preview \--region "REGION" \
--format="value(status.url)")",CONTAINER_CONFIG="CONTAINER_CONFIG" && \
gcloud compute network-endpoint-groups create server-side-tagging-neg \
--region=NEW_REGION \
--network-endpoint-type=SERVERLESS \
--cloud-run-service="server-side-tagging" && \
gcloud compute backend-services add-backend --global "BACKEND_NAME" \
--network-endpoint-group-region=NEW_REGION \
--network-endpoint-group=server-side-tagging-negGCP CloudRunで作成したサービスにサブドメインをマッピングする
- 実際のサイトとおなじプライマリドメインを持つサブドメインをマッピングする
- 検証環境においては「sgtm.xxx-01.com」と「sgtm.xxx.com」を利用（クロスドメインの場合、非クロスドメインなら1つでOK）
- あえて複雑な構成にしているのでValueDomainから設定したが、 通常はネームサーバーサービスから簡単に発行できるはず
- Cloud Runのドメインマッピング画面から追加 マッピングするサービスは「タグ設定サーバー」のみでOKらしい
- 過去に認証通していない場合はVerify a new domainしか選べない
- 次の画面でSEARCH CONSOLEのリンクがでてくるのでSCからドメイン認証を行う
- SCからサブドメ所有権確認の認証を通す 続行を押すと出てくる（ドメイン管理者がDNSにTXTレコード追加）
- SC側の認証完了後再度CloudRunのドメインマッピングを開くと 確認済みのドメイン選択のプルダウンにプライマリドメインが出現 sGTM用のサブドメインを手動で入力して続行
- サブドメのDNS設定にCNAMEを追加（サブドメのIPをgooglehostedに向ける）
- ValueDomainのDNS設定画面においては以下の1行を追加 「cname sgtm ghs.googlehosted.com.」 （sgtmの部分がsgtm.xxx.comのようにサブドメ名に対応している）
- クロスドメイン計測が必要な場合、もう一つのドメインからも同じ手順でサブドメマッピング
通常GTM＆sGTM側の設定
- 最初の手順で作成したsGTMコンテナの設定を開き、 「サーバーコンテナのURLにCloudRunで作成したタグ設定サーバーのURL」（プレビューサーバーのURLは不要） 「マッピングしたサブドメインのURL（httpsから記述）」を貼り付ける 以下の例ではクロスドメインを想定し、「https://sgtm.xxx.com」と「https://sgtm.xxxxx.com」を追加している
- サーバーコンテナのURLにCloudRunで作成したタグ設定サーバーのURL
- sGTMコンテナ側の画面
- sGTMのタグトリガー設定：通常GTMからリクエストを受けたGA4発火を受け入れる
- 基本的にタグにGA4の全てのイベントを受け入れる設定を追加するだけ より厳密にフィルタする場合はGA4の計測IDも指定しておく
- 通常GTM：GA4設定タグの発火をsGTM経由に変える
- 非クロスドメイン環境の場合
- サーバーコンテナのURLにマッピングしたサブドメインのURLを入れる Cloud RunのサービスURLの方を入力するとITPの影響を受けるので注意（後述）
- 非クロスドメイン環境の場合
- GA4設定タグ→Googleタグに変わってる場合 「サーバーコンテナに送信する」の欄は無くなるので、 代わりに設定パラメーターで「server_container_url」として入力する
- クロスドメイン環境の場合
- カスタム変数で実際にユーザーがアクセスしているサイトのドメインに合わせた サブドメインに送信するように一工夫する
- 具体的には 「domain1.com」のサイトにユーザーアクセスしたとき →「xxx01.com」のサーバコンテナに送信 「domain2.com」のサイトにユーザーアクセスしたとき →「xxx2.com」のサーバコンテナに送信 という条件分岐をカスタム変数で実装
- 変数→正規表現の表で作成する場合以下のような設定になる 正規表現を使うことでプライマリドメインに対して条件分岐をかけている そのためサイトのプライマリドメイン自体が増えなければメンテナンス不要 （サイト側のサブドメインが増えたとしても、プライマリで判定しているので）
[正規表現の表で変数を作る]正規表現の表で変数を作る
[作成した変数をサーバーコンテナURLとして設定する] 作成した変数をサーバーコンテナURLとして設定する
その他
- イベント数があまりにも多い場合はロギングをOFFにしておいたほうがよい（コスト観点）
データの確認
Chrome開発者ツールから確認
- まず、非sGTMの場合はauthorityはanalytics.google.comになる
- sGTM経由でカスタムドメインマッピングをしない状態のGA4発火の場合、 Request HeadersのauthorityがCloud RunのURLにり、Set-Cookieの部分に警告が出る この状態だとITPの影響をモロに受けるためsGTM化した意味が薄れる（NGパターン）
- 前述のカスタムドメインマッピング＋WebGTMの設定変更＋sGTMの設定変更を行った場合 authorityが設定したサブドメインになり、 表示しているサイトのプライマリドメインと一致している場合、Set-Cookieの警告もでない
- クロスドメイン環境なのに、前述のクロスドメイン用の設定をしていない場合、 やはりSet-Cookieにエラーがでてくる**（NGパターン）** 以下の例では「sgtm.datamarketing-training-01.com」のみをマッピング設定し、 「www.datamarketing-training-02.com」にアクセスした場合の画面
- クロスドメイン計測が必要な場合、もう一つのドメインからも同じ手順でサブドメマッピング クロスドメイン環境の場合 の手順を満たした場合、どちらのドメインもSet-Cookieでエラーは吐かない