作成: IILL Editorial。イベント名と成功条件はサイトごとの計測契約に合わせて検証してください。

ランディングページの成果はCTAを押した瞬間ではなく、サーバーが問い合わせを 正常に受け付けた瞬間に計測します。クリック、送信試行、成功、失敗を一つに まとめると問い合わせ数が膨らみ、フォーム障害も見つけにくくなります。

最小の実務フローはpage_view → contact_click → submit_intent → submit_successです。 失敗はsubmit_failureとして成功とは別に見ます。

各段階の意味を決める

段階 イベント例 発生条件 主要成果か
訪問 page_view ランディングページが表示された いいえ
関心 contact_click フォーム、電話、メールのCTAを使った いいえ
送信意図 contact_form_submit_intent 有効なリクエストを送る直前 いいえ
受付成功 contact_form_submit_success サーバーが保存・送信を確認した はい
受付失敗 contact_form_submit_failure 入力、通信、サーバーで失敗した いいえ

GA4はフォームや情報リクエストを送信したときにgenerate_leadを使うことを推奨して います。この意味が組織の報告基準に合う場合に使ってください。このサイトでは、 サーバーが受付を確認した成功だけを完了した問い合わせとします。送信を試みても 保存や配信に失敗したものは問い合わせではありません。サーバー確認後に generate_leadを送るか、既存の成功イベントを維持して対応関係を文書化します。

イベント → キーイベント → Google Adsコンバージョン

これは別々の三段階です。

  1. イベント:サーバー確認後にサイトがcontact_form_submit_successを送ります。
  2. キーイベント:GA4で、このイベントを事業上重要な行動として指定します。
  3. Google Adsコンバージョン:GA4とGoogle Adsを連携している場合、このキー イベントを広告計測や、設定に応じた入札に使うコンバージョンとして作成または インポートします。

三段階で同じサーバー確認済みの結果を使います。データ量が多いという理由でCTA クリックを昇格させると、問い合わせではなくクリックを最適化します。ただし、 アトリビューション、集計期間、タイムゾーン、設定の違いでGA4とAdsの合計は異なる ことがあるため、利用したイベントと設定を記録してください。

クリックだけを成果にすると何がずれるか

CTAを押した後も、次の理由で問い合わせは完了しないことがあります。

  • 必須項目のエラーが出る。
  • 通信が切れる。
  • サーバーがエラーを返す。
  • 保存やメール配信が失敗する。
  • 連続クリックで同じリクエストが重複する。

クリックだけを数えるとキャンペーンは成功したように見えても担当者には何も 届きません。クリックは文言とCTA配置を診断する指標として残し、確認済みの成果だけを キーイベントにします。

実装の順序

1. 共通情報を小さくする

localepage_typecontent_groupui_locationcontact_methodのように 報告で使う値だけを送ります。変化し続けるボタン文言や自由入力をカスタム ディメンションにしません。

gtag("event", "contact_click", {
  locale: "ja",
  page_type: "landing_page",
  ui_location: "hero",
  contact_method: "form"
});

2. 有効な送信を始める直前に意図を記録する

ブラウザーの入力確認を通過し、実際の送信を始める直前に一度記録します。送信 ボタンのクリックだけでは、キーボード送信と入力エラーを正確に分けられません。

3. サーバー応答後に成功と失敗を分ける

成功応答後にcontact_form_submit_successを送ります。失敗は contact_form_submit_failureへ制限した結果分類だけを付けます。エラー原文、フォーム 入力値、メールアドレスは送りません。

4. 重複を防ぐ

送信中はボタンを無効にし、必要ならサーバー側で重複処理を防ぎます。同じ成功でGA4 イベントが二度発生しないようにします。完了ページも使う場合は、応答処理とページ側で 同じ問い合わせを重複計測していないか確認します。

UTMは流入の目印であり個人情報欄ではない

外部キャンペーンのリンクには合意したutm_sourceutm_mediumutm_campaignを 使います。内部ナビゲーションへUTMを付けると元の流入情報を上書きすることがあるため 使いません。任意のクエリ全体ではなく、許可した値だけを正規化します。

  • utm_source: googlenewsletter、合意した媒体名
  • utm_medium: cpcorganicemail
  • utm_campaign: チームが管理する短いキャンペーンID

氏名、メール、電話番号、問い合わせ内容、内部顧客IDをUTMやイベントパラメータへ 入れないでください。GA4は顧客管理記録ではありません。

公開前QA

  1. 専用ブラウザーをQAトラフィックとして区別する。
  2. CTAクリック、有効な送信、成功、失敗を各一回実行する。
  3. ブラウザーの送信内容でイベント名と制限したパラメータを確認する。
  4. GA4 RealtimeまたはDebugViewで順序と受信を確認する。
  5. サーバーが実際に問い合わせを保存・送信したことも確認する。
  6. QAを分析で分離し、元の検証記録をすぐ削除しない。

Googleのlead form reporting guide は、訪問から送信までの離脱をファネルデータ探索で見る方法を説明します。カスタム 定義はパラメータの収集と報告用途を確認した後に作ります。過去データには遡って 反映されません。

最初の報告で見る四つの比率

  • CTA interest rate = contact_click / landing sessions
  • Form attempt rate = submit_intent / landing sessions
  • Completion rate = submit_success / submit_intent
  • Failure rate = submit_failure / submit_intent

最初は言語、ランディングページ、参照元/メディア程度に分けます。小さな標本を ボタン、端末、キャンペーンごとに分割するとノイズが増えます。傾向は比較可能な28日間で 見ますが、フォーム失敗は運用障害なので直ちに確認します。

次にすること:実際のテスト問い合わせを一件送り、ブラウザーの送信内容、GA4 DebugView、サーバーが保存したメールまたはデータベースの記録まで追跡します。Adsを 連携している場合は、同じイベントが意図したコンバージョンに入ったことも確認します。 ページの種類を決める段階ならホームページとランディングページの 違いを確認し、フォームと計測条件を一緒に設計する 場合はIILLへの相談窓口から現在の構成を共有してください。

NEXT PROJECT

Webサイト制作、何から決めるべきか迷っていませんか?

現在の状況と必要な成果を伺い、制作範囲と次のステップを先に整理します。

あわせて読みたい記事

  1. workflows 制作会社が廃業してサイトが消えたら、再制作より先にドメインを復旧
  2. engineering Webサイトのバックアップは復元テストを完了して初めて証明できる
  3. privacy 問い合わせフォームのプライバシー表示に公開前から必要な項目