工務店・ハウスメーカーサイトのGA4イベント設計クリックと送信完了を分ける

Google アナリティクス（GA4）の問い合わせ件数が、実際に届いた問い合わせより多い。そのときにまず疑うのは、ボタンを押した回数を問い合わせとして数えていることです。フォームを開いたが途中でやめた人、入力の誤りで送れなかった人、二度押した人まで件数に入ります。

この記事では、問い合わせや予約をGA4で数えるとき、どの時点をイベントにすれば、受付の件数と照合できる数字になるかを説明します。答えを先に書くと、「ボタンを押した」と「送信が受け付けられた」を別のイベントにし、成果として数えるのは後者だけにします。

GA4の仕様は、Googleの公式ヘルプを2026年10月2日に確認した内容です。画面の名称や機能は変わることがあるため、設定のときは公式ヘルプの現行の説明に従ってください。イベント名の一部と設計表は架空の例です。

ハウスメーカーで拠点別のフォームを計測する場合

展示場や拠点ごとにフォームや予約の仕組みが違う会社では、02章の「成果は一つ」を守りつつ、どの拠点の受付かを区別する値を決めます。拠点名は送っても、03章のとおり氏名や連絡先は送りません。

04章の照合は各拠点の受付台帳と同じ期間で行い、テスト送信を除く決まりを全拠点でそろえます。

「押した」と「受け付けられた」は別の出来事

フォームに関わる行動は、少なくとも四つに分かれます。相談ページへ進むボタンを押す、入力を始める、送信ボタンを押す、送信が受け付けられる、の四つです。前の三つには、途中でやめた人や、必須項目の入力漏れで送れなかった人が含まれます。会社に問い合わせが届いたと言えるのは四つ目だけです。

GA4には、管理画面で有効にするとコードを変えずにイベントを収集できる「拡張計測機能」があり、フォームの操作として form_start と form_submit が用意されています。公式ヘルプの説明は、form_start が「ユーザーがセッションで初めてフォームを操作したとき」、form_submit が「ユーザーがフォームを送信したとき」です（拡張計測機能イベント）。

この説明からは、送信が受け付けられたかどうかまでは読み取れません。自社のフォームで form_submit がどの時点で記録されるか、入力エラーで送れなかったときにも記録されるかは、実際に操作して確かめるまで分かりません。確かめないまま成果の数字に使うことは勧めません。

目的に必要な行動だけを選び、成果は一つに決める

イベントは多いほどよいわけではありません。施工事例を見た、予約フォームに入力を始めた、送信が受け付けられた、というように、後で判断に使う行動を選びます。

GA4のイベントには、自動収集イベント、拡張計測機能イベント、推奨イベント、カスタムイベントの四種類があります。推奨イベントは名前とパラメータがあらかじめ定義されたもので、カスタムイベントは、他のイベントが適切でない場合にだけ作るよう案内されています（イベントについて）。問い合わせや予約の受付には、推奨イベントの generate_lead が使えます。公式の説明は「ユーザーが問い合わせのためにフォームまたはリクエストを送信したとき」です（GA4の推奨イベント）。

次は、見学会の予約フォームを例にした架空の設計表です。

表1

横にスワイプして、右側の列を確認できます

行動	イベント名の例	記録する条件	成果に数えるか
施工事例ページを見た	page_view	事例ページの表示	数えない
予約フォームに入力を始めた	form_start	フォームを最初に操作	数えない
送信ボタンを押した	reserve_submit_click（カスタム）	ボタンの押下	数えない（補助の数字）
予約が受け付けられた	generate_lead	サーバーが受付成功を返したとき	数える

GA4では、ビジネスにとって重要な行動のイベントに「キーイベント」の印を付けて測定できます（イベントにキーイベントとしてマークを付ける）。印を付けるのは、受付成功のイベントだけにします。送信ボタンのクリックは、押したのに受け付けられなかった人がどれだけいるかを見るための補助の数字として別に持ち、問い合わせ件数には足しません。成果の数字と途中の数字の分け方は工務店の集客KPIで扱っています。

「受け付けられた」をどう検知するかは、フォームの作りで変わります。

送信後に完了ページへ移るフォームは、完了ページの表示を条件にできます。ただし、再読み込みでもう一度数えられるおそれがあるので、重複を防ぐ対策が要ります。
同じページのまま完了の文言を出すフォームは、サーバーから受付成功の応答を受け取った時点で記録します。
外部のフォームサービスを埋め込んでいる場合は、完了を自社サイトの側で検知できないことがあります。サービスが用意している計測の方法を調べ、それでもできなければ、GA4では送信完了を数えられないと分かったうえで、受付台帳の件数を使います。

実装を制作会社や担当者に頼むときは、イベント名、記録する条件、重複を防ぐ方法、確かめ方の四つを書いて渡します。「問い合わせを計測してください」という依頼だけでは、クリックで計測されていても気付けません。

氏名やメールアドレスをGA4へ送らない

Googleは、個人情報として使用または認識できるデータをアナリティクスへ送ることをポリシーで禁じています。例としてメールアドレスや個人の携帯電話番号が挙げられています。URLのパスとパラメータに個人情報が含まれないようにすること、ユーザーが入力した情報からは送信前に個人情報を取り除くことも求められています。カスタムディメンションやイベントに関するディメンションなどを使うときは、氏名やメールアドレスが送られないよう特別な注意が必要だとしています（個人を特定できる情報（PII）を送信しないようにするためのヒント）。GA4では、イベントのパラメータがこれに当たると編集部は読んでいます。

工務店のフォームで気を付けるのは、氏名、メールアドレス、電話番号、住所や建築予定地、相談の本文です。フォームの値をそのままイベントのパラメータに渡す実装は避け、渡すのは「どのフォームか」「どの見学会か」といった、個人を示さない区分だけにします。

見落としやすいのはURLです。完了ページのURLに氏名やメールアドレスが付くフォームでは、ページの表示を記録するだけで個人情報がGA4に入ります。テスト送信をして、完了ページのアドレス欄を自分の目で見ます。広告や投稿のリンクに付けるパラメータの決め方は工務店のUTMパラメータ設計で扱っています。

重複とテスト送信を除き、受付の記録と突き合わせる

実装したら、三つのことを試します。

一つ目は重複です。完了画面で再読み込みをする、ブラウザの「戻る」で戻ってからもう一度進む、という操作をして、受付成功のイベントが二回記録されないかを見ます。GA4のDebugViewを使うと、デバッグモードにした端末から届くイベントをリアルタイムで確かめられます（DebugView でイベントをモニタリングする）。

二つ目は、確認のための送信が本番の成果に混ざらないことです。GA4のデータフィルタには、デバッグモードを使っている開発者の操作を除く「デベロッパートラフィック」と、指定したIPアドレスからの操作を除く「内部トラフィック」があります。フィルタの影響は恒久的で、除外されたデータは処理の対象から外れ、後から使えません（データフィルタ）。条件を誤ると本物の訪問まで失うので、どの範囲を除くかを実装の担当者と確かめてから有効にします。受付台帳の側でも、テスト送信に印を付けて件数から外します。

三つ目は、受付の記録との照合です。同じ期間について、GA4の受付成功イベントの件数と、フォームの受信記録や受付台帳の件数を並べます。GA4のほうが多ければ、重複かテスト送信の混入を疑います。GA4のほうが少ない場合は、計測のタグが動かなかった環境からの送信が考えられます。タグが動かなければ、送信は届いていてもGA4には記録されないからです。件数の基準にするのは受付の記録で、GA4の数字は、どのページや経路から来たかを見るために使います。差の調べ方は工務店の集客データが合わないときで扱っています。

フォームやサイトを改修したときは、この三つをもう一度試します。計測は、ページの作りが変わると、気付かないうちに止まっていることがあります。