WordPressへGA4を設定したものの、お問い合わせが何件完了したか、どのページや流入元が問い合わせにつながったかを確認できずに困っていませんか。
GA4では、重要な行動を計測するイベントを「キーイベント」として扱います。以前の解説で「コンバージョン」と呼ばれていた設定に近い役割ですが、現在のGA4画面と本文ではキーイベントという名称を基本にします。
問い合わせ計測で最初に決めるのは、どの画面を操作したかではなく、何をもって「正常に問い合わせが完了した」とするかです。送信ボタンのクリックだけを成果にすると、入力エラーやメール送信失敗まで数える恐れがあります。
page_viewや全フォーム共通のform_submitを、そのままキーイベントにしないでください。すべてのページ閲覧や検索フォーム、ログインフォームまで成果に含むと、問い合わせ数を実態より多く見せる原因になります。
先に結論|問い合わせ計測は8段階で設定する
- 問い合わせフォームが正常に送信・受信できることを確認する
- GA4の対象プロパティ、測定ID、権限を確認する
- 問い合わせ完了の条件を言葉で決める
- 完了ページ、フォーム成功イベント、拡張計測から方式を選ぶ
- 問い合わせ専用の
generate_leadイベントを作る generate_leadをキーイベントとして設定する- DebugView、リアルタイム、実際の通知メールを照合する
- イベント名、条件、実装場所、確認日を記録する
GA4のプロパティやデータストリーム、測定ID、WordPressへのタグ設置が未確認なら、先にWordPressへGA4を設定する手順を完了してください。タグが二重になっている状態でキーイベントを追加すると、原因の切り分けが難しくなります。
イベントとキーイベントの違い
| 用語 | 役割 | 問い合わせでの例 |
|---|---|---|
| イベント | サイト内で起きた行動の記録 | ページ閲覧、フォーム開始、送信 |
| 推奨イベント | Googleが用途別に名称を定めたイベント | generate_lead |
| キーイベント | 事業上重要として印を付けたイベント | 正常に完了した問い合わせ |
| Google広告のコンバージョン | 広告最適化・評価に使う別管理の成果 | GA4キーイベントから作る場合がある |
Google公式のキーイベントの説明では、重要な行動を測るイベントを作成または特定し、そのイベントをキーイベントとして設定します。キーイベント化はイベントを受信する条件そのものを作る作業ではありません。
問い合わせや資料請求には、Googleの推奨イベント一覧にあるgenerate_leadを使うと、用途が分かりやすくなります。独自名を増やす前に、推奨イベントで表現できるか確認します。
問い合わせ完了の条件を先に決める
「送信ボタンが押された」「フォーム送信処理が始まった」「画面に成功表示が出た」「管理者通知メールの送信処理が完了した」は同じではありません。サイトのフォームがどの時点を取得できるかを確認します。
| 候補 | 成果としての精度 | 主な問題 |
|---|---|---|
| 送信ボタンクリック | 低い | 入力エラーや連打も含み得る |
| フォーム送信イベント | 実装次第 | 全フォーム混在、成功前発火の確認が必要 |
| 成功メッセージ表示 | 比較的高い | フォーム固有の成功イベント取得が必要 |
| 専用完了ページ表示 | 分かりやすい | 直アクセス・再読み込み・共有を考慮 |
| 管理者通知メール受信 | 運用確認に有用 | ブラウザー側GA4とは直接連動しない |
フォーム自体がまだ安定していない場合は、計測コードより先に送信・受信を直します。作成から公開前テストまではWordPressのお問い合わせフォームの作り方で確認してください。
問い合わせ完了を測る3つの方法

| 方式 | 向いているフォーム | 長所 | 注意 |
|---|---|---|---|
| 専用完了ページ | 成功後に固有URLへ移動する | GA4画面で条件を作りやすい | 直アクセス・再読み込みも数え得る |
| フォーム固有の成功イベント | 同じページに成功表示するAJAXフォーム | 成功時点へ合わせやすい | プラグイン・GTM・コードの知識が必要 |
拡張計測のform_submit | GA4が送信を安定検出できるフォーム | 追加コードなしで候補を確認できる | 全フォーム混在、AJAX非検出、成功条件の確認が必要 |
最適な方式はフォームの挙動で決まります。すでに専用完了ページへ移動するなら完了ページ方式、Contact Form 7のように同じページで結果を表示するならプラグイン固有の成功イベントが候補です。拡張計測は、実際に取れるイベントとパラメータを検証してから使います。
完了ページ方式でgenerate_leadを作る

問い合わせ成功後だけ専用URLへ移動するフォームでは、page_viewと完了ページURLを条件に、新しいgenerate_leadイベントを作れます。Google公式のキーイベント設定チュートリアルも、確認ページの閲覧を別イベントとして測る流れを案内しています。
- フォームを正常送信し、成功後の正確なURLを確認する
- GA4で対象プロパティを選ぶ
- 「管理」から「データの表示」のイベント画面を開く
- 新しいイベントの作成を選ぶ
- イベント名を
generate_leadにする - 元のイベントを
page_viewにする - ページURL条件へ専用完了ページを指定する
- 条件を保存する
- キーイベントとして扱う設定を有効にする
GA4画面は更新されるため、ボタン名や配置が少し違う場合があります。ログインしているプロパティと権限を確認し、現行公式画面を優先してください。
完了ページURLは専用にする
トップページや通常の記事を完了条件に使うと、問い合わせと無関係な閲覧が混ざります。完了ページはフォーム成功後だけ案内する固有URLにし、URLの表記揺れ、末尾スラッシュ、クエリ文字列を含むかを実際のブラウザーで確認します。
完了ページのURLへ氏名、メールアドレス、問い合わせ内容を付けないでください。URLはブラウザー履歴、アクセスログ、GA4のpage_location等へ残る可能性があります。完了ページ本文にも送信内容を不用意に再表示しません。
フォーム固有の成功イベントを使う
同じページ内で送信結果を表示するフォームは、完了ページのpage_viewでは測れません。フォームプラグインが提供する「送信成功後」のイベントを取得し、generate_leadとしてGA4へ送る方法を検討します。
Contact Form 7公式のGA4送信計測の説明では、メール送信が正常完了したときに発生するwpcf7mailsentというDOMイベントを使い、GA4へイベントを送る例が案内されています。送信ボタンのクリックより、成功条件へ近い実装です。
ただし、公式例のコードをそのまま本番テーマへ貼るのではなく、次を確認します。
- GA4タグの設置方法がSite Kit、GTM、テーマのどれか
- イベントを送る実装場所を誰が管理するか
- 複数フォームがある場合に問い合わせフォームだけを識別できるか
- テーマ更新で消えない実装か
- テスト環境またはプレビューで事前確認できるか
- 同じ
generate_leadを別経路から二重送信していないか - 同意設定で送信可否がどう変わるか
GTMを使う場合も、クリックトリガーだけで済ませず、フォーム成功イベントをdataLayer等へ渡し、GA4イベントタグを一度だけ発火させる設計にします。実装担当がいない場合は、コードを推測で追加せず、現状のフォームとGA4設置方法を記録して専門家へ渡せる状態にします。
拡張計測のform_submitは検証してから使う
GA4の拡張計測では、フォーム操作を有効にするとform_startとform_submitを収集できる場合があります。Google公式の拡張計測イベントの説明では、form_id、form_name、form_destination、form_submit_text等のパラメータが案内されています。
ただし、サイト内には問い合わせ以外にも検索、ログイン、コメント、会員登録、資料請求など複数のフォームがあります。form_submit全体をキーイベントにすると、問い合わせ以外まで成果に含む可能性があります。
- データストリームの拡張計測でフォーム操作の状態を確認する
- Tag AssistantまたはDebugViewを開く
- 問い合わせフォームを一度だけ正常送信する
form_submitが発生するか確認するform_id、form_name、送信先等で対象フォームを識別できるか確認する- 入力エラー時や検索フォーム送信時にも発生しないか比較する
- 識別条件から問い合わせ専用イベントを作れる場合だけ採用する
Ajax等で送信するフォームでは、拡張計測が意図どおり検出しない場合があります。取れるはずだと決めつけず、実際のイベントを見て判断してください。フォーム固有の成功イベントが安定しているなら、そちらを使う方が成功条件を説明しやすい場合があります。
イベントをキーイベントとして設定する
generate_leadが正しい条件で送られる準備ができたら、GA4でキーイベントに設定します。Google公式のイベントをキーイベントにする手順では、受信済みイベントへの印付けと、新しいイベントを事前にキーイベントとして作る方法が案内されています。
- 対象のGA4プロパティを選ぶ
- 管理画面のイベントを開く
generate_leadを検索する- キーイベントとして扱う設定を有効にする
- 初期値と計数方法を確認する
- 設定者、日付、イベント条件を記録する
設定ボタンが表示されない場合は、GA4の権限を確認します。閲覧だけの権限では作成・変更できないことがあります。権限を広げるときは個人アカウントへ共有せず、担当と回収方法も記録します。
計数方法を確認する
キーイベントには「イベントごと」と「セッションごと」の計数方法があります。Google公式の計数方法の説明では、イベントごとは発生するたび、セッションごとは一つのセッションで一度だけ数えます。
一人が別件を2回問い合わせる業務ならイベントごとが実件数に近い一方、完了ページの再読み込みや二重送信が多いサイトでは重複が目立ちます。計数方法だけで不具合を隠さず、まずイベントが一送信につき一度だけ発生する状態を作ります。
DebugViewとリアルタイムで検証する

| 確認場所 | 確認すること | 分かること |
|---|---|---|
| フォーム画面 | 成功表示とエラー表示 | 読者側の処理結果 |
| 管理者受信箱 | 通知メールが一通届くか | 実運用上の問い合わせ成立 |
| DebugView | generate_leadと発生時刻 | 端末単位のイベント送信 |
| リアルタイム | イベントとキーイベント | 対象プロパティでの受信 |
| Tag Assistant | タグ・トリガー・重複 | 実装経路と発火回数 |
| 通常レポート | 翌日以降の件数・流入元 | 集計と改善への利用 |
Google公式のDebugViewの確認方法に沿い、Tag Assistant等で自分の端末をデバッグ対象にします。テスト送信は実在する管理用アドレスで行い、個人情報をGA4パラメータへ送らないようにします。
- 未ログインまたはテスト用ブラウザーでフォームを開く
- 入力エラーを一度発生させ、
generate_leadが出ないことを確認する - 正常な内容で一度送信する
- 成功表示と管理者通知を確認する
- DebugViewで
generate_leadが一度だけ出ることを確認する - リアルタイムのキーイベント欄を確認する
- 完了ページ方式なら再読み込み時の挙動を確認する
- 検索フォーム等を送信し、誤って
generate_leadにならないことを確認する
Google公式のキーイベントのレポート確認では、リアルタイムとDebugViewを短時間の検証に使い、通常レポートで継続的に分析する流れが説明されています。標準レポートへの反映には時間がかかるため、設定直後に空でも重複設定を追加しません。
よくある誤計測と直し方
| 症状 | 最初の確認 | 対応 |
|---|---|---|
| 問い合わせ0件 | フォーム通知とGA4測定ID | フォーム障害と計測障害を分ける |
| 実件数より多い | タグ二重、再読み込み、複数経路 | 一経路ずつ停止して検証 |
| 入力エラーも数える | クリック・送信開始で発火していないか | 成功イベントへ変更 |
| 検索フォームも数える | 汎用form_submitをキー化していないか | 問い合わせ固有条件を作る |
| DebugViewだけ見えない | デバッグモード、同意、除外 | 対象端末と設定を確認 |
| 別プロパティへ入る | 測定IDとGTMコンテナ | 送信先を一本化 |
タグやプラグインを追加する前に、イベント名、発生時刻、フォーム通知時刻、完了ページURL、測定IDを記録します。原因を一つずつ切り分け、同じgenerate_leadをGA4画面、GTM、テーマコードから重ねて送らないようにします。
計測後は流入とページを改善する
キーイベントが安定したら、件数だけで良し悪しを判断せず、ランディングページ、流入元、端末、問い合わせ前に見たページを確認します。ページ別の閲覧と回遊はGA4で記事を改善する見方で整理しています。
検索結果の表示回数、クリック率、順位はSearch Consoleで記事を改善する見方と組み合わせます。検索流入が多いのに問い合わせへ進まない場合は、記事内容と問い合わせ導線の一致、リンク文、フォーム前の説明を確認してください。
問い合わせへつなぐ内部リンクを増やすときは、すべての記事へ同じ誘導を置かず、読者が相談を必要とする箇所に絞ります。読者導線の基本はWordPress内部リンクの貼り方を使ってください。
フォーム、GA4、GTM、同意設定を変更した後は、同じテストを再実行します。確認日と担当をWordPress保守チェックリストへ残すと、突然件数が0になったときに変更点を追いやすくなります。
よくある質問
送信ボタンのクリックをキーイベントにしてもよいですか?
問い合わせ完了を測りたい場合は勧めません。クリック後に入力エラーや送信失敗が起きても数える可能性があります。完了ページまたはフォーム固有の成功イベントを優先します。
完了ページは必須ですか?
必須ではありません。Contact Form 7等が提供する成功イベントを取得できれば、同じページで送信完了するフォームも測れます。計測のためだけに不要なリダイレクトを追加する前に、フォーム公式の計測方法を確認してください。
過去の問い合わせもキーイベントになりますか?
キーイベントとして設定する前の過去データへ遡って印が付くわけではありません。設定後のデータを対象にし、開始日を運用記録へ残します。
まとめ
GA4で問い合わせ完了を測るときは、先に成功条件を決めます。専用完了ページがあるならpage_viewとURL条件、同じページで完了するならフォーム固有の成功イベント、拡張計測を使うなら問い合わせフォームを識別できるかを確認します。
問い合わせ専用のgenerate_leadを作ってキーイベントに設定し、入力エラーでは出ず、正常送信時に一度だけ出ることをDebugView、リアルタイム、管理者通知で照合してください。数を表示することではなく、実際の問い合わせと説明できる数字を作ることが計測の目的です。