真策堂
· アクセス解析

GTMのフォーム送信トリガーが発火しない原因と対処|Contact Form 7・Ajax送信・埋め込みフォームの切り分けと代替トリガー

GTMのフォーム送信トリガーが発火しない原因を、Ajax送信・iframe埋め込み・トリガー条件の3型で切り分け。プレビューモードでの1分判定、Contact Form 7のwpcf7mailsentを使う設定、要素の表示やpostMessageなど代替トリガーの選び方、誤発火と二重計上の確認まで当日中に進められる手順でまとめました。

この記事のポイント

  • GTMのフォーム送信トリガーが発火しない原因は、Ajax送信・iframe埋め込み・条件の不一致の3型にほぼ収まる。
  • プレビューモードで1回テスト送信し、gtm.formSubmitの有無・URLの変化・iframeの有無の3点を見れば型を判定できる。
  • Contact Form 7はwpcf7mailsentをカスタムイベントで受ける方法が、入力エラーを数えない最も確実な計測手段である。
  • 発火後は失敗送信・二重発火・拡張計測のform_submit混在を確認しないと、広告の自動入札が誤ったCVで学習する。

フォームを送信してもプレビューモードの左側に何も出ない。トリガーの条件は合っているはずなのに、Google広告のコンバージョンもGA4のイベントも増えない。ここで設定画面を何度も開き直して時間を溶かす担当者は、決して少なくありません。

先に言っておくと、GTMのフォーム送信トリガーが発火しない原因は、設定ミスよりも「仕組み上そもそも拾えないフォーム」であるケースの方が多いと言われます。この記事では、プレビューモードで1回テスト送信するだけで自社フォームの型を判定し、型に合った代替トリガーを選んで、当日中に計測を復旧するところまでを順に進めます。

フォームを送信しても計測が増えない担当者

GTMのフォーム送信トリガーが発火しないのはなぜ?

発火しない3つの型と代替トリガー 図1: 発火しない3つの型と代替トリガー

GTMのフォーム送信トリガーが発火しない主因は、ブラウザのsubmitイベントがGoogleタグマネージャー(GTM)まで届かないことで、その多くはAjax送信・iframe埋め込み・トリガー条件の不一致の3型のどれかに当たります。

フォーム送信トリガーはブラウザのsubmitイベントを聞いているだけ

GTMのフォーム送信トリガーとは、ページ上のフォームで発生したsubmitイベントを検知し、gtm.formSubmitというイベントをdataLayerに出す仕組みです。GTMがフォームの中身を理解しているわけではありません。ブラウザが出す合図を待っているだけです。

Simo Ahavaのブログでは、フォームが正規のsubmitイベントを発生させ、それがdocumentノードまで伝播して初めてトリガーが動くと説明されています。途中で伝播を止める実装やJavaScriptでの独自送信では、トリガー側の設定をどういじっても検知できません。つまり「設定を直す問題」か「別の手法に切り替える問題」かを早めに見極めることが、時間の節約になります。

発火しない3つの型(Ajax送信・iframe埋め込み・トリガー条件の不一致)

1つ目はAjax送信です。ページを遷移せず、JavaScriptがバックグラウンドで送信してサンクスメッセージだけを表示します。WordPressのContact Form 7が代表例です。2つ目はiframe埋め込みで、Googleフォーム、HubSpotフォームなどの外部サービスが該当します。親ページのGTMからはiframeの中が見えません。3つ目は、gtm.formSubmitは出ているのにトリガー条件やチェックボックスのせいでタグが動かない状態で、ここだけが設定で直せる層です。

型別の代替トリガー早見表

型見分けるサイン第一候補の代替トリガー
条件の不一致gtm.formSubmitは出るがタグが動かないトリガー設定の修正
Ajax送信(CF7)gtm.formSubmitが出ない・URLが変わらないwpcf7mailsentのカスタムイベント
Ajax送信(その他)同上送信成功時のdataLayer.push、次点で要素の表示
iframe埋め込みフォームがiframeの中にあるiframe側からのpostMessE、または完了後リダイレクト
通常送信でサンクスページへ遷移URLが変わるページビューのトリガー

自社のフォームはどの型?プレビューモードで1分で見分ける方法

1分で分かるフォーム型の判定ツリー 図2: 1分で分かるフォーム型の判定ツリー

自社フォームの型は、プレビューモードでテスト送信を1回行い、gtm.formSubmitの有無・送信後のURL変化・iframeの中かどうかの3点を見れば判定できます。プレビュー自体が開かない場合は、先にGTMプレビューが接続できない時のチェックリストを確認してください。

送信した瞬間にgtm.formSubmitが左側に出るか

Tag Assistantの画面左側にあるイベント一覧を開いたまま、フォームを実際に送信します。ここで「Form Submission」(gtm.formSubmit)が出れば、submitイベントは届いています。出ていればセクション3へ。出ない場合は次の2点を見ます。

送信後にURLが変わるか・サンクスメッセージが出るだけか

送信後にサンクスページへ遷移するなら、そのページでページビューのトリガーを使えば足ります。URLが変わらずフォームの下や上にメッセージが出るだけなら、Ajax送信の可能性が高いです。なお、最初に出たgtm.formSubmitのあとで遷移が起きる場合は、遷移前にタグが送れているかも見ておきます。

フォームがiframeの中にあるかを開発者ツールで確認する

ブラウザで右クリックして「検証」を開き、フォームの上にカーソルを当てて親要素をたどります。途中に<iframe>タグがあれば、iframe埋め込みです。見た目は自社ページの一部でも、中身は別ドメインのページということがよくあります。

判定結果ごとの読み進め先

  • gtm.formSubmitは出るがタグが動かない → セクション3
  • Contact Form 7を使っている → セクション4
  • CF7以外のAjaxフォーム → セクション5
  • iframeの中にある → セクション6

gtm.formSubmitは出ているのにタグが発火しない時はどこを直す?

gtm.formSubmitがプレビューに出ているのにタグが動かない場合は、トリガーの条件と2つのチェックボックス、組み込み変数の有効化を順に確認すれば、たいてい設定だけで直ります。

Form IDやForm Classesの組み込み変数が有効になっていない

「Form ID」「Form Classes」「Form URL」などの組み込み変数は、初期状態では無効です。条件に使うにはGTMの「変数」画面から有効化しておく必要があります。有効化せずに条件を書くと、値が空のまま比較され、一致しません。まずプレビューのgtm.formSubmitを選び、変数タブに実際の値が入っているかを見てください。

「フォーム要素の検証をチェック」で止まっている

トリガー設定にある「フォーム要素の検証をチェック」は、入力エラーで送信が止まった時に発火させないための機能です。ただ、バリデーションをJavaScriptで独自に処理しているフォームでは、この判定が合わずに常にブロックされることがあります。切り分けのためだけに一度オフにしてみて、発火するかを見ます。発火したら原因はここです。その場合も、必須項目を空にした失敗送信で発火しないかを必ずテストしてください。

「タグの配信を待つ」と待ち時間の設定

「タグの配信を待つ」は、フォーム送信後のページ遷移より先にタグを送り切るための待機設定です。これをオフにしていると、遷移が速いフォームでGA4や広告のリクエストが途中で切れます。待ち時間は2000ミリ秒が標準で、短すぎると取りこぼし、長すぎると遷移が遅く感じられます。

一部のフォームだけ指定した条件の書き方が合っていない

特定フォームだけに絞る場合、Form IDの完全一致で書くのが基本です。ただしWordPressでは、IDが空だったり、プラグインが自動採番していたりして、条件が空振りしやすいと言われます。Form IDが空ならForm Classesの「含む」で絞るか、Form Elementに対するCSSセレクタで指定します。

Contact Form 7でフォーム送信が計測できない時はどう設定する?

CF7のメール送信成功を確認する CF7のメール送信成功を確認する

Contact Form 7では、メール送信まで成功した時にだけ出るwpcf7mailsentイベントをカスタムHTMLタグでdataLayerへ渡し、GTMのカスタムイベントトリガーで受けるのが、最も確実で壊れにくい設定です。

CF7で標準のフォーム送信トリガーが当てにならない理由

Contact Form 7とは、WordPressで広く使われている問い合わせフォームのプラグインです。送信はAjaxで行われ、画面遷移がありません。gtm.formSubmitがそもそも出ないか、出ても入力エラー時を区別できないため、標準トリガーはCVの根拠になりません。

wpcf7submitではなくwpcf7mailsentを使う理由

Impressionの解説では、CF7は送信の各段階でDOMイベントを出すこと、wpcf7submitは入力エラーでも出るため計測に使わず、メール送信まで成功した時だけ出るwpcf7mailsentを聞くことが勧められています。日本では「確認画面なしで1ページ完結」のCF7が多く、ここを間違えるとエラーまでCVに数えてしまいます。

カスタムHTMLタグでdataLayerへ渡し、カスタムイベントトリガーで受ける

GTMに「カスタムHTML」タグを作り、トリガーは「All Pages」にします。中身は次の通りです。

<script>
document.addEventListener('wpcf7mailsent', function(event) {
  window.dataLayer = window.dataLayer || [];
  window.dataLayer.push({
    event: 'cf7_mailsent',
    contactFormId: event.detail.contactFormId
  });
}, false);
</script>

次に、イベント名を cf7_mailsent としたカスタムイベントトリガーを作り、GA4イベントタグやGoogle広告コンバージョンタグに紐付けます。プレビューで送信すると、左側に cf7_mailsent が出るはずです。値が取れない場合はデータレイヤー変数がundefinedになる原因が次の切り分け先です。

フォームが複数ある時はcontactFormIdで出し分ける

サイト内に資料請求と問い合わせの2つのフォームがあるなら、データレイヤー変数 contactFormId を作り、トリガーの条件に「contactFormId が 123 と等しい」のように加えます。IDはCF7の管理画面のショートコードで確認できます。

サンクスページへリダイレクトする方法との使い分け

CF7でサンクスページへ飛ばす方法もあります。ページビューのトリガーで済むので簡単ですが、直接アクセスやリロードでも数えるリスクがあります。実装の手間が許せば、wpcf7mailsentの方が精度は上がります。

Ajax送信のフォームはどの代替トリガーを選べばいい?

CF7以外のAjaxフォームでは、確実さの高い順に「送信成功時のdataLayer.push」「カスタムイベント」「要素の表示」「ページ遷移」を選び、開発者に頼めない場合の次善策として要素の表示トリガーを使います。

代替トリガー4種の比較表

トリガー確実さ開発者の要否壊れやすさ
送信成功時のdataLayer.push高い必要低い
wpcf7mailsentなどのカスタムイベント高い不要(ツールが出す場合)低い
要素の表示(サンクスメッセージ)中不要文言やクラス名の変更で壊れる
サンクスページのページビュー中〜高不要リロードで二重になる

サンクスメッセージを要素の表示トリガーで拾う時の設定と弱点

要素の表示トリガーとは、指定したCSSセレクタの要素が画面に現れた時に発火するトリガーです。サンクスメッセージのクラス名を指定し、発火回数は「ページあたり1回」か「要素ごとに1回」にします。具体手順はGTMで要素が表示されたときに発火するトリガーの設定方法で解説しています。弱点は、非表示のままDOMに置かれたメッセージを誤検知する場合があること、デザイン変更でクラス名が変わると静かに止まることです。

開発者に依頼できるなら送信成功時のdataLayer.pushが一番堅い

送信が成功した時点でフォーム側が dataLayer.push({event: 'form_success'}) を実行すれば、画面の見た目に左右されません。カスタムイベントトリガーで受けるだけなので、GTM側の設定も単純です。

送信ボタンのクリックで代用しない方が良い理由

クリックトリガーは手軽ですが、必須項目が空でも、通信が失敗しても発火します。Analytics Maniaでは、成功送信だけでなく必須項目を空のまま送る失敗送信でも発火しないかをテストすることが原則とされています。クリックで代用すると、このテストに必ず落ちます。

iframeの埋め込みフォームはGTMで計測できる?

iframeの埋め込みフォームは、親ページのGTMだけでは計測できません。iframe側にコードを置けるなら計測でき、置けないなら完了後リダイレクトやサービス側の連携機能に頼ることになります。

親ページのGTMからiframe内の送信もサンクス表示も見えない理由

ブラウザは、別ドメインのiframeの中身を親ページのスクリプトから読むことを許しません。クロスオリジンの制限です。送信イベントもサンクス表示も、親からは見えません。Googleフォームのような外部サービスが典型です。

iframe側にコードを置ける場合はpostMessageで親へ渡す

Bounteousのガイドでは、iframe側で完了を検知してpostMessageで親へ送り、親のGTMでリスナーがdataLayerに積み、親のGA4タグで計測する3部構成が定石とされています。iframe側にコードを置けなければ、この方法は成立しません。日本の中小サイトでは、外部サービスに任せているケースが多く、ここが分かれ目になります。

iframe内に計測タグを直接入れると流入元が切れやすい

Simo Ahavaは、クロスサイトのiframe内でGA4を直接動かすと、サードパーティCookie制限で別ユーザー扱いになりやすいと指摘しています。広告経由の流入元とCVの紐付けが切れるので、iframe内で計測せず、イベントだけ親へ渡して親側で計測するのが現実的です。

コードを置けない外部フォームの現実解(完了後リダイレクト・サービス側の連携機能)

選ぶ順番は次の通りです。

  1. フォームサービスに「送信後のリダイレクト先URL」の設定があれば、自社ドメインのサンクスページへ飛ばしてページビューで計測する。
  2. HubSpotフォームなど、サービス側にGoogle広告やGA4との連携機能があれば、それを使う。
  3. どちらもなければ、フォーム画面の表示数など別指標で代用する。このとき参考値と明記し、入札の最適化対象には入れない。

外部ドメインへ遷移する予約システム型は予約システム経由のCVが計測できない原因と対処が別領域です。

発火するようになった後に何を確認すればいい?

発火した後は、失敗送信で発火しないか、1回の送信で2回発火していないか、拡張計測のform_submitが混ざっていないかを確認します。ここを省くと、広告のスマート入札が誤ったCVで学習します。

必須項目を空にした失敗送信で発火しないか

プレビューモードで必須項目を空のまま送信し、イベントもタグも出ないことを確認します。出るなら誤発火です。

1回の送信で2回発火していないか

プレビューの左側で、同じイベントが2回並んでいないかを見ます。標準トリガーと代替トリガーの併存が典型です。詳細な切り分けはGA4イベントが重複計測される3つの原因にまとめています。

GA4拡張計測のform_submitが混ざっていないか

MeasureSchoolでは、GA4拡張計測のform_submitについて、成功と失敗を区別できない、Ajaxフォームを取りこぼす、といった報告が実務者から多いとされています。ただしこれは実務者の観測であり、Googleの公式見解ではありません。GTMで正しく設計したなら、拡張計測の「フォーム操作」はオフにするのが無難です。

GA4のDebugViewと広告管理画面の両方で1件ずつ確認する

1回送信して、GA4のDebugViewで1件、Google広告やMeta広告のテスト機能で1件、それぞれ確認します。DebugViewに出ない場合はGA4のDebugViewにイベントが表示されない時の確認手順へ。広告側で二重になっていれば広告CVのダブルカウントを発見・修正する手順が診断先です。

公開忘れとバージョンの確認

プレビューで動いても、「公開」を押していなければ本番では動きません。公開済みなのに反映されない場合はGTMで公開したのに本番に反映されない時の確認手順を確認してください。

それでも計測できない時は誰に何を頼めばいい?

自力で直らない場合は、制作会社やフォームサービスに「送信が成功した時にイベントを1つ出してほしい」と具体的に頼むのが最短です。

制作会社に伝える依頼文の要点

依頼文には次の3点を入れます。

  • フォームの送信が成功した時点で、dataLayer.push({event: 'form_success'}) を1回だけ実行してほしい
  • 入力エラー時には実行しないでほしい
  • iframeなら、親ページへpostMessageで完了を通知してほしい

今後の制作では、こうした計測要件を最初から仕様に入れておくと手戻りが減ります。広告成果を守るLP・サイト発注仕様書の作り方も参考になります。

フォームを作り替える前に検討したい順番

作り替えは最後の手段です。順番は、(1) カスタムイベントで取れるか、(2) サンクスページへのリダイレクトで足りるか、(3) 要素の表示で暫定計測するか、(4) それでもだめなら作り替え、です。計測が直った後は問い合わせフォームのCV率診断と改善実務でフォーム自体の改善に進めます。Google広告側にステータスが出ている場合はGoogle広告「タグは無効」「最近のコンバージョンはありません」の意味と対処も確認してください。

よくある質問

Q:GTMのフォーム送信トリガーが反応しないのはなぜですか?

ブラウザのsubmitイベントがGTMに届いていないのが主因です。Ajax送信、iframe埋め込み、トリガー条件の不一致の3型に分かれ、プレビューでテスト送信して型を判定すれば、原因を絞り込めます。

Q:Contact Form 7のフォーム送信をGTMで計測するにはどうすればいいですか?

wpcf7mailsentを聞くカスタムHTMLタグでdataLayerにイベントを渡し、GTMのカスタムイベントトリガーで受けます。contactFormIdも一緒に渡せば、複数フォームの出し分けもできます。

Q:URLが変わらないフォームのコンバージョンはどう計測しますか?

要素の表示トリガーか、送信成功時のカスタムイベントを使います。確実さは後者が上で、前者はサンクスメッセージの変更で壊れやすいという弱点があります。

Q:wpcf7mailsentとwpcf7submitの違いは何ですか?

wpcf7submitは入力エラーでも出ます。wpcf7mailsentはメール送信まで成功した時だけ出ます。計測に使うのは後者です。

Q:「フォーム要素の検証をチェック」はオンとオフどちらが良いですか?

基本はオンです。誤発火を防げます。発火しない時だけ切り分けのためにオフにし、その場合は失敗送信テストを必ず行ってください。

Q:GoogleフォームやHubSpotフォームなどiframeの埋め込みフォームはGTMで計測できますか?

親ページ側だけでは計測できません。iframe側にコードを置けるか、完了後リダイレクトや連携機能があるかで決まります。

Q:プレビューモードでは発火するのに本番でコンバージョンが計測されないのはなぜですか?

公開忘れ、同意モードの設定、ページ遷移でタグの送信が間に合わない、広告ブロックの順に確認します。

Q:フォーム送信のコンバージョンが2回カウントされるのはなぜですか?

標準トリガーと代替トリガーの併存、拡張計測のform_submit、要素の表示トリガーの発火回数設定が主な原因です。

Q:送信ボタンのクリックをコンバージョンにしても良いですか?

入力エラーでも数えるため非推奨です。他に手段がない時だけ参考値として使い、入札の最適化対象からは外してください。


フォーム計測の切り分けや、制作会社・フォームサービスへの依頼内容の整理でお困りの際は、真策堂までご相談ください。広告運用とトラッキング設計の両面から、状況に合った進め方を一緒に考えます。

Related Articles
Contact

広告運用・マーケティングのご相談はこちらから
お問い合わせフォーム・公式LINEのどちらでもOK