GA4で問い合わせの送信完了を測るには、フォーム方式に合う送信成功の信号からイベントを用意し、正常送信・入力エラー・再読み込みでサイト側の受付結果と照合したうえで、キーイベントとして利用します。
キーイベントは、ビジネスの成果にとって重要な行動を測るイベントです。Googleは、対象の行動を測るイベントを作成または特定し、キーイベントとしてマークする流れを説明しています。マークを付けるだけで、サイト側の送信成功を検知できるようになるわけではありません。（出典：Google アナリティクスのコンバージョンとキーイベント）
ここでは、問い合わせ完了を「サイト側で問い合わせの受付が成立したこと」として設計する方法を提案します。完了信号の選び方と受付結果との照合は、問い合わせボタンのクリック数やページ閲覧数を、送信できた件数と混同しないための編集部の提案です。
送信後に別ページへ移るか、同じ画面で完了するかを確かめる
まず、自サイトのフォームがどちらの方式かを確認します。
- サンクスページ型：送信成功後に、専用の完了ページへ移る方式です。そのページの閲覧を完了信号の候補にします。
- 同一画面完了型：ページを移らず、完了メッセージなどを表示する方式です。フォームの受付成功を示す通知を候補にします。
架空の例として、送信後に /contact/thanks へ移るフォームなら、実際の完了ページURLを調べます。同じ画面に完了メッセージを出すフォームなら、その表示につながる成功通知が何かを実装担当へ確認します。
問い合わせボタンや送信ボタンのクリックは、受付が成立したこととは分けて扱います。クリック後に入力エラーが出る場合など、操作をしたことと問い合わせが受け付けられたことは別だからです。
GA4のイベントは、ページ閲覧やフォーム送信などの行動を記録する情報です。拡張計測機能の form_submit は、Google公式ではフォーム送信時に記録されるイベントと説明されています。ただし、この説明だけでは、自サイトのサーバーで受付が成立したことや、問い合わせ管理システムなどで受信できたこととの一致までは確認できません。（出典：拡張計測機能イベント）
候補を選ぶときには、サイト側の受信ログや問い合わせ管理画面など、受付の成否を確かめられる記録も用意しておきます。
選んだ完了信号を、対象フォームのイベントにする
新しいイベントを追加する前に、すでに問い合わせ完了用のイベントがあるかを確認することを提案します。既存のイベントがあるなら、名前だけで判断せず、どの操作で発生する設定かを調べます。
また、計測を始める前に、GA4へ送る情報を確認してください。Googleは、個人を特定できる情報の送信を禁止しています。イベントに付ける補足情報であるパラメータやフォーム入力情報に加え、ページURLのパス・クエリパラメータ・ページタイトルにも、氏名やメールアドレスなどが含まれないようにします。受付結果を照合するための個人情報も、GA4へ送信しません。（出典：個人を特定できる情報を送信しないためのヒント）
サンクスページ型では、特定の完了ページの閲覧からイベントを作る公式例を参照できます。page_view はページ閲覧を記録するイベントで、Googleはこれを基に generate_lead を作成する方法を示しています。generate_lead は推奨イベントの一つで、公式資料では可能な限り推奨イベントを使うことが勧められています。
確認ページを使う公式チュートリアルの設定は、次の流れです。
- ［管理］→［データの表示］→［イベント］へ進み、［+ イベントを作成］を選びます。
- イベント名に
generate_leadを入力します。 - 作成方法で［コードなしで作成］を選びます。
- 元になるイベントに
page_viewを選び、URL欄に自サイトの完了ページURLを指定します。 - ［作成］を選びます。
/contact/thanks は説明用の仮のパスです。設定には、自サイトで実際に表示される完了ページのURLを使います。この方法が直接測るのは完了ページの閲覧なので、受付成功との対応は次の節で検証します。（出典：チュートリアル：キーイベントを設定する）
このチュートリアルは管理者または編集者の権限を求めています。一方、特定フォームのイベントを作る別の公式資料では、マーケティング担当者以上と記載され、画面表記も異なります。操作できない場合は、二つの手順を混ぜず、対象のGA4プロパティの表示と自分の権限を管理担当へ確認してください。（出典：Google アナリティクスでキーイベントを測定する方法）
同一画面完了型では、受付成功の通知をGA4のイベントにつなげられるか、実装担当へ確認します。次は、確認する目的を分けた質問例です。
- 「受付成功を示す通知は何ですか」
- 「その通知は、入力エラーやサーバー側の失敗でも発生しますか」
- 「同じ受付成功に対して、通知が繰り返されることはありますか」
受付成功のときだけ発生する通知を特定できれば、それをイベントにする方法を相談できます。今回参照した公式資料には、同一画面型の成功通知に接続する具体的な実装方法は示されていないため、通知の条件が分かるまでは送信完了の計測として採用する判断を保留します。
なお、Google公式には、form_submit を form_name で絞り込み、特定フォーム用のイベントを作る例もあります。form_name はフォームのHTMLの name 属性から取得される値です。これは対象フォームを識別する方法であり、絞り込むだけで受付成功を保証するものではありません。（出典：Google アナリティクスでキーイベントを測定する方法）
正常送信・入力エラー・再読み込みを試し、受付結果と照合する
イベントを設定したら、GA4に記録されることと、サイト側の受付結果に対応していることを分けて確かめます。
Google公式は、リアルタイムレポートの［イベント名別のイベント数］で対象イベントを確認する方法を説明しています。表示されない場合は、処理を待つか設定を見直します。表示がないまま、計測できているとは判断できません。（出典：Google アナリティクスでキーイベントを測定する方法）
そのうえで、正常送信・入力エラー・送信後の再読み込みを試し、受信ログなどの受付結果と照合することを提案します。これはGoogle公式の必須手順ではなく、編集部の受入テスト例です。
下表は「受付が成立した送信ごとに完了イベントを記録する」という仮の設計例です。回数は公式基準や実測結果ではなく、この設計で目指す期待値を示しています。
| 試す操作 | サイト側で確かめること | 完了イベントの仮の期待値 |
|---|---|---|
| 正常送信 | 受付が成立したか | 1回 |
| 入力エラー | 受付が成立していないか | 0回 |
| 送信後の再読み込み | 新しい受付がないか | 追加0回 |
各操作について、試した時刻、サイト側の受付結果、GA4で記録されたイベント数、修正が必要な点を手元に記録します。正常送信でイベントが出ないなら取りこぼし、入力エラーで出るなら誤計測、新しい受付がない再読み込みで増えるなら重複として調べます。
サンクスページへ直接アクセスできる場合は、新しい受付がない閲覧でもイベントが記録されるかを追加で確認してください。完了ページのURLを条件にしただけでは、直接アクセスや再読み込みによる記録を防げるとは限りません。
受付結果とイベントがずれる操作が見つかったら、その操作を実装担当へ伝え、イベントの発生条件を見直します。未確認の操作は確認済みとせず、次に試す作業として残します。
検証したイベントをキーイベントにし、成果として使う
受付結果との対応を検証したイベントを、問い合わせ完了のキーイベントとしてマークします。対象イベントの［キーイベントとしてマークを付ける］をオンにする操作が、公式資料で説明されています。（出典：Google アナリティクスでキーイベントを測定する方法）
完了ページを使うチュートリアルでは、イベント作成時にマークを付けることもできます。作成時に設定した場合も、受付結果との照合が済むまでは、その数値を問い合わせ件数として評価しない方針にします。
マークの設定が適用されたら、正常送信を行い、リアルタイムレポートの［イベント名ごとのキーイベント数］で対象イベントを確認します。ここで確かめるのは、GA4がキーイベントとして扱っていることです。前の節で行った、受付成功との対応や誤計測・重複の検証とは役割が異なります。（出典：チュートリアル：キーイベントを設定する）
また、GA4のキーイベントと、広告の評価や入札に使うコンバージョンは区別してください。キーイベントとしてマークしただけでは、Google広告のコンバージョンまで作成したことにはなりません。（出典：Google アナリティクスのコンバージョンとキーイベント）
外部支援を検討していて、成功通知や重複の原因を自社で確認できない場合は、フォーム方式、現在のイベントの発生条件、テストで受付結果とずれた操作を整理して相談すると、調べる対象を具体的に伝えられます。
