こんにちは。バナナデスクです。
問い合わせボタンは押されているのに、届いた問い合わせは少ない。こういうとき、GA4の数字だけを見てフォームが壊れたと判断するのは早いかもしれません。ボタンを押した後で入力エラーになった人も、入力をやめた人もいるからです。
キーイベントを設定するときは、最初に「何が起きたら1件か」を決めます。この記事では、フォームの入力内容をサーバーが正常に受け付けた時点を問い合わせ完了とします。ボタンのクリック数とは別に持ち、完了ページの再表示でも増えない設計を考えます。
キーイベントにするのは、受付が確認できた行動
GA4のキーイベントは、事業にとって重要なイベントへ目印を付けたものです。目印を付けるだけで、クリックが正常な受付に変わるわけではありません。Googleのキーイベント設定の説明も、先に対象のイベントを用意する構成になっています。
| 見る行動 | この例のイベント | 分かること／まだ分からないこと |
|---|---|---|
| 問い合わせ導線を押した | contact_button_click（自作名） | 関心を持って進もうとした。受付は未確定 |
| 入力を送信しようとした | フォーム側で必要に応じて記録 | 送信操作があった。入力エラーや通信失敗があり得る |
| サーバーが新しい受付を確定した | generate_lead | この例でキーイベントにする行動。売上や成約ではない |
generate_leadは、フォームなどによる見込み客の獲得を記録するためにGoogleが示している推奨イベントです。問い合わせの売上価値が決まっていないのに、見栄えを整えるための金額を付ける必要はありません。valueを設定するなら、その意味と通貨を決めてから使います。
4回押して2件受け付ける例を追う
次は教材用に作った、6つの状態を順番に処理する例です。Pythonで成功条件と同じ受付IDの重複判定を実行しました。実フォームやGA4へ送信したログではありません。画面・通信・GA4の確認に進む前に、期待する動きをはっきりさせるための例です。
| 試す状態 | クリックの追加 | 完了の追加 | 理由 |
|---|---|---|---|
| 必須項目が空で入力エラー | 1 | 0 | 受付が成立していない |
| 正常に受け付けたDEMO-A | 1 | 1 | 新しい受付が成立した |
| 同じDEMO-Aの成功通知をもう一度処理 | 0 | 0 | 同じ通知を完了として重ねない |
| DEMO-Aの完了表示を再読み込み | 0 | 0 | 新しい受付ではない |
| 別の問い合わせDEMO-Bが正常に成立 | 1 | 1 | 別の受付なので追加する |
| 送信したがサーバー側で受付失敗 | 1 | 0 | 成功画面を先に出さない |
この例ではクリック4回、完了イベント2回、架空の受付ID2件になりました。受付IDは判定と照合のための教材用の値で、計測へ送るデータからは外しています。計測側へ渡す見本はイベント名と、個人情報を含まない固定のフォーム種別だけです。
この状態判定プログラムは、一度の実行中に見た受付を記憶しています。ブラウザーを閉じた後や別端末まで含めた重複防止を証明するものではありません。本番では、フォームのサーバー側で同じ送信を二重受理しない仕組みと、計測側で同じ完了通知を重ねない仕組みをそれぞれ確認します。
フォームが成功した根拠につなげてイベントを送る
実装担当者へ渡す条件は、「送信ボタンが押されたら」ではなく、「サーバーの受付成功が確認でき、新しい受付として扱うとき」です。Ajaxフォームなら成功応答を受けた処理、別ページへ移動するフォームなら受付完了と対応する処理を使います。採用するフォームの公式イベントや成功通知の仕様に合わせてください。
Googleタグでイベントを送る基本形は次のようになります。これは、適切に読み込まれたタグと同意の取り扱いがあるサイトで、受付条件が成立した箇所から呼ぶ部分の例です。これだけをすべてのページへ貼るコードではありません。GTMを使う場合も、同じ成功条件をトリガーへ渡します。Googleのイベント実装ガイドが実装方法の基準になります。
gtag('event', 'generate_lead', {
form_id: 'lesson_inquiry'
});成功処理への直書きとGTMのタグを両方動かせば、同じ受付が2回送られる可能性があります。プラグインがすでに同じイベントを送っていないかも確認します。「GA4の数字が2だからフォームも2件受け付けた」とは決めず、受付記録と送信回数を別々に調べましょう。
氏名、メールアドレス、電話番号、問い合わせ本文をイベントのパラメータへ入れません。完了ページのURLやタイトルにメールアドレスが入っていれば、それも確認対象です。GoogleのPIIを送信しないためのガイドは、イベントだけでなくURLや入力内容も扱っています。
GA4で対象イベントへキーイベントの印を付ける
ここからは2026年10月1日に確認した公式資料に沿った手順です。対象のプロパティを選び、管理画面の「データの表示」から「イベント」を開きます。すでに受信していれば「最近のイベント」でgenerate_leadを探し、スターを付けます。受信前のイベントを作成して、あらかじめキーイベントにする方法もあります。
権限が不足する場合は編集担当者へ依頼します。公式説明ではマーケティング担当者以上の権限が案内され、既存イベントの操作説明には編集者以上と記載される箇所もあるため、利用中の画面で実行できる権限を確認してください。設定できない問題をイベントの送信失敗と混同しないようにします。
完了ページのpage_viewを条件に新しいイベントを作る方法もあります。ただし、そのページが直接開けたり再読み込みできたりすれば、新しい受付がない閲覧も数え得ます。URL条件だけの方法を選ぶなら、この制約を含めて試します。既存イベントからの作成手順を、受付の確定条件とセットで確認してください。
セッションごとに1回へ変えても、重複実装は直らない
GA4には「イベントごとに1回」と「セッションごとに1回」のカウント方法があります。前者は対象イベントが起きるたびに、後者は同じセッション内で1回だけ数える方法です。変更は過去へさかのぼりません。Googleのカウント方法の説明を参照してください。
先ほどのDEMO-AとDEMO-Bが同じセッションなら、正当な別受付2件でも「セッションごとに1回」では1になります。反対に、二重送信されたイベントをセッションでまとめて見えなくしても、原因は残ったままです。受付件数を知りたいのか、問い合わせをしたセッション数を知りたいのかで使い分けます。
実際のフォームでは、失敗時と再表示まで確かめる
本番へ反映する前に、検証用のフォームとプロパティで、表の6条件を試します。記録するのは実行時刻、ブラウザー、同意状態、フォームの受付結果、タグが送ったイベント、GA4で受信したイベントです。受付記録には業務側のテストIDを使っても、GA4へその値を追加することとは分けます。
GA4へ届かないときは、①受付が本当に成立したか、②成功処理からイベントを送ったか、③対象の測定先が合っているか、④同意やブロックの条件はどうか、⑤受信後にキーイベントの印が付いているか、の順で見ます。通常レポートには反映の待ち時間もあるため、表示されないという一点でコードを重ねないでください。
受付台帳とGA4の総数が違う場合も、期間・タイムゾーン・テスト除外・同意条件をそろえてから比較します。計測に参加していない受付までGA4に現れるとは限りません。私は、業務上の受付数を基準として残し、GA4はそこへ至る経路を理解するために使う整理を勧めます。