GA4の問い合わせコンバージョンが受付件数と合わないときに確かめる順番

GA4の件数と受付件数は、まず「数えているもの」が違うと考える

ホームページの問い合わせを、Googleアナリティクス4（以下GA4）のコンバージョンで数え始めたものの、管理画面の件数と、実際にメールや受付画面に届いた件数が合わず、どちらを判断に使えばよいか迷うことがあります。GA4のほうが多い月もあれば、少ない月もあるかもしれません。数字が合わないと、改善の効果を確かめられず、広告や記事の判断も止まってしまいます。

最初に押さえておきたいのは、件数がずれていても、それだけで設定の誤りとは限らないという点です。この記事が主に扱う、ホームページのフォームにブラウザー側で付けた計測では、GA4に届くのは利用者のブラウザーの中で起きた「操作」や「画面の表示」の記録です。GA4にはサーバーなどから直接イベントを送る方法もありますが、この記事ではその仕組みづくりは扱いません。一方、受付の件数は、フォームの仕組みが内容を受け取り、保存し、担当者に届けた「結果」です。同じ問い合わせを見ているようで、実際には別の場所で、別の条件で数えています。ずれをゼロにすることより、ずれの理由を説明できる状態にし、判断に使える数字を一つ決めることが目標になります。

この記事では、GA4のキーイベント（以前の画面で「コンバージョン」と呼ばれていたもの）と、問い合わせの受付件数を突き合わせるための手順を、担当者が自分で進められる順番で整理します。対象は、自社サイトの問い合わせフォームを持つ小規模な企業や店舗で、計測の設定を制作会社や詳しい社員に頼みつつ、数字の読み方は自分で判断したい方です。

扱う範囲は「件数の整合」と「設定の検証」に絞ります。問い合わせが少ない原因を、訪問・内容・導線・フォーム・計測の五つに分けて広く点検したい場合は、先に問い合わせが来ないときに最初に切り分ける5つの原因を読むと、この記事の位置づけがつかみやすくなります。数字そのものの読み方は集客データの見方で扱っています。この記事は、その五つのうち「計測」の部分を深く掘り下げる続編にあたります。

あらかじめお断りしておくと、GA4の画面のメニュー名や配置は、提供元の更新で変わることがあります。この記事では2026年10月3日時点で確認した公式ヘルプの説明に沿って書いていますが、手元の画面と名前が違う場合は、同じ役割の項目を探してください。また、この記事は実際のGA4の設定作業や、本番のフォームへの送信テストを代行するものではありません。設定の変更は、権限を持つ担当者が自社の判断で行ってください。

問い合わせの「件数」を7つの段に分けて書き出す

件数が合わない原因を探す前に、「問い合わせ1件」という言葉が指しているものを分解します。社内では、次の7つの段が一つの言葉で呼ばれていることがあり、それぞれ記録される場所も、数える人も違います。

この表のうち、1〜3段はブラウザーの中の出来事なので、ブラウザー側の計測で数えやすい段です。4〜7段は、フォームの仕組みや担当者の手元で起きる出来事です。4段目は、受付に成功した応答を合図にイベントを送る作りにすればGA4でも数えられますが、ブラウザー側の記録だけで受付や配送の成功が保証されるわけではありません。6段目と7段目は人の判定が要るため、台帳で数えます。GA4が「問い合わせ」として数えている件数が、どの段の出来事を指しているのかを確かめると、ずれの理由を絞り込みやすくなります。

【公式情報】GA4の拡張計測機能には、フォームの操作を記録する仕組みがあります。公式ヘルプでは、form_start はセッションの中で利用者が最初にフォームを操作したとき、form_submit は利用者がフォームを送信したときに記録されると説明されています（出典1）。それぞれ入力開始とフォーム送信の操作の記録であり、受付や配送の成功を示すものではありません。

【編集部の提案】社内で数字を話すときは、「問い合わせ」という言葉を単独で使わず、「送信の操作」「受付の成功」「有効な新規の相談」のように、段の名前で呼ぶことをおすすめします。会議の資料でも、GA4から取った数字には「GA4の送信イベント」、台帳から取った数字には「受付台帳の件数」と、出どころを必ず書き添えておくと、後で比べるときに混乱しにくくなります。

相談ボタンのクリックと入力開始は、別の数として読む

1段目の「相談ボタンのクリック」と、2段目の「フォームの入力開始」も、よく混同されます。ボタンを押してフォームのページを開いても、入力欄に触れずに戻る人がいます。逆に、トップページの下にフォームが直接置かれているサイトでは、ボタンを押さずにいきなり入力を始める人もいます。そのため、クリックの数が入力開始の数より少ないこともあり得ます。

また、公式ヘルプの説明では、入力開始はセッションの中で最初にフォームを操作したときに記録されます。サイトにフォームが複数ある場合や、フォームの作り方によって記録のされ方が変わることがあるため、自社のフォームでどう記録されるかは、テスト送信で確かめてください。一方、クリックのイベントは、押した回数だけ記録する設定にしていることがあります。二つの数の比を「フォームを開いた人のうち入力を始めた割合」と読むときは、この数え方の違いを頭に置いておきます。【編集部の提案】この二つは、フォームの手前で離れているのか、フォームの中で離れているのかの目安として使い、問い合わせの件数としては扱わないことにすると、話がこじれません。

判断に使う「正本」の段を一つ決める

7つの段をすべて同じ重さで追いかける必要はありません。経営や改善の判断に使う件数は、多くの場合、6段の「重複を除いた件数」か、7段の「有効な新規の相談」です。この二つは人の判定が要るので、受付の台帳で数えます。そこで【編集部の提案】として、問い合わせの件数の「正本」は受付の台帳に置き、GA4は主に「どの経路から来た人が、どの段で止まったか」を見る道具として使う、という役割分担をおすすめします。GA4で受付の成功を数える設計を否定するものではなく、判断に使う数字の置き場所を決めておくための分担です。

GA4の件数を正本にしてしまうと、計測の設定を変えるたびに過去との比較が崩れます。台帳を正本にしておけば、GA4の設定に不具合があった期間も、問い合わせの実数は残ります。この考え方を前提に、以下の手順を進めます。

受付の台帳を先に整える

GA4の設定を確かめる前に、比べる相手である受付の台帳を整えます。台帳が曖昧なままでは、GA4の数字が正しいのか誤っているのかを判断できません。台帳は高価な仕組みでなくてかまいません。表計算のシートに、1件ごとに1行を足していく形で十分です。

受付番号と日時は、人の手で書くより、フォームの仕組みが付けたものを写すほうが確実です。フォームの管理画面から一覧を書き出せる場合は、週に一度、その一覧と台帳を見比べるだけでも、「通知メールは届かなかったが受付はされていた」件を見つけられます。

受付・相談・リードの単位を分けておく

台帳で数える「1件」には、いくつかの単位が混ざりやすいので、先に言葉を決めておきます。【編集部の提案】この記事では、フォームから1通届いたことを「受付」、その中身の用件を「相談」、相談してきた人や会社を「リード」、すでに取引のある相手を「既存客」と呼び分けます。たとえば、同じ会社の担当者が、翌月に別の用件で相談してきた場合、相談としては新しい1件ですが、リードとしては新規ではありません。新規の問い合わせ数を目標にしている場合は、どちらの単位の目標なのかを決め、同じ人や会社を新規のリードとして二重に数えないようにします。

受付の成功と、担当者への到着を分けて確かめる

台帳を作るときに、4段の「受付の成功」と5段の「担当者への到着」を分けておくと、計測とは別の問題が見えてきます。フォームの管理画面には記録が残っているのに、通知メールが担当者に届いていない、という状態も起こり得ます。通知の宛先が退職した人のアドレスのままだった、迷惑メールのフォルダーに振り分けられていた、転送の設定が途中で切れていた、といった理由が考えられます。

この状態では、GA4の件数と台帳の件数が合っていても、問い合わせへの返信が漏れています。【編集部の提案】月に一度は、フォームの管理画面の一覧（受付の成功）と、受信箱に届いた通知の件数（到着）を数えて並べてください。管理画面がないフォームの場合は、制作会社に、受付の記録がどこに残っているかを確かめておきます。計測の点検は、実はこの到着の点検とセットで行うと効果が大きい作業です。

個人の情報はGA4に送らず、件数と時刻で照合する

台帳とGA4を突き合わせるとき、「この人の送信がGA4に記録されたか」を1件ずつ確かめたくなるかもしれません。しかし、メールアドレスや電話番号、氏名、フォームへの入力内容をGA4へ送ることは避けてください。【公式情報】Googleアナリティクスの公式ヘルプは、個人を特定できる情報を送らないよう求めており、ページのURLやキャンペーンのパラメーターに個人の情報が含まれてしまう例にも注意を促しています（出典5）。

たとえば、送信後の完了ページのURLが「…/thanks/?email=…」のように入力内容を含む作りになっていると、ページの表示を記録するだけで、個人の情報がGA4へ送られてしまいます。こうした作りになっていないかは、テスト送信をしたときに、完了ページのアドレス欄を見れば確かめられます。もし入力内容がURLに出ている場合は、計測の設定より先に、フォームの作りを制作会社に相談してください。

【編集部の提案】照合は、個人単位ではなく「日付と時間帯ごとの件数」で行います。たとえば、ある日の台帳に受付が3件、GA4の送信イベントが4件あれば、時間帯を1時間単位に区切って並べ、どの時間帯で数が合わないかを見ます。合わない時間帯が見つかれば、その時間帯に何が起きていたか（テスト送信をした、フォームを修正した、広告を始めた）を作業記録から探します。個人を特定しなくても、ずれが起きた時間帯はこの方法で絞り込めます。

フォームの方式ごとに、確かめる場所が違う

GA4が送信を記録する仕組みは、フォームの作り方によって変わります。自社のフォームがどの方式なのかを最初に確かめておくと、後の点検が早く進みます。方式が分からないときは、テスト送信をしたときの画面の動きで見分けられます。

完了ページ型：表示の回数と受付の回数は同じではない

送信後に完了ページへ移る方式は、計測の設定が分かりやすい方式です。【公式情報】公式ヘルプのチュートリアルでは、既存のページ表示のイベントをもとに、完了ページのURLを条件として新しいイベントを作り、キーイベントとして扱う手順が紹介されています。設定が反映されるまで数分から数時間かかる場合があること、確認にはリアルタイムのレポートを使えることにも触れられています（出典7）。

この方式で気をつけたいのは、完了ページが「表示された回数」と「受付が成功した回数」が一致しない点です。送信した人が完了ページで再読み込みをしたり、ブラウザーの戻る操作で一度離れてまた戻ったり、完了ページをブックマークして後から開いたりすると、表示の回数は増えます。逆に、完了ページへ移る前に画面を閉じた場合は、受付は成功しているのに表示は記録されません。

確かめ方としては、テスト送信の後に完了ページで再読み込みを2回してみて、GA4のリアルタイムのレポートで、キーイベントが何回記録されたかを見ます。3回記録されていれば、再読み込みのたびに数えている状態です。対策は制作会社と相談して決めますが、たとえば完了ページを直接開いた場合は別の画面に戻す作りにする、といった方法が考えられます。

同じ画面型：何を合図に数えるかを決める

送信してもページが移らず、その場で「送信しました」と表示される方式もあります。この方式では、ページの表示を合図にできないため、何か別の合図でイベントを送る必要があります。

拡張計測機能の form_submit が使える場合もありますが、【編集部の提案】フォームの作りによっては期待どおりに記録されない場合があると考え、必ずテスト送信で確かめてください。より確実なのは、フォームの仕組みが「受付に成功した」という応答を返した後に、その応答を合図にしてイベントを送る作りです。こうすると、送信ボタンを押しただけの段階ではなく、受付が成功した段階で数えられます。ただし、この作りはフォームのプログラムに手を入れることになるため、制作会社や開発担当に依頼する内容です。

依頼するときは、「送信ボタンが押されたとき」ではなく「受付に成功した応答を受け取ったとき」に1回だけイベントを送ってほしい、と段の名前で伝えると誤解が減ります。失敗の応答のときに送らないことも、あわせて書いておきます。

外部サービス型：記録できる範囲を先に確かめる

予約サービスや、外部のフォーム作成サービスを使っている場合、フォームそのものが別のドメインにあったり、自社ページの中に別のサイトの枠として埋め込まれていたりします。この場合、自社のGA4のタグを、そのフォームの画面に入れられるかどうかは、サービスの仕様次第です。

【公式情報】複数のドメインをまたいで同じ利用者として数える設定（クロスドメイン測定）は、すべてのドメインで同じウェブのデータストリームの同じタグを使うことが前提で、ドメイン間の移動のときにURLへ「_gl」というパラメーターを付けて情報を引き継ぐ仕組みです（出典6）。つまり、外部サービスの画面に自社のタグを入れられない場合、この設定だけでは計測をつなげられません。

外部サービスを使っている場合の確かめ方は、次の順番です。まず、そのサービスの管理画面やヘルプで、GA4との連携や、送信完了時に自社のページへ戻す設定があるかを調べます。次に、連携がある場合は、テスト送信をして、どの名前のイベントが自社のGA4に届くかを確かめます。連携がない場合は、GA4で送信を数えることは諦め、相談ボタンのクリック（1段目）までをGA4で見て、受付の件数はサービスの管理画面から取る、という分担にします。無理に推測の設定を重ねるより、記録できる範囲をはっきりさせるほうが、判断を誤りにくくなります。

送信の失敗：「押した」と「受け付けた」を分ける

入力の漏れでエラーが出たとき、サーバーが一時的に不調だったとき、送信の途中で通信が切れたときも、送信ボタンは押されています。送信の操作（3段目）だけを数える設定では、これらの失敗も件数に入ります。逆に、受付の台帳には失敗した送信は残りません。GA4のほうが多く出る原因の一つです。

失敗が多いかどうかは、テスト送信で、必須項目を空のまま送ってみると確かめられます。エラーが表示されたのに、GA4のリアルタイムのレポートに送信のイベントが記録されていれば、失敗も数えている状態です。入力エラーそのものが多いフォームは、計測の問題とは別に、使い勝手の問題を抱えている可能性があります。業種の例になりますが、ジムの予約フォームを点検する記事では、入力中につまずきやすい点を整理しています。

二重に数える仕組みを見つける

GA4の件数が受付の件数より明らかに多いときは、同じ送信を2回以上数えている仕組みがないかを疑います。小さな会社のサイトでは、制作の時期や担当者が変わるたびに計測の設定が継ぎ足され、気づかないうちに二重になっていることがあります。

タグを置く方法が二つ重なっていないか

GA4のタグをサイトに置く方法には、ページのHTMLに直接Googleタグを書く方法と、Googleタグマネージャー（GTM）のようなタグ管理ツールを通して置く方法があります。サイトを作り直したときや、担当者が交代したときに、両方の方法でタグが置かれていることがあります。ただし、両方にあるだけで二重に記録されているとは限りません。片方が別の測定IDや別の目的のタグであることもあれば、同じタグが二度動かないように設定されていることもあります。問題になるのは、1回の送信で、同じ測定IDに同じイベントが2回以上送られている場合です。

確かめ方は、テスト送信をしながら、ブラウザーの開発者向けの機能やGA4のデバッグ用の画面で、1回の送信で同じイベントが何回送られたかを見る方法です。慣れていない方は、制作会社に「このサイトのGA4のタグはどこに何か所あるか」と「1回の送信で同じイベントが何回送られるか」の二つを確かめてもらいます。重複が確認できてから直し方を相談します。置き場所を一か所にまとめるのは、後から見る人が迷わないようにするための、この記事の簡素化の一案です。

同じ送信を、別の名前のイベントで二度数えていないか

拡張計測機能の form_submit が記録されている状態で、さらに自作の送信イベントや、完了ページの表示から作ったイベントもキーイベントにしていると、一度の送信で複数のキーイベントが記録されます。キーイベントの一覧を開き、問い合わせに関係しそうなイベントがいくつキーイベントになっているかを数えてください。問い合わせ1件に対して、キーイベントは原則として一つに絞るのが分かりやすい設計です。

【公式情報】Googleの開発者向けリファレンスには、見込み客の獲得に関する推奨イベントとして、問い合わせなどで見込み客が得られたことを表す generate_lead、見込み客が条件を満たしたことを表す qualify_lead、見込み客が顧客になったことを表す close_convert_lead などが載っています（出典2）。推奨イベントは名前と使い方の目安が決まっているので、自社で名前を考えるより、後から見た人が意味を取り違えにくくなります。

【編集部の提案】推奨イベントには金額を添える項目もありますが、問い合わせ1件の価値が分かっていない段階で、仮の金額を入れることはおすすめしません。根拠のない金額が入ると、広告の判断などで実際より価値があるように見えてしまいます。金額は空のまま、件数だけを扱い、価値は台帳の「有効の判定」と、その後の成約の記録で判断します。

段とイベントの名前を対応させておく

キーイベントを一つに絞るときは、7つの段のどれをGA4で数えるのかを先に決め、イベントの名前と対応させておきます。【編集部の提案】小さな会社のサイトなら、次のような対応が分かりやすいはずです。1段目の相談ボタンのクリックは、ボタンの場所が分かる名前の自作イベント。2段目と3段目は、拡張計測機能の form_start と form_submit をそのまま参考の数として残し、キーイベントにはしない。4段目の受付の成功は、受付に成功した応答を合図にした generate_lead を一つだけキーイベントにする。

6段目と7段目の判定は台帳で行う段なので、小さな会社では無理にGA4へ送る必要はありません。qualify_lead や close_convert_lead のような推奨イベントは、受付後の判定を仕組みで送れる体制ができてから検討すれば十分です。その場合も、誰の相談かが分かる情報は送らないことが前提です。対応表は、台帳の別のシートに残しておくと、担当者が替わったときの引き継ぎにも使えます。

キーイベントの数え方：1回ごとか、1セッションに1回か

【公式情報】GA4のキーイベントには、イベントが起きるたびに数える方法（推奨）と、1回の訪問（セッション）の中で何回起きても1回と数える方法があり、どちらになっているかは、作られた経緯によって既定が異なります。数え方を変えた場合は、変更後のデータにだけ適用され、過去のデータは変わりません（出典3）。

ここで混同しやすいのは、この「数え方」と、受付の台帳で行う「重複の判定」は別のものだという点です。1セッションに1回の数え方にすると、同じ訪問の中での再読み込みや連打は1回にまとまります。しかし、同じ人が翌日にもう一度送ってきた場合は、別のセッションなので2回と数えます。逆に、同じ訪問の中で、問い合わせと資料請求の二つのフォームを別々に送った場合、1回にまとまってしまうこともあります。

つまり、GA4の数え方の設定を変えても、台帳と同じ数にはなりません。数え方を変えるのは、二重に数える原因を確かめたうえで、それでも防げない重複を減らしたい場合に限るのがよいでしょう。変更したときは、変更日を作業記録に残し、変更の前後を同じ表で比べないように注意します。

数えられない仕組みを見つける

GA4の件数が受付の件数より少ないときは、逆に、記録されない仕組みを探します。ここでは、設定の誤りではなく、計測という方法そのものの限界によるものも含まれます。

計測の同意と、ブラウザー側の制限

サイトで閲覧の記録について同意を求めるバナーを出している場合、同意しなかった利用者の行動は、設定によっては記録されないか、記録の方法が変わります。また、広告やトラッキングを遮る拡張機能を入れている利用者や、プライバシーの保護を強めたブラウザーを使っている利用者の行動も、記録されないことがあります。

これらは不具合ではなく、利用者の選択や環境によるものです。どの程度の割合が記録されないかは、サイトの利用者の構成によって違い、一般的な数字で決めつけることはできません。【編集部の提案】受付の台帳を正本にしておけば、記録されない分があっても問い合わせの実数は把握できます。GA4の件数は、受付の件数の「何割くらいが見えているか」を月ごとに確かめ、その割合が急に変わった月を点検のきっかけにする、という使い方が現実的です。ただし、全体の割合は、どの端末やどの流入元で記録が欠けているかまでは示しません。

タグが動く前に送信が終わる、またはページが閉じる

ページの読み込みが遅いと、GA4のタグが動き始める前に利用者が送信を終えてしまうことがあります。また、送信の直後に別のページへ移る作りでは、イベントを送る前にページが閉じて、記録が途切れることもあります。こうした取りこぼしは、通信が遅い環境のスマートフォンで起きやすいと考えられます。

確かめるには、自分のスマートフォンで、通信の速さが違う場所（社内のWi-Fiと、モバイル回線）からテスト送信をしてみます。片方でだけ記録されない場合は、タグの置き方やイベントを送る時機について、制作会社に相談します。

内部の通信の除外や、データの絞り込み

社内からのアクセスを除外する設定や、特定の条件のデータを除く設定を入れている場合、社内で行ったテスト送信は記録されません。これは意図した動きですが、テストのときに「記録されない」と勘違いしやすい点です。テストの前に、除外の設定があるかを確かめておきます。

サイトの改修で、きっかけの条件が外れる

完了ページのURLを条件にしてキーイベントを作っている場合、サイトのリニューアルやフォームの差し替えで完了ページのURLが変わると、条件に合わなくなり、ある日から急に記録が0件になることがあります。フォームのサービスを乗り換えたときや、同じ画面型に作り替えたときも同じです。

【編集部の提案】サイトやフォームに手を入れる予定があるときは、作業の完了条件に「テスト送信をして、問い合わせのキーイベントが1回記録されること」を入れておきます。制作会社への依頼文にもこの一文を加えておくと、公開の後で気づく事態を減らせます。週次の照合で件数が急に0件になった場合も、まずこの可能性から確かめてください。

データの反映には時間がかかる

【公式情報】GA4のデータは、処理に24〜48時間かかる場合があり、データが確定する時刻は保証されていません（出典4）。リアルタイムのレポートでは直近の動きを見られますが、標準のレポートや探索の数字は、後から増えることがあります。

【編集部の提案】確定の時刻が保証されていない以上、どこかで区切りを決める必要があります。この記事では運用の目安として、直近の2日分を暫定の数字として扱い、それより前の期間で台帳と比べることにします。これは48時間を過ぎれば確定するという意味ではありません。前週の数字も後から変わる可能性は残るので、気になる差があった週は、翌週の照合のときにもう一度数字を取り直してください。

日付・時差・流入のスコープをそろえる

設定に問題がなくても、比べ方がずれていると件数は合いません。照合の表を作るときに、次の三つをそろえます。

日付の境目と時差

GA4のレポートの日付は、プロパティに設定したタイムゾーンで区切られます。一方、フォームの仕組みやサーバーの記録は、世界標準時で保存されていることがあります。日本時間との差は9時間なので、世界標準時で記録された受付は、日本時間の午前0時から9時までの分が前日の日付になって見えます。

月の境目も同じです。月末の深夜に届いた問い合わせが、GA4では翌月、台帳では当月に入る、ということが起こります。月に数件しか問い合わせがないサイトでは、1件の移動でも割合が大きく変わって見えます。GA4のプロパティのタイムゾーンと、受付の記録のタイムゾーンを、台帳の列名に書いておきましょう。

期間の指定と、比べるレポート

GA4には、標準のレポート、探索、リアルタイムなど、いくつかの見方があります。同じ期間を指定しても、見ている指標や集計の単位が違うと、数字が合わないことがあります。照合に使うレポートと指標を一つに決め、毎回同じ手順で数字を取ります。手順は台帳の別のシートに、画面の名前と操作の順番を書いておくと、担当者が替わっても同じ数字を取れます。

流入元のスコープ

「広告から来た問い合わせは何件か」のように、流入元ごとの件数を比べるときは、スコープの違いにも注意します。GA4では、そのユーザーが最初に来たときの流入元で見る方法と、その訪問（セッション）の流入元で見る方法などがあり、どちらで見るかで、同じキーイベントがどの流入元に入るかが変わります。【公式情報】公式ヘルプでは、流入元の項目にユーザー・セッション・イベントの3つのスコープがあり、イベントのスコープの項目には、選んでいるアトリビューションモデルが反映されると説明されています（出典8）。

たとえば、最初は検索から来て、数日後に広告から来て問い合わせた人は、最初の流入元で見れば「検索」、訪問の流入元で見れば「広告」に入ります。どちらが正しいということではなく、何を確かめたいかで選びます。【編集部の提案】訪問（セッション）の流入元は、問い合わせた訪問がどの経路から始まったかを確かめるのに向きます。広告などの施策が問い合わせのキーイベントにどれだけ貢献したかを比べたいときは、イベントのスコープの項目を使い、アトリビューションモデルや対象期間などの条件をそろえてから比べます。どの見方でも、GA4の件数だけで広告の優劣を決めず、広告の実費と、台帳で有効と判定した受付まで照合してください。どの経路で会社を知ったかを見たいなら最初の流入元、のように、目的と見方を一緒に記録しておくと混乱しません。

さらに、外部サービス型のフォームで、クロスドメイン測定がつながっていない場合は、送信の記録の流入元が、自社サイトからの参照として記録されることがあります。流入元ごとの件数が不自然に偏っている場合は、この点も疑ってください。

切り分けの手順と、担当・完了条件

ここまでの点検を、実際に進める順番に並べます。この記事では、受付担当、Webの担当（または制作会社）、数字を見て判断する責任者の三者で分担する形を想定します。それぞれの段に、誰が担当し、何ができたら完了かを決めておくと、点検が途中で止まりにくくなります。

順番には理由があります。台帳（1）を先にするのは、比べる相手がないと点検が進まないからです。方式の特定（2）とキーイベントの書き出し（3）は、テスト送信（4）の前に、何が起きるはずかを予想しておくためです。予想と違う結果が出たときに、初めて二重計測（5）や取りこぼしの点検に進みます。比べ方の統一（6）は、設定に問題がなくても件数がずれる原因を取り除く段階です。最後に、判断に使う数字（7）を決めます。

制作会社や開発担当への依頼文の例

手順の2〜5は、制作会社や開発担当の協力が必要になることが多い段です。依頼するときは、「GA4の数字がおかしいので見てほしい」とだけ伝えると、何をどこまで確かめればよいかが相手に伝わらず、やり取りが何度も往復しがちです。【編集部の提案】次のように、知りたいこと、分かっていること、完了の形を分けて書くと、相手も見積もりや作業の範囲を決めやすくなります。

依頼文には、問い合わせをした人の氏名や連絡先、本文の内容を貼り付けないでください。照合に必要なのは、件数と時刻、テスト送信の記録で足ります。どうしても特定の1件を確かめる必要があるときは、受付番号だけを伝え、内容は社内の台帳の権限の中で確認してもらいます。

テスト送信の作法

テスト送信は、点検の中心になる作業ですが、本番のフォームを使うため、いくつかの決まりを設けておきます。

• 送信する前に、受付担当に「何時ごろにテストを何件送る」と伝え、本物の問い合わせと取り違えないようにする
• 入力内容には、実在の人の氏名や連絡先を使わず、社内で決めたテスト用の名前と、社内で管理しているテスト用の受信先を使う。本文の先頭に「テスト」と書く
• 送信した時刻を分単位で記録し、受付の台帳では重複の判定を「テスト」にして、件数から除く
• GA4では、リアルタイムのレポートやデバッグ用の画面で、イベントの名前と回数を確かめる。社内の通信を除外する設定がある場合は、その影響を考える
• 成功の送信だけでなく、必須項目を空にした失敗の送信、完了画面での再読み込みも試す

テスト送信の結果は、次の表のような形で記録しておくと、制作会社に相談するときにそのまま渡せます。

架空の例で見る、ずれの理由

ここからは、ずれの理由をつかむための架空の例を3つ紹介します。いずれも説明のために編集部が作った例で、実在の会社やサイトの数字ではありません。また、例の中で「未取得」と書いた項目は、その時点で分かっていない情報です。推測で埋めずに、分からないものは分からないと残すことも、点検の大切な作法です。

架空の例A：完了ページ型で、GA4のほうが多い整体院

ある整体院のサイトでは、4週間でGA4のキーイベントが28件、受付の台帳には18件の予約の申込みが記録されていました。フォームは送信後に完了ページへ移る方式です。

テスト送信をしたところ、完了ページで再読み込みをするたびにキーイベントが増えることが分かりました。さらに制作会社に確認すると、2年前のリニューアルのときにタグ管理ツールを導入したが、ページに直接書いたタグも残っている、という回答でした。制作会社がテスト送信で通信を確かめたところ、1回の送信で同じ測定IDに同じイベントが2回送られていました。

この例で分かっていることは、再読み込みで増えることと、1回の送信で同じイベントが2回送られていることです。一方で、28件と18件の差の10件のうち、何件がタグの重複によるもので、何件が再読み込みによるものかは未取得です。過去のデータは設定を直しても変わらないので、この内訳は今後も分からないままです。対応としては、タグを一か所に寄せ、完了ページを直接開いたときの扱いを制作会社と決めたうえで、変更日以降の4週間で改めて照合することにしました。

架空の例B：同じ画面型で、GA4のほうが少ない工務店

ある工務店のサイトでは、4週間でGA4の送信のイベントが3件、受付の台帳には11件の問い合わせがありました。フォームは送信してもページが移らず、その場に「送信しました」と表示される方式です。

キーイベントの一覧を見ると、拡張計測機能の送信のイベントだけをキーイベントにしていました。テスト送信をしてみると、成功しても送信のイベントが記録されない場合があり、記録されたのは入力エラーの後に送り直したときだけでした。原因の詳しい仕組みは未取得ですが、少なくとも今の設定では、受付の成功を数えられていないことは分かりました。

対応として、制作会社に「受付に成功した応答を受け取ったときに、1回だけ generate_lead を送る」作りを依頼し、拡張計測の送信のイベントはキーイベントから外すことにしました。作業の費用と日程は、制作会社からの見積もり待ちで、この時点では未取得です。設定が終わるまでの間は、台帳の件数だけで判断することを社内で共有しました。

架空の例C：外部の予約サービスで、件数は合うが経路が合わない学習教室

ある学習教室では、体験授業の申込みに外部の予約サービスを使っています。予約サービスにはGA4との連携機能があり、4週間の件数は、GA4が9件、予約サービスの管理画面が10件と、ほぼ合っていました。

ところが、流入元ごとに見ると、9件のうち7件が自社サイトからの参照として記録されていて、検索や広告から来た申込みがほとんど見えませんでした。予約サービスのヘルプを確かめると、自社サイトと予約サービスのドメインをまたいで同じ利用者として数える設定には対応していないことが分かりました。

この例では、件数はおおむね使えるが、経路の判断には使えない、という結論になります。1件の差の理由は未取得です。対応として、経路の判断は、自社サイトで「体験授業を申し込む」ボタンがどのページで押されたか（1段目のクリック）で行い、件数は予約サービスの管理画面を正本にすることにしました。

3つの例に共通するのは、「GA4の数字を直す」より先に、「受付の台帳を正本にして、GA4に何を見させるかを決め直す」ことで、判断が前に進んでいる点です。

7日と28日で、直したことを確かめる

設定を直した後は、本当に直ったかを数字で確かめます。ただ、問い合わせの件数が少ないサイトでは、短い期間の数字だけで判断すると誤りやすくなります。【編集部の提案】次のように、期間ごとに確かめることを分けておきます。

7日の確認は、不具合を早く見つけるためのものです。たとえば、直した後の1週間で台帳に5件、GA4に0件なら、何かがまだ動いていないと分かります。一方、台帳に5件、GA4に4件だった場合、その差が誤差なのか不具合なのかは、7日では判断がつきません。

28日の確認では、台帳の件数に対して、GA4でどれくらいの割合が見えているかを見ます。この割合が月ごとに大きく変わらなければ、GA4の件数を、全体の推移を見る参考値として使い続ける判断材料になります。

ただし、全体の割合が安定していても、流入元ごとの比較が正しいとは限りません。記録が欠ける分が、特定の端末や流入元に偏っている可能性があるからです。たとえば、計測に同意しない人や、トラッキングを遮る環境の人がある経路に多ければ、その経路だけ少なく見えます。外部サービス型のフォームのように、経路そのものが途中で切れることもあります。さらに、問い合わせが月に十数件ほどの規模では、流入元ごとに分けると1経路あたり数件になり、1件の増減で割合が大きく動きます。【編集部の提案】流入元の比較は、件数が少ないうちは傾向の参考にとどめ、台帳の側で「何を見て知ったか」を相談の受付時に聞くなど、別の情報と照らし合わせて判断してください。

逆に、全体の割合が大きく変わる場合は、設定の変更、同意の取り方の変更、フォームの改修など、何かが変わった可能性があるので、作業記録と照らし合わせます。

週に一度の照合を、短い定例にする

点検を一度で終わらせず、週に一度、決まった曜日に照合する定例にしておくと、設定の不具合やフォームの故障に気づきやすくなります。定例の作業は、台帳の前週分の件数を数え、GA4から同じ期間の件数を取り、照合のシートに1行足すことです。【編集部の提案】たとえば週に10分ほどの確認の枠を決めておく、という運用が一例です。実際の所要時間は台帳の状態やフォームの数で変わりますし、最初の台帳の整備や、ずれが見つかったときの調査は、この枠とは別の作業として時間を取ってください。

この記入例では、第2週だけGA4の件数が台帳を大きく上回っています。その週にフォームの文言を修正していたので、修正の作業の中でタグやイベントの設定が変わった可能性を疑い、テスト送信をやり直す、という判断につながります。「見えている割合」は、重複などを除いた台帳の件数に対するGA4の件数の比で、ここでは参考の目安として使います。件数が少ない週は割合が大きく振れるので、1週だけの数字で結論を出さず、28日の単位で落ち着いているかを見てください。

広告の管理画面の件数は、さらに別の数として扱う

GA4のキーイベントを広告の管理画面に取り込んで使っている場合、広告の管理画面に出る件数は、広告側の設定で数え方や集計の期間が別に決まります。そのため、GA4の件数とも、受付の台帳の件数とも、そのまま一致しない場合があります。【編集部の提案】広告の判断に使う数字の出どころも、照合のシートに一列足して記録しておくと、広告の担当者や運用会社と話すときに、どの数字の話をしているのかを取り違えずに済みます。広告の予算を決める前の数字の整理は、広告予算を決める前に、予約・問い合わせまでの数字を整理するで扱っています。

また、どの期間で見る場合も、変更日をまたいで比べないこと、直近の2日分は暫定の数字として扱うことを守ります。問い合わせが月に数件しかない場合は、割合の比較そのものが不安定になるため、件数の推移を台帳で見ることを優先してください。改善の施策そのものの効果を見る方法は、問い合わせを増やすWeb改善ガイドの手順と組み合わせると進めやすくなります。

GA4でできないこと、させないほうがよいこと

計測を整えても、GA4に任せられないことがあります。役割を最初に線引きしておくと、無理な設定に時間を使わずに済みます。

• 問い合わせが有効な新規の相談かどうかの判定。営業メールや既存客の連絡、採用の応募は、GA4の画面からは見分けられません
• ブラウザー側の記録だけで、受付や配送の成功を保証すること。送信の操作が記録されても、受付の仕組みが内容を保存し、担当者に届いたことまでは示しません。受付の成功の応答を合図にする作りにしても、担当者への到着は別に確かめます
• 個人単位の照合。個人を特定できる情報をGA4へ送らないことが前提です
• 過去のデータのやり直し。数え方や設定を変えても、過去の記録は変わりません
• 外部サービスの画面の計測。サービスの仕様でタグを置けない場合、設定だけでは解決できません
• 問い合わせの金額の価値。根拠がない段階で仮の金額を入れると、判断を誤らせます
• 計測の完全さ。同意や利用者の環境によって記録されない分は、一定程度残ります

これらは、受付の台帳と担当者の判断が受け持つ範囲です。この記事の役割分担では、GA4は、どの経路から来た人が、どのページを見て、どの段で止まったのかを見る道具として使います。

再送・重複・例外の扱いを、台帳のルールにする

受付の台帳を正本にするなら、どの送信を1件と数え、どれを除くかのルールを決めておく必要があります。ルールがないと、担当者によって件数が変わり、月ごとの比較ができなくなります。【編集部の提案】次の表は、判定のルールの例です。自社の業務に合わせて変えてください。

新規のリードを数えるときは、相手の区分の列で、同じ人や会社を二度数えていないかを確かめます。また、重複の判定は、GA4のキーイベントの数え方とは別の作業です。GA4の数え方を1セッションに1回にしても、翌日の再送は別に数えられますし、別の内容の相談がまとまってしまうこともあります。重複の判定は台帳で行い、GA4にはその役割を持たせない、と分けておくと迷いません。

再送が多い場合は、計測の問題ではなく、送信後の案内が足りない可能性があります。完了画面や自動返信で、いつごろ連絡するかを伝えているかを確かめてください。案内の書き方や返信の流れは、問い合わせ導線チェックの返信の区分でも点検できます。

登録不要で使える、件数照合のチェック表

最後に、この記事の点検をまとめたチェック表を載せます。印刷するか、表計算に写して、上から順に記入してください。これは自分で記入して使う資料で、誰かが所見を返すものではありません。記入の結果を見て、自社だけでは判断がつかない点が残った場合に、制作会社や詳しい担当者に相談する材料として使ってください。

チェックがつかなかった項目は、上の「切り分けの手順」の表のどの段に当たるかを確かめ、担当と完了条件を決めてから進めてください。全部に一度にチェックをつける必要はありません。台帳の4項目から始めるだけでも、数字の信頼性は大きく変わります。

まとめ：数字を合わせるより、役割を決める

GA4の問い合わせのコンバージョン（キーイベント）と、受付の件数が合わないとき、最初にすることは、GA4の設定を触ることではなく、「問い合わせ」という言葉を段に分け、受付の台帳を正本として整えることです。そのうえで、フォームの方式を特定し、テスト送信で成功・失敗・再読み込みの記録を確かめ、二重に数える仕組みと、数えられない仕組みを順に点検します。比べ方の時差・期間・スコープをそろえれば、残ったずれの多くは、理由を説明できるずれとして扱えるようになります。

GA4でも、受付の成功を合図にしたイベントを数えることはできます。ただ、ブラウザー側の記録だけでは受付や配送の成功までは保証されず、記録が欠ける分も残ります。判断に使う件数の正本は台帳に置き、GA4は主に、どこから来た人がどこで止まったかを見る道具として使う。台帳とGA4の役割をこのように分けておけば、計測の設定が完全でなくても、判断を止めずに済みます。

点検の結果、問い合わせが少ない原因が計測ではなく、ページの内容や導線にありそうだと分かった場合は、問い合わせが来ないときに最初に切り分ける5つの原因に戻って、ほかの段を確かめてください。数字の読み方を社内でそろえたい場合は、集客データの見方が役に立ちます。

この記事の内容は、Akatsuki編集部の実務の提案であり、特定のサイトで効果を測った結果ではありません。点検を進めても自社だけで判断がつかない点が残った場合は、記事の下にある相談の窓口から、希望される方だけご連絡ください。返信までの日数や、相談の結果としての成果をお約束するものではありません。