問い合わせ完了をGA4で計測する方法と注意点

入力エラーを手前で除外し、正常に完了した問い合わせ1件だけを検査して受け皿へ通す精密計測装置

ホームページの成果を測るとき、問い合わせボタンのクリック数だけを「問い合わせ件数」として扱うと、実際より多く見えることがあります。入力エラー、途中離脱、通信失敗があっても、クリック自体は発生するためです。

BtoBサイトでは、フォームが正常に受け付けられた時点でgenerate_leadを1回だけ送信し、GA4のキーイベントとして管理する方法が基本です。本記事では、WordPressとGoogle Tag Manager(GTM)を想定し、設計から検証までを解説します。

結論:完了した事実を発火条件にする

問い合わせ計測の優先順位は次のとおりです。

入力エラーを手前で除外し、正常に完了した問い合わせ1件だけを検査して受け皿へ通す精密計測装置
  1. 正常送信後だけ表示される完了ページ
  2. フォーム側が返す送信成功イベント
  3. 成功メッセージの確実な表示
  4. GTMのフォーム送信トリガー

送信ボタンのクリックは、完了を保証できないため最終手段です。

計測前に決めること

成果とする問い合わせ

  • 一般問い合わせ
  • 見積もり依頼
  • 資料請求
  • 採用応募
  • セミナー申込み
  • 営業目的の連絡

事業上の重要度が違う場合は、すべてを同じ成果として合算せず、form_typeなどのパラメータで区別します。採用応募や購入には、用途に合う別の推奨イベントがないかも確認します。

イベント名

見込み顧客がフォームや情報請求を完了した行動には、Googleの推奨イベントgenerate_leadを使います。独自のcontact_completeだけで管理するより、標準レポートや将来の連携で扱いやすくなります。

方法1:完了ページで計測する

正常送信後に/contact/thanks/などへ移動するサイトでは、完了ページの表示を条件にします。

GTMの基本構成

  • タグ種類:Google アナリティクス:GA4イベント
  • イベント名:generate_lead
  • トリガー:ページビュー(一部のページ)
  • 条件:Page Pathが完了ページのパスと一致

利点

  • 設定が分かりやすい
  • 入力エラー時に発火しにくい
  • Tag Assistantで確認しやすい

注意点

  • 完了URLを直接開くと誤計測される
  • 再読み込みで重複発火する可能性がある
  • 複数フォームが同じ完了ページを使うと種類を判別できない
  • 外部フォームへ移動する場合は別設計が必要

完了ページを検索結果へ出さず、サイト内リンクからも通常アクセスできないようにします。重複防止が重要な場合は、送信完了時にだけ発行される状態値やサーバー側の識別子も検討します。

方法2:フォームの送信成功イベントで計測する

ページ遷移せず「送信しました」と表示するフォームでは、フォームプラグインやJavaScriptが返す成功イベントを利用します。

基本の流れ

  1. 正常送信後にサイト側からdataLayerへイベントを送る
  2. GTMでカスタムイベントトリガーを作る
  3. GA4イベントタグからgenerate_leadを送る

概念例です。実際のイベント名や取得値はフォーム仕様に合わせます。

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({
  event: 'contact_form_success',
  form_type: 'general_contact'
});

GTMではcontact_form_successを受けたときだけ、generate_leadを発火させます。

利点

  • 成功時点を正確に捉えやすい
  • 完了ページが不要
  • フォーム種類を渡しやすい
  • 再読み込みによる重複を抑えやすい

注意点

  • プラグイン更新でイベント仕様が変わる場合がある
  • 成功と失敗のコールバックを取り違えない
  • 同じ成功イベントを複数箇所から送らない

方法3:GTMのフォーム送信トリガーを使う

GTMにはフォーム送信トリガーがあります。「検証をチェック」を有効にすると、検証に通った送信だけへ絞れる場合があります。「タグの配信を待つ」では、ページ移動前にタグ送信の時間を確保できます。

ただし、Ajaxフォームや独自JavaScript、埋め込みフォームでは正しく検知しないことがあります。トリガーが反応してもサーバー受付の成功を保証するとは限らないため、実際のフォーム挙動を確認します。

計測パラメータを設計する

個人情報を送らず、分析に必要な分類だけを送ります。

パラメータ例 値の例 用途
form_type general_contact フォーム種類
form_location contact_page 設置場所
service_category web_production 相談サービス分類

メールアドレス、氏名、電話番号、自由記述本文など、個人を識別できる情報はGA4へ送信しません。

GTMでの設定手順

1. Googleタグを確認する

GA4データストリームに対応するGoogleタグが、全ページで1回だけ読み込まれているか確認します。WordPressテーマ、Google Site Kit、別のアクセス解析プラグイン、直書きコードから重複出力されていないかを調べます。

2. 成功条件を特定する

実際にテスト送信し、次のどれが発生するか確認します。

  • 完了URLへの遷移
  • dataLayerイベント
  • フォームプラグイン固有イベント
  • 成功メッセージ
  • 通常のフォーム送信

3. 専用トリガーを作る

全フォームではなく、対象URL、Form ID、カスタムイベント名などで問い合わせフォームへ限定します。

4. GA4イベントタグを作る

  • イベント名:generate_lead
  • 必要に応じて非個人情報のパラメータを追加
  • 作成した成功トリガーを指定

5. キーイベントに指定する

GA4の管理画面でgenerate_leadをキーイベントとして登録します。イベントを受信する前でも名称を正確に入力して事前登録できます。

Tag Assistantで発火を確認する

  1. GTMで「プレビュー」を開く
  2. 対象サイトへ接続する
  3. フォームを途中まで入力する
  4. 入力エラーを発生させる
  5. 正常送信する
  6. Tag Assistantのイベント順序を確認する

期待する結果は次のとおりです。

操作 generate_lead
フォームページ表示 発火しない
入力開始 発火しない
送信ボタンクリック まだ発火しない
入力エラー 発火しない
正常送信完了 1回発火
無関係な別フォーム送信 発火しない

同じイベント内で複数のGA4タグが発火していないか、Googleタグが二重に読み込まれていないかも確認します。

GA4 DebugViewで着信を確認する

Tag Assistantのプレビューモードを使うと、対象端末のデバッグモードを有効にできます。GA4の「管理」からDebugViewを開き、次を確認します。

  • generate_leadが1回だけ表示される
  • 発生時刻が送信完了と一致する
  • form_typeなどの値が正しい
  • 個人情報が含まれていない
  • 入力エラー時は表示されない

DebugViewは実装確認用です。流入元の正式な評価は、処理後の集客レポートなどで行います。

リアルタイムと通常レポートを確認する

リアルタイムレポートでは、直近30分に収集されたイベントを確認できます。通常レポートへの反映には時間がかかる場合があるため、実装直後はTag AssistantとDebugViewを優先します。

翌日以降に次を確認します。

  • イベント数
  • キーイベント数
  • ユーザー数
  • セッションのキーイベント率
  • ランディングページ
  • セッションの参照元/メディア

form_startとの違い

GA4の拡張計測機能では、フォーム操作をform_startform_submitとして収集できる場合があります。

  • form_start:フォームへの入力開始
  • form_submit:フォーム送信の検知
  • generate_lead:見込み顧客獲得という事業成果

開始数と完了数を比較すると離脱傾向を把握できます。ただし、自動計測のform_submitがサイト固有の正常送信と一致するか必ず検証します。

二重計測が起きる主な原因

  • Site KitとGTMの両方から同じGA4を出している
  • テーマへGoogleタグを直書きしている
  • 完了ページと成功イベントの両方で発火する
  • GA4イベントタグが複製されている
  • 同じGTMコンテナを二重設置している
  • 成功コールバックが複数回実行される
  • 完了ページの再読み込みで再発火する
  • テスト環境と本番環境の設定が混在している

「GA4で1件見えた」だけで終わらず、GTMコンテナ、Googleタグ、GA4イベントの各層を確認します。

公開前チェックリスト

  • 変更前のGTMバージョンまたは設定記録を残した
  • 問い合わせ完了の定義が明確
  • イベント名はgenerate_lead
  • 成功時のみ発火する
  • 1回の送信につき1回だけ発火する
  • 入力エラー・離脱では発火しない
  • 別フォームへ誤発火しない
  • 個人情報を送信していない
  • Tag Assistantで確認した
  • DebugViewまたはリアルタイムで着信を確認した
  • GTMのバージョン名と変更内容を記録した

よくある質問

送信ボタンのクリック計測ではだめですか

補助指標には使えますが、正常送信を保証できないため問い合わせ完了数には向きません。成功後の状態を計測します。

電話やメールリンクもgenerate_leadでよいですか

クリック時点では実際に相談が成立したか分かりません。click_to_callなどの補助イベントとして分け、フォーム完了と同列に扱う場合は定義を明記します。

完了ページ方式と成功イベント方式は併用できますか

同じ送信に対して両方からgenerate_leadを送ると二重計測になります。原則として信頼性の高い一つへ統一します。

テスト送信も件数へ入りますか

通常は入ります。公開前テストの日時を記録し、開発者トラフィックのフィルタや社内アクセスの扱いを設計します。フィルタ適用前には必ずテスト状態で影響を確認してください。

まとめ

問い合わせ計測では、ボタンクリックではなく「正常に受け付けられた事実」を条件にgenerate_leadを送ります。Tag AssistantとGA4 DebugViewを使い、入力エラーでは発火せず、正常送信時に1回だけ着信することを確認してから公開します。

株式会社サーハビーでは、札幌のBtoB企業向けに、WordPress・Google Site Kit・GTM・GA4を横断した重複確認、問い合わせイベント設計、検証、月次分析まで支援しています。現在の計測が正しいか分からない場合も、既存設定を残しながら調査できます。

参考資料

  • Google Analytics ヘルプ「推奨イベント」
  • Google Analytics ヘルプ「キーイベントを測定する方法」
  • Google Analytics ヘルプ「DebugViewでイベントをモニタリングする」
  • Google Tag Manager ヘルプ「フォーム送信トリガー」
  • Google Tag Manager ヘルプ「Tag ManagerでGoogle Analyticsを設定する」

お問い合わせ

CONTACT

WEB制作、マーケティング、運用のご相談など、お気軽にお問い合わせください。

お問い合わせ