GA4でホームページの問い合わせを計測する設計 クリックと受付完了を分ける

「問い合わせボタンが押された回数」と「受付が成立した件数」を分けて計測します。入口クリックはフォームを見に行く行動、受付完了はサービス側で成功を判断できる地点、実受信は事業者が内容を確認できた地点です。外部フォームを利用する場合は、どこまで自分の権限で確認できるかを最初に記録します。

まず、行動ごとに誰が確認できるかを書きます。サイト内のフォームへの移動は、サイト側で観測できる場合があります。受付成功は、完了ページやフォーム提供元が示す成功の通知を利用できる場合に検討します。担当者が受信したことや、事業者が返信したことは、受付システムや担当者の記録で別に確認します。どこから先が見えないかを先に決めると、入口のデータを問い合わせ件数として説明する誤りを防げます。

電話や地図のリンクも、クリックで分かるのはリンクを操作したところまでです。実際の電話の通話や来店を数える場合は、事業者が持つ別の記録を使います。フォームの受信点検と一緒に、メール通知の到着と成功表示を分けてください。

複数のフォームがある場合は、誰が見るデータかに応じて、受付の目的と経路を記録します。一般相談と体験申込を分けるときは、フォームの種類を示す程度の値を使い、入力した人を識別できる情報が不要かを確かめます。来店予約の完了と資料の申込みを混ぜると、変更後の比較が難しくなります。

完了ページで判断する場合

成功時だけ到達する専用ページを使う場合も、再読み込み、ブラウザーの戻る操作、同じURLを直接開いた場合を検証します。ページが開くたびに成功とする設計では、同じ受付を重複して数えることがあります。受付の成功を判断できる条件と、同じ操作で再度記録しない条件を、実装を担当する人と決めます。完了ページのURLに入力内容や個人を識別する値が入らないかも確認します。

完了の通知を使う場合

フォームから成功を受け取れる方式なら、どの通知が受付成立を示すかを提供元の公式説明で確認します。クリック、入力検証の通過、受付の成功は別の地点です。サイトから外部の予約先へ移るだけの構成で、外部側の成功を取得できない場合は、入口の計測と外部側で見られる集計を分けます。計測を作る前に、二重クリック、必須項目不足、再読み込み、外部遷移の各ケースに、どの出来事が何回起きるべきかを書きます。

検証前に、どの時点で受付を一件と数えるかを言葉にします。例えば「入力の誤りを直し、事業者のフォームで成功が確定した時に一件。完了表示を見直す操作では追加しない」と書きます。キャンセルや途中で画面を閉じる操作を試し、成功前にイベントを送る設定が入っていないかを確認します。

GA4で見込み客の獲得を扱う場合は、Google公式の推奨イベント generate_lead の定義を確認します。問い合わせ入口を開くだけの出来事は、別の名前と用途で定義します。この記事の検証では inquiry_start を説明用の名前として使いました。既存の計測と一緒に使う場合は、同じ名前や用途で設定が重複していないか、作成前に管理者と確認します。

氏名、メールアドレス、電話番号、相談本文をイベントの値へ含めないようにします。ページURLやクエリ、ページタイトルなどに入力した値が含まれる仕組みでは、個別のイベント値を絞っただけで解決できないことがあります。どの項目がどこに送信されるかを検証用データで確認し、公開での計測の同意や権限を事業の担当者と照合します。受付番号などを計測へ送る必要がある場合は、個人の特定につながるかを担当者が判断し、目的に使う最小限の情報に絞ります。

利用者の入力に由来する文字列を扱う場合は、タグやフォームを更新した後も再検査します。架空の氏名やアドレスを入れ、イベントの値、リクエスト、到達先のURLに残らないことを確認します。計測の受け皿が複数ある場合はそれぞれで確認し、不要な値は送る前に除きます。

架空のフォームをローカルの受け皿に接続し、クリック、入力エラー、受付成功、二度押し、再読み込み、外部遷移を順に試しました。記録したのは入口の一件と、成功の一件でした。試験で入力した文字はイベントに含まれませんでした。これはブラウザーで発生した検証用の記録で、実際のGA4プロパティで受信した結果は含みません。

GA4を導入する場合は、権限のある検証プロパティでデバッグ用の設定を行い、DebugViewで表示されたイベント名、値、発生時刻をテスト表と照合します。タグの重複、拒否時の扱い、別のドメインへ進む場合、閲覧端末による差も、使う構成で確認します。デバッグで記録が見つからない場合は、検証対象のプロパティ、端末の設定、同意の状態を分けて調べます。実際の利用者の値やテストのデータが本番集計に入らない環境を事前に用意します。

試験に使う検収表は、期待と観測を並べると見直しやすくなります。下の結果はローカルの検証だけを記入した例です。

公開時はこの表を複製し、権限のある環境で確認した結果と日時を書きます。未計測の経路にゼロ件を記入せず、観測できる範囲を残します。

事業者側の件数と比較する時は、期間、タイムゾーン、受付経路、成功の定義をそろえます。例えば受付台帳の十件に電話三件が含まれるなら、フォームの成功記録と直接比べる対象は残りのフォーム分です。テストや重複受付、外部サービスで集計した分、計測への同意がない場合など、説明できる差を別欄に書きます。この数は比較の手順を示す例で、実際の結果ではありません。

計測の目的がサイトの改善なら、入口のクリックが減ったことだけで受付が減ったと判断せず、フォームの成功と受信を確かめます。問い合わせページを改修した時は、発火する地点と送信値を再点検し、変更日を残します。検索結果のクリックを見直す手順では、ページに入る前の検索上の動きを別に確認できます。

受信側と同じ件数になった時も、テストした経路と期間を記録します。同じ時期に外部予約へ切り替えた場合や、問い合わせの受付時間が変わった場合は、比較できる範囲を分けます。違いが大きいときは、受付側の実績を先に確かめ、成功前のクリックが混ざっていないかを調べます。

確認に使った資料

• Google アナリティクス 推奨イベント
• Google アナリティクス 個人を特定できる情報
• Google アナリティクス DebugView
• 個人情報保護委員会 法令とガイドライン

情報確認 2026/11/09。製品・サービスの仕様は参照先でご確認ください。