GTM バージョンの見方と公開中の設定・変更差分を確認する方法

GTM バージョンの公開状態は、対象コンテナの「バージョン」一覧で「ライブ」の表示を確認します。新しい版番号やワークスペースの編集内容だけでは、現在サイトで使われている設定を判断できません。

Googleタグマネージャーで計測の状態を調べるとき、ワークスペースに表示されている内容だけを見て判断していませんか。ワークスペースには、作業中でまだ公開されていない変更が含まれることがあります。そのため、編集画面にタグがあることと、サイトでその設定が使われていることは同じではありません。

この違いを確かめるうえで役立つのが、バージョン履歴です。公開されている設定のまとまりと、変更されたタグ・トリガー・変数を確認すると、「いつから計測が変わったのか」「どの設定を比較すればよいか」を整理できます。

不具合調査では、まず現在公開されているバージョンを確かめ、その後に作業中の変更を見ることが大切です。この記事では、既存コンテナの設定を調べる担当者向けに、バージョン履歴の読み方と、差分を実際の計測確認につなげる方法を説明します。

バージョンとワークスペースの役割を分けて考える

GTMのワークスペースは、タグやトリガーなどの変更を進める作業場所です。一方、バージョンは、ある時点のコンテナ設定をひとまとまりにしたものです。サイトで使われる状態を確かめるときは、そのバージョンが実際に公開されているかまで確認する必要があります。

バージョンが作られたことと公開されたことを混同すると、関係者の認識がずれます。「変更を保存しました」という報告だけでは、タグの編集保存なのか、バージョンの作成なのか、サイトへの公開なのかが分かりません。やり取りでは、どの段階まで進んだかを言葉にしましょう。

たとえば、イベントタグを修正して保存しただけでは、通常のサイト訪問者にその変更が適用されているとは限りません。逆に、過去のタグ設定を開いて「まだ古い」と感じても、現在公開中の版とは別の履歴を見ている可能性があります。画面内の設定値だけでなく、今どの版を見ているかを確認してください。

複数人が同じコンテナで作業する場合は、この区別がさらに重要です。自分の変更が小さくても、別のワークスペースで進んでいる変更を取り込むと、公開対象が広がる場合があります。確認したい変更と、それ以外の変更を分けて読みます。

対象コンテナの公開状態から履歴を開く

GTMにアクセスしたら、アカウントとコンテナを選びます。複数のサイトを管理している場合は、会社名が合っていることだけでなく、対象ドメインとコンテナIDの対応を確かめてください。テスト用と本番用のコンテナが似た名前で並んでいることもあります。

対象コンテナのバージョンを開く

対象コンテナを開いたら、画面上部の「ワークスペース」の隣にある「バージョン」タブを選びます。赤枠の入口から履歴一覧へ進みます。対象サイトとの対応を確認できない場合は、先に管理担当へ確認してください。

履歴一覧で公開状態を読む

一覧には「バージョンID」「ステータス」「名前」「作成日時」「公開済み」が並びます。版番号と日時に加えて、ステータスを見て現在の公開状態を確認します。過去に公開された日付があることと、今も公開中であることは区別してください。新しい番号だからという理由だけで、現在の本番設定だと判断しないことが大切です。

公開中の版の表示を確認する

掲載画面では、バージョン4のステータスに「ライブ、最新」と表示されています。「ライブ」は公開中の版、「最新」はGTM内でワークスペースの設定を同期するときの基準となる版です。両者は役割が異なり、いつも同じ版になるとは限りません。現在の表示を読み、自社環境の番号と確認時刻を記録してください。

公開中かどうかは「ライブ」で確認し、「最新」だけで判断しないことが要点です。たとえば過去版を再公開した場合、公開中の版と同期基準の版が分かれることがあります。その状態を見つけても、確認のために「最新バージョンに設定」を実行しないでください。設定の変更は調査とは別に判断します。

確認の完了条件は、対象コンテナ、公開中の版、状態表示、確認時刻を一組で記録できることです。一覧は画像を開いて原寸でも確認でき、公開状態の文字は拡大画像でも確認できます。履歴を読む段階では、公開・削除・最新バージョンへの設定は行いません。

画面の構成は権限や利用するコンテナの種類によって異なることがあります。履歴が見つからない場合は、対象コンテナ、利用権限、管理画面の表示を確認しましょう。履歴の番号だけを共有するより、コンテナIDとバージョン名をセットにすると、相手が同じものを開きやすくなります。

また、確認時刻も残しておくと役立ちます。複数人が作業しているコンテナでは、自分が確認した後に別の公開が行われる場合があります。「昨日見た設定」と「今日の公開設定」が同じとは限りません。計測結果を比較するときは、公開時点を境に期間を分けます。

変更差分と公開前後の計測を確認する

変更差分はタグ・条件・値をつないで読む

タグの名前が変わっていないから、計測も変わっていないとは言えません。同じイベントタグでも、送信するパラメータ、発火させるトリガー、参照する変数が変わると、集計結果が変わることがあります。

比較するときは、タグ単体だけでなく、タグが利用するトリガーと変数まで確認しましょう。たとえば、問い合わせ完了イベントのタグが同じでも、トリガーが「完了ページへの到達」から「フォームボタンのクリック」へ変わっていれば、送信完了前の操作まで数える可能性があります。

比較対象は、現在公開中の版と調べたい時点の版について、番号・日時・状態をそろえて記録します。公開済みの設定同士を比べるのか、ワークスペースの未公開変更を調べるのかを、最初に明確にしましょう。後者の基準となる版が現在のライブと同じかも確認します。

通常の設定値の比較と、カスタムHTMLタグやカスタムJavaScript変数のソースコードの差分は分けて扱います。コードの変更では処理自体の違いを、通常の設定ではイベント名や条件値などの違いを確認します。ここでは比較の観点を整理し、差分画面を開く詳細なクリック手順は扱いません。

別の版の内容を調べることと、現在の作業内容へ取り込むことも違います。「最新バージョンに設定」は比較するためのボタンではありません。差分を表示する目的で設定を変更したり、変更を破棄したりせず、対象と基準が不明なら管理担当と照合してください。

差分を読むときには、追加・変更・削除の種類も分けます。タグが追加されても、条件が一致しなければ動作しません。トリガーを削除すると、関連する設定の動作に影響することがあります。削除された項目がある場合は、どこから参照されていたかまで確認してください。

変更された行数よりも、何を数える定義が変わったかを見ると、レポートの変化を解釈しやすくなります。イベント名の変更による集計の分断と、本当に問い合わせが減った場合では、必要な対応が違います。

調査で確認した差分のスクリーンショットを関係者へ共有する場合は、修正箇所だけを赤枠で示し、値の前後が読める範囲を残します。画面全体を小さくすると、条件の演算子や値が読めず、確認ミスにつながります。顧客情報や不要な識別情報が写っていないことも確認しましょう。

公開時刻とデータの変化を照合する

バージョン履歴は、不具合が起きた時点を絞る手掛かりになります。ただし、公開時刻の後に数値が変わったからといって、その公開が原因だとすぐに断定することはできません。広告の配信量、サイトの更新、同意画面の変更、計測先の設定など、同時期に起きた別の変更も確認します。

最初に、いつから何が変わったのかを整理します。「CVが少ない」ではなく、「特定の完了イベントが、どの期間から、どのページで減ったのか」まで分けると、差分と対応させやすくなります。アクセス全体が減っている場合と、特定イベントだけ減っている場合では調査先が違います。

公開日時と症状を並べる記入例

たとえば「午後にタグ設定を公開し、翌朝のレポートで完了イベントの減少に気づいた」場合、発見した時刻を発生時刻とは決めつけません。公開日時と、最後に正常を確認した期間、変化が見られる期間、サイト改修の日時を別々に記録します。時刻の基準が異なる資料は、タイムゾーンをそろえてから並べましょう。

記入例としては「公開日時：管理画面で確認した日時」「症状：特定ページの完了イベントが減少」「受付記録：社内で確認中」「同時期の改修：開発担当へ確認」と整理できます。原因の欄を先に埋めず、事実と仮説を分けて残すことが大切です。

GA4などの集計画面を比較する場合は、処理時間やタイムゾーンにも注意します。公開した直後の数値と、確定に近い過去の集計をそのまま比較すると、設定変更とは関係のない差が含まれます。リアルタイムの到達確認と、期間を揃えた集計の確認を分けて進めましょう。

また、GTMの履歴だけでサイト全体の変更を追えるわけではありません。サイトへ直接埋め込まれたコードや、別の計測ツールから送られるイベントは、GTMの変更履歴に出ない場合があります。GTMに変更がなかったから計測実装も変わっていない、と結論付けないことが大切です。

プレビューで現在の仮説を確かめる

この節では、検証の前に決める条件と結果の読み方を整理します。プレビューの起動や版の切り替えを画面付きで案内するものではありません。

差分から原因の候補が見つかったら、対象の操作と発火条件がどう対応するかを検証する準備をします。タグの動作を調べる確認と、送信先で受信・集計されたかの確認は、別の段階として計画しましょう。

ここでも、どの設定をプレビューしているかを揃えましょう。現在のワークスペースには、公開中のバージョンとは別の変更が含まれることがあります。作業中の設定で正常に動くことが確認できても、公開中の設定が正常とは限りません。検証する版、対象URL、操作、期待するイベントを先に決めます。

検証条件と結果の記録表

問い合わせ計測では、ボタンを押した段階と、送信が成功した段階を区別します。エラーがある入力を送信しようとしたときに完了イベントが発火していないか、同じ完了操作で何回送られているかも確認します。正常系だけでなく、数えてはいけない操作を確認することが重要です。

プレビューで本番のフォームを使うと、営業担当への通知や自動返信が発生する場合があります。計測を調べるために無断で送信を繰り返さず、検証用ページや許可された手順を用意してください。送信を行わずに確かめられる範囲と、実送信が必要な範囲を分けて扱います。

検証結果は、「タグが動いた」という一言で終わらせず、対象イベント、発火回数、送信先、主な値を整理します。GTM上の発火と、GA4など送信先での受信も別の段階です。Tag Assistantでタグが動いても、同意や通信、送信先の設定によって、期待した集計にならない場合があります。

過去版へ戻す前に影響範囲を確かめる

過去版の公開と「最新バージョンに設定」は、作用する対象が異なります。過去版を公開するとサイトへ適用する版が変わり、「最新バージョンに設定」はGTM内の設定の基準を変えます。一方の操作だけで、公開中の状態と作業の基準が両方そろうとは考えないでください。

ライブだけを過去版へ戻しても、同期基準に問題の設定が残っていれば、後で別の担当者が作業を同期・公開するときに、その設定が再び含まれる可能性があります。逆に、同期基準を戻しても、それだけで公開中の版が変わったとは判断できません。複数担当者で、公開状態と作業基準の両方を共有する必要があります。

以前のバージョンが正常だった場合、戻せば解決するように感じるかもしれません。しかし、過去版へ戻すと、その後に加わった正しい変更まで失われる可能性があります。問題のある変更だけを修正すべきか、版全体を戻す必要があるかを分けて判断します。

たとえば、問い合わせイベントの不具合が起きた後に、別の広告媒体の計測タグが追加されていた場合、過去版の公開によってそのタグが消える可能性があります。担当者ごとの変更を確認せずに戻すと、別施策の計測が止まるおそれがあります。

過去版への変更を検討する前の確認表

戻す場合にも、対象コンテナ、戻すバージョン、失われる変更、影響するイベント、確認方法を整理しましょう。設定を戻した後は、問題のイベントだけでなく、維持したい主要な計測も確認します。「以前の状態に戻した」ことと「現在必要な計測がすべて動いている」ことは同じではありません。

この節は影響範囲の判断を扱い、復元の実行手順は扱いません。過去の履歴そのものが消えるという意味ではなく、採用する設定内容に後続の変更が含まれなくなる点を確認してください。

バージョン名や説明には、作業の目的が分かる言葉を使うと管理しやすくなります。「修正」「テスト」だけでは、後から変更内容を見つけにくくなります。対象イベントや確認した内容を短く整理し、公開した担当者と確認先を共有しておくと、次の調査の手間が減ります。

確認の担当が変わる場合は、比較した版と検証した操作も引き継ぎます。履歴の画面を開けることだけでは、判断の前提までは伝わりません。どの条件が誤りで、修正後にどの動作を期待しているのかを説明しておくと、次の担当者が同じ作業を最初から繰り返さずに済みます。公開後に値が安定したかを確認する担当と時点も決めておくと、設定の反映だけで完了してしまうことを防げます。

履歴の確認を日々の広告計測に生かす

設定を調べる担当者が、過去のバージョンを開いたまま作業を続ける場合にも注意が必要です。その画面で確認した値を現在の設定として報告しないよう、調査の終わりに公開中の版を再確認します。並行して作業する担当者がいる場合は、公開状態が途中で変わっていないかを確かめると、確認結果の食い違いを防げます。

一方、ワークスペースに未公開の変更が残っていても、それをすべて不要と判断して削除しないでください。別施策の作業途中や、次の公開に必要な修正かもしれません。自分の調査対象とは分け、変更を進めている担当者へ用途を確認します。履歴を整理する目的であっても、作業中の設定までまとめて消すことは適切ではありません。

公開を伴う修正の準備では、確認した不具合、変更する項目、維持する項目を整理します。小さな修正でも、同じ変数が複数のタグから参照されていれば影響は広がります。参照関係を確認してから変更し、対象外の主要イベントも必要な範囲で点検すると、別の計測を壊すことを防ぎやすくなります。

バージョン履歴を読めるようになると、広告の成果が変わったときに、配信の問題と計測の問題を分けて考えやすくなります。設定の変更時点を把握できれば、データを比較するときの期間や注意点も明確になります。

調査結果を引き継ぐための確認表

数値の増減が配信改善によるものか、計測定義の変更によるものかを切り分け、次の施策を判断できる状態から整えていきましょう。たとえば「問い合わせが減った」という相談も、実際の受付記録が減ったのか、計測上の完了イベントだけ減ったのかで調査先が異なります。上の表と手元の記録を合わせると、依頼したい確認範囲を具体的に伝えられます。

計測だけでなく広告運用全体の相談をする場合は、目的・予算・社内の担当体制も整理すると、必要な支援を検討しやすくなります。

関連記事：広告運用代行に相談する前に準備すること｜目的・予算・計測を整理する

広告運用と計測の課題をまとめて相談するには

分析・制作・運用にまたがる課題は、確認結果を誰が次の改善へつなげるかが相談先選びの判断材料になります。トミラの共通サービス情報で、各業務の連携と報告内容を確認し、自社で必要な工程と照らし合わせてください。設定の調査を依頼したい場合も、対象イベント、比較した版、未確認事項をまとめて伝えると、相談範囲を確認しやすくなります。

トミラ　広告運用代行コンサルティング

GTM単独の調査・設定支援の受付可否、実際に依頼できる範囲、料金や開始時期は個別に確認してください。サービス情報にない作業を対応済み・費用込みと考えず、社内の担当と外部へ任せたい作業を分けて相談しましょう。支援内容はカード内の公式サイト、社内検討用の資料は資料ページの案内から確認できます。