GA4のフォーム開始が多いのに問い合わせが少ない？送信と受付を分けて確かめる

開始・送信イベントは、何を数えている？

入力を始めた記録と送信の記録は、社内で相談を受け付けた証拠とは別です。最初に、表示している数字の名前と集計単位を読みます。

数字は何を示す？

図では、入力欄と送信操作の観測を、結果画面と受付記録から分けています。並んだ資料を、全部成功した一連の実績として読まないことがポイントです。

説明図の原画を開く

送信イベントまで見つかっても、画面に何が出たか、社内に何が保存されたかは残ります。未確認の資料を、前の段階の記録で埋めません。

form_start

Google公式では、一つのセッションで利用者がフォームに初めて関わったときのイベントです。セッションは、サイトでの利用をまとめる単位です。「開始」の数だけで、別々の相談者や相談案件の数とは読みません。

form_submit

フォームの送信時に計測するイベントです。名前だけで、社内の保存・通知・内容確認まで済んだとは判断できません。画面のボタンを押した回数と、どの実装でも必ず一致するとも決めません。

社内の受付

会社で決めた受付先に内容が残り、担当者が確認できたという業務上の記録です。利用するフォームや受付方法に合わせ、何を受け付けたと数えるかを社内で定めます。

イベント数、利用者数、相談案件数を混ぜないようにします。同じ人の再操作や、対象外のフォームが含まれるかを調べずに、開始と送信の差を「離脱した人数」として引き算しません。

また、Googleの推奨イベントには、情報の提出を扱うgenerate_leadと、会社の条件に合う見込み顧客として判定した段階を扱うqualify_leadがあります。推奨イベントは自動で送られるものではなく、名前を付けただけで営業の適格判定まで分かる仕組みではありません。

根拠：Google公式のフォーム操作イベントと、推奨イベント。実会社の受付・適格判定は、この説明では未確認です。

対象の相談フォームと比較条件をそろえる

「サイト全体のフォーム送信」ではなく、調べたい相談フォームの記録を選びます。検索欄や別の申込欄などが同じ集計へ入っていないかも、対象を見分けてから確かめます。

どのフォームの数字？

図のフォームの紙面と計測条件の資料を見比べます。フォームの見出しが同じでも、計測側の識別情報や比較期間がそろっているとは限りません。

説明図の原画を開く

対象が特定できなければ、先にフォームとイベントの対応を調べます。表示件数の多さを理由に、全フォームの計測を止めたり、新しいタグを足したりしません。

1. 公開ページと相談フォームを一つ選びます。Web担当が対象ページとフォームの役割を、計測担当・受付担当に示します。同じページに別のフォームがある場合も分けます。
2. 計測された識別情報を、フォームの実装と照合します。Google公式のform_idはフォーム要素のid属性、form_nameはname属性、form_destinationは送信先URLです。見た目のフォーム名だけでなく、実際の値を実装担当と確認します。原票がない値は作りません。
3. 比較範囲と単位をそろえます。期間と時間帯の設定、対象ページ、端末、公開版か確認用か、イベント数・利用者数などの指標名を残します。期間・端末は「合わせる予定」と「確認できた条件」を区別します。

GA4側では、まず使っているレポートや探索に、どのフォームの条件が入っているかを読みます。Google公式の例では「探索」のファネルデータ探索で、対象ページのpage_viewと、form_nameで絞った開始・送信の段階を設定しています。ファネルは、条件を決めた段階ごとの行動を見る方法です。単なる全イベント合計の比較とは区別してください。

フォーム情報がレポートに出ていない場合、未確認と記し、計測担当に調べてもらいます。公式資料には、パラメータをレポートで利用するためのカスタムディメンション等の条件もあります。表示されないからという理由だけで、フォーム不存在や送信失敗とはしません。新しい設定の作成や変更が必要なら、対象と影響を権限のある担当者が判断します。

根拠：識別パラメータと利用条件、対象フォームのファネルを作る公式例。公式例のフォーム名を、自社の実値として使うものではありません。

送信後の画面と、社内の受付を別々に確かめる

画面に完了と出たかと、社内に相談が残ったかを、別の確認結果として読みます。送信イベントだけを見て、受付成功とは書きません。

送信の記録があれば、届いた？

図は、送信イベントを観測した架空の別例です。結果画面と受付記録の「未確認」が残ることに注目してください。例Aを直した後の結果ではありません。

説明図の原画を開く

この例で言えるのは、開始と送信のイベントを観測したことまでです。完了画面・受付・適格判定・原因を、成功にも失敗にも補完しません。

確認作業を行うときは、フォーム担当と受付担当が、テストの方法・対象・受付先を先に決めます。実際の顧客の相談と混ざらない方法を選び、担当者の許可範囲で操作します。この記事の制作で実フォームへ送信したという意味ではありません。

計測の確認

対象フォームで、どの操作に対して開始・送信のイベントが出たかを計測担当が記録します。確認時刻、端末、対象ページ、識別情報を画面・受付の確認に対応させます。

画面の確認

送信操作の後、入力エラー、完了メッセージ、別ページへの移動など、実際に見えた結果をフォーム担当が残します。見ていない画面結果を「完了」にしません。

受付の確認

受付担当が、その確認操作に対応する内容が会社所定の記録へ残り、読めるかを確認します。通知メールだけを見る運用か、保存先もあるかは自社で確かめます。通知と保存も、同じ結果と決めません。

記録を対応させる際は、会社で使える確認方法を担当者と決めます。顧客の氏名・メールアドレス・相談本文を、照合のためにGA4のイベントへ付け足さないでください。分析へ送る情報と、社内で取り扱う受付内容は分けます。

画面結果は確認できたが受付を見られないなら、「受付未確認」のまま受付担当へ依頼します。受付側で見つからなかった場合も、調べた対象・期間・保存先を残し、永久に届いていない、原因がフォームである、とまで広げません。観測できた範囲から次の調査先を選びます。

三つの架空例では、次に何を確認する？

開始だけ分かる例、送信も分かる例、対象フォームを特定できない例では、先に確かめる場所が違います。下の三つは別々の観測です。

同じ「多い」でも、何が未確認？

図の別々の紙面で、観測された記録と未確認を見比べてください。上から下へ修正が成功した流れではありません。

説明図の原画を開く

開始だけなら送信以降を、送信までなら画面と受付を、対象不明ならフォームの識別を先に調べます。未確認を埋めるための新しい件数や離脱率を作る必要はありません。

例A：入力開始まで観測

サービス相談フォームの開始イベントを観測した記録です。送信、完了画面、社内受付、適格判定、原因は未確認です。「開始した人は送らなかった」とは言わず、識別情報と期間を記録して、送信以降を別に確認します。

例B：送信イベントまで観測

同じ名称の相談フォームで、開始と送信を観測した別記録です。画面結果と社内受付は未確認です。受付成功と報告せず、対応する画面と受付の記録を担当へ照会します。

例C：別フォームと混在という見出しの観測

開始・送信の記録はありますが、対象フォーム自体が未確認です。見出しだけで混在の原因を確定せず、form_id・form_name・form_destinationと期間で対象を絞れるか調べます。特定できるまでは、サービス相談の受付と直接比較しません。

共通欄の「同じ確認期間に合わせる」「同じ端末条件を記録する」は、そろえるための方針です。すでに全部取得・確認した条件という意味ではありません。実サイト、実GA4プロパティ、個人データも、この架空原票では未確認です。

原因を決めつけず、直す前後の確認を決める

対象の違い、計測の重なり、フォームの処理、画面と受付のどこに差があるかを確かめてから、直す箇所を選びます。数字を一致させることだけを目的に設定を切り替えません。

何を直す前に、何を確かめる？

図は、対象の資料・計測記録・画面と受付を見比べ、未確認の担当へ質問する関係です。原因が見つかって修正完了した実績ではありません。

説明図の原画を開く

対象フォームの識別が不明なら、計測担当と実装担当へ。画面が未確認なら、フォーム担当へ。受付が未確認なら、受付担当へ確認します。分からない段階を飛ばして、入力項目の削除やタグの追加を始めません。

1. 差を、確認できた資料付きで伝えます。対象ページ、フォームの識別情報、期間・端末、使った指標、イベントの観測、画面結果、受付の確認範囲を示します。見られない記録は未確認とします。
2. 原因の候補と、確かめる担当を分けます。対象外フォームの混在や二重計測は計測の候補、送信後の処理や通知・保存先はフォームと受付の候補です。いずれも、この原票で証明した原因ではありません。
3. 変更内容と再確認条件を先に決めます。権限のある担当が、対象を絞る、実装を直す、表示や受付を直す等の必要な変更を判断します。変更後は、同じフォーム・端末等の条件で、イベント、画面、受付をもう一度別々に確認します。変更履歴も残し、以前の集計と定義が変わった場合は区別します。

対象のリードフォームだけを計測するイベントが必要と分かった場合、Google公式には一般のform_submitをform_name条件で絞る例があります。ただし、新しいイベントの作成やキーイベントへの指定を先に行えば、受付との関係まで正しくなるわけではありません。現状の定義と実装を、権限のある担当が確認してから設計します。

根拠：対象フォームに絞るGoogle公式例。イベント作成・キーイベント登録・実フォームの処理変更は行っていません。

まとめ：イベントと受付の間を、一つのフォームで照合する

フォーム開始・送信の数字を、そのまま実際の問い合わせ件数にしないことが出発点です。対象と条件をそろえ、計測、画面、受付のどこまで確認できたかを分けて読みます。

最初に何をそろえる？

図の対象フォーム、計測の条件、受付記録の資料を対応させます。確認前の資料を、成功した相談の印として扱いません。

説明図の原画を開く

開始・送信が観測されても、画面と受付が未確認なら、その確認が残ります。対象フォーム自体が分からなければ、まず識別情報を調べます。条件を合わせられない差は、その限界を残して報告してください。

サイト全体の相談条件や入力項目の改善は、BtoBサイトの問い合わせ改善へ、広告とLPの説明・導線はLP改善の記事へ分けています。検索クリックや訪問と相談の集計は、SEOの段階別測定を参照してください。タグを追加する前の設置経路は、Site KitとGTMの送信先確認で扱っています。

計測担当と受付担当の間で対象や確認方法が整理できないときは、対象ページと観測済み・未確認の範囲を添えてDREEXYへ相談できます。支援範囲・費用・受付可否は個別に確認してください。

2026年10月23日にGoogle公式の必要主文を確認しました。フォーム到達・開始・送信の一般的な考え方は導入の説明、段階別の見方は報告の説明に分かれています。三つの例に実際の件数や離脱率はなく、実フォーム送信、GA4/GTM設定変更、実顧客情報の計測、原因や改善成功の認定はしていません。