Frontend Craft Labフロントエンド開発の実験場
← 記事一覧に戻る
google-analytics

GA4でフォーム送信数を月別集計する方法

複数フォームの異なるイベント名を統合する必要性

Googleアナリティクス4 (GA4) ではイベントベースの計測モデルを採用しており、同種のアクションはイベント名を統一することが推奨されています。フォーム送信の計測でも、本来は全フォームで共通のイベント名（例: form_submit あるいは推奨イベントの generate_lead など）を使い、フォームの種類や場所はパラメータで区別するのが理想です。

しかし既に各ページやフォームごとに「form_submit_1」「contact_send」「entry_complete」などイベント名がバラバラの場合、そのままではサイト全体の送信数を集計しづらくなります。こうしたバラバラなイベント名は統合・正規化することで、月次の合計件数を正確に把握しやすくなります。

対処方法の概要:

  1. イベント名を統一する: GA4の管理画面からイベント名を変更・生成するか、GTMで送信イベントのタグを共通化します。
  2. イベントパラメータで詳細を付加: 統一したイベントにフォーム識別のパラメータ（フォームIDや名前など）を付与すれば、後からフォーム別内訳も分析可能です。
  3. 過去データの扱い: イベント名の統一は新規データに適用され、履歴データには遡及しません。過去分を集計する際は、探索レポートやBigQueryでイベント名を条件指定してグルーピングします。

以上を踏まえ、次章以降でイベント名のグルーピングと月次集計の具体策、およびGTMでの統一管理、正確な計測の注意点について解説します。

イベント名のグルーピングと月次集計方法

異なる名称のフォーム送信イベントをまとめて月別集計する方法として、GA4の探索レポート、BigQuery連携、カスタムディメンション/指標の活用などが考えられます。それぞれの手法について説明します。

GA4探索レポートによる月次集計

GA4の探索（Explorer）を使えば、複数イベントをグルーピングして期間別に集計できます。まず探索でディメンションに「月」を追加し、行に配置します。GA4では「月」ディメンションが2種類あるため、正しい方（例えば月（YYYYMM形式）など）を選択してください。列や値にはイベント数（Event count）を設定します。

次にフィルタで対象イベントを絞ります。フィルタ条件でイベント名が「form_submit_1」「contact_send」「entry_complete」等いずれかに一致するよう設定します（複数条件のOR指定が可能です）。これにより、それらイベントの合計イベント数が抽出されます。フィルタを工夫すれば、キーイベント（コンバージョン）に設定していないイベントでもそれぞれの件数を把握できます。例えば各流入経路別にセッション数とフォーム送信数（月別）を一覧表示する、といったレポートも作成可能です。

ポイント:

  • GA4探索では期間を月単位にまとめる場合、ディメンション「月」を使います。期間指定は画面右上の日付範囲で月初〜月末を選択すればOKです。
  • フィルタ条件として正規表現を使う方法もあります。イベント名が一定のパターン（例: "form|contact|entry"を含む 等）なら正規表現フィルタで一括抽出できます。
  • グラフ表示も可能です。折れ線グラフに月を軸、イベント数を値として可視化すれば、月次推移がひと目で分かります。

このように探索レポートを使えば、複数イベントをグルーピングしてもサンプリングなしで正確な件数を確認できます。また、キーイベント（コンバージョン）に設定しなくても送信完了数を把握できるので、「サイト目標のみキーイベントに設定する」という原則も保てます。

BigQueryによるイベント集計

さらに精緻に分析したい場合や社内レポートに組み込みたい場合、GA4のBigQuery連携を活用する方法があります。GA4プロパティをBigQueryにリンクすると、ユーザーのあらゆるイベント（ページビュー、クリック、フォーム送信など）が生データとしてエクスポートされます。これを使ってSQLクエリで自由に集計・正規化が可能です。

BigQuery集計の例:

SELECT 
  FORMAT_DATE('%Y-%m', PARSE_DATE('%Y%m%d', event_date)) AS month,
  COUNT(*) AS total_form_submissions
FROM `プロジェクト名.データセット名.events_*`
WHERE event_name IN ('form_submit_1', 'contact_send', 'entry_complete')
GROUP BY month
ORDER BY month;

上記のようなクエリにより、指定したイベント名の発生数を月単位で合計できます。event_date（YYYYMMDD形式の日付文字列）から月を抽出し、event_name IN (...)で対象イベントを複数指定しています。実行結果は各月のフォーム送信数一覧となります。

メリット: BigQueryでは生データに対して任意の条件で集計できるため、イベント名の正規化も柔軟です。例えばCASE文を用いて複数イベント名を「form_submit_all」という擬似イベント名にマップして集計することも可能です。GA4 UI上では困難な過去データの再集計や、送信数と他のデータ（例: Recaptcha通過可否フラグなど）の統合分析も行えます。

なお、GA4→BigQuery連携の設定はGA4管理画面の「BigQuery のリンク」から行います。一度設定すれば以降日次でデータが自動エクスポートされます。

注意点: BigQueryのクエリ実行には多少のコストが発生しますが、フォーム送信数の月次集計程度であればごく少額（数センティ～数十円規模）です。必要に応じて結果をLooker Studio（旧称: Data Studio）に接続し、自動レポート化することもできます。

カスタムディメンション/指標を利用した正規化

GA4のカスタム定義（カスタムディメンションやカスタム指標）を使ってイベント名をグルーピングする方法もあります。たとえば、以下のアプローチが考えられます。

  1. カスタムイベントの作成: GA4管理画面の「イベントを作成」で、複数の既存イベントをまとめる新しいイベントを定義します。条件として「event_name が form_submit_1 または contact_send または entry_complete のとき」、新イベント名「all_form_submit」を発火、と設定できます。これにより今後は各送信時に「all_form_submit」イベントも記録されます（元のイベントも残ります）。この新イベントをコンバージョン（キーイベント）に設定すれば、GA4標準レポートのコンバージョン列で月次件数を確認できます。※過去データには適用されない点に留意してください。

  2. イベント名のリネーム（Modify Event）: GA4の「イベントを修正」機能を使い、受信データ上でイベント名を置き換えることも可能です。例えば、マッチ条件に上記3つのイベント名を指定し、アクションでevent_nameを「form_submit」に変更する設定を追加します。これで今後は3種すべてGA4上では「form_submit」という統一名で扱われます。ベストなのはタグ送信側で直すことですが、開発リソースが不足する場合の一時的な救済策として有効です。

  3. カスタムディメンション・指標: GTMやサイト側で、フォーム送信イベントに共通のイベントパラメータ（例: form_category: "submission" や form_submit_count: 1）を付与し、GA4でそれをカスタムディメンション/指標として定義する方法です。実装例として、あるフォーム送信イベント発生時にパラメータcontact_submit_count=1を送り、この値をイベント集計用のカスタム指標として登録すれば、GA4探索でその指標を列に配置することで当該イベントの発生数を直接表示できます。この方法では各種フォーム送信イベントそれぞれに異なるカウント用パラメータ名を付ける必要がありますが、探索内で個別の列に値を出せる利点があります（ただしプロパティあたり50件の上限に注意）。単に全フォーム送信の合計数だけ知りたい場合は、ここまで細かく設定しなくても探索フィルタだけで十分です。

以上のように、GA4自体の機能でもイベント名の正規化・集計は可能です。手軽さで言えば探索レポートでフィルタ集計する方法が第一選択でしょう。一方、社内で継続的にモニタリングしたい場合はBigQuery＋SQLやカスタム指標で仕組みを作るのも有効です。それぞれの状況に応じて使い分けてください。

GTMを用いたフォーム送信イベントの一元管理

Googleタグマネージャー (GTM) を使って、サイト上のフォーム送信トラッキングを共通の仕組みで一括管理することも可能です。フォームごとにバラバラのタグを仕込む代わりに、共通トリガーと共通GA4イベントタグを設定することで、全フォームから同一のイベント名を送信できます。この方法ならフォームの構造や実装方法が多少異なっていても、安定して計測できる可能性が高まります。

共通トリガーの設定

  1. フォーム送信トリガーの利用: GTMにはあらかじめ「フォームの送信」トリガータイプがあります。これを使用すると、ページ上でフォームが送信されたタイミングを検出できます。GTMの管理画面で「トリガー」→「新規」からトリガータイプに「フォームの送信」を選び、サイト全体または特定ページで発火するよう設定します。トリガー設定内の「[妥当性をチェック]」オプションをオンにすると、フォームが正しく送信完了した場合のみ発火します（無効にするとユーザーが送信を試みた段階でも発火します）。通常はチェックをオンにしておくことで、送信エラー時のカウントを防ぐことができます。

    補足: フォーム送信後にページ遷移（例: サンクスページ表示）がある場合は基本的にこのトリガーで検知できます。ただし、開発側でevent.preventDefault()を使ったAjax送信が行われていると、このトリガーは「妥当性をチェック」オンの場合発火しない可能性があります。その場合は次項のアプローチが有効です。

  2. クリックトリガーの利用: フォームが通常の要素ではなくボタン押下で送信処理を行う場合などは、「要素のクリック」トリガーで代用できます。送信ボタンに共通のテキストやCSSセレクタがあるなら、それを条件に全送信ボタンのクリックを捕捉します。ただしクリックだけでは不十分なケースもあります。ユーザーがボタンをクリックしてもフォーム検証エラーで送信されないことがあり、その場合クリックイベントを発火させると未送信の試行までカウントされてしまう可能性があります。したがってクリックトリガーを使う場合は、後述の確認方法と組み合わせることが重要です。

  3. 要素の表示トリガーの利用: フォーム送信後にページ内に表示されるサンクスメッセージや確認要素に着目する方法です。例えば「送信ありがとうございました」というメッセージや、送信完了時に現れる特定の要素などをターゲットに、GTMの「要素の表示」トリガーを設定します。この方法なら、その要素が実際に表示された（＝フォーム送信が成功した）場合にのみイベントを発火できます。入力不備で送信が行われなかった場合は確認メッセージも出ないため、確実に送信成功時だけカウントできます。フォームの構造がページごとに違っていても、各ページの完了メッセージ要素さえ指定すれば適用できる汎用的なアプローチです。

以上のいずれか、または組み合わせで全フォーム送信を捉えるトリガーを構築します。具体的には、まず通常のフォーム送信を拾えるトリガーをセットし、漏れるケース（Ajax送信等）は要素表示トリガーで補完すると良いでしょう。

GA4イベントタグの設定

次に、上記トリガーに紐付けるGA4イベント送信タグを用意します。タグマネージャーで新規タグを作成し、以下を設定します。

  • タグタイプ: GA4イベントタグ（既にGA4設定タグがある前提で）
  • イベント名: 例えば "form_submit" と統一した名前を指定。GA4の推奨イベントに「form_submit」（拡張計測の自動収集イベント名）がありますが、重複を避けるなら "form_submit_custom" や "lead_form_send" など任意の名称にしても構いません。
  • イベントパラメータ: 必要に応じてフォーム識別のパラメータを追加します。例えば form_name や form_id を変数で取得して送ることで、どのフォームから送信されたか後で区別できます。GA4拡張計測の自動イベントでもform_idやform_destinationなどがパラメータとして取得されるので、それらに合わせても良いでしょう。
  • トリガー: 作成した共通フォーム送信トリガーを適用します。複数トリガー（例えば通常のフォーム送信＋要素表示）を使っている場合、それぞれにこのタグを割り当てます。同一タグに複数トリガーを与えれば、いずれかが発動したときタグが実行されます。

この設定により、サイト内のどのフォームが送信されても常に一貫したイベント名でGA4に記録されるようになります。結果、GA4上での集計もシンプルになり、「イベント名＝フォーム送信」のイベント数を月別に見るだけで全フォームの合計送信数を把握可能となります。

さらにGA4側でこのイベント名をコンバージョン（キーイベント）にマークしておけば、標準レポートのコンバージョン列でも全体数を確認できます。ただし前述のとおりコンバージョン指標は全コンバージョン合算値なので、他にもキーイベントがある場合は探索やBigQueryで個別集計する方が明確です。

備考: GA4には2022年以降、拡張計測機能として「フォームの操作」の自動検出が導入されています。データストリーム設定で「フォームの操作」をONにすると、サイト上のフォーム開始（form_start）と送信（form_submit）が自動でイベント収集されます。ただし現状、この自動検出は対応状況にムラがあり、必ずしも全フォームで動作するとは限りません。既にGTMで独自送信イベントを設定済みの場合、二重計測になる恐れもあります。そのため、導入済みサイトではGTM経由で統一イベントを送る方法が確実と言えるでしょう。

正確な送信数カウントのための注意点（Recaptcha課金対策）

最後に、フォーム送信数を正確かつ過不足なく計測する上での注意事項を整理します。これは背景にある「Recaptchaの課金ティア検討」の文脈でも重要です。Recaptcha（特にEnterprise版）は月ごとの検証（assessment）回数に応じて料金ティアが変動します。たとえば月1万回までは無料、10万回までは一律8ドル、その後は1,000回ごとに1ドルという料金体系です。したがって送信数を過大に数えれば不要なコスト見積りにつながり、過少ならセキュリティ予算の不足リスクがあります。正確な計測のため、以下の点に留意してください。

  1. 二重カウントの防止: 1回のフォーム送信につきイベントが複数回発火しないようにします。例えばGTMのクリックトリガーとフォーム送信トリガーが両方作動すると二重計測になります。共通タグを使う場合も、1送信でタグが重複発火しないようトリガー条件を調整しましょう（通常は同一タグに複数トリガーを紐付けても、実際の動作はどちらか一方のタイミングで1回送信するだけです）。また、フォーム送信後にリダイレクトでサンクスページに飛んだ際、そのページで別の送信完了イベントを発火させている場合も要注意です。イベント発火のタイミングを統一し、「送信動作」か「サンクス到達」かどちらか一方に絞ることで二重カウントを避けます。

  2. 未送信の除外: フォームエラーやユーザーキャンセルによる送信未完了はカウントしないようにします。前述のようにGTMトリガーで「妥当性をチェック」を有効にする、送信完了の確認要素ベースでトリガーを発火する等の対策で、実際に送信が完了した場合だけイベント計測される仕組みにします。これにより「送信ボタンは押されたがエラーで送れなかった」といったケースを除外できます。

  3. 漏れのない実装: すべてのフォームが計測対象になっているか確認しましょう。サイト内にGTMで捕捉していないフォームや、第三者提供の埋め込みフォームなどがあると、その送信はカウント漏れになります。必要に応じて開発者に協力を仰ぎ、埋め込みフォームからdataLayer.pushでイベントを送信してもらうなどの対策も検討してください。デバッグモードやGA4のリアルタイムレポートで主要なフォーム送信が確実にイベントとして記録されることをテストするのが望ましいです。

  4. 集計期間の整合: Recaptchaの課金はおそらく**月単位（暦月）**で区切られるため、GA4側の集計期間もカレンダーマンスで見ます。月をまたいだ集計やタイムゾーンの違いに注意し、GA4プロパティの時差設定が実運用と合っているか確認してください。例えば日本時間での月次なら、GA4プロパティがJST設定であれば問題ありません。

  5. Recaptcha動作との乖離: 厳密には、Recaptchaの「評価（assessment）」回数とフォーム送信数が1対1で一致しない場合があります。例えばRecaptcha v3ではユーザーがフォームページを開いた時点でトークンを取得し、その後送信時に評価が行われるケースがあります。この場合ユーザーが送信ボタンを複数回押せば評価も複数回実施され得ます。しかし通常、送信完了イベントは1回しか発生させません。Recaptcha側のカウントとGA4上の送信数に差異が出る場合は、その理由（再送信やボットアクセスなど）を考慮に入れてください。とはいえ大半の正規ユーザー操作では1送信1評価でしょうから、送信完了数をもっておおよそのRecaptcha利用回数と見なして問題ないはずです。

以上を徹底することで、過剰でも不足でもない正確なフォーム送信数が計測できます。そのデータをベースに、例えば「月1万件程度なので当面無料枠内だが、月10万件を超えるようなら次のティア（8ドル/月）を検討しよう」といった判断が可能になります。

まとめ

GA4でサイト全体のフォーム送信数を月次集計するには、まず異なるイベント名を統合・正規化することが重要です。GA4探索レポートで月ディメンション×イベント数をフィルタ集計する方法が手軽で、必要に応じてBigQueryで高度なクエリ分析もできます。イベント名の統一は、可能であればGA4の設定変更やGTMでの共通タグ送信によって今後のデータを整理すると良いでしょう。特にGTMを使えばフォーム構造の違いを超えて一元的な計測が可能です。最後に、Recaptchaコスト検討のためには数え漏れや二重計測を防ぎ、適切な数値を得ることが大切です。これらのポイントを押さえて実装・集計すれば、GA4上でフォーム送信数を正確に把握し、月次の変動や累計をレポートできるようになるでしょう。