検索ブランド相談室 | 検索と評判の専門メディア

フォーム離脱を監査する方法|CTAクリック後の入力開始・エラー・完了率を改善

部署:マーケティング担当者部署:経営者・責任者レベル:実践Webサイト改善Web集客、コンテンツマーケティング、マーケティングDX
問い合わせフォームを確認するPC画面と「CTAの先で、どこで止まる?」というコピーを組み合わせたフォーム離脱監査のアイキャッチ

記事から問い合わせフォームへユーザーを送れているのに、問い合わせ件数が増えない場合、問題はCTAより後ろにあるかもしれません。

フォーム離脱を改善するには、「フォームのCVRが低い」という1つの数字だけを見るのではなく、CTAクリック、フォーム到達、入力開始、エラー、送信完了までを分解して確認することが重要です。

特に、入力を開始したユーザーがどの項目で止まり、どのエラーを経験し、スマートフォンとPCで差があるのかまで確認すると、削除すべき項目や修正すべき入力仕様を特定しやすくなります。

この記事では、GA4を中心にフォーム離脱を監査し、改善の優先順位まで決める方法を解説します。

フォーム離脱の監査では「到達→入力開始→エラー→完了」を分けて見る

フォーム離脱を監査するときの重要なポイントは、フォーム全体を1つのCVRだけで評価しないことです。

記事からCTA、フォーム、リード化までの全体導線は、オウンドメディアの集客導線全体像で確認できます。

フォーム到達前のCTA配置・訴求・遷移先を比較する必要がある場合は、記事CTAのA/Bテスト設計を参照してください。

最低でも、次の流れに分解します。

段階 確認する行動 主な確認目的
CTAクリック 記事内CTAを押した 訴求からフォームへ移動したか
フォーム到達 フォームページを表示した 遷移途中の離脱がないか
入力開始 最初の入力操作をした フォームを見て入力する意思を持ったか
エラー発生 入力・送信時にエラーが出た 入力仕様が障害になっていないか
送信完了 正常に問い合わせを完了した 最終的なフォーム完了率

CTAクリックからフォーム到達、入力開始、エラー、送信完了までを5段階に分解したフォーム離脱監査フロー

フォーム全体のCVRだけでなく、CTAクリックから送信完了までを段階別に分けると、離脱が起きている場所を特定しやすくなります。

Google Analytics 4(GA4)では、拡張計測機能によってform_startform_submitが取得されます。form_startはセッション内で初めてフォームを操作したとき、form_submitはフォームを送信したときに記録されます。

Googleも、フォーム入力開始者と送信者の割合を見ることで、必須質問の多さや予期しないエラーなどを発見できると説明しています。

ただし、フォーム内のすべての問題がGA4の標準イベントだけで分かるわけではありません。

「どの項目でエラーになったか」「離脱直前にどの項目を操作していたか」まで監査する場合は、項目単位のイベントを追加して分析する必要があります。

最初にフォーム監査用の計測イベントを設計する

フォーム改善を始める前に、まず必要なイベントが取得できているか確認します。

フォームの色やボタンを変更しても、どこで離脱したかを測定できなければ、改善理由も成果も判断できないためです。

最低限取得したい6種類のイベント

一般的なBtoBの問い合わせフォームであれば、次のイベントを基準に設計できます。

イベント例 意味 GA4での扱い
cta_click 記事CTAをクリック カスタム計測
form_view 対象フォームを表示 ページ表示等から判定
form_start フォーム入力開始 GA4で自動取得可能
field_error 項目単位の入力エラー カスタム計測
submit_attempt 送信操作を実行 必要に応じてカスタム計測
submit_success サーバー側で正常受付 カスタム計測または完了ページ

GA4のform_startとform_submitに加え、CTAクリックや項目別エラー、正常受付を追加計測するフォーム監査イベント設計図

GA4の標準イベントで入力開始・送信を確認し、項目別エラーや正常受付など詳細な監査が必要な部分は追加イベントで補います。

GA4のform_submitだけを、そのまま「問い合わせ完了」と考えないことも重要です。

JavaScriptやAJAXを利用したフォーム、送信後に同じページ内で完了表示するフォームなど、実装方式によって自動計測の挙動が変わることがあります。

したがって、重要な問い合わせフォームでは、サンクスページ表示、正常完了メッセージ、送信成功時の処理など、実際に受付が完了した地点をsubmit_successとして別途確認すると安全です。

項目名は送っても入力値はGA4へ送らない

項目別分析では、

  • form_id
  • field_id
  • error_type
  • step_index
  • device_type

などをイベントパラメータとして保持すると分析しやすくなります。

一方、氏名、メールアドレス、電話番号、問い合わせ本文など、ユーザーがフォームへ入力した値自体をGA4へ送ってはいけません。

Googleも、フォームフィールドなどに入力された個人を特定できる情報をAnalyticsへ送信しないよう求めています。

項目別に計測したい場合は「電話番号欄でエラーが発生した」という事実だけを送り、「090-XXXX-XXXX」という入力内容は送らない設計にします。

フォーム離脱率は4つの数字に分解すると原因を見つけやすい

計測ができたら、まずフォーム全体を上から順番に確認します。

1.CTAクリック後のフォーム到達率

計算例は次のとおりです。

フォーム到達率=フォーム到達ユーザー数÷CTAクリックユーザー数

CTAはクリックされているのにフォームへ到達していない場合、フォームそのものより、ページ遷移や表示速度、別タブ遷移、計測設定などを先に確認します。

CTAのコピーや配置を改善する段階と、フォーム内のUXを改善する段階を混同しないことが重要です。

2.フォーム到達後の入力開始率

入力開始率=フォーム入力開始ユーザー数÷フォーム到達ユーザー数

フォームまでは来ているのに入力が始まらない場合は、入力前の心理的・視覚的な負担を疑います。

たとえば、

  • 入力項目が一見して多い
  • 個人情報の利用目的が分かりにくい
  • 何分かかるか分からない
  • 問い合わせ後の流れが分からない
  • スマートフォンで入力欄が小さい

といった問題です。

3.入力開始後の完了率

入力完了率=正常送信ユーザー数÷入力開始ユーザー数

フォーム監査で特に重視したい数字です。

入力開始までは進んでいるのに完了率が低ければ、入力項目、エラー、確認画面、モバイル操作、送信処理など、フォーム内部に問題がある可能性が高まります。

GA4のファネルデータ探索では、ユーザー行動を複数ステップに分け、各段階の通過・離脱状況を確認できます。デバイスカテゴリなどによる内訳も確認できます。

4.項目別エラー率

項目ごとに、

項目別エラー率=その項目でエラーが発生したセッション数÷その項目を操作したセッション数

を確認します。

会社名は問題ないのに電話番号だけエラー率が高いのであれば、フォーム全体を作り直す前に電話番号欄を調べるべきです。

「ハイフン必須」「全角不可」「桁数判定が厳しい」など、入力仕様そのものが離脱原因になっている可能性があります。

項目別離脱は「最後に操作した項目」を見る

フォーム内でユーザーが最後に触った項目を記録すると、離脱が集中している場所を発見しやすくなります。

たとえば100件のフォーム入力開始セッションについて、離脱前の最終操作項目を集計した結果、次のようになったとします。

最終操作項目 離脱セッション 監査上の判断
氏名 3 大きな問題は見えにくい
会社名 5 要観察
電話番号 21 優先調査
予算 18 必須条件を確認
問い合わせ内容 7 入力量を確認

これはあくまで分析例ですが、このように項目単位へ分解すると、「フォームが長い」という曖昧な問題を「電話番号と予算項目を優先して確認する」という具体的な改善課題へ変えられます。

さらに、

  • エラー回数
  • 同じ項目の再入力回数
  • 項目滞在時間
  • 自動入力の有無
  • デバイス

を組み合わせると原因を絞り込みやすくなります。

ただし「最後に触った項目=必ず離脱原因」とは限りません。

ユーザーが電話対応を始めた、別ページを確認した、単純に検討を中断した可能性もあります。

そのため、最終操作項目だけで断定せず、エラー率、再入力、デバイス差、セッション観察などと組み合わせて判断します。

フォーム離脱はPCとスマートフォンを必ず分けて監査する

フォーム全体の平均値だけを見ると、スマートフォンだけで発生している問題を見逃す可能性があります。

同じ問い合わせフォームをPCとスマートフォンに並べ、操作性の違いを比較したフォーム離脱監査図

同じフォームでもPCとスマートフォンでは入力環境が異なります。全体平均だけでなくデバイス別に離脱状況を確認します。

GA4のファネル探索では、デバイスカテゴリなどでファネルを分解できます。

特にスマートフォンでは次を実機で確認します。

  • 入力欄を指で正確に選択できるか
  • キーボード表示後も対象項目が見えるか
  • メール欄で入力しやすいキーボードになるか
  • 電話番号欄で数字を入力しやすいか
  • チェックボックスが小さすぎないか
  • エラー表示によって画面が大きく移動しないか
  • 送信ボタンがキーボードや固定UIに隠れないか

W3Cでは、ポインター操作のターゲットについて44×44 CSSピクセル以上を基準とするアクセシビリティ指針があります。

また、W3Cはフォームの各コントロールへ目的が分かるラベルを付け、ラベルと入力欄を明確に関連付けることを推奨しています。ラベルを入力欄の上へ配置する方法は、モバイルや拡大表示時の横スクロールを減らす点でも有効です。

入力項目は「少ないほど良い」ではなく、取得理由で監査する

項目数を減らすことはフォーム改善の代表的な方法ですが、一律に「5項目以内」などと決める必要はありません。

BtoBでは、問い合わせ後の営業対応に必要な情報もあります。

各項目を次の3種類へ分けてください。

区分 判断基準 対応
必須 初回対応前に必ず必要 残す
任意 あれば便利だが後でも取得可能 任意化を検討
不要 営業・対応でほぼ使わない 削除候補

特に「社内で昔から取っている」という理由だけで残っている項目は確認が必要です。

ECを対象としたBaymard Instituteの2024年調査では、平均チェックアウトには11.3のフォームフィールドがあり、米国のオンライン購入者の17%が「長い・複雑なチェックアウト」を理由に購入を中断したと回答しています。これはBtoB問い合わせフォームへそのまま適用できる数字ではありませんが、表示する入力項目の多さがUX上の負担になることを考える参考になります。

フォームから項目を削除するときは、完了率だけでなく「問い合わせ後に必要情報が不足し、商談化率が下がっていないか」まで確認してください。

エラーは「件数」と「直しやすさ」の両方を確認する

エラーが多い項目を特定したら、次にエラー表示そのものを確認します。

「入力内容に誤りがあります」だけでは、ユーザーは何を修正すべきか判断できません。

たとえばメールアドレスなら、

「メールアドレスの形式を確認してください」

だけでなく、必要に応じて入力形式を分かるようにします。

W3Cも、必須項目を明確に示し、入力エラーをユーザーへ理解可能な形で伝える設計を案内しています。

エラーの位置についても研究があります。

Secklerらが303人を対象に6種類のエラー表示位置を比較した研究では、フォーム上部や下部へまとめて表示するより、エラーが発生した入力欄の近くへ表示した方が、効率・有効性・満足度の面で良い結果が確認されました。

一方、「入力した瞬間に必ずエラーを出せばよい」とは限りません。

Bargas-Avilaらが77人と90人を対象に行った研究では、即時エラー表示が入力行動を妨げるケースも確認されています。

そのため、

  • 入力途中に早すぎるエラーを出さない
  • 項目からフォーカスが外れた段階で確認する
  • 送信後だけに大量のエラーをまとめない
  • エラー項目の近くに修正方法を表示する

といった設計を候補にし、自社フォームで実際に検証します。

20個のフォーム改善ガイドラインを適用した研究でも操作性が改善

フォーム改善は単一のテクニックではなく、複数の小さなUX改善を組み合わせることが重要です。

Secklerらが実在企業のフォームを使い65人を対象に行った2014年の実験では、20項目のフォーム改善ガイドラインを適用したフォームで、完了時間の短縮、送信試行回数の減少、視線移動の減少、利用者満足度の向上が確認されました。

フォーム監査でも、単に色やボタンだけを見るのではなく、

  • 項目数
  • ラベル
  • 入力形式
  • エラー
  • 自動入力
  • スマートフォン
  • 送信処理

を一連の体験として確認することが重要です。

フォーム改善は「影響度×確信度×実装負荷」で優先順位を決める

監査すると、多くの場合は複数の問題が見つかります。

すべてを同時に変更すると、何が成果へ影響したのか分からなくなるため、優先順位を決めます。

たとえば次のように整理できます。

改善候補 影響度 根拠の強さ 実装負荷 優先度
エラー率の高い電話番号仕様を修正 最優先
不要な必須項目を任意化 最優先
モバイルのタップ領域拡大
フォーム全体を再デザイン 後で検討
送信ボタンの色だけ変更 不明 優先度低

フォーム改善案を影響度、根拠の強さ、実装負荷で整理した改善優先順位マトリクス

改善候補は一度に変更せず、影響度、データ上の根拠、実装負荷を比較して優先順位を決めます。

重要なのは、改善案の「一般的な正しさ」ではなく、自社データで問題が確認できているかです。

たとえば電話番号欄の離脱・エラーが突出しているのであれば、フォーム全体のデザイン変更より、電話番号欄の修正を先に行う方が原因と改善結果を確認しやすくなります。

フォーム離脱監査を実施する7ステップ

実務では次の順番で進めると整理しやすくなります。

STEP1.対象フォームと成果地点を決める

問い合わせ、資料請求、見積もりなど、対象フォームを特定します。

「送信ボタンを押したこと」ではなく、「正常に受付が完了したこと」を成果地点に設定します。

STEP2.CTAから送信完了までのイベントを確認する

cta_clickform_viewform_startsubmit_successが一貫して計測できるか確認します。

GA4のカスタムイベントパラメータをレポートで分析する場合は、イベントスコープのカスタムディメンションとして登録できます。

STEP3.フォーム全体のファネルを作る

CTAクリック→フォーム到達→入力開始→送信完了の順に通過率を確認します。

GA4のファネルデータ探索では最大10ステップまで設定できます。

STEP4.問題がある段階を特定する

入力開始率が低いのか、開始後の完了率が低いのか、送信直前に問題があるのかを分けます。

STEP5.項目別データを確認する

必要に応じてfield_errorや最終操作項目を計測し、問題が集中するフィールドを特定します。

STEP6.デバイス・流入元で分解する

PCでは問題がなくても、モバイルだけ完了率が低い場合があります。

広告、自然検索、記事、指名流入などによってもユーザーの検討度は異なるため、十分なデータ量がある場合は流入元も分けます。

STEP7.改善後に同じ指標で再測定する

改善前と改善後で、

  • 入力開始率
  • 入力完了率
  • 項目別エラー率
  • 項目別離脱
  • モバイル完了率
  • 問い合わせ件数
  • 問い合わせ後の商談化率

を比較します。

フォーム完了率だけが上がり、問い合わせ品質が大きく下がるのであれば、必須項目を削りすぎている可能性もあります。

フォーム監査は「フォームを短くすること」ではなく、必要な情報を維持しながら不要な摩擦を減らすことが目的です。

フォーム離脱監査チェックリスト

最後に、実務で確認したい項目をまとめます。

計測

  • CTAクリックを取得できている
  • フォーム到達を取得できている
  • form_startを確認できている
  • 正常な送信完了を判定できている
  • 二重発火がない
  • 個人情報をGA4へ送信していない

項目

  • 各入力項目の取得理由が明確
  • 不要な必須項目がない
  • 後から聞ける情報を任意化できないか確認した
  • 項目別エラーを確認できる
  • 離脱直前の操作項目を確認できる

エラー

  • エラー内容が具体的
  • 修正方法が分かる
  • エラー対象項目の近くに表示される
  • 入力途中に不必要なエラーを出していない
  • 送信後に大量のエラーを一括表示していない

モバイル

  • 実機で入力確認した
  • 入力欄・ボタンを押しやすい
  • 適切なキーボードが表示される
  • キーボードで入力欄が隠れない
  • エラー後も修正箇所を見つけられる
  • PCとモバイルの完了率を比較した

改善後

  • 改善前と同じ条件で再測定した
  • 問い合わせ数を確認した
  • 問い合わせ品質も確認した
  • 一度に変更しすぎていない

まとめ

記事CTAから問い合わせを増やすには、CTAクリック数だけでなく、その後のフォーム体験まで計測する必要があります。

フォーム離脱監査では、まず「CTAクリック→フォーム到達→入力開始→送信完了」のファネルを作り、どの段階で大きく減っているかを確認してください。

入力開始後の離脱が大きければ、さらに項目別エラー、最後に操作した項目、再入力、モバイル差分まで確認します。

その上で、問題が集中している項目から改善します。

フォーム全体を感覚で作り直すより、「どこで」「誰が」「何につまずいたか」を計測してから修正する方が、改善の根拠と優先順位を明確にできます。

記事への流入やCTAクリックは獲得できているのに問い合わせへつながらない場合は、フォームを独立したCV改善対象として監査することが重要です。

参考文献・データ元

この記事で参照した情報を確認できます。

‹ 親記事: オウンドメディアの集客導線とは?記事からリード獲得までを設計する全体像とCTA・リードマグネット・フォーム最適化の基本

関連記事

関連テーマ