フォーム履歴があるのにGA4は0件｜経営者の計測断絶3点診断

年商1〜100億円で専任の分析担当を置きにくい製造業・建設業・士業・BtoBサービスのフォームDBに行があるのにGA4のコンバージョンが0件なら、主な原因はイベント未送信、キーイベント未指定、タグ阻害、イベント名不一致です。「GA4が0件だからSEOや広告を止めるべきか」と迷っている経営者・事業責任者・マーケティング責任者・一人マーケターは、この矛盾を「どちらかが正しい」で片付けず、送信操作、GA4イベント、業務DBへの保存を、同じ期間・完了条件・重複除外で照合してください。成果ゼロと計測断絶を分けるためです。

この記事は、年商1〜100億円程度で専任の分析担当を置きにくい中小・中堅の製造業、建設業、士業、BtoBサービスにおいて、GA4のコンバージョンが0件という報告を受け、SEOや広告を止めるべきか迷っている経営者、事業責任者、マーケティング責任者、一人マーケター向けです。ATK編集部「atk.jp 本番フォームDB・GA4監査」（2026年9月10日集計）では、本番フォームDBに累計204行がある一方、最後に取得できたGA4では56日連続でコンバージョン0件でした。この矛盾を「どちらかが正しい」で片付けず、成果計測の断絶を発見する材料にします。

ATKではフォームDB 204行とGA4 56日連続0件が同時に存在した

ATK編集部「atk.jp 本番フォームDB・GA4監査」（2026年9月10日集計）によると、本番DBの `diagnosis_leads` には2026年4月19日から9月9日までに204行が保存されていました。直近28日間（2026年8月13日〜9月9日）の行数は4、その前の28日間（2026年7月16日〜8月12日）は30で、同監査の2期間の行数から本記事で算出した減少率は86.7%（(30−4)÷30×100）です。一方、同監査で参照した前回取得済みGA4では、上記2つの28日期間（2026年7月16日〜9月9日の合計56日間）ともコンバージョンが0でした。これらは顧客実績ではなく、ATK自社システムの監査値です。

記録	観測値	現時点で言えること	まだ言えないこと
フォームDB	累計204行	データベースへの書込み履歴が存在する	204件の有効問い合わせがあったとは言えない
直近28日	4行	2026年8月13日〜9月9日に4行保存された	4社の見込み客、4商談とは言えない
前の28日	30行	2026年7月16日〜8月12日に30行保存された	減少原因が需要、計測、スパムのどれかは現状の記録だけでは判断できない
GA4	2026年7月16日〜9月9日の56日間連続0件	GA4上でキーイベントとして成果を確認できなかった	フォーム送信自体が0だったとは言えない
リード状態	204行すべて `new`	営業結果がデータへ反映されていない	有効、重複、テスト、スパム、商談化を区別できない

特に注意すべきなのは、同ATK編集部「atk.jp 本番フォームDB・GA4監査」（2026年9月10日集計）で確認した2026年6月の日別行数に、1日17行など送信が集中した日があることです。これはキャンペーン成功の可能性も、テストやボットの可能性もあります。内容を確認せず「累計204リード」と外部へ公表するのは不適切です。個人情報を記事へ出さず、日別行数、重複率、メール到達、営業確認などの集計だけで判定します。

フォーム保存とGA4イベントが別処理である理由と6つのずれパターン

フォーム完了までには、画面、ブラウザ計測、API、DB、通知、CRMという複数の境界があります。ユーザーから見ると送信ボタン1回でも、システム内では別の成功条件です。GA4イベントをボタンクリックで送ると、入力エラーやAPI失敗でも件数が増えます。逆にDB保存後に画面遷移が起き、計測タグが動く前に離脱すると、DBだけ増えてGA4は0のままになることがあります。次の6行は204行すべてで発生したと断定する監査結果ではなく、ATKの計測断絶を切り分けるために検証した技術仮説です。

ずれ方	起きる状態	確認方法
クリック時にイベント送信	DB保存失敗でもGA4だけ増える	成功レスポンス後に送っているかコード確認
完了ページだけでイベント送信	遷移阻害・同意拒否・タグ読込失敗でDBだけ増える	Google公式DebugViewの手順とネットワークログで確認
イベントは届くがキーイベント未指定	イベント一覧にあるが成果列は0	Google公式キーイベント設定を確認
イベント名が環境で異なる	`generate_lead` と独自名に分散する	Google公式推奨イベントを基準に本番・検証を照合
ボット・テストがDBへ保存	DBだけ大量に増える	送信間隔、重複、テストドメイン、営業確認で分類
CRM更新が戻らない	全件 `new` のまま	有効・商談・受注・失注の更新責任者を決める

Google Analytics「イベントについて」は、イベントがサイト上の操作を測定する仕組みであることを示します。「推奨イベント」（2026年6月26日更新）は、見込み客獲得の行動に `generate_lead` を挙げており、これはイベント名を選ぶ根拠です。名前だけを送れば正しく計測できるという意味ではないため、フォームの成功条件と送信タイミングを合わせます。

別のGoogle Analyticsヘルプ「イベントにキーイベントとしてマークを付ける」（更新日の記載なし、2026年9月11日確認）は、収集済みイベントをキーイベントとして設定する手順を示しています。さらに「DebugViewでイベントをモニタリングする」は、開発端末から届くイベントを確認する検証手順を示します。イベント受信、キーイベント指定、検証はそれぞれ独立した確認工程です。

成果計測3点照合で、どこが切れたか特定する

一般的なGA4設定確認はイベント受信など個別工程の点検になりがちですが、この記事の成果計測3点照合は、送信操作・分析イベント・業務記録を同じテスト送信IDまたは時刻で一本につなぎます。第1点はユーザー操作、第2点は分析イベント、第3点は業務記録です。

この照合により、画面だけ成功してイベントが届かない、画面とDBは成功しているのにGA4の0件を需要ゼロと誤読する、3点すべて成功しても全行が `new` のままで事業成果を判定できない、という三つの見落としを分けられます。3点それぞれの成否と証拠を一行に記録します。

点	完了条件	証拠	担当
第1点 送信操作	利用者に成功が表示され、二重送信されない	画面、HTTP応答、エラーログ	Web・開発
第2点 分析イベント	本番GA4に1回だけ `generate_lead` が届く	DebugView、リアルタイム、イベント一覧	マーケ・分析
第3点 業務記録	DBへ1行保存され、営業が有効性を更新できる	DB、通知、CRM、ステータス履歴	営業・業務

第1点だけ通るならAPIやタグ、第1・2点が通って第3点が落ちるなら保存処理、第1・3点が通って第2点が落ちるならGA4設定を調べます。3点すべて通っても、営業が全件 `new` のままにすれば事業成果は測れません。計測の完成条件はフォーム送信ではなく、有効性と商談結果が戻ることです。

生のDB行からテスト・スパム・重複を除いて有効リードを作る

DB行数をそのままリード数にすると、重複送信、社内テスト、営業対象外、ボットを成果に含めます。最低限、次の状態を分けます。名称は既存CRMに合わせて構いませんが、判定条件を文章で定義します。

状態	判定例	SEO成果に含めるか
raw	DBに保存された未判定行	含めない
test	社内・開発・監視による送信	含めない
spam	営業対象外の自動送信や不正送信	含めない
duplicate	同一人物・同一要件の重複	原則1件に統合
valid	連絡可能で、対象サービスの相談として成立	有効リードに含める
qualified	課題、予算、時期、決裁等を確認し商談化	商談に含める
won / lost	受注または失注理由が確定	売上・粗利分析に使う

スパム対策は件数を減らすためではなく、判断できる母数を作るために行います。サーバー側検証、レート制御、ハニーポット、チャレンジ、重複判定を組み合わせます。ただし強すぎる対策で正規ユーザーを落とす可能性もあるため、拒否数とフォーム完了率を同時に観測します。

generate_leadはフォーム保存成功後に一度だけ送る

GA4へ送るのはイベントと分析に必要な非個人情報です。メールアドレス、氏名、自由記述の相談内容など、個人を直接特定できる情報をイベントパラメータへ入れてはいけません。フォームDBとGA4を照合する場合も、生の個人情報を分析ツールへ転送せず、同意と社内方針に沿った非識別の識別子、時刻、ランディングページ、キャンペーン情報等で設計します。

イベントには、少なくともフォーム種別、完了したページ、流入キャンペーンを後から区別できる設計が必要です。項目を増やしすぎると保守できないため、経営判断に使うものだけを残します。フォームの入力開始、エラー、送信成功を別イベントにすると、流入はあるが入力で止まるのか、送信処理で落ちるのかを分けられます。

GA4とSearch Consoleの基本構成はGA4・Search Console連携の設定、経営会議で見る指標はKPIダッシュボードの作り方に分けて整理しています。これらの基準値を作る前に、成果計測3点照合でフォーム経路の断絶を除きます。

1件のテスト送信を成功画面・GA4・DB・営業まで追跡する

1. 準備：本番テストであることを識別できる会社名・メールドメインを決め、終了後に `test` へ分類します。
2. 流入：専用UTM付きURLから対象フォームへ入り、ランディングページと参照元を記録します。
3. 入力：必須エラーを一度発生させ、エラーイベントが送信成功に数えられないことを確認します。
4. 送信：ボタンを1回押し、成功表示、HTTP応答、DB1行、通知1通を確認します。
5. GA4：`generate_lead` が1回届き、キーイベントとして確認できるかを見ます。
6. 業務：CRMまたはDBを `test` へ更新し、更新履歴と担当者が残るか確認します。
7. 再送：戻る操作や更新で二重計上されないことを確認します。

本番テストは、実データへ混ぜない運用まで含めて完成です。テスト行が永遠に `new` のままだと、後で有効率を計算したときに分母を汚します。月次でテスト・スパム・重複の比率を確認し、急増時だけ送信元と防御を深掘りします。

GA4・DB・営業の組み合わせで断絶箇所を切り分ける

GA4	DB	営業確認	優先調査
0	あり	有効あり	イベント送信、キーイベント指定、同意、タグ読込
あり	0	0	クリック時の誤発火、API失敗、完了条件
あり	あり	0	スパム、対象外、重複、フォーム質問設計
あり	あり	有効あり	流入元、商談化、受注・粗利の接続
0	0	0	母数不足、フォーム障害、検索意図、CTA到達

この表の目的は、マーケティング、開発、営業のどこへ調査を依頼するか決めることです。「GA4が0だからマーケの問題」「DBにあるから開発は正常」という部門別の早合点を避け、同じテストIDを3部門で追います。

フォーム改修・タグ変更後は日次3点比較で計測断絶を即日発見できる

フォーム改修、タグ変更、同意管理、ドメイン移行のいずれかが発生した翌日から、DB保存数・GA4イベント数・有効判定数の3列を日次で比較することで、計測断絶を月次会議より前に発見できます。計測は一度直しても、これらの変更によって再び切れます。重要なのは完全一致を強制することではなく、差が生じたときに理由を追えることです。

観測パターン	疑う箇所	確認するログ	初動
DB保存あり、GA4イベントなし	タグ発火、同意状態、イベント名、キーイベント設定	ブラウザ通信、タグ管理、GA4 DebugView	本番と同じ条件でテストし、成功応答後の発火を確認する
GA4イベントあり、DB保存なし	送信前発火、API障害、入力検証、二重画面遷移	アプリケーション、API、データベースのエラー	分析上の成果報告から除外し、保存成功を完了条件にする
DB行が急増し、有効リードが増えない	スパム、自動巡回、重複、テスト送信	送信時刻、参照元、入力傾向、営業判定	raw行と有効リードを分離し、防御策を追加する
全レコードが同じ未処理状態	通知、担当割当、営業連携、状態更新処理	通知履歴、CRM同期、担当者の処理記録	計測復旧と並行して運用上の未処理を解消する

監視表には、日付、フォーム名、成功応答数、DB保存数、GA4イベント数、キーイベント数、有効判定数、異常理由、対応者を残します。フォームが複数ある場合は全体合計だけでなくフォーム別に分けます。一つの資料請求フォームだけが切れても、全体合計では他のフォームに隠れるためです。

復旧後の評価期間は、障害中のゼロを通常実績へ混ぜず、「計測可能だった期間」と「計測不能だった期間」を分けます。施策前後を比べるときも、曜日構成と期間幅をそろえ、DBとGA4の両方が正常だった日だけで基準値を作ります。これにより、タグを直しただけの増加をマーケティング成果と誤認せずに済みます。

経営向けには、総問い合わせ、計測一致率、有効リード、商談の四つを並べます。総問い合わせが増えて一致率が落ちた場合は計測品質、イベントが増えて有効リードが増えない場合は流入品質またはスパム、商談だけ落ちた場合は営業対応や相談内容との不一致を調べます。異なる問題を「コンバージョン率低下」の一言でまとめないことが、正しい投資判断につながります。

異常通知にも十分な状況を含めます。「件数が違う」だけでは担当者が最初から調査し直すことになります。対象フォーム、発生時刻、直前の正常時刻、DB保存の有無、GA4受信の有無、直近のリリース、同意状態を通知へ添えれば、マーケティング、開発、営業のどこが初動を持つべきか判断できます。復旧時には原因、影響期間、欠損を後から補完できるか、再発防止策を記録し、同じ障害を別のフォームで繰り返さないようにします。

計測の責任者は、タグを設置した人ではなく、数字の意味と異常時の連絡先を維持する役割です。担当交代後もテスト手順、正常値、除外条件、履歴が残るようにし、個人の記憶へ依存させません。

売上・利益はraw行ではなく有効リードから計算する

成果計測の事業式は、有効リード数 × 商談化率 × 受注率 × 1件当たり粗利 − 集客費 − 対応工数です。生のDB行数を有効リード数へ入れると、スパムが多いほど見かけのROIが高くなります。GA4が0のままなら、チャネル別の集客費をどの成果へ配分するか決められません。

入力	自社値	必要な整備
rawフォーム行	［　］件	DBから集計
テスト・スパム・重複	［　］件	状態分類
有効リード	raw − 除外 = ［　］件	営業確認
商談化率・受注率	［　］% / ［　］%	CRM更新
1件当たり粗利	［　］円	管理会計
集客費・対応工数	［　］円	媒体費、制作費、営業工数

上記の表に自社値を入れると、成果計測の事業式で月次の投資対効果を再計算できます。再計算用の試算例：以下の件数と金額は実在する問い合わせ実績ではなく、raw行の誤用が生む差を示すための架空データです。仮にrawフォーム行が月20件、テスト・スパム・重複が12件なら有効リードは8件です。商談化率50%、受注率25%、1件当たり粗利100万円、集客費と対応工数を月30万円と仮定すると、8件 × 50% × 25% × 100万円 − 30万円 = 月70万円です。raw20件を誤って有効リードへ入れると、20件 × 50% × 25% × 100万円 − 30万円 = 月220万円となり、架空例の差額は150万円です。表の6項目を自社実績へ置き換えると、除外分類前後の投資判断を同じ式で比較できます。

この表の空欄が埋まらないうちは、SEO記事や広告の停止判断をしません。計測断絶を直す費用と、誤判断で止める集客機会を比較し、まず一つのフォームと一つの流入元だけでも経路を完成させます。

GA4フォームコンバージョン0件は4つの主因から確認する

GA4 コンバージョン 0件 フォームの主な原因は何ですか

GA4のフォームコンバージョンが0件になる主な原因は、イベント未送信、キーイベント未指定、同意やブラウザによるタグ阻害、イベント名の不一致です。フォームDB、通知、CRMの同期間データと照合し、問い合わせゼロなのか計測断絶なのかを分けます。

GA4でフォーム送信を計測できない場合、最初に何を確認しますか

最初に、本番GA4へ対象イベントが届いているかと、そのイベントがキーイベントに指定されているかを別々に確認します。受信がなければ実装・同意・タグ読込を、受信済みで成果列が0ならキーイベント設定と集計期間を確認します。

generate_lead はいつ送信すればよいですか

Google Analyticsの推奨イベント資料は見込み客獲得の行動に `generate_lead` を挙げ、キーイベントの公式ヘルプはイベント受信とキーイベント指定が別工程であることを示しています。`generate_lead` はボタンを押した瞬間ではなく、API成功やDB保存確認後など自社フォームの成功条件を満たした時点で一度だけ送信します。

フォームDB 件数を問い合わせ数として報告してよいですか

フォームDB件数は、有効性を分類する前は問い合わせ数ではなくraw行として報告します。テスト、スパム、重複、対象外を除き、営業が連絡可能性と相談内容を確認したものを有効リードにします。

GA4とDBのフォーム件数を完全一致させる必要がありますか

GA4とDBのフォーム件数は、必ずしも完全一致させる必要はありません。同意設定、ブラウザ制限、通信失敗などによる差の理由と許容範囲を説明でき、重要な経路で障害を検知できる状態にします。

この診断はATK一次監査とGoogle公式4資料で検証する

• ATK編集部「atk.jp 本番フォームDB・GA4監査」（2026年9月10日集計。DBは2026年9月9日まで、GA4は前回取得済み期間）
• Google Analyticsヘルプ「イベントについて」（更新日の記載なし、2026年9月11日確認）— 操作をイベントとして測定する仕組みの根拠。
• Google Analytics「推奨イベント」（2026年6月26日更新、2026年9月11日確認）
• Google Analyticsヘルプ「イベントにキーイベントとしてマークを付ける」（更新日の記載なし、2026年9月11日確認）
• Google Analyticsヘルプ「DebugViewでイベントをモニタリングする」（更新日の記載なし、2026年9月11日確認）— イベント受信を検証する手順の根拠。

計測断絶を1本の成果経路へ直す

次の3条件のどれか一つでも当てはまる場合は、広告やSEOの停止前に計測経路の整理が必要です。

1. GA4は0件なのに、DB保存と営業確認では有効相談がある
2. GA4イベントはあるのに、フォームDBへ保存されていない
3. 同じテスト送信IDで3点を追えない、またはraw行と有効リードを区別できない

対象フォームURL、テスト日時、DB行数、GA4イベント名、キーイベント設定、営業ステータスを用意してください。

相談後にお渡しするのは一枚の照合シートです。送信操作・分析イベント・業務記録の3点それぞれについて、断絶箇所、欠損期間、最初に直す実装、マーケティング・開発・営業の担当を明記します。どの工程で計測が切れているかと修正の優先順位が、その一枚で判断できる状態になります。

該当する場合の依頼先は一つです。Content to Leadで、記事閲覧から有効相談までの計測経路を整理する。