GTMのCVトリガーはPage PathとPage URLのどちらにすべき?計測漏れ・誤発火を防ぐ設計
GTMのCVトリガーはPage PathとPage URLを条件別に使い分けることで計測漏れ・誤発火を防げます。
結論:ケース別の推奨設定#
| ケース | 第一推奨 |
|---|---|
| 固定された通常のサンクスページ | Page Path+「等しい」 |
| 同じパスが複数ドメインに存在 | Page Hostname+Page Path |
| クエリ値で成否を判定 | URLユーザー定義変数のQueryコンポーネント |
| URLが変化するSPA | History Change+Page PathまたはNew History Fragment |
| URLが変化しないフォーム | dataLayerカスタムイベント |
目次
Page PathとPage URLの違い#
Google タグマネージャー(GTM)でトリガーを作成するとき、条件変数として「Page Path」と「Page URL」のどちらを選ぶかで、一致対象の文字列の範囲が変わります。
| 変数 | 取得範囲 | 例 |
|---|---|---|
| Page URL | スキーム〜クエリ・フラグメントを含むURL全体 | https://example.com/thanks?order=123#top |
| Page Path | ドメインを除いたパス部分のみ | /thanks |
Page URL は document.location.href 相当で、プロトコル・ドメイン・パス・クエリ文字列・フラグメントをすべて含みます。一方 Page Path は document.location.pathname 相当で、パス部分だけを返します。
たとえばサンクスページのURLが https://example.com/thanks?order=123 であれば、Page Pathは /thanks、Page URLは https://example.com/thanks?order=123 となります。この違いが、トリガーの一致条件の設計を左右します。
基本はPage Pathを推奨する理由#
同一ドメインで運用する通常のCVページ(サンクスページ)のトリガーは、Page Pathを既定にすることを推奨します。理由は次のとおりです。
- クエリ文字列の揺れに強い:広告パラメーター(
utm_source等)やセッションIDがURLに付与されても、Page Pathはパスだけを見るため一致条件が崩れません。 - 条件が簡潔で可読性が高い:
/thanksのような短い文字列で済むため、レビュー・引き継ぎ時にも意図が伝わりやすくなります。 - プロトコル・サブドメインの影響を受けない:
httpとhttpsの混在やwwwの有無によってPage URLが変わっても、Page Pathは不変です。
設定方法は以下のとおりです。
- GTMでトリガーを新規作成し、種類を「ページビュー」(または「DOM Ready」「ウィンドウの読み込み」)にする。
- 「一部のページビュー」を選択し、条件変数を Page Path にする。
- 演算子を「次と等しい」にして
/thanksのようにパスを入力する。 /thanksと/thanks/の両方を許可する場合は、演算子を「正規表現に一致」とし、^/thanks/?$を指定します。
条件別の推奨トリガー(Page URL・カスタムイベントを使うケース)#
Page Pathが最適でない状況が4つあります。それぞれの判断基準と代替トリガーをまとめます。
複数ドメインにまたがるCV#
異なるドメイン(例:shop.example.com と checkout.partner.com)のサンクスページにそれぞれタグを設置するとき、Page Pathだけでは「どちらのドメインか」を区別できません。
- 対処(第一推奨):
Page Hostnameを対象ドメインと「等しい」、Page Pathを対象パスと「等しい」にし、この2条件を AND で指定します。Page URLにhttps://checkout.partner.com/completeを「含む」で指定する方法は、似たパスへの誤発火やURL変更の影響を受けるため代替案として扱います。
クエリ文字列で完了を判定するケース#
決済サービスによっては、同一パス(/result)にクエリで成否を返すことがあります(例:/result?status=success)。この場合、Page Pathの /result だけでは失敗ページも一致してしまいます。
- 対処(第一推奨):ユーザー定義の「URL」変数で Queryコンポーネント を選択し、クエリキー
statusの値を取得します。その変数がsuccessと等しい場合にタグを発火させます。補助的な方法としてPage URLを「含む」でstatus=successを指定する方法もありますが、not_status=successなどにも一致し得るため、Queryコンポーネントによる値取得を第一推奨とします。
シングルページアプリケーション(SPA)#
React・Vue・Angular等のSPAでは通常のページ読み込みを伴わず、History API(pushState)によってURLやパスが更新されることがあります。この場合、通常のページビュートリガーが再発火しないことがあります。
- 対処:「履歴の変更」トリガーを使用し、発生時点の
Page Pathが/thanksと等しい場合に発火させます。ハッシュルーティングの場合はNew History Fragmentを使用します。URLや履歴が変化しない完了処理では、dataLayer.push()によるカスタムイベントを使用します。なお「履歴の変更」はpushStateだけでなく、URLフラグメント(ハッシュ)の変更にも対応します。
URLが変わらないフォーム(同一ページ送信)#
モーダルやAjax送信でフォームを完了しても、URLが一切変化しないサイト構造では、ページビューベースのトリガーはそもそも機能しません。
- 対処:開発者に依頼して送信完了時に
dataLayer.push({ event: 'form_complete' })を追加し、GTMで カスタムイベントトリガー(イベント名:form_complete)を作成する。これにより、URLの変化に依存しない計測が実現できます。
計測漏れ・誤発火が起きる設定例#
実際の現場でよく見られる失敗パターンを挙げます。設定前にこれらのケースに該当しないか確認してください。
- クエリ付きPage URLを「含む」で設定し、テストパラメーターが本番でも残る:
utm_content=testを含むURLで発火テストを行ったまま公開し、本番のCVが一致しない。 - Page Pathに末尾スラッシュの揺れが存在する:サーバー設定によって
/thanksと/thanks/が混在し、どちらか一方しか一致しない。演算子「正規表現に一致」で^/thanks/?$を指定して対処する。 - サンクスページのパスが汎用的すぎる:
/completeなどを「含む」で指定したとき、別のページ(例:/complete-guide)でも誤発火する。「等しい」または正規表現の$アンカーを使う。 - SPAで通常のページビュートリガーだけを設定する:履歴変更が発生してもページビューイベントが再発火しないため、CVが計測されない。
- 複数ドメインでPage Pathのみ指定する:同じパスが自社サイトにも存在する場合、意図しないドメインでもタグが発火する。
- iframeで読み込まれた決済フォームをPage URLで判定しようとする:GTMのdataLayerは親ページのコンテキストで動くため、iframe内のURLは通常取得できない。
公開前チェックと実装後の検証#
トリガーを設定したら、公開前と公開後の2段階で検証します。
公開前の確認項目#
公開前にトリガーの設定を次の観点でレビューします。
- 条件変数の選択が今回のケースに適切か(Page Path / Page URL / カスタムイベントのどれか)。
- 演算子と入力値の組み合わせで意図しないページに一致しないか。
- 同じタグに複数トリガーが紐づいている場合、OR条件になっていないか(意図しない拡大発火の原因になる)。
- 除外トリガー(例外トリガー)が必要なページはないか。
GTMプレビューでの検証#
- GTM画面右上の「プレビュー」をクリックしてプレビューモードを起動する。
- 実際のサンクスページURL(クエリ付きも含む)をブラウザで開く。
- Tag Assistant の「Tags Fired」一覧に対象タグが表示されることを確認する。
- サンクスページ以外のページ(トップ・カテゴリーページ等)を開き、「Tags Not Fired」に留まることを確認する(誤発火チェック)。
- SPAの場合は、フォーム送信→完了画面への遷移を実際に操作して「履歴の変更」や「カスタムイベント」トリガーが期待どおり発火するか確認する。
媒体管理画面での確認#
GTMプレビューでタグが発火しても、広告媒体側でCVが記録されているかを別途確認します。
- Google 広告:「目標」→「コンバージョン」→「概要」から対象のコンバージョンアクションを確認し、必要に応じて Tag Assistant のトラブルシューティングを実行します。検証済みコンバージョンアクションのステータスは、テストから約30分後を目安に更新されます(実際のコンバージョンレポートへの反映時間とは分けて確認してください)。
- Meta 広告:ピクセルの「イベントマネージャー」でテストイベントモードを使い、
Purchase等のイベントが受信されているかを確認する。 - 反映時間は媒体ごとに異なる:ステータス更新とレポート反映のタイミングは媒体・アカウントにより異なります。「すべての媒体で数時間〜1日」と一律に断定せず、各媒体のテストイベント機能やヘルプで確認してください。
以上の設計・検証フローを踏まえることで、トリガーの選択ミスに起因する計測漏れと誤発火を体系的に防ぐことができます。
よくある質問#
Page PathとPage URLはどちらを優先して使うべきですか?#
同一ドメインで通常のサンクスページを計測する場合はPage Pathが推奨です。クエリ文字列での完了判定や複数ドメインが絡む場合はPage URLを使います。SPAやURL不変フォームはカスタムイベントトリガーが適しています。
Page Pathで「含む」を使うと誤発火するリスクがありますか?#
あります。たとえば /complete を「含む」で設定すると /complete-guide なども一致します。「等しい」演算子か、正規表現で末尾アンカー($)を使って厳密に一致させることを推奨します。
SPAでページビュートリガーが発火しない原因は何ですか?#
SPAでは通常のページ読み込みが発生しないため、通常のページビューイベントが発生しません。GTMの「履歴の変更」トリガー(ハッシュルーティングでは New History Fragment)を使うか、URLが変化しないフォームでは開発者に dataLayer.push() でカスタムイベントを実装してもらうことで解決できます。