Googleタグマネージャー(GTM)とは?仕組み・使い方・GA4との違いを徹底解説
Webサイトのアクセス解析や広告効果測定を行う際には、計測用のコードをページへ設置する必要があります。しかし、利用する解析サービスや広告媒体が増えるほど、管理するコードの数も増え、更新や削除のたびにWebサイトの改修作業が発生します。こうした計測コードの管理を効率化するために利用されているのが、Googleタグマネージャーです。
Googleタグマネージャーを導入すると、Googleアナリティクス4の計測、広告の成果測定、ボタンのクリック計測、資料ダウンロードの計測などを、管理画面から設定できるようになります。ただし、導入すれば自動的にすべてのデータが取得できるわけではありません。タグ、トリガー、変数、データレイヤーなどの役割を理解し、目的に合った設計を行うことが重要です。
本記事では、Googleタグマネージャーの仕組みや導入手順だけでなく、Googleアナリティクス4やGoogleタグとの違い、タグが動作しない場合の確認方法、運用時の注意点まで詳しく解説します。初めて導入する担当者はもちろん、すでに利用しているものの設定方法に不安がある方にも役立つ内容です。
1. Googleタグマネージャー(GTM)とは
Googleタグマネージャーは、Webサイトやアプリに設置する計測用コードを一元管理するための仕組みです。管理画面上で計測条件や送信内容を設定できるため、コードを追加するたびにWebページのファイルを直接編集する負担を減らせます。
1.1 Googleタグマネージャーの定義
Googleタグマネージャーとは、Googleが提供するタグ管理システムです。アクセス解析、広告効果測定、利用者行動の把握などに使う計測用コードを、コンテナと呼ばれる管理単位にまとめて運用できます。
Webサイトには最初にGoogleタグマネージャーのコンテナコードを設置します。その後は管理画面から各種タグを登録し、どのページで、どのような条件のときに実行するかを指定します。
| 項目 | 内容 |
|---|---|
| 提供元 | |
| 主な目的 | 計測用コードの一元管理 |
| 管理対象 | 解析、広告、行動計測などのタグ |
| 主な利用者 | Web担当者、広告担当者、解析担当者、制作者 |
| 利用料金 | 標準版は無料 |
1.2 タグ管理システムが必要とされる理由
計測サービスを個別に導入する場合、それぞれのコードをWebサイトへ直接追加しなければなりません。広告媒体が増えるたびに改修依頼が発生し、設置場所や実行条件の確認にも時間がかかります。
Googleタグマネージャーを利用すれば、計測コードの追加や停止を管理画面から行えます。公開前に動作確認もできるため、担当者間のやり取りや、軽微な改修にかかる作業時間を減らしやすくなります。
1.3 コンテナの役割
コンテナは、Webサイトごとのタグ、トリガー、変数などを格納する管理領域です。一般的には、Webサイトやアプリなど、計測対象ごとにコンテナを分けて作成します。
異なるWebサイトを一つのコンテナで管理すると、誤ったタグを別サイトで配信する危険が高まります。運用担当者や公開範囲が異なる場合も、コンテナを分離したほうが権限管理を行いやすくなります。
| コンテナの分け方 | 適したケース |
|---|---|
| サイト単位 | 一般的な企業サイトやサービスサイト |
| ブランド単位 | ブランドごとに運用担当者が異なる場合 |
| 環境単位 | 本番、検証、開発環境を厳密に分ける場合 |
| アプリ単位 | Webサイトと携帯アプリを別管理する場合 |
1.4 Googleタグマネージャーの利用対象
Googleタグマネージャーは、大規模な通販サイトだけでなく、企業サイト、採用サイト、個人運営のメディア、予約サイトなどでも利用できます。複数の計測サービスを導入しているWebサイトほど、管理効率を高めやすくなります。
一方、更新頻度が低く、計測コードも一つしか使用しない小規模サイトでは、必ずしも導入が必要とは限りません。運用する人員や、今後追加する可能性のある計測内容を考慮して判断します。
1.5 導入すれば自動計測されるわけではない
Googleタグマネージャーのコンテナコードを設置しただけでは、Googleアナリティクス4のデータや広告成果は送信されません。管理画面でタグを作成し、実行条件となるトリガーを設定して公開する必要があります。
また、購入金額や商品名、会員区分など、ページ内に表示されているだけでは取得しにくい情報もあります。その場合は、Webサイト側からデータレイヤーへ必要な値を渡す実装が求められます。
2. Googleタグマネージャーでできること
Googleタグマネージャーでは、ページ閲覧だけでなく、クリック、入力、送信、動画再生、画面の表示状況など、さまざまな利用者行動を計測できます。目的を明確にすれば、広告改善やサイト改善に必要なデータを効率よく集められます。
2.1 ページ閲覧の計測
Googleアナリティクス4の測定用タグを登録すると、ページ閲覧を計測できます。すべてのページでタグを動作させる設定にすれば、サイト全体の閲覧状況を把握できます。
ただし、単一ページアプリケーションなど、ページを再読み込みせずに画面が切り替わるサイトでは追加設定が必要です。画面遷移の仕組みに合わせて、履歴変更や独自イベントを利用します。
2.2 ボタンやリンクのクリック計測
問い合わせボタン、電話番号リンク、外部サイトへのリンク、資料請求ボタンなどのクリックを計測できます。ページ閲覧数だけでは判断できない、利用者の具体的な行動を確認できる点が特徴です。
クリック計測では、リンク先、要素の識別子、表示文字列、クラス名などを条件として使います。条件を広くしすぎると不要なクリックまで記録されるため、対象要素を正確に指定する必要があります。
| 計測対象 | 活用例 |
|---|---|
| 問い合わせボタン | 問い合わせ意向の把握 |
| 電話番号リンク | 携帯端末からの電話行動の把握 |
| 資料請求ボタン | 見込み顧客の行動分析 |
| 外部リンク | 送客先の確認 |
| 採用応募ボタン | 求職者の応募意向の把握 |
2.3 入力フォームの送信計測
問い合わせフォーム、資料請求フォーム、予約フォーム、会員登録フォームなどの送信を計測できます。送信完了ページが存在する場合は、完了ページの表示を成果として計測する方法が一般的です。
画面遷移を伴わないフォームでは、送信成功時に独自イベントをデータレイヤーへ送る方法が適しています。送信ボタンのクリックだけを成果にすると、入力エラーや送信失敗も含まれる可能性があります。
2.4 動画・スクロール・ファイル取得の計測
埋め込み動画の再生、一定割合までのスクロール、PDFや資料ファイルの取得なども計測できます。記事や販売ページの内容が、どこまで閲覧されたかを判断する材料になります。
ただし、計測項目を増やしすぎると、必要な情報が埋もれやすくなります。改善施策へ結び付く行動を優先し、目的のないイベントを大量に作らないことが重要です。
2.5 広告成果と再訪問向け配信の計測
検索広告や表示広告の成果測定タグを設定し、問い合わせ、購入、会員登録などの成果を広告媒体へ送信できます。成果地点ごとに値や通貨を設定すれば、件数だけでなく売上ベースの評価も可能です。
再訪問向け広告に利用するタグも管理できます。ただし、広告目的の識別情報を扱う場合は、利用者の同意取得やプライバシーポリシーへの記載など、法令と各媒体の規約に沿った運用が必要です。
3. Googleタグマネージャーの仕組み
Googleタグマネージャーは、タグ、トリガー、変数という三つの要素を組み合わせて動作します。さらに、Webサイト側からデータを渡すデータレイヤーを活用すると、より正確で柔軟な計測を実現できます。
3.1 タグの役割
タグは、条件を満たしたときに実行される処理です。Googleアナリティクス4へイベントを送信するタグ、広告成果を送信するタグ、独自の処理を実行するタグなどがあります。
タグを作成する際は、送信先、イベント名、測定識別子、送信する値を指定します。タグ単体ではいつ実行するか決まらないため、必ずトリガーと組み合わせます。
3.2 トリガーの役割
トリガーは、タグを実行する条件です。ページが表示されたとき、特定のリンクがクリックされたとき、フォームが送信されたときなど、利用者の行動やページの状態を条件にできます。
一つのタグに複数のトリガーを設定することも可能です。ただし、条件が重複すると同じタグが複数回動作する場合があるため、公開前に発火回数を確認します。
3.3 変数の役割
変数は、ページや操作の状況によって変化する値を保持する仕組みです。ページのURL、クリックされた文字列、リンク先、商品金額、会員区分などをタグやトリガーで利用できます。
あらかじめ用意された組み込み変数に加え、独自の変数も作成できます。データレイヤー変数、定数、参照表、独自JavaScript変数などを目的に応じて使い分けます。
| 種類 | 取得できる値の例 |
|---|---|
| ページ関連変数 | URL、ホスト名、参照元 |
| クリック関連変数 | 文字列、リンク先、識別子 |
| フォーム関連変数 | 要素名、識別子、送信先 |
| データレイヤー変数 | 商品名、価格、会員区分 |
| 定数 | 測定識別子、固定値 |
3.4 データレイヤーの役割
データレイヤーは、WebサイトとGoogleタグマネージャーの間で情報を受け渡すためのデータ領域です。ページ構造に依存せず、商品情報や注文情報などを一定の形式で渡せます。
画面上の文字列を直接読み取る方法は、デザイン変更によって動作しなくなる可能性があります。重要な成果や売上情報は、データレイヤー経由で取得する設計が安定しています。
3.5 公開バージョンの仕組み
Googleタグマネージャーでは、設定を保存しただけでは実際の利用者に配信されません。プレビューで確認した後、公開操作を行うことで新しいバージョンが配信されます。
公開履歴には、その時点の設定が保存されます。不具合が発生した場合は以前のバージョンへ戻せるため、公開名と変更内容を具体的に記録しておくことが大切です。
4. GoogleタグマネージャーとGoogleアナリティクス4の違い
GoogleタグマネージャーとGoogleアナリティクス4は、同じGoogleのサービスですが役割が異なります。Googleタグマネージャーは計測処理を管理し、Googleアナリティクス4は送信されたデータを保存、集計、分析します。
4.1 役割の違い
Googleタグマネージャーの主な役割は、いつ、どの情報を、どのサービスへ送るかを管理することです。Googleアナリティクス4は、受信した閲覧や行動データをレポートとして確認するために使います。
両者は競合するサービスではなく、組み合わせて利用する関係です。Googleタグマネージャーを使わず、Googleアナリティクス4のコードをサイトへ直接設置する方法もあります。
| 比較項目 | Googleタグマネージャー | Googleアナリティクス4 |
|---|---|---|
| 主な役割 | 計測処理の管理 | データの保存・分析 |
| データの蓄積 | 原則として行わない | 行う |
| レポート表示 | 原則として行わない | 行う |
| 実行条件の設定 | 得意 | 一部のみ |
| 外部広告タグの管理 | 可能 | 主目的ではない |
4.2 データ保存の違い
Googleタグマネージャーは、タグを実行して各サービスへ情報を送るための仕組みであり、通常のアクセス解析レポートを保存する場所ではありません。
Googleアナリティクス4には、イベント、利用者、流入元、端末、成果などのデータが保存されます。過去の分析を行う場合は、Googleアナリティクス4側の保存期間や設定も確認する必要があります。
| 確認内容 | Googleタグマネージャー | Googleアナリティクス4 |
|---|---|---|
| タグの発火履歴 | プレビュー時に確認 | 確認対象外 |
| イベント件数 | 集計しない | 集計する |
| 利用者属性 | 保存しない | 条件に応じて表示 |
| 流入経路 | 分析しない | 分析できる |
| 過去比較 | 設定履歴のみ | 計測データを比較可能 |
4.3 設定画面の違い
Googleタグマネージャーでは、タグ、トリガー、変数、フォルダ、公開バージョンを管理します。設定内容は、計測処理が動く条件や送信値に直結します。
Googleアナリティクス4では、イベント、成果、データストリーム、参照元除外、利用者権限などを管理します。計測後のデータをどのように扱うかという設定が中心です。
| 設定例 | Googleタグマネージャー | Googleアナリティクス4 |
|---|---|---|
| クリック条件 | 設定可能 | 詳細条件は限定的 |
| イベント送信 | 設定可能 | 受信・加工 |
| 成果指定 | 送信処理を設定 | 成果イベントとして指定 |
| 権限管理 | コンテナ単位 | アカウント・プロパティ単位 |
| 公開管理 | バージョン公開 | 設定保存が中心 |
4.4 不具合確認方法の違い
Googleタグマネージャーでは、プレビューモードを使い、タグがどの操作で発火したか、どの変数に何が入ったかを確認します。発火しなかったタグについても、条件の不一致を調べられます。
Googleアナリティクス4では、リアルタイムレポートやデバッグ表示を使い、送信されたイベントが受信されているかを確認します。両方を確認することで、送信側と受信側のどちらに問題があるかを切り分けられます。
| 確認したい内容 | 使用する機能 |
|---|---|
| タグが実行されたか | Googleタグマネージャーのプレビュー |
| トリガー条件が一致したか | Googleタグマネージャーのプレビュー |
| イベントが受信されたか | Googleアナリティクス4のデバッグ表示 |
| 即時の利用状況 | Googleアナリティクス4のリアルタイム |
| 公開前の設定 | Googleタグマネージャーのワークスペース |
4.5 導入方法の違い
Googleアナリティクス4を直接導入する場合は、測定用コードをWebサイトへ設置します。構成が単純なサイトでは、直接設置でも計測できます。
Googleタグマネージャー経由で導入する場合は、最初にコンテナコードを設置し、管理画面でGoogleアナリティクス4用のタグを作成します。将来的にイベントや広告タグを追加する予定がある場合は、管理しやすくなります。
| 導入方法 | 長所 | 注意点 |
|---|---|---|
| 直接設置 | 構成が単純 | 追加のたびにサイト改修が必要 |
| GTM経由 | 一元管理しやすい | 初期設計と公開管理が必要 |
| 両方を併用 | 特別な理由がある場合に対応 | 二重計測の危険が高い |
5. GoogleタグマネージャーとGoogleタグの違い
Googleタグは、Googleアナリティクス4やGoogle広告などへデータを送信するための共通的な計測タグです。一方、Googleタグマネージャーは、Googleタグを含む複数のタグを管理するための仕組みです。
5.1 管理範囲の違い
Googleタグは、主にGoogleの計測サービスへ情報を送るために利用します。測定識別子や送信先を設定し、ページ閲覧やイベントを記録します。
Googleタグマネージャーでは、Googleタグに加え、広告成果タグ、独自HTML、第三者サービスの計測タグなども管理できます。複数サービスを一つの画面で運用したい場合に適しています。
| 比較項目 | Googleタグマネージャー | Googleタグ |
|---|---|---|
| 役割 | 複数タグの管理 | Googleサービスへのデータ送信 |
| 管理対象 | Google以外も含む | 主にGoogleの送信先 |
| トリガー設定 | 詳細に設定可能 | 設置方法により異なる |
| 変数利用 | 可能 | 単体では限定的 |
| 公開履歴 | バージョン管理可能 | 設置環境側で管理 |
5.2 設置コードの違い
Googleタグを直接利用する場合は、対象となるWebページへGoogleタグのコードを設置します。設定変更によっては、Webサイトのファイル編集が必要になります。
Googleタグマネージャーを利用する場合は、コンテナコードを設置し、その中でGoogleタグを設定します。管理画面から変更できる範囲が増えるため、継続的な計測改善に向いています。
| 項目 | 直接設置 | GTM経由 |
|---|---|---|
| 最初のコード | Googleタグ | GTMコンテナ |
| 設定変更 | サイト改修が必要な場合がある | 管理画面で対応しやすい |
| 複数媒体 | 個別管理 | 一元管理 |
| 公開確認 | サイト側の確認が中心 | プレビューで確認可能 |
| 誤配信対策 | 開発工程に依存 | 権限・公開履歴を利用可能 |
5.3 実行条件の違い
Googleタグを直接設置すると、通常はページの読み込み時に実行されます。特定のボタンが押されたときだけ実行するには、追加のJavaScript実装が必要になる場合があります。
Googleタグマネージャーでは、クリック、フォーム送信、スクロール、動画再生、独自イベントなどをトリガーとして設定できます。管理画面で条件を組み合わせられる点が大きな違いです。
| 実行条件 | Googleタグ単体 | GTM |
|---|---|---|
| 全ページ表示 | 対応可能 | 対応可能 |
| 特定ページ | コード側の条件が必要な場合がある | URL条件で設定可能 |
| ボタンクリック | 追加実装が必要になりやすい | クリックトリガーを利用 |
| 独自イベント | JavaScript実装が必要 | データレイヤーと連携 |
| 除外条件 | コード側で管理 | トリガー条件で管理 |
5.4 運用担当者の違い
Googleタグの直接設置は、HTMLやJavaScriptを編集できる開発担当者が管理するケースが多くなります。変更のたびに制作会社や開発部門への依頼が必要になることもあります。
Googleタグマネージャーは、一定の知識を持つ解析担当者や広告担当者も操作できます。ただし、独自HTMLや複雑なデータレイヤーを扱う場合は、開発担当者との連携が必要です。
| 作業 | 直接設置 | GTM |
|---|---|---|
| 初期コード設置 | 開発担当者が中心 | 開発担当者が中心 |
| タグ追加 | 開発担当者への依頼が多い | 運用担当者でも対応可能 |
| 複雑な値取得 | 開発実装が必要 | 開発連携が必要 |
| 公開承認 | 開発工程で実施 | GTM権限で分担可能 |
| 日常確認 | ソース確認が中心 | プレビューを利用可能 |
5.5 使い分けの違い
計測内容が少なく、今後も追加予定がないWebサイトでは、Googleタグの直接設置が適する場合があります。構成が単純であるため、管理対象を増やさずに済みます。
複数の広告媒体、クリックイベント、購入イベントなどを継続的に管理する場合は、Googleタグマネージャーが適しています。将来の拡張性と運用体制を考えて選択します。
| 条件 | 適した方法 |
|---|---|
| 計測がページ閲覧のみ | 直接設置も選択肢 |
| 広告媒体が複数ある | GTM |
| クリック計測が多い | GTM |
| 更新担当者が複数いる | GTM |
| 開発工程で厳密に一括管理する | 運用方針により判断 |
6. Googleタグマネージャーを導入するメリット
Googleタグマネージャーの価値は、単にコードを追加しやすくすることだけではありません。管理場所の統一、公開前確認、履歴保存、権限分担などを通じて、計測運用全体の品質を高められます。
6.1 タグを一元管理できる
アクセス解析、広告成果測定、利用者行動分析などのタグを、一つのコンテナ内で管理できます。どのタグが、どの条件で動作しているかを確認しやすくなります。
直接設置されたコードが複数ページに分散していると、削除漏れや重複が発生しやすくなります。Googleタグマネージャーへ集約すると、不要なタグの把握や停止も行いやすくなります。
6.2 軽微な変更を迅速に反映できる
URL条件の変更、イベント名の修正、広告タグの追加など、Webサイトの構造を変えない作業であれば、管理画面から対応できる場合があります。
ただし、開発確認を完全に省略してよいわけではありません。サイト表示や個人情報に影響する設定は、社内の承認手順や検証工程を通してから公開します。
6.3 プレビューで公開前に確認できる
プレビューモードでは、実際のWebサイトを操作しながら、どのタグが発火したかを確認できます。タグが動かなかった場合は、トリガー条件や変数の値を調べられます。
公開前の確認を習慣化すれば、誤ったページでの発火や、同一イベントの二重送信を減らせます。重要な成果計測では、送信先サービス側の受信状況も合わせて確認します。
6.4 バージョン履歴を残せる
公開するたびに設定内容がバージョンとして保存されます。いつ、どのような変更を公開したかを後から確認できるため、不具合の原因調査に役立ちます。
公開名に「修正」だけを入力すると、後から内容を判別できません。「問い合わせ送信イベント追加」「購入金額の変数修正」のように、変更目的を具体的に記録します。
| 悪い公開名 | 改善した公開名 |
|---|---|
| 修正 | 資料請求完了イベントの条件修正 |
| タグ追加 | 検索広告の購入成果タグ追加 |
| 更新 | 電話リンククリックの除外条件追加 |
| テスト | 会員登録イベントの本番公開 |
6.5 権限を分担できる
閲覧、編集、承認、公開などの権限を役割に応じて分けられます。広告代理店には編集まで許可し、最終公開は社内担当者が行うといった運用も可能です。
全員へ公開権限を付与すると、確認不足の設定が本番へ反映される危険があります。担当者の業務範囲に合わせ、必要最小限の権限を設定します。
7. Googleタグマネージャーのデメリットと注意点
Googleタグマネージャーは便利な仕組みですが、使い方を誤ると計測漏れ、二重計測、表示速度への影響、情報漏えいなどにつながります。導入後の運用ルールまで含めて設計する必要があります。
7.1 初期学習が必要になる
タグ、トリガー、変数、データレイヤーなど、独自の構成を理解する必要があります。画面操作だけを覚えても、計測条件を正しく設計できるとは限りません。
特に、クリック条件やフォーム送信は、Webサイトの構造によって挙動が異なります。最初は小規模なイベントから設定し、プレビュー結果と送信先のデータを照合しながら学習します。
7.2 誤設定が全ページへ影響する
すべてのページを対象とするトリガーに誤ったタグを設定すると、サイト全体で不要な処理が実行されます。独自HTMLの内容によっては、画面表示や他の処理へ影響する可能性もあります。
本番公開前には、対象ページだけでなく、対象外ページでも動作を確認します。除外条件を利用する場合は、対象条件と除外条件の優先関係も確認します。
7.3 タグの増加で表示性能へ影響する
Googleタグマネージャー自体は非同期で読み込まれますが、コンテナ内で多数の外部タグを実行すると、通信や処理が増加します。特に、重い第三者プログラムや不要な再訪問向けタグには注意が必要です。
定期的にタグを棚卸しし、利用していない広告媒体や検証用タグを停止します。すべてのページで実行する必要がないタグは、対象ページや同意状態を限定します。
7.4 個人情報を送信しない設計が必要になる
メールアドレス、電話番号、氏名、住所などを、解析サービスのイベント値としてそのまま送信してはいけません。URLの問い合わせ文字列や入力欄の値から、意図せず個人情報を取得する場合もあります。
変数を作成する際は、取得する値の中身を確認します。ページURLへ個人情報が含まれるシステムでは、送信前に除去する処理や、Webサイト側の仕様変更を検討します。
7.5 管理ルールがないと複雑化する
担当者ごとに自由な名前を付けると、同じ目的のタグや変数が重複します。数年後には、どの設定が現役なのか判断できなくなる可能性があります。
命名規則、公開手順、確認項目、削除基準、権限方針を文書化します。タグ名だけで、媒体、計測対象、イベント、実行条件を判別できる形が理想です。
| 種類 | 命名例 |
|---|---|
| Googleアナリティクス4イベント | GA4_問い合わせ送信 |
| 広告成果 | 広告_購入完了 |
| クリックトリガー | CLK_ヘッダー問い合わせ |
| データレイヤー変数 | DLV_購入金額 |
| 定数 | CONST_GA4測定識別子 |
8. アカウントとコンテナの設計方法
導入時にアカウント名やコンテナ構成を適当に決めると、サイト追加や権限変更の際に管理しにくくなります。組織、ブランド、Webサイト、環境の関係を確認してから作成します。
8.1 アカウントの作成単位
一般的には、企業や組織単位で一つのアカウントを作成します。その配下に、Webサイトやアプリごとのコンテナを配置します。
代理店のアカウント内に顧客企業のコンテナを作成すると、契約終了後の移管が複雑になる場合があります。原則として、Webサイトを所有する企業がアカウントを管理します。
8.2 コンテナの作成単位
一つのWebサイトに一つのWeb用コンテナを作成する方法が分かりやすい設計です。複数ドメインを同じ計測方針で運用する場合は、共通コンテナを使う選択肢もあります。
ただし、公開担当者、計測目的、サイト構造が大きく異なる場合は分けたほうが安全です。コンテナを共有する場合は、ドメイン条件を明確に設定します。
8.3 本番環境と検証環境の分け方
本番サイトと検証サイトで同じコンテナを使う場合、ホスト名によってタグの実行を分けます。誤って検証データを本番の解析先へ送らないように注意します。
より厳密に管理する場合は、環境機能や別コンテナを利用します。開発体制、公開頻度、検証サイトの構成に応じて選択します。
| 方法 | 長所 | 注意点 |
|---|---|---|
| ホスト名で分岐 | 管理対象が少ない | 条件漏れに注意 |
| 環境機能を利用 | 同じ設定を環境別に配信可能 | 運用知識が必要 |
| 別コンテナ | 完全に分離しやすい | 設定の同期が必要 |
8.4 ワークスペースの使い分け
ワークスペースを利用すると、複数の変更作業を分けて進められます。広告タグ追加と解析イベント修正を別々に管理することが可能です。
同じタグを複数のワークスペースで編集すると、競合が発生します。作業開始時に担当範囲を共有し、公開前に差分を確認します。
8.5 権限設計
社内管理者、解析担当者、広告代理店、制作会社など、それぞれに必要な権限を設定します。閲覧だけでよい担当者へ公開権限を与える必要はありません。
退職者や契約終了した外部担当者の権限が残っていないか、定期的に確認します。個人アカウントだけに管理権限を集中させず、複数の社内管理者を設定しておくと安全です。
9. Googleタグマネージャーの導入手順
Googleタグマネージャーの導入は、アカウント作成、コンテナ作成、コード設置、動作確認という順番で進めます。コードの設置場所を誤ると、タグが正しく実行されないため注意が必要です。
9.1 アカウントを作成する
Googleタグマネージャーの管理画面で、アカウント名、国、コンテナ名、対象プラットフォームを指定します。Webサイトへ導入する場合は、対象プラットフォームとしてWebを選択します。
アカウント名には企業名、コンテナ名にはサイト名やドメインを使用すると管理しやすくなります。個人名だけを使用すると、担当変更時に所有関係が分かりにくくなります。
9.2 コンテナコードを取得する
コンテナを作成すると、GTM-XXXXXXXの形式でコンテナ識別子が発行されます。同時に、Webサイトへ設置する二種類のコードが表示されます。
一つ目はページ上部のhead要素内へ設置し、二つ目はbody開始直後へ設置します。利用している管理システムに専用入力欄がある場合は、その仕様を確認して設置します。
設置コード例
<!-- Googleタグマネージャー -->
<script>
(function(w,d,s,l,i){
w[l]=w[l]||[];
w[l].push({'gtm.start': new Date().getTime(),event:'gtm.js'});
var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),
dl=l!='dataLayer'?'&l='+l:'';
j.async=true;
j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;
f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-XXXXXXX');
</script>
<!-- Googleタグマネージャー終了 -->
9.3 head内へコードを設置する
スクリプト部分は、可能な限りhead要素内の上部へ設置します。早い段階でコンテナを読み込むことで、ページ表示直後に必要な計測を実行しやすくなります。
同じコンテナコードを複数回設置すると、タグが二重に実行される可能性があります。テンプレート、拡張機能、管理システムの設定が重複していないか確認します。
9.4 body開始直後へ補助コードを設置する
noscriptを含む補助コードは、body開始タグの直後へ設置します。JavaScriptが無効な環境で利用される補助的な部分です。
管理システムの制限によって設置できない場合がありますが、スクリプト部分の設置が計測の中心です。設置可否はシステム提供元や開発担当者へ確認します。
補助コード例
<!-- Googleタグマネージャー(noscript) -->
<noscript>
<iframe
src="https://www.googletagmanager.com/ns.html?id=GTM-XXXXXXX"
height="0"
width="0"
style="display:none;visibility:hidden">
</iframe>
</noscript>
<!-- Googleタグマネージャー(noscript)終了 -->
9.5 設置後に読み込みを確認する
ブラウザの開発者向け機能やプレビューモードを使い、コンテナが読み込まれているか確認します。プレビュー接続が成功し、ページ表示イベントが確認できれば、基本的な設置は完了です。
確認時は、本番ドメイン、wwwの有無、常時暗号化通信、下位ドメインなど、実際に利用者がアクセスするURLを試します。特定のテンプレートだけコードが欠落していないかも確認します。
10. タグの設定方法
タグは、計測先へデータを送る中心的な要素です。タグ名、送信先、イベント名、値、トリガーを明確に設定し、公開前に実際の操作で確認します。
10.1 Googleタグを設定する
Googleアナリティクス4を利用する場合は、Googleタグを作成し、測定識別子を設定します。通常は、すべてのページで実行するページ表示トリガーを指定します。
測定識別子は、環境ごとに誤りがないか確認します。本番用と検証用で異なるプロパティを使う場合は、ホスト名による参照表や定数変数を利用すると管理しやすくなります。
10.2 Googleアナリティクス4イベントを設定する
問い合わせ、資料請求、電話リンク、商品閲覧などを計測する場合は、イベントタグを作成します。イベント名は小文字と下線を中心にし、意味が分かる名前へ統一します。
イベント名を担当者ごとに自由に付けると、同じ行動が複数の名称へ分散します。事前に計測設計書を作り、イベント名、発火条件、送信値、確認方法を記録します。
| 行動 | イベント名の例 |
|---|---|
| 問い合わせ送信 | generate_lead |
| 会員登録 | sign_up |
| 購入完了 | purchase |
| 資料取得 | file_download |
| 電話リンク | click_phone |
10.3 広告成果タグを設定する
広告成果タグでは、成果識別子、成果ラベル、金額、通貨、取引識別子などを設定します。媒体側で発行された値を正確に入力します。
購入成果では、同じ注文を再読み込みした際に二重計測しない設計が必要です。取引識別子を送信し、完了ページへの再訪問時の挙動も確認します。
10.4 独自HTMLタグを設定する
用意されたテンプレートで対応できない場合は、独自HTMLタグを利用できます。第三者サービスの計測コードや、独自のJavaScript処理を実行する際に使います。
独自HTMLは自由度が高い一方、サイト表示や安全性へ影響する可能性があります。出所不明のコードを貼り付けず、処理内容、通信先、取得情報を確認します。
独自イベント送信例
<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
event: 'custom_banner_view',
banner_name: 'summer_campaign'
});
</script>
10.5 タグの実行順序を管理する
複数のタグに依存関係がある場合は、タグの順序を管理します。設定用タグが完了してからイベントタグを送信するなど、先に必要な処理を明確にします。
ただし、複雑な順序指定を増やしすぎると、不具合時の原因調査が難しくなります。可能であれば、データレイヤー上の明確なイベントを基準に各タグを実行します。
11. トリガーの設定方法
トリガー設計では、必要なときだけタグが一回実行される状態を目指します。対象条件だけでなく、除外条件、再実行の可能性、画面遷移の有無も確認します。
11.1 ページ表示トリガー
ページ表示トリガーは、ページが読み込まれる過程でタグを実行します。すべてのページ、特定のURL、特定のホスト名などを条件にできます。
通常の解析タグは広い範囲で動作させますが、広告成果タグは完了ページなどに限定します。URLの部分一致だけでなく、パスや問い合わせ文字列の違いも確認します。
11.2 クリックトリガー
クリックトリガーには、リンクのみを対象とする方法と、すべての要素を対象とする方法があります。a要素のリンクはリンククリック、ボタン要素などは全要素クリックを利用します。
クリック文字列だけを条件にすると、文言変更で計測できなくなる場合があります。識別子や専用のデータ属性を付与し、安定した条件で計測する方法が望ましいです。
計測用属性の例
<a
href="/contact/"
data-track-action="contact"
data-track-location="header">
お問い合わせ
</a>
この場合、クリック要素の属性値を取得する独自変数を用意し、contactと一致した場合にタグを実行できます。
11.3 フォーム送信トリガー
標準的なフォーム送信であれば、フォーム送信トリガーを利用できます。ただし、非同期通信を利用するフォームでは、標準トリガーが正しく反応しない場合があります。
確実性を高めるには、送信成功後にWebサイト側から独自イベントを送信します。クリックではなく、サーバー側の処理が成功した時点を成果条件にすることが重要です。
送信成功イベント例
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
event: 'form_submit_success',
form_type: 'contact'
});
11.4 スクロールトリガー
スクロールトリガーでは、ページの25%、50%、75%、90%など、指定した位置まで閲覧されたことを計測できます。長い記事や販売ページの読了状況を確認する際に役立ちます。
ページごとに長さが異なるため、単純なスクロール率だけで評価しないことが大切です。滞在時間、ボタンクリック、成果率などと組み合わせて判断します。
11.5 独自イベントトリガー
独自イベントトリガーは、データレイヤーへ送信されたイベント名を条件としてタグを実行します。購入完了、ログイン、商品追加、入力成功など、Webサイト固有の処理を正確に計測できます。
イベント名は、開発側と計測側で共通仕様にします。大文字と小文字、下線、単数形と複数形が異なるだけでも、トリガーは一致しません。
12. 変数の設定と活用方法
変数を適切に利用すると、同じタグを複製せず、ページや行動に応じて値を切り替えられます。一方、変数の取得元が不安定だと、タグ全体の計測品質へ影響します。
12.1 組み込み変数を有効化する
Googleタグマネージャーには、ページURL、ページのホスト名、クリック文字列、クリック先などの組み込み変数があります。必要な変数を管理画面から有効にします。
すべての変数を無条件に有効化しても、直接的な問題が起こるとは限りませんが、確認画面が見にくくなります。利用する計測に必要な変数を中心に有効化します。
12.2 定数変数を利用する
測定識別子や固定の成果値など、複数のタグで共通利用する値は定数変数にします。値を変更する際に、一か所の修正で済むようになります。
タグへ直接測定識別子を入力すると、変更時に修正漏れが発生しやすくなります。変数名には用途と環境を含め、検証用と本番用を区別します。
12.3 データレイヤー変数を利用する
データレイヤー変数は、Webサイト側から渡された商品名、金額、注文番号などを取得します。画面上のHTMLを読み取る方法よりも、構造変更の影響を受けにくい点が特徴です。
データの階層が深い場合は、参照する変数名を正確に指定します。値が存在しないページでタグを実行すると、未定義の値が送信される可能性があります。
データレイヤー変数の参照例
{
event: 'purchase',
ecommerce: {
transaction_id: 'ORDER-1001',
value: 12800,
currency: 'JPY'
}
}
購入金額を取得する場合は、データレイヤー変数名としてecommerce.valueを指定します。
12.4 参照表を利用する
参照表は、入力値に応じて出力値を切り替える変数です。ホスト名によって測定識別子を変える場合や、内部名称を解析用名称へ変換する場合に利用できます。
入力値がどの条件にも一致しない場合に備え、既定値を設定します。既定値を空欄にすると、誤った環境へデータが送られないようにできます。
| 入力となるホスト名 | 出力する環境 |
|---|---|
| www.example.jp | 本番 |
| staging.example.jp | 検証 |
| localhost | 開発 |
| その他 | 送信対象外 |
12.5 独自JavaScript変数を利用する
組み込み変数やデータレイヤー変数だけで取得できない値は、独自JavaScript変数で加工できます。文字列の置換、値の正規化、条件による出力変更などが可能です。
複雑な処理を独自変数へ詰め込むと、担当者以外が理解しにくくなります。重要な情報は可能な限りWebサイト側で整形し、データレイヤーへ渡す設計を優先します。
URLから不要な問い合わせ情報を除く例
function() {
var url = new URL(window.location.href);
url.search = '';
url.hash = '';
return url.toString();
}
13. データレイヤーの設計と実装
データレイヤーは、高品質な計測を行ううえで重要な仕組みです。画面表示に依存せず、業務上必要な情報を一定の形式でGoogleタグマネージャーへ渡せます。
13.1 データレイヤーを初期化する
データレイヤーは、Googleタグマネージャーのコンテナコードより前に初期化します。初期表示時に必要な情報がある場合は、初期化と同時に値を設定します。
コンテナ読み込み後に値を設定すると、初回のページ表示タグで取得できない場合があります。ページ情報や会員状態を初回送信に利用する場合は、実行順序に注意します。
初期化コード例
<script>
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
page_type: 'product_detail',
member_status: 'guest'
});
</script>
13.2 イベントを送信する
利用者の操作やシステム処理が完了した時点で、eventを含む情報をデータレイヤーへ追加します。Googleタグマネージャーでは、そのイベント名を独自イベントトリガーとして利用します。
イベントと同時に必要な値を送信すると、タグが実行される時点で正しい情報を取得できます。値だけを先に追加し、別のタイミングでイベントを送る設計は、状態の食い違いに注意が必要です。
ボタンクリックイベント例
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
event: 'cta_click',
cta_name: 'contact',
cta_location: 'article_bottom'
});
13.3 通販サイトの購入情報を送信する
購入イベントでは、注文番号、合計金額、通貨、商品情報などを送信します。注文番号は、同一購入の重複判定に利用できる一意の値を使用します。
商品価格、数量、値引き、送料などの定義は、社内の売上集計と合わせます。税込と税抜が混在すると、広告媒体や解析画面の売上値が社内数値と一致しません。
購入イベント例
window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
event: 'purchase',
ecommerce: {
transaction_id: 'ORDER-1001',
value: 12800,
tax: 1163,
shipping: 500,
currency: 'JPY',
items: [
{
item_id: 'SKU-001',
item_name: 'オリジナルバッグ',
price: 6150,
quantity: 2
}
]
}
});
13.4 会員情報を扱う
会員と非会員で利用行動を比較する場合は、会員状態や会員区分をデータレイヤーへ渡せます。ただし、個人を直接識別できる情報は送信しません。
会員識別子を利用する場合は、利用規約、プライバシーポリシー、送信先サービスの規約を確認します。メールアドレスや電話番号を、そのまま解析用変数へ設定しないようにします。
| 送信を検討できる情報 | 送信を避ける情報 |
|---|---|
| 会員・非会員の区分 | 氏名 |
| 会員ランク | メールアドレス |
| ログイン状態 | 電話番号 |
| 匿名化された内部区分 | 住所 |
| 契約プラン | 入力フォームの自由記述 |
13.5 データレイヤー仕様書を作成する
データレイヤーのイベント名、変数名、型、発生条件、例を仕様書へ記載します。開発担当者と解析担当者が同じ定義を参照することで、実装の認識違いを減らせます。
仕様変更時は、Webサイト側の実装とGoogleタグマネージャー側の設定を同時に更新します。古い変数を突然削除すると、公開中のタグが未定義になるため、移行期間を設けます。
| 記載項目 | 内容例 |
|---|---|
| イベント名 | purchase |
| 発生条件 | 決済成功後 |
| 必須変数 | 注文番号、金額、通貨 |
| 任意変数 | 送料、割引、商品分類 |
| 値の型 | 文字列、数値、配列 |
| 重複対策 | 注文番号を一意にする |
14. 動作確認と問題解決
Googleタグマネージャーの設定は、保存しただけで正しいと判断できません。プレビュー、ブラウザの通信確認、送信先サービスのデバッグ機能を組み合わせて検証します。
14.1 プレビューモードを利用する
プレビューモードへ対象URLを入力すると、Webサイトと確認画面が接続されます。ページ表示、クリック、独自イベントなど、発生した処理を時系列で確認できます。
各イベントを選択すると、発火したタグ、発火しなかったタグ、変数の値を確認できます。タグが動かない場合は、トリガー条件のどこが一致していないかを確認します。
14.2 タグが発火しない原因を確認する
タグが発火しない主な原因には、URL条件の誤り、クリック対象の不一致、変数の未定義、イベント名の相違、除外条件への一致などがあります。
推測で設定を何度も変更するのではなく、プレビュー上の実際の値を確認します。クリック文字列やクラス名は、想定していた値と異なる場合があります。
| 症状 | 主な確認箇所 |
|---|---|
| 全ページで発火しない | コンテナ設置、公開状態 |
| 特定ページだけ発火しない | URL、ホスト名、除外条件 |
| クリックで発火しない | クリック要素、リンク先、文字列 |
| 独自イベントで発火しない | イベント名、送信タイミング |
| 値が空になる | 変数名、データ階層、実行順序 |
14.3 タグが二重発火する原因を確認する
二重発火は、コンテナコードの重複、直接設置との併用、複数トリガーの一致、完了イベントの重複送信などによって発生します。
Googleアナリティクス4を直接設置した状態で、Googleタグマネージャーからも同じ測定先へ送信すると、ページ閲覧が重複する場合があります。Webサイトのソース、管理システムの拡張機能、コンテナ設定を横断して確認します。
14.4 送信内容を通信画面で確認する
ブラウザの開発者向け機能にある通信画面では、解析サービスや広告媒体へ送られた通信を確認できます。イベント名、測定識別子、送信値などの確認に役立ちます。
タグが発火済みでも、通信が広告遮断機能や同意設定によって停止される場合があります。発火確認と受信確認を分けて考えることが重要です。
14.5 公開前の確認項目を定める
公開前には、対象ページ、対象外ページ、携帯端末、パソコン、入力成功、入力失敗、再読み込みなどを確認します。成果計測では、一回の操作で一件だけ記録されることを確認します。
確認者と設定者を分けると、思い込みによる見落としを減らせます。重要な変更では、公開後にもリアルタイムデータや成果件数を確認します。
| 確認項目 | 確認内容 |
|---|---|
| 対象条件 | 必要なページや操作で発火する |
| 除外条件 | 不要なページでは発火しない |
| 送信値 | イベント名、金額、通貨が正しい |
| 発火回数 | 一操作につき一回 |
| 受信確認 | 送信先でイベントを確認できる |
| 個人情報 | 送信値やURLに含まれていない |
15. 安全で成果につながる運用方法
Googleタグマネージャーは、設定を増やすことではなく、意思決定に必要なデータを安定して取得するために利用します。計測目的、運用責任、確認手順、改善方法を継続的に見直すことが重要です。
15.1 計測目的を先に決める
「取得できそうだから」という理由でイベントを追加すると、レポートが複雑になります。事業上の課題、確認したい仮説、改善する画面や導線を先に決めます。
問い合わせを増やしたい場合は、完了件数だけでなく、入力開始、入力エラー、途中離脱などを計測すると改善点を把握しやすくなります。ただし、必要な範囲に限定します。
15.2 計測設計書を管理する
タグ名、イベント名、目的、発火条件、送信値、確認方法、担当者を一覧化します。管理画面だけに情報を残すと、設定の背景や利用目的が分からなくなります。
新しいタグを追加する際は、既存イベントと重複しないか確認します。廃止した施策のタグには停止日を記録し、一定期間後に削除を検討します。
| 管理項目 | 記載内容 |
|---|---|
| 計測目的 | 何を判断するためのデータか |
| イベント名 | 送信する名称 |
| 発火条件 | ページ、操作、独自イベント |
| 送信値 | 金額、場所、分類など |
| 担当者 | 設定者、確認者 |
| 状態 | 稼働中、停止、確認中 |
15.3 同意状態に応じてタグを制御する
広告や解析に関する識別情報を扱う場合は、利用者の同意状態に応じてタグの動作を制御します。同意前に不要な保存や送信が行われない設計が必要です。
同意管理画面を設置するだけでなく、選択結果が各タグへ正しく反映されるか確認します。拒否後の再訪問、設定変更、地域差なども検証します。
初期同意状態の例
<script>
window.dataLayer = window.dataLayer || [];
function gtag() {
dataLayer.push(arguments);
}
gtag('consent', 'default', {
ad_storage: 'denied',
analytics_storage: 'denied',
ad_user_data: 'denied',
ad_personalization: 'denied'
});
</script>
15.4 定期的に棚卸しする
少なくとも数か月ごとに、タグ、トリガー、変数、権限、公開履歴を確認します。終了した広告施策や、利用しなくなった解析サービスのタグを放置しないようにします。
停止タグを永続的に残すと、コンテナが見にくくなります。復元の必要性や監査方針を考慮し、一定期間後に削除する基準を定めます。
15.5 検索流入改善へ活用する
Googleタグマネージャー自体が検索順位を直接上げるわけではありません。しかし、記事の読了、内部リンクのクリック、問い合わせ導線、資料取得などを計測することで、検索流入後の改善に必要な情報を得られます。
検索順位だけで評価すると、訪問後に利用者が目的を達成できたか判断できません。検索語句、閲覧ページ、スクロール、次の行動、成果を組み合わせ、内容と導線を改善します。
| 改善対象 | 計測例 |
|---|---|
| 記事の読みやすさ | スクロール率、滞在、離脱 |
| 内部リンク | リンク位置、リンク先、クリック数 |
| 問い合わせ導線 | ボタン位置、入力開始、送信完了 |
| 資料配布 | 資料名、取得ページ、成果率 |
| 商品ページ | 商品閲覧、追加、購入完了 |
おわりに
Googleタグマネージャーとは、アクセス解析や広告効果測定に利用するタグを、一つの管理画面で運用するための仕組みです。タグ、トリガー、変数を組み合わせることで、ページ閲覧だけでなく、クリック、フォーム送信、動画再生、スクロール、購入などの行動を計測できます。
Googleアナリティクス4はデータを保存して分析するサービスであり、Googleタグマネージャーはデータを送る条件や処理を管理するサービスです。また、Googleタグは主にGoogleの計測先へ情報を送るタグであり、GoogleタグマネージャーはGoogleタグを含む複数のタグを管理します。それぞれの役割を区別することで、二重計測や設定漏れを防ぎやすくなります。
導入時には、コンテナコードを正しい位置へ設置し、プレビューモードで発火条件を確認します。運用開始後も、計測設計書、命名規則、権限管理、個人情報対策、同意管理、定期的な棚卸しを継続することが重要です。必要なデータを正確に取得し、Webサイトや広告施策の改善へ結び付けることが、Googleタグマネージャーを活用する本来の目的です。
EN
JP
KR