作成: 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コンバージョン
これは別々の三段階です。
- イベント:サーバー確認後にサイトが
contact_form_submit_successを送ります。 - キーイベント:GA4で、このイベントを事業上重要な行動として指定します。
- Google Adsコンバージョン:GA4とGoogle Adsを連携している場合、このキー イベントを広告計測や、設定に応じた入札に使うコンバージョンとして作成または インポートします。
三段階で同じサーバー確認済みの結果を使います。データ量が多いという理由でCTA クリックを昇格させると、問い合わせではなくクリックを最適化します。ただし、 アトリビューション、集計期間、タイムゾーン、設定の違いでGA4とAdsの合計は異なる ことがあるため、利用したイベントと設定を記録してください。
クリックだけを成果にすると何がずれるか
CTAを押した後も、次の理由で問い合わせは完了しないことがあります。
- 必須項目のエラーが出る。
- 通信が切れる。
- サーバーがエラーを返す。
- 保存やメール配信が失敗する。
- 連続クリックで同じリクエストが重複する。
クリックだけを数えるとキャンペーンは成功したように見えても担当者には何も 届きません。クリックは文言とCTA配置を診断する指標として残し、確認済みの成果だけを キーイベントにします。
計算例:クリックを数えると報告には何が出るか
ランディングページを1か月運用し、ランディングセッションが1,000回あったとします。 数値は説明用です。
120回のクリックから38件の問い合わせへ
contact_click120contact_form_submit_intent45contact_form_submit_success38contact_form_submit_failure7contact_clickをキーイベントにしていたら、報告にはリードが120件と出ます。
チームが実際に受け取った問い合わせは38件です。下の比率で計算すると、CTA
関心率は12%、フォーム開始率は4.5%、完了率は84%です。失敗7件は試行の16%、
およそ6回に1回にあたり、キャンペーンの成果ではなく今日直すべきフォームの問題です。
実装の順序
1. 共通情報を小さくする
locale、page_type、content_group、ui_location、contact_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_source、utm_medium、utm_campaignを
使います。内部ナビゲーションへUTMを付けると元の流入情報を上書きすることがあるため
使いません。任意のクエリ全体ではなく、許可した値だけを正規化します。
utm_source:google、newsletter、合意した媒体名utm_medium:cpc、organic、emailutm_campaign: チームが管理する短いキャンペーンID
氏名、メール、電話番号、問い合わせ内容、内部顧客IDをUTMやイベントパラメータへ 入れないでください。GA4は顧客管理記録ではありません。
事例:HTML2WEBは購入意向と決済をどう分けているか
IILLのHTML共有ツールHTML2WEBは、決済にも同じ原則を使っています。決済を自社の データベースに4段階で記録します。
- 訪問者が料金プランのボタンを押すと
checkout_intent_clicked。商品、決済事業者、 ボタンの位置、決済が開いていたかを一緒に残します。 - 決済ページが作られると決済開始。
- 決済ページから戻ると復帰。
- 決済事業者のWebhookが注文を確認したときだけ有効化。
売上として数えるのは有効化だけです。決済ページから戻っただけでは数えません。
支払わずに戻ることもあるからです。決済を開始する前も、料金プランのボタンは
本物と同じように動きました。押すと結果値unavailableとともに
checkout_intent_clickedが記録され、訪問者の言語で決済は準備中だという案内が
表示されました。クリックを売上と呼ばずに需要を測った方法です。QAと印を付けた
トラフィックは意思決定用の報告から除きます。
テンプレート:キーイベントごとに1枚の契約
昇格させるイベントごとに短い契約を1つずつ用意します。フォームやサーバーの応答が 変わるたびに見直してください。
event: contact_form_submit_success
fires_when: サーバーが問い合わせの保存または配信を確認したとき
key_event: true
ads_conversion: GA4からインポート # または: なし
parameters:
locale: [en, ko, ja]
page_type: [landing_page, service, contact]
contact_method: [form]
never_send: [name, email, phone, message, raw_error, free_text_query]
duplicates: サーバーの結果1回につきイベント1回。送信中は送信ボタンを無効化
qa: 公開前に内部トラフィックとして印を付ける
owner: Web担当
verified_on: 2026-09-25
公開前QA
- 専用ブラウザーをQAトラフィックとして区別する。
- CTAクリック、有効な送信、成功、失敗を各一回実行する。
- ブラウザーの送信内容でイベント名と制限したパラメータを確認する。
- GA4 RealtimeまたはDebugViewで順序と受信を確認する。
- サーバーが実際に問い合わせを保存・送信したことも確認する。
- 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への相談窓口から現在の構成を共有してください。