GA4の問い合わせ数とメール件数が合わない｜計測・フォーム・受信箱を照合する

作成日編集日 約13分

GA4では問い合わせが20件なのに、受信メールは12件。数字が違うと、どちらを報告に使えばよいのか迷いますよね。

GA4の設定を変える前に、「GA4が何を1件と数え、メール側では何を数えたのか」を確認し、比較の基準をそろえます。送信ボタンのクリック、フォームの受付成功、通知メールの到着、有効な商談の発生は、それぞれ違う出来事です。

この記事では、計測・フォーム・受信箱の3か所を照合し、どこで件数に差が出たかを調べます。GA4の仕様や画面名は2026年9月16日に公式資料で確認しています。実際の画面は権限や設定によって異なります。

「問い合わせ1件」の定義を先に決める

たとえば、次の3つの数字を同じものとして扱っていないでしょうか。

数字数えているものそれだけでは分からないこと
フォームの送信成功数フォーム側で成功と判定された送信通知メールが担当者へ届いたか
通知メールの件数受信側で確認できた通知計測できなかった送信や、重複通知の有無
有効な問い合わせ数営業やテストなどを除いた、対応対象の相談除外前の送信成功数

広告やサイト改善では、まず「対象フォームで受付が成功した送信」を完了として計測し、テスト・営業メール・商談対象外などの分類は業務側の集計として分けると整理しやすくなります。

ただし、サイトの仕様によって「成功」の意味は違います。データベースへの保存完了なのか、メール送信処理の成功なのか、外部システムの受付完了なのかを確認してください。メール送信処理が成功しても、受信者への到着が保証されるわけではありません。

定義は、短い文章で残しておきます。

対象：お問い合わせフォームA
完了：フォーム側の正常な送信成功が確認できたもの
数える単位：成功した送信1回を1件
含めるもの：一般のお問い合わせ。テスト分は別記録する
別集計：営業メール、重複相談、商談につながった相談
比較する期間とタイムゾーン：
計測に使うイベント名：
フォーム側の記録元：

「有効な問い合わせ」を成果指標にすること自体は問題ありません。その場合も、ブラウザ上の送信成功数とは自動的に一致しない指標として、分けておくことが大切です。

GA4が多いときと、少ないときで確認先が変わる

差の方向を分けると、最初に見る場所を絞れます。ただし、以下は候補であり、件数の差だけで原因が決まるわけではありません。

差の方向よく確認したい設定・状態確かめ方
GA4が多い送信ボタンを押しただけで完了を計測している必須項目を空にしたテストでも発火するか
GA4が多い完了ページの再読み込みや直接アクセスを数えている送信せずに開いた場合、イベントが発生するか
GA4が多い同じ成功を複数のタグやイベント作成ルールで計測している1回の送信で何回イベントが送られるか
GA4が多いテストや営業の送信も含めているメール側で除外したものと条件が違わないか
GA4が少ない対象ページでタグが動いていないGTMのプレビューやDebugViewで確認する
GA4が少ない同意の状態やブロック機能で計測が制限される許可されたテスト条件ごとに動作を確かめる
GA4が少ない成功後の経路が変わり、想定した完了ページを通らない送信後の遷移先を実際に追う
GA4が少ないセッションに1回だけ数える設定になっているキーイベントのカウント方法を見る
メール側が多い自動返信、複数宛先への通知、転送、重複通知まで数えている同じ受付にひもづくメールを整理する
メール側が少ない迷惑メールへの振り分け、配送失敗、表示上のスレッド集約個々の通知とフォーム側の成功記録を照合する

GA4のキーイベントのカウント方法には、「イベントごとに1回」と「セッションごとに1回」があります。後者なら、同じセッションで正常に2回送信しても、キーイベントは1回になることがあります。

重複計測を隠すために「セッションごとに1回」へ変えるのは、原因の修正ではありません。まずイベントそのものの発生回数を確認します。

また、全サイトのキーイベント合計には、電話クリックや資料ダウンロードなどが含まれる場合があります。問い合わせの対象イベントだけを絞り、ユーザー数やセッション数ではなく、そのイベントの回数を比較してください。

form_submitという名前だけで、問い合わせ完了にしない

GA4の拡張計測機能には、「フォームの操作」があります。ここでは、フォームへの最初の操作を示す「formstart」と、送信を示す「formsubmit」が扱われます。

確認する場所は、「管理」から「データの収集と修正」内の「データストリーム」を開き、対象のウェブストリームにある「拡張計測機能」の設定です。「フォームの操作」が有効かを見ます。

ただし、拡張計測機能のform_submitは、自社の問い合わせ業務で「受け付けが完了した」と判断する条件を、自動的に理解しているわけではありません。受信メールの到着を保証するイベントでもありません。

フォームの実装や追加したタグによって、入力エラーの前後で何が起きるかも変わります。イベント名だけで「エラーでも必ず数えられる」「正常な送信なら必ず計測できる」とは判断できません。

同じテスト送信を、3か所で確認する

まずテスト用のブラウザで、GTMのプレビューなど、デバッグできる状態を用意します。GA4では「管理」の「データの表示」から「DebugView」を開きます。

次の条件を一つずつ試し、フォームの画面、発生したイベント、通知メールを対応させます。

操作フォーム側の期待結果問い合わせ完了イベントの期待回数
フォームを開くだけまだ送信していない0回
必須項目を空にして送信する入力エラー0回
正常な内容で1回送信する送信成功1回
完了表示後にページを再読み込みする新しい送信はしていない0回
改めてフォームから正常に送信する別の送信成功新たに1回

ここに実際のform_submitの発生回数を書き加えます。正常な送信成功と一致するなら、その環境で完了の候補にできます。入力エラーや別フォームまで拾うなら、完了の基準を別に用意するか、対象を正しく絞る必要があります。

DebugViewの公式案内では、プライバシー設定や同意の状態によってイベントが表示されない場合も説明されています。表示がないだけで、すぐにコードの故障と決めないでください。利用者の同意を無視して計測を通す設定にはしません。

なお、過去に届いたメールとGA4の集計を、後からすべて1件ずつ対応づけられるとは限りません。この照合は、まず自分で条件を管理できるテストで行います。

完了の基準は、フォームの成功イベントか、完了ページか

基準を選ぶときは、「成功したときだけ、安定して通る場所はどこか」を見ます。

方法向いている状態確認が必要な弱点
フォーム固有の成功イベント画面遷移せず完了する、成功・失敗の状態が明確に分かれているどの時点を成功としているか、対象フォームを区別できるか
完了ページの表示正常な送信後に、専用の完了ページへ必ず進む再読み込み、直接アクセス、別フォームからの流入
サーバーや受付システムの記録業務上の受け付けを確実に管理したい個人情報の管理、記録範囲、GA4との比較条件

送信成功イベントを使うなら、そのフォームの公式仕様を確認します。Contact Form 7のAjax送信では、「wpcf7mailsent」がメール送信成功時のイベントです。「wpcf7submit」は入力エラーやスパムなどの結果も含むため、同じものとして扱いません。

それでも「wpcf7mailsent」は、担当者の受信箱へ届いた証明ではありません。CF7のイベント仕様とWordPressのメール処理の意味を踏まえ、ここでは「フォームの送信処理が成功した数」を計測します。

完了ページを使う場合の設定例

すでに専用の完了ページがあり、成功したときだけ遷移するなら、GA4の公式設定例のように、page_viewをもとに新しいイベントを作る方法があります。

「管理」の「データの表示」から「イベント」を開き、イベント作成へ進みます。例としてイベント名を「generatelead」とし、コードを使わず、対象ストリームのpageviewと完了ページURLを条件にします。

URLの判定には、実際の送信後URLを使います。たとえば「/thanks/を含む」という条件だけでよいかは、ほかのフォームにも同じ文字列を使っていないかまで見て決めます。必要に応じてホスト名やパスを絞ります。

ここで設定できたとしても、再読み込みや直接アクセスによる水増しが解決するわけではありません。サーバー側で受付の状態を確認して完了画面を表示する設計などが必要なケースは、ページ表示だけでの厳密な計測を無理に続けないようにします。

CF7なら、GTMへ成功イベントを渡す方法もある

ここからは、Contact Form 7をAjax送信で使い、GTMでタグを管理している場合の実装例です。独自フォームや非Ajax送信には、そのまま適用できません。

既存のGoogleタグ、同意管理、問い合わせ計測を調べてから追加してください。すでに同じ成功を計測しているなら、古い計測と新しい計測を二重に有効にしないよう整理します。現在のGTM公開バージョンも控えておきます。

成功をdataLayerへ渡す

GTMの「カスタムHTML」タグに、次のコードを設定します。123は説明用の仮IDです。CF7のイベントで通知される対象フォームIDを確認して置き換えてください。

<script>
(function () {
  // 同じコードが再実行されても、リスナーを二重に登録しない。
  if (window.__cf7InquiryBridgeInstalled) {
    return;
  }
  window.__cf7InquiryBridgeInstalled = true;

  // 実際の対象フォームIDへ置き換える。
  var targetFormId = '123';

  document.addEventListener('wpcf7mailsent', function (event) {
    if (
      !event.detail ||
      String(event.detail.contactFormId) !== targetFormId
    ) {
      return;
    }

    window.dataLayer = window.dataLayer || [];
    window.dataLayer.push({
      event: 'cf7_inquiry_success',
      form_id: 'cf7_' + targetFormId
    });
  });
})();
</script>

このタグは、対象フォームが存在するページの「DOM Ready」で動かすように設定します。ポップアップなどで複数ページにフォームがあるなら、それらも対象です。フォーム送信前にリスナーが登録されることを、プレビューで確かめます。

このコードは、指定したフォームの成功イベントを、GTMで受け取れるイベントに変えて渡しています。dataLayerの仕組みを使い、フォームID以外の入力内容は渡していません。

冒頭の処理は、同じコードの二重登録を防ぐためのものです。別のタグが同じ送信を計測することまで防いだり、利用者の再送信を自動で同一問い合わせとして統合したりするものではありません。

カスタムイベントからGA4のイベントを送る

GTMで「カスタムイベント」トリガーを作り、イベント名に「cf7inquirysuccess」を指定します。正規表現を使う必要はありません。

続いて、GA4のイベントタグを作ります。対象のGoogleタグ・ウェブストリームに接続し、イベント名を「generate_lead」、発火トリガーをいま作ったカスタムイベントにします。

対象フォームをレポートでも区別したい場合は、データレイヤー変数として「formid」を読み取り、イベントパラメータの「formid」へ渡します。利用するレポートによっては、GA4側でカスタムディメンションの登録も必要です。

すでに「generate_lead」を別の問い合わせにも使っている場合は、そのイベントの集計範囲も確認します。イベント名を増やすことよりも、「どのフォームの何を数えるか」をそろえることが重要です。

GTMのカスタムイベントトリガーの設定後は、通常送信で1回、入力エラーで0回、完了後の再読み込みで0回になるかをプレビューします。GA4のDebugViewにも届くことを確認してから公開します。既存の同意管理に従う設定は維持してください。

最後に、GA4の「管理」から「イベント」を開き、確認したイベントをキーイベントとしてマークします。これは権限が必要な操作です。キーイベントへの設定は過去へさかのぼって集計を作り直すものではないため、変更日を記録します。

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

メールと突き合わせたいからといって、氏名、メールアドレス、問い合わせ本文をイベントパラメータに入れないでください。完了ページのURLにメールアドレスが含まれている場合も見直しが必要です。

GA4には個人を特定できる情報の送信に関する制限があります。フォーム側の詳細記録は、アクセス制限された別の管理場所で扱います。

1週間だけ、3つの記録を同じ条件で並べる

テストが通ったら、次は日々の運用で差を確認します。いきなり数か月分を追うより、対象フォームを一つに絞り、1週間分を並べると扱いやすくなります。

最初にそろえるのは、期間、タイムゾーン、フォーム、数える単位です。GA4とメール一覧で日付の境目が違うと、同じ送信でも別の日に入ります。直近のデータは処理が進むため、通常レポートの値をすぐに確定扱いしません。

GoogleはGA4のデータ処理について、24〜48時間かかる場合があり、その間にレポートが変わることを案内しています。ここでは、終了してから少なくとも48時間たった週を候補にし、値がまだ変わっていないか、処理上の注意点がないかを確認して使います。

以下は照合方法を示すための架空の記録です。実際の改善結果ではありません。

日フォームの成功記録重複を整理した通知メール対象イベントの回数残しておくメモ
月444同じ条件で一致
火334GA4が1件多い。重複発火などを調査
水544配送と計測の両方に差。別々に確認
木222うち1件がテスト。業務集計では区別
金665計測できない条件などを調査
土111同じ条件で一致
日000送信なし
合計212020合計の一致だけでは日別の差が消えて見える

この例では、メールとGA4の合計は同じ20件です。それでも、火曜と金曜では違いがあり、フォームの成功記録とは一致していません。合計だけを見て「直った」と判断すると、問題を見落とします。

フォーム側の保存記録がない場合は、その列を「未取得」にします。CF7は標準では送信内容を保存しないため、過去の記録が必ずあるとは限りません。メールの件数をコピーして、フォーム側も同じだったことにしないでください。

受信箱は「見えている行数」ではなく、対象の通知を数える

メール側では、自動返信、担当者間の転送、同じ受付の複数通知を区別します。会話表示で何通かが1行にまとまっている場合も、一覧の行数だけを件数にしないようにします。

受付番号があるなら、同じ受付番号を基準に整理できます。ない場合は、日時と内容から同じ通知かを確認します。ただし、同じ人からの追加相談まで一律に重複として消さないよう、業務上の基準を決めてください。

過去のGA4に対応する識別情報がないときは、日別・フォーム別の差までは分かっても、どのメールが未計測だったかは特定できません。「おそらく広告ブロック」と推測で説明せず、原因未確認として残します。

許容する差は、割合より「説明できるか」で決める

問い合わせが月に数件のサイトでは、1件の取りこぼしが大きな割合になります。反対に、大量の通知があっても、二重計測による差なら直すべき設定不備です。「何％以内なら正常」という一律の基準では判断しにくいところです。

確認は2つに分けます。

まず、フォームで受け付けた正常な問い合わせが、業務側で確認できるか。これは機会損失に関係するため、通知の未着があるなら先に対応します。

次に、ブラウザでの計測にどんな制約があり、差の方向や変化を説明できるか。正常な送信でも計測が制限される条件はありますが、急に差が広がったときは、設定変更やフォーム改修との前後関係を調べます。

入力途中で止まる原因を調べたい場合は、完了数の照合とは別に、送信ボタンは押されるのに送信されないときの確認へ進めます。数字の整合が取れているのに問い合わせ自体が少ない場合は、問い合わせが来ない原因の切り分けで、流入とページの内容を見直します。

数字を合わせるより、数えているものをそろえる

計測を修正した日は、変更前の定義、変更後の定義、対象イベント、テスト結果を残します。イベントやカウント方法を変えた前後は、そのまま連続した成果として比較できない場合があります。

フォームの成功、メールの受信、有効な相談を分けておけば、報告のたびに「どれが正しい数字か」と迷うことも減らせます。

タグが複数あって整理しきれない、成功イベントの意味が分からない、通知の未着と未計測を区別できない。そんなときは、サイト改善・GA4計測の相談で状況をお聞かせいただけると幸いです。完了として数える条件と1件の送信経路を一緒に確認し、件数の違いを整理するお手伝いができればと思います。

SNS SHARE

はてなブックマークでシェアXでシェアLINEでシェア