はじめに こんにちは！ KINTOテクノロジーズのデジタル戦略部DataOpsグループ所属の三浦です。 普段は、社内のデータ分析基盤の開発・保守・運用に加え、Google Analytics 4（以下、GA4）やGoogleタグマネージャー（以下、GTM）を利用した、Webサイトのアクセス解析や計測環境の整備を担当しています。 WebサイトでGA4やGoogle広告を計測する場合、一般的にはGoogleドメインからGoogleタグを読み込み、Googleドメインへ計測リクエストを送信します。 一方、ブラウザのプライバシー保護機能や広告ブロッカーなどの影響により、Googleタグの読み込みや計測リクエストがブロックされ、イベントが欠損することがあります。 今回、この課題への対応として、既存のAmazon CloudFrontを利用し、Googleタグゲートウェイを導入しました。 本記事では、Googleタグゲートウェイを導入した背景や構成、社内での役割分担、検証時に確認したポイント、導入後に確認できた効果について紹介します。 本記事の対象者 本記事は、以下のような方を対象としています。 GTMやGA4を利用したWebサイトの計測を担当している方 Googleタグゲートウェイの導入を検討している方 Amazon CloudFrontをCDNとして利用している方 本記事では、CloudFrontの細かな設定手順ではなく、導入時の考え方や進め方、検証内容を中心に紹介します。 Googleタグゲートウェイ導入の背景と概要 背景 当グループでは、Webサイトの利用状況や広告施策の成果を把握するため、GTMを利用してGA4やGoogle広告などの計測タグを配信しています。 通常の構成では、WebサイトからGoogleドメイン上のGoogleタグを読み込み、計測したイベントをGoogleドメインへ送信します。 通常のGoogleタグ配信の構成 しかし、Googleドメインへの通信は、ブラウザのプライバシー保護機能や広告ブロッカーなどによって、制限されることがあります。 計測タグや計測リクエストがブロックされると、ユーザーが実際にページを閲覧したり、コンバージョンしたりしていても、GA4やGoogle広告へイベントが送信されません。 その結果、以下のような課題が発生する可能性があります。 GA4で確認できるイベント数が、実際の発生件数より少なくなる コンバージョン数が正しく計測されない Webサイトの施策評価に使用するデータが不完全になる 広告経由の成果を正しく評価できない 広告配信の最適化に使用するコンバージョンデータが不足する 特に広告配信では、計測したコンバージョンデータが、自動入札や配信対象の最適化に利用されます。 そのため、イベントの欠損は、レポート上の数値が少なくなるだけでなく、広告配信の学習や最適化にも影響する可能性があります。 実際に対象サイトでは、GA4で計測しているコンバージョンページのイベント数と、バックエンドのデータベースに保存されているコンバージョン件数に差がありました。 もちろん、GA4とバックエンドのデータベースでは、計測の仕組みや集計条件が異なります。 そのため、数値が完全に一致するものではありません。 一方で、差が大きい状態では、実際に発生したコンバージョンの一部をGA4で取得できていない可能性があり、広告施策やサイト改善を評価するうえで課題となっていました。 そこで、Googleタグへの通信を自社ドメイン経由に変更し、タグやイベントがブロックされる影響を軽減することを目的として、Googleタグゲートウェイを導入しました。 概要 対象のWebサイトでは、CDNとしてすでにAmazon CloudFrontを利用していました。 そのため、新たにサーバーを構築するのではなく、既存のCloudFrontを利用してGoogleタグゲートウェイへの通信を中継する構成を採用しました。 導入後の構成は以下のとおりです。 flowchart TB Browser[Webブラウザ] --> Domain[Webサイトと同じ自社ドメイン] Domain --> CF[Amazon CloudFront] CF -->|通常のWebコンテンツ| Origin[既存の配信先] CF -->|Googleタグゲートウェイ用のパス| GTG[Googleタグゲートウェイ] GTG --> GA4[GA4・Google広告など] Webサイト上にGoogleタグゲートウェイ用のパスを用意し、そのパスへの通信をCloudFrontからGoogle側へ転送します。 ブラウザから見ると、Googleタグの読み込み先や対象となる計測リクエストの送信先が、Googleドメインではなく、Webサイトと同じ自社ドメインになります。 Googleタグゲートウェイ導入前後の構成図 要素技術・アーキテクチャの紹介 ここからは、今回の導入で利用したGoogleタグゲートウェイとAmazon CloudFrontについて紹介します。 Googleタグゲートウェイとは？ Googleタグゲートウェイ（ Google tag gateway for advertisers ）は、自社が管理するCDNやロードバランサーなどのインフラを利用して、Googleタグを自社ドメイン経由で配信する仕組みです。 通常はGoogleドメインから読み込まれるGoogleタグを、自社ドメイン上の特定のパスから読み込めるようにします。導入前後の経路の違いは、前述の「 概要 」節の構成図のとおりです。 Googleタグゲートウェイでは、GA4のイベント設計や、GTMコンテナ内のタグの処理内容を大きく変更するのではなく、Googleタグへアクセスする経路を変更します。 そのため、既存のGTMコンテナ内のタグ、トリガー、変数などを維持したまま導入できます。 Amazon CloudFrontとは？ Amazon CloudFront は、AWSが提供するCDNサービスです。 Webサイトのコンテンツを利用者に近い拠点から配信することで、表示速度や可用性の向上に利用されます。 CloudFrontでは、アクセスされたURLのパスに応じて、異なる配信先へリクエストを振り分けられます。 今回はこの仕組みを利用し、Googleタグゲートウェイ用のパスへの通信のみを、Google側へ転送するようにしました。 サーバーサイドGTMとの違い Googleタグゲートウェイと混同しやすい仕組みに、サーバーサイドGTMがあります。 サーバーサイドGTMでは、サーバー用のGTMコンテナを構築し、サーバー側で計測リクエストを処理し、送信先を制御します。 一方、Googleタグゲートウェイは、Googleタグの読み込みや対象となる計測リクエストを、自社ドメイン経由に変更する仕組みです。 観点 Googleタグゲートウェイ サーバーサイドGTM 変更するもの Googleタグへの通信経路 計測リクエストの処理・送信先 追加で必要なもの CDN / ロードバランサーの設定 サーバー用GTMコンテナと実行環境 既存のWeb用GTMコンテナ そのまま利用 サーバー用コンテナ向けの設定追加が必要 今回の目的は、既存のGTM構成を維持しながら、Googleタグへの通信経路を変更することでした。 そのため、新たなサーバー用GTMコンテナは構築せず、既存のCloudFrontとWeb用のGTMコンテナを利用する構成を採用しました。 導入の進め方 各担当者の役割分担 今回の導入では、計測担当だけでなく、インフラ担当、プロダクトチームのサイト管理者と連携して進めました。 大きな役割分担は以下のとおりです。 DataOpsグループ・計測担当 Googleタグゲートウェイの導入目的と要件の整理 対象ドメインや対象環境の整理 Googleタグゲートウェイ用パスの検討 ブラウザやGA4を利用した動作確認 既存の計測への影響確認 導入前後のイベント数の比較 インフラ担当 CloudFrontへのGoogleタグゲートウェイ用設定の追加 Googleタグゲートウェイへの転送設定 検証環境と本番環境への設定反映 必要に応じたCloudFrontやWAFの調査 プロダクトチーム・サイト管理者 Webサイトに設置しているGTMコードスニペットの差し替え 検証環境と本番環境へのリリース Googleタグゲートウェイは、GTMやGA4だけで完結する機能ではありません。 CDNなどの配信基盤と、Webサイトへ設置しているGTMコードスニペットの両方に対応が必要です。 そのため、導入前に各担当者の作業範囲と、検証時の確認項目を整理しました。 GTMコンテナ側の設定は変更しない Amazon CloudFrontを利用した今回の構成では、GTMコンテナ側でGoogleタグゲートウェイ用の設定変更は行っていません。 既存の本番用GTMコンテナを、そのまま利用しました。 変更したのは、Webサイトに設置されているGTMコードスニペットの読み込み先です。 変更前 GoogleドメインからGTMコンテナを読み込む 変更後 自社ドメイン上のGoogleタグゲートウェイ用パスから 同じGTMコンテナを読み込む GTMコンテナ内のGA4タグ、Google広告タグ、トリガー、変数などは変更していません。 GTMコードスニペットの差し替えについては、Webサイトを管理しているプロダクトチームへ依頼し、検証環境と本番環境へ反映してもらいました。 通信経路のみを変更する構成だったため、既存の計測設計への変更を抑えて導入を進められました。 検証用GTMコンテナは作成しない 今回の導入では、Googleタグゲートウェイの検証用に、新しいGTMコンテナは作成しませんでした。 実際に本番環境で利用しているGTMコンテナを、検証環境でもそのまま利用しました。 導入の流れは以下のとおりです。 検証環境のCloudFrontへ設定 検証環境のGTMコードスニペットを差し替え 検証環境で動作確認 本番環境のCloudFrontへ設定 本番環境のGTMコードスニペットを差し替え 本番環境で動作確認 先に検証環境のCDNへGoogleタグゲートウェイの設定を追加し、プロダクトチームに検証環境のGTMコードスニペットを差し替えてもらいました。 そこで問題がないことを確認した後、本番環境のCloudFront設定とGTMコードスニペットを変更しました。 本番用のGTMコンテナをそのまま使用したことで、検証用コンテナと本番用コンテナの間に設定差分が発生しません。 実際に本番で使用するタグ構成のまま、通信経路の変更による影響を確認できました。 検証時のポイント Googleタグが自社ドメインから読み込まれているか 最初に、ブラウザの開発者ツールにあるNetworkタブを利用し、GTMコンテナの読み込み先を確認しました。 導入前はGoogleドメインから読み込まれていたGTMコンテナが、導入後は自社ドメイン上のGoogleタグゲートウェイ用パスから読み込まれていることを確認します。 導入前 https://www.googletagmanager.com/... 導入後 https://www.example.com/<Googleタグゲートウェイ用パス>/... 読み込み先だけでなく、HTTPステータスコードが正常であることや、ページ表示時にGTMコンテナが問題なく実行されていることも確認しました。 既存のタグがこれまでどおり発火するか Googleタグの読み込み先を変更しても、GTMコンテナ内のタグやトリガーが、これまでどおり動作する必要があります。 GTMのプレビューモードを利用し、以下を確認しました。 ページ表示時に必要なタグが発火すること クリックなどのイベントタグが発火すること GA4へ必要なイベントが送信されること イベントパラメータの値が導入前と変わっていないこと 同一イベントが重複して送信されていないこと 今回、GTMコンテナ内の設定自体は変更していません。 そのため、通信経路を変更したことで、既存のタグ発火やイベント送信に影響が出ていないかを中心に確認しました。 GA4でイベントを確認できるか ブラウザ上でタグが発火していても、最終的にGA4へイベントが到達していなければ、計測は成立しません。 GA4のDebugViewやリアルタイムレポートを利用し、以下を確認しました。 ページビューが送信されていること 主要なイベントが送信されていること イベントパラメータが欠損していないこと page_location などの値が正しいこと コンバージョンページのイベントが送信されていること 導入前と比較して、想定外の重複や減少がないこと Googleタグゲートウェイを経由した場合でも、GA4上では、これまでと同じイベント名やパラメータとして確認できます。 SPAの画面遷移も確認する 対象サイトには、ページ全体を再読み込みせずに画面を切り替えるSPA形式のページもありました。 SPAでは、初回表示時にGTMコンテナが正常に読み込まれていても、その後の画面遷移でページビューやイベントが正しく送信されるとは限りません。 そのため、以下を分けて確認しました。 ページを最初に表示したときの計測 ページ内で画面遷移したときの計測 画面遷移後の page_location 仮想ページビューの発火 前画面の値が dataLayer に残っていないか 同じイベントが重複して送信されていないか Googleタグゲートウェイ自体は通信経路を変更する仕組みですが、導入を機に、既存のSPA計測が正常に動作していることも合わせて確認しました。 プレビューモードだけで判断しない GTMのプレビューモードでは正常に見えていても、プレビューモードを利用しない通常アクセスでは、想定した通信が発生していない場合があります。 そのため、以下の両方で確認しました。 GTMのプレビューモードを利用した状態 プレビューモードを利用しない通常アクセス 問題が発生した場合は、以下の順番で確認すると、原因を切り分けやすくなります。 Webサイト上でGTMコードスニペットが実行されているか GTMコンテナが読み込まれているか 対象のタグが発火しているか ブラウザから計測リクエストが送信されているか CloudFrontへリクエストが到達しているか Google側へ転送されているか GA4でイベントを確認できるか ブラウザのNetworkタブにリクエスト自体が表示されていない場合は、CloudFrontより前のWebサイトやGTMの処理を確認します。 一方、ブラウザからリクエストが送信されているものの、エラーになっている場合は、インフラ担当と連携して、CloudFrontやWAFなどを確認します。 すべての通信が自社ドメイン経由になるわけではない 検証時には、ブラウザのNetworkタブからGoogle関連の通信を確認しました。 その結果、GA4の計測では自社ドメイン経由になっている通信を確認できましたが、一部の通信は、引き続きGoogleドメインへ送信されていました。 :::message Googleタグゲートウェイを導入したからといって、Googleに関係するすべての通信が自社ドメイン経由になるわけではありません。 ::: そのため、Googleドメインへの通信が完全になくなるかどうかではなく、対象となるGoogleタグや計測リクエストが、想定どおり自社ドメインを経由しているかを確認しました。 導入後の効果 Googleタグゲートウェイの導入後、タグの発火状況と、コンバージョンページのイベント数を確認しました。 タグの発火状況が改善した 導入前は、Googleタグの読み込みや計測リクエストをGoogleドメインへ直接送信していました。 導入後は、対象通信が自社ドメインを経由する構成へと変更されました。 これにより、広告ブロッカー等に起因するタグの未発火が抑制され、GA4へ送信されるイベント数が前月比・前週比で約10〜15%増加しました。 :::message 旧環境との完全な並行稼働による厳密な差分比較はできないため、前後期間の傾向に基づく推定値です。 ::: Googleタグゲートウェイを導入しても、すべてのユーザー環境で必ずタグが発火するようになるわけではありません。 例えば、以下のような要因によって、引き続きイベントが送信されない可能性があります。 JavaScriptが無効化されている ユーザーの同意状況によって計測が制限されている ページ表示が完了する前にユーザーが離脱した ブラウザやネットワークの状態によって通信に失敗した 一方で、Googleドメインへの直接通信がブロックされることによるイベント欠損については、一定の改善効果を確認できました。 GA4とバックエンドデータベースの数値差が縮小した 今回、導入効果を確認するため、GA4で計測したコンバージョンページのイベント数と、バックエンドのデータベースに保存されているコンバージョン件数を比較しました。 導入前は、バックエンドのデータベース上ではコンバージョンが記録されているものの、GA4では対応するイベントを確認できないケースがあり、両者の数値に大きな差がありました。 導入前 バックエンドDBのコンバージョン件数 ＞ GA4のコンバージョンページイベント数 Googleタグゲートウェイの導入後は、GA4で確認できるコンバージョンページのイベント数が増加し、バックエンドのデータベースに記録されている件数へ大きく近づきました。 導入後 バックエンドDBのコンバージョン件数 ≒ GA4のコンバージョンページイベント数 バックエンドのデータベースとGA4では、計測の仕組みや集計条件が異なるため、両者の数値が完全に一致するとは限りません。 例えば、コンバージョン処理がバックエンドで完了していても、ユーザーが完了ページを表示する前に離脱した場合は、GA4のページイベントが発生しない可能性があります。 また、同意設定やブラウザ環境などによって、GA4への送信が制限される場合もあります。 それでも、導入後に両者の数値差が大きく縮小したことから、これまで欠損していた一部のイベントを取得できるようになったと考えています。 広告施策の評価に利用するデータが改善した コンバージョンイベントの取得数が増えたことで、GA4やGoogle広告で確認できるデータが、実際のコンバージョン状況により近づきました。 これにより、広告施策ごとの成果を、導入前より正確に評価できるようになりました。 また、Google広告へ連携されるコンバージョンデータの欠損が減ることで、自動入札や広告配信の最適化に利用できるデータ量の改善も期待できます。 ただし、広告の成果や配信精度は、以下のような複数の要因に左右されます。 広告予算 入札戦略 ターゲティング 広告クリエイティブ ランディングページ 市場環境 コンバージョン設定 そのため、Googleタグゲートウェイの導入だけで広告成果や広告精度が向上したとは断定していません。 今回の主な成果は、広告施策の評価や配信最適化に利用する、コンバージョンデータの欠損を減らせたことだと考えています。 振り返り GTMコンテナ内の変更を抑えて導入できた 今回の構成では、GTMコンテナ内のGA4タグ、Google広告タグ、トリガー、変数などを変更していません。 CloudFront側の通信経路と、Webサイトに設置しているGTMコードスニペットの読み込み先を変更することで導入できました。 既存の計測設計への影響を抑えながら導入できた点は、大きなメリットでした。 検証環境から段階的に導入することが重要 いきなり本番環境へ反映するのではなく、先に検証環境のCloudFront設定とGTMコードスニペットを変更しました。 検証環境では、GTMコンテナの読み込み、GA4イベント、SPA遷移、コンバージョンページなどを確認しました。 問題がないことを確認した後に本番環境へ展開することで、既存計測への影響を抑えながら導入できました。 複数チームの連携が必要 Googleタグゲートウェイは、GTMやGA4だけでなく、CloudFrontなどの配信基盤と、Webサイトに設置されるコードにも関係します。 今回の導入では、DataOpsグループ、インフラ担当、プロダクトチームがそれぞれ以下を担当しました。 DataOpsグループ：要件整理、計測確認、効果検証 インフラ担当：CloudFrontの設定 プロダクトチーム：GTMコードスニペットの差し替え 事前に担当範囲を整理したことで、検証環境から本番環境への展開をスムーズに進められました。 レイヤーごとに切り分けることが重要 Googleタグゲートウェイ導入後の通信には、複数の要素が関係します。 Webサイト ↓ GTMコードスニペット ↓ GTMコンテナ ↓ ブラウザ ↓ Amazon CloudFront ↓ Googleタグゲートウェイ ↓ GA4・Google広告など 問題が発生した場合は、最初からすべてを調査するのではなく、どこまで正常に処理されているかを順番に確認することが重要です。 ブラウザのNetworkタブ、GTMのプレビューモード、GA4のDebugViewなどを組み合わせることで、問題がWebサイト側にあるのか、GTMにあるのか、インフラ側にあるのかを切り分けやすくなりました。 おわりに 今回は、Amazon CloudFrontを利用して、Googleタグゲートウェイを導入した事例を紹介しました。 Googleタグゲートウェイの導入だけで、すべてのイベント欠損を防げるわけではありません。 一方で、Googleドメインへの直接通信がブロックされることによる欠損を軽減し、サイト改善や広告施策の判断に利用するデータを、実態に近づける効果を確認できました。 Amazon CloudFrontを利用してGoogleタグゲートウェイの導入を検討されている方にとって、本記事が少しでも参考になれば幸いです。

トリビューでリードエンジニアをしています、志甫 (@shihochan_jp) です。 弊社では、美容医療アプリ「トリビュー」の4リポジトリ（iOS、Android、Webフロントエンド、バックエンド）から、Google Analytics・Braze・Adjustの計測定義279エントリ（イベントのほか、ユーザー属性や配信トリガーの定義も含む）を横断するカタログを、AIで自動生成する仕組みを運用しています[1]。 AIにコードを読ませてドキュメントを生成させると、次の2つが問題になります。 実行のたびに出力が微妙に揺れて、変更差分が読めなくなる コードに存在しないイベント名が、もっと

GA4のGeminiを活用した新機能「Ask Advisor」（旧 Analytics Advisor）について検証します。