データから紐解くEFO対策！GA4による離脱分析からフォーム改修まで”徹底解説”

 

広告やSEO対策でどれだけWebサイトへのアクセスを増やしても、最後の入力フォームでユーザーが離脱している状態では、ザルで水をすくうようなもので、成果にはつながりません。
そんなときに行うのがEFO対策です。

 

EFOは「Entry Form Optimization」の略で、入力フォーム最適化と呼ばれます。
お問い合わせや資料請求、予約、採用エントリーなどのフォームを見直し、入力途中の離脱や送信エラーを減らす取り組みです。

Webサイトを改善するときは、成果に近い場所から確認するほうが効果を見込みやすくなります。
新たにアクセスを増やすよりも、すでにフォームまで来ているユーザーの離脱を減らすほうが、少ない改修で成果につながります。

ただし、項目を減らしたりボタンを目立たせたりすればよいとは限りません。
入力前に戻っているのか、入力中に止まっているのか、送信後に失敗しているのかで対処法は変わります。

 

本記事では専用のEFOツールを前提としません。GA4（Google Analytics 4）やGoogleタグマネージャー、既存フォームのHTMLを使い、離脱の原因を絞り込む方法を解説します。
制作会社やエンジニアへ依頼するときの確認材料としてぜひ活用してください。

 

1．EFO対策ではフォームのどこから漏れているかを調べる

 

EFO対策というと、入力項目の削減やボタンのデザイン変更を思い浮かべるかもしれません。

 

もちろん、そうした対応が必要なフォームもありますが、最初から思いつくままに改修すると、本当の原因を直せないことがあります。
フォームを開いた時点で入力を諦めている場合は、項目数や説明の見せ方に問題があるかもしれません。

 

フォーム内の行動は、大きく4段階に分けられます。

 

段階	ユーザーの行動	確認する数字
フォーム閲覧	フォームページを開いた	フォーム閲覧数
入力開始	入力欄を操作した	入力開始数
送信操作	フォームを送信した	送信操作数
送信完了	正常に受け付けられた	送信完了数

 

この4段階の人数を比較すると、ユーザーが大きく減っている場所を確認できます。

 

例えばフォーム閲覧数は多いのに入力開始数が少ない場合、入力前の段階で不安や負担を感じている可能性があります。
項目が多く見える、所要時間が分からない、個人情報をどこまで入力するのか不安といった理由が考えられます。

 

一方で入力開始数は多いのに送信操作数が少ない場合は、フォームの途中に問題がありそうです。
入力形式が厳しい、回答しにくい項目がある、ブラウザの自動入力で別の情報が入るといった原因を確認します。
送信操作数と送信完了数に差がある場合は、画面の使いやすさではなくサーバーや外部システムの問題かもしれません。

 

1.1 フォーム内のCVRを分けて考える

CVRはコンバージョン率を表す言葉です。 ただし、何を分母にするかで意味が変わります。
フォームを改善するときは、CVRが低いとひとまとめにせず、各段階の割合を分けて確認します。

 

指標	計算方法	確認できること
サイト全体のCVR	コンバージョン数÷セッション数	サイト訪問から成果に至った割合
入力開始率	入力開始数÷フォーム閲覧数	フォームを見て入力を始めた割合
入力完了率	送信操作数÷入力開始数	入力を始めた人が送信まで進んだ割合
送信成功率	送信完了数÷送信操作数	送信後の処理が完了した割合

 

フォーム完了率だけではどこに問題があるか判断できません。
入力開始率、入力完了率、送信成功率を分けて見ることで、改修する場所を絞り込みやすくなります。

 

1.2 数字の減り方から確認場所を決める

 

数字の動き	起きていること	最初に確認する場所
閲覧数に対して入力開始数が少ない	フォームを見て入力せずに戻っている	項目数、必須項目、説明、所要時間
入力開始数に対して送信操作数が少ない	入力途中で止まっている	項目別エラー、入力形式、自動入力
送信操作数に対して完了数が少ない	送信後の処理に失敗している	サーバー、API、外部システム
スマートフォンだけ完了率が低い	端末に応じた問題がある	レイアウト、キーボード、自動入力
特定ブラウザだけ完了率が低い	ブラウザ固有の不具合がある	HTML属性、JavaScript、実機動作

 

この表だけで原因が確定するわけではありません。
数字から可能性を絞り、その後で実際のフォームを操作します。 フォームを初めて見る人にも触ってもらうと、運用担当者が気づきにくい問題を見つけやすくなります。

 

2．GA4でフォームの離脱状況を確認する

 

フォームの4段階を確認するにはGA4を使います。
主なイベントは次のとおりです。

 

段階	イベント例	計測するタイミング
フォーム閲覧	page_view	フォームページを表示したとき
入力開始	form_start	フォームを初めて操作したとき
送信操作	form_submit	フォームが送信されたとき
送信完了	generate_lead	問い合わせや申し込みが完了したとき

 

GA4の拡張計測機能では、フォーム操作に関するform_startとform_submitを自動で取得できます。
ただし、自動計測が有効でも実際のフォームで正しく記録されるとは限りません。
画面を切り替えずに送信するフォームや独自のJavaScriptで動くフォームでは、イベントが記録されないことがあります。

 

2.1 フォーム操作の自動計測を確認する

まずはGA4の管理画面から、対象サイトのデータストリームを開きます。 拡張計測機能のフォーム操作が有効になっているか確認してください。
その後、実際のフォームを操作します。

1. GA4の管理画面を開く
2. データストリームを選ぶ
3. 対象のウェブストリームを開く
4. 拡張計測機能を確認する
5. フォーム操作の計測が有効か確認する
6. 実際のフォームを操作する

 

動作確認にはGA4のDebugViewやGoogleタグマネージャーのプレビューモードを使います。

• 入力を始めたときにform_startが記録されるか
• 送信したときにform_submitが記録されるか
• 同じ操作が複数回記録されていないか
• 送信に失敗したときに完了扱いになっていないか
• ページ内に複数のフォームがある場合に区別できているか

 

この確認はGA4のDebugViewや、Googleタグマネージャーのプレビューモードで行えます。
設定作業に慣れていない場合は、制作会社へ次のように依頼してください。

 

お問い合わせフォームを実際に操作し、form_start、form_submit、送信完了イベントが正しいタイミングで一度だけ発生するか確認してください。

 

2.2 送信操作と送信完了を分ける

form_submitが記録されても、問い合わせが正常に受け付けられたとは限りません。
送信後には次の処理があります。

1. 入力内容を確認する
2. サーバーへ送信する
3. データを保存する
4. CRMや予約システムへ登録する
5. メールを送る
6. 完了画面を表示する

 

途中でエラーが起きれば、送信ボタンは押されていても、実際の問い合わせは届きません。
そのため、送信操作とは別に受付完了を計測します。
問い合わせや資料請求では、サーバー側の処理が成功し、完了画面が表示された時点でgenerate_leadを送る方法があります。

 

2.3 目標到達プロセスデータ探索を設定する

GA4の目標到達プロセスデータ探索を使うと、各段階の人数を並べて確認できます。

 

ステップ	条件の例
ステップ1	フォームページのpage_view
ステップ2	form_start
ステップ3	form_submit
ステップ4	generate_leadまたは完了ページの表示

 

ここまで設定すれば、入力前、入力途中、送信後のどこで大きく減っているかを把握できます。
細かな設定方法をすべて理解する必要はありません。Web担当者として把握したいのは、4段階を分けて確認することです。

 

2.4 デバイスやブラウザでも比較する

全体の平均値だけでは、一部の環境で起きている問題を見落とします。
次の条件でも数字を比べてください。

• PCとスマートフォン
• iPhoneとAndroid
• SafariとChrome
• 広告流入と自然検索
• 問い合わせフォームと資料請求フォーム

 

全体のフォーム完了率が35％でも、PCが45％、スマートフォンが20％ということがあります。
この場合はフォーム全体を作り直すのではなく、スマートフォンでの表示や入力方法から確認します。
Safariだけ完了率が低いなら、自動入力やJavaScriptの動作に問題があるかもしれません。
スマートフォン向けのレイアウトやボタンサイズについては、以下の記事で詳しく紹介しています。

 

関連記事：スマホを意識したEFOで、入力フォームのストレスを軽減

https://www.weblab.co.jp/blog/staff/sp/11579.html

 

3．入力項目ごとの離脱やエラーを追加計測する

 

GA4の標準計測で分かるのは、入力を始めた人数と送信した人数の差です。
どの項目で止まったかまでは分かりません。
入力開始が500件、送信操作が300件だったとしても、会社名で止まったのか、電話番号でエラーになったのかは判断できません。

 

項目ごとの問題を調べるには追加計測が必要です。

 

3.1 計測目的に合わせてイベントを決める

項目単位では次のような情報を記録できます。

 

イベント名の例	発生させるタイミング	確認できること
form_field_start	項目を初めて操作した	その項目まで到達した人数
form_field_complete	項目の入力を終えた	項目を完了した人数
form_field_error	入力エラーが表示された	エラーが多い項目
form_step_view	次の入力画面へ進んだ	複数画面フォームの離脱
form_submit_error	送信処理でエラーが起きた	送信後の失敗件数

 

すべての項目を計測する必要はありません。
まずはエラーが多い項目や、入力が複雑な箇所から始めます。
電話番号、メールアドレス、住所、ファイル添付などが候補です。複数画面に分かれたフォームであれば、各画面への到達数も確認します。
計測項目を増やしすぎると、データを見る手間も増えます。何を改善するために計測するのかを先に決めてください。

 

3.2 エラー項目をデータレイヤーへ送る

メールアドレスの形式エラーが発生した場合は、次のように情報を送ります。

 

 

各パラメータの役割は次のとおりです。

 

パラメータ	内容
form_id	どのフォームか
field_name	どの入力項目か
error_type	どのようなエラーか

 

この情報をGoogleタグマネージャーで受け取り、GA4のイベントとして送ります。
field_nameやerror_typeをGA4の探索で使う場合は、カスタム定義への登録も必要です。

 

3.3 入力内容はGA4へ送らない

項目別の計測では、ユーザーが入力した内容をGA4へ送らないようにします。
次の情報は送信対象に含めません。

• 氏名
• メールアドレス
• 電話番号
• 住所
• 問い合わせ内容
• 会員番号
• 履歴書の内容
• パスワード

 

記録するのは、メールアドレス欄で形式エラーが起きた、ファイルの容量エラーが起きたといった事実までです。
ファイル添付の場合も、ファイル名や履歴書の内容は送りません。
入力された値を確認する必要がある場合は、GA4ではなくアクセス権限を管理したサーバーログや業務システムを使います。

 

3.4 最後の操作を離脱原因と決めつけない

最後に操作した項目が離脱原因とは限りません。
電話番号まで入力した後、下に並ぶ長いアンケートを見て離脱した場合を考えてみます。
最後に操作したのは電話番号ですが、離脱の原因はアンケートの長さかもしれません。

 

判断するときは、次の情報を組み合わせます。

• 項目への到達数
• 項目の完了数
• エラー発生数
• 次の項目へ進んだ数
• フォーム全体の送信数
• 実機で確認した操作性

 

項目別計測は原因を断定するためではありません。問題がありそうな場所を絞るために使います。

 

4．データをフォームの修正指示へ落とし込む

 

GA4や項目別イベントで問題のある場所を絞り込んだら、数字と修正内容を結び付けます。
フォームを使いやすくしてくださいという依頼だけでは、制作会社やエンジニアは何を直せばよいか判断できません。
修正する場所、対応内容、完了の条件まで整理して伝えます。

 

4.1 数字と修正内容を対応させる

 

データ上の症状	主な原因候補	修正内容の例
入力開始率が低い	項目が多く見える	必須項目数や所要時間を表示する
特定項目のエラーが多い	入力条件が厳しい	ハイフンや全角・半角を柔軟に扱う
特定項目から先へ進まない	回答方法が分からない	入力例や補足説明を追加する
スマートフォンだけ完了率が低い	キーボードが合っていない	typeやinputmodeを見直す
Safariだけ完了率が低い	自動入力が正しく働いていない	nameやautocompleteを見直す
送信後の失敗が多い	サーバーやAPIのエラー	ログと外部連携を確認する
問い合わせが重複する	二重送信が起きている	ボタン制御と重複防止を実装する

 

よくあるのが、電話番号の入力エラーです。
フォームではハイフンなしを求めているのに、ユーザーは普段どおりハイフンを入れます。何度かエラーが続けば、そのまま離脱されるかもしれません。
この場合は注意書きを増やすだけでなく、ハイフンありとなしの両方を受け付ける方法を検討します。

 

4.2 制作会社やエンジニアへ伝える修正指示例

 

優先度	修正箇所	修正指示	完了条件
高	送信完了の計測	サーバー処理成功後にgenerate_leadを送信する	正常完了時だけDebugViewに表示される
高	GA4への送信値	入力内容をイベントに含めない	GTMプレビューで個人情報が含まれていない
高	外部API連携	登録失敗時は完了画面を表示しない	失敗時に完了イベントが発生しない
高	二重送信	画面とサーバーの両方で重複を防ぐ	連続クリックしても1件だけ登録される
中	自動入力	項目に合ったHTML属性を設定する	SafariとChromeで正しく入力される
中	入力エラー	項目の近くに修正方法を表示する	エラー後も入力した値が残る

 

すべてをそのまま依頼する必要はありません。
自社フォームで見つかった問題だけを残します。必要に応じて期限や担当者も加えます。

 

4.3 修正前後で同じ数字を確認する

フォームを変更した後は、改修前と同じ指標で比較します。
電話番号の入力条件を変更した場合は、次の数字を確認します。

• 電話番号欄のエラー数
• 次の項目へ進んだ数
• 入力完了率
• フォーム完了率

 

フォーム全体の完了率だけでは、個別の修正効果を判断できないことがあります。改修した項目に関係する数字も確認します。

 

5．自動入力と入力エラーによる離脱を防ぐ

 

ブラウザの自動入力は、入力の手間を減らしてくれる便利な機能です。
一方で、フォームの設定が曖昧だと次のような問題が起こります。

• 姓の欄に住所が入る
• 会社名の欄に個人名が入る
• 郵便番号に電話番号が入る
• パスワード欄に別の情報が入る
• 自動入力後にエラーになる

 

こうした問題は、フォームの入力欄が何を求めているかブラウザへ伝わっていないときに起こりやすくなります。
iPhoneのSafariとAndroidのChromeでは動きが異なることもあるため、両方で確認します。

 

5.1 自動入力に関係するHTML属性

 

属性	役割
name	送信データの項目名を指定する
id	ラベルとの関連付けに使う
autocomplete	自動入力する情報の種類を示す
type	入力内容の種類を示す
inputmode	スマートフォンのキーボードを指定する

 

主な設定例は次のとおりです。

 

入力項目	type	autocomplete	inputmode
姓	text	family-name	省略可
名	text	given-name	省略可
会社名	text	organization	省略可
郵便番号	text	postal-code	numeric
都道府県	textまたは選択欄	address-level1	省略可
市区町村	text	address-level2	省略可
住所	text	street-address	省略可
電話番号	tel	tel	tel
メールアドレス	email	email	email
現在のパスワード	password	current-password	省略可
新しいパスワード	password	new-password	省略可

 

メールアドレスの設定例です。

 

 

郵便番号は計算に使う数字ではありません。type="number"ではなく、type="text"とinputmode="numeric"を組み合わせる方法があります。

 

 

Web担当者がコードを書く必要はありません。
制作会社へは次のように依頼できます。

 

氏名、会社名、郵便番号、電話番号、メールアドレスに適切なname、autocomplete、type、inputmodeを設定してください。SafariとChromeの自動入力でも確認してください。

 

5.2 意味の分からないname属性を避ける

次のように機械的な名前が付いているフォームがあります。

 

 

この状態では、ブラウザだけでなく、フォームを保守する人にも項目の意味が伝わりません。
項目の役割が分かる名前にします。

 

 

分かりやすい名前にしておくと、フォームの保守や項目別計測、外部システムとの連携もしやすくなります。

 

5.3 入力形式の違いはシステム側で吸収する

バリデーションは、入力内容が条件を満たしているか確認する処理です。
入力漏れや形式間違いを防ぐために必要ですが、条件が厳しすぎると離脱の原因になります。
ユーザーが入力し直さなくても処理できる内容は、システム側で整えます。

 

入力内容	避けたい処理	改善例
電話番号	ハイフンがあるとエラー	保存時にハイフンを除去する
郵便番号	全角数字をエラーにする	半角数字へ変換する
メールアドレス	前後の空白でエラー	空白を除去する
フリガナ	ひらがなをエラーにする	カタカナへ変換する
数字項目	全角数字をエラーにする	半角数字へ変換する

 

電話番号欄の形式エラーが多い場合は、field_name="tel"とerror_type="format"の件数を確認します。
ハイフンの有無にエラーが集中しているなら、ユーザーに入力し直してもらう必要はありません。システム側で形式を統一します。

 

5.4 エラーの理由と直し方を表示する

「入力内容に誤りがあります」だけでは、何を直せばよいか分かりません。
メールアドレスなら、次のように修正方法を示します。

 

メールアドレスに@が含まれているか確認してください。

 

電話番号なら、必要な桁数やハイフンの扱いを伝えます。

 

電話番号を10桁または11桁の数字で入力してください。ハイフンはどちらでも構いません。

 

エラーは対象の入力欄の近くに表示します。
送信後にエラーが起きた場合も、問題のない項目は残してください。すべてを最初から入力し直すフォームは、大きな離脱要因になります。

 

5.5 ブラウザ側のチェックだけに頼らない

入力中に表示するエラーは、ユーザーを助けるための機能です。
一方で、正しいデータを受け取るための確認はサーバー側でも行います。
ブラウザ側のチェックは回避されることがあるため、文字数や形式、値の範囲をサーバー側でも確認します。
EFOの入力支援とセキュリティ対策は役割が異なります。どちらか一方だけでなく、両方を実装します。

 

6．予約フォームと採用フォームの改善例

 

フォームの目的によって、起きやすい問題は変わります。
問い合わせフォームだけを基準にせず、予約や採用に必要な処理まで確認します。

 

6.1 予約フォームの計測例

予約フォームでは、日時選択から予約システムへの登録までが一つの流れです。

 

段階	ユーザーの行動	計測例
予約フォーム閲覧	予約ページを開いた	ページ表示
日時選択	希望日時を選んだ	日時選択
情報入力	氏名や連絡先を入力した	入力開始
確認画面	入力内容を確認した	画面表示
送信操作	予約を申し込んだ	送信操作
予約受付完了	予約システムへ登録された	送信完了

 

予約フォームでよくある問題は次のとおりです。

 

症状	原因	修正内容
日時選択後の離脱が多い	空き枠が分かりにくい	選択できない枠を明確にする
同じ予約が複数入る	二重送信	重複登録を防ぐ
送信後に完了しない	予約APIの失敗	登録成功後に完了表示する
受付後の問い合わせが多い	受付と確定の違いが不明	画面とメールで状態を示す

 

予約ボタンを押しただけでは、予約システムへの登録が終わっていない場合があります。
完了イベントは、予約システム側で受付に成功した後に発生させます。
予約リクエストの受付と予約確定が異なる場合は、その違いを完了画面と自動返信メールに明記します。

 

6.2 採用フォームの計測例

採用フォームでは、入力項目が多くなりやすく、履歴書や職務経歴書の添付もあります。

 

段階	ユーザーの行動	計測例
フォーム閲覧	応募フォームを開いた	ページ表示
基本情報入力	氏名や連絡先を入力した	入力開始
経歴入力	職歴や希望条件を入力した	画面表示
ファイル添付	履歴書を選択した	添付操作
送信操作	応募ボタンを押した	送信操作
応募完了	採用管理システムへ登録された	送信完了

 

採用フォームでよくある問題は次のとおりです。

 

症状	原因	修正内容
添付前後で離脱が多い	形式や容量が不明	選択前に条件を表示する
スマホだけ添付率が低い	端末で操作しにくい	iPhoneとAndroidで確認する
エラー後に入力が消える	エラー時に初期化される	ほかの入力値を残す
応募が管理画面にない	採用管理システムとの連携失敗	登録成功まで確認する

 

ファイル名や履歴書の内容はGA4へ送りません。
計測するのは、添付操作や容量エラーが発生したことまでです。

 

7．送信後の不具合を防ぎ公開前後にテストする

 

フォーム画面で送信完了と表示されても、外部システムへデータが届いていないことがあります。
確認するのはフォーム画面だけではありません。

 

7.1 外部システムへの登録結果まで確認する

 

確認場所	確認内容
フォーム画面	完了画面が表示されるか
管理者メール	通知メールが届くか
ユーザーメール	自動返信が届くか
CRM・MA	正しい項目へ登録されるか
予約・採用システム	受付が完了しているか
サーバーログ	エラーが出ていないか
GA4	完了イベントが発生するか

 

外部システムへ登録されたかだけでなく、登録内容も確認します。
会社名と氏名が逆になっていないか。問い合わせ内容が途中で切れていないか。希望日時や応募職種が正しい項目に入っているか。実際のデータまで見てください。

 

7.2 二重送信を防ぐ

送信に時間がかかると、ユーザーが何度もボタンを押すことがあります。
送信中はボタンを押せない状態にし、処理中であることを表示します。
通信エラーが起きた場合は、再送できる状態へ戻します。
ブラウザ側のボタン制御だけでは不十分です。サーバー側にも重複登録を防ぐ仕組みを用意します。

 

予約や採用フォームでは、二重登録が業務上の混乱につながります。公開前に必ず連続クリックを試してください。

 

7.3 公開前チェックリスト

 

分類	確認内容
通常送信	正常に完了できるか
入力エラー	直し方が分かるか
データ保持	エラー後も入力値が残るか
自動入力	SafariとChromeで正しく動くか
外部連携	CRMや管理システムへ登録されるか
メール	管理者通知と自動返信が届くか
計測	GA4へ個人情報を送っていないか
異常操作	二重送信や通信エラーに対応できるか

 

正常な操作だけでなく、次のケースも試します。

• 必須項目を空欄にする
• メールアドレスの形式を崩す
• 大きすぎるファイルを添付する
• 送信ボタンを連続で押す
• 送信中に通信を切る
• 長時間開いた後に送信する

 

問題を完全に防ぐことだけが目的ではありません。
問題が起きた後も、ユーザーが状況を理解し、入力を続けられることが大切です。

 

7.4 改修後は同じ数字で効果を確認する

改修後は、改修前と同じ指標を確認します。

• 入力開始率
• 入力完了率
• 送信成功率
• フォーム完了率
• 項目ごとのエラー数
• デバイス別の完了率
• ブラウザ別の完了率
• 外部システムへの登録成功率

 

電話番号の入力条件を変えた場合は、電話番号欄のエラー数を見ます。
Safari向けに自動入力を修正した場合は、Safariのフォーム完了率を確認します。
フォーム完了率が上がっても、商談化率や予約成立率が下がる場合は注意が必要です。
入力項目を減らしすぎたことで、対応に必要な情報が不足しているかもしれません。フォーム内の数字だけでなく、その後の成果まで含めて判断します。

 

7.5 EFOツールが向いている場合

ここまで紹介した対策は、GA4やGoogleタグマネージャー、既存フォームの修正で進められます。
一方で、次のような場合はEFO専用ツールも選択肢になります。

• フォーム数が多い
• 項目ごとの動きを継続して比較したい
• ABテストを頻繁に行いたい
• 社内でフォームを改修できない
• 複数サイトをまとめて管理したい

 

最初からツールを導入する必要はありません。
まずはGA4で大きな離脱箇所を確認します。明らかな入力エラーや連携不具合を直した後も継続した分析が必要なら、ツールを検討します。

 

8．まとめ

 

EFO対策では、思いつくままに項目やデザインを変えるのではなく、フォームのどこでユーザーが減っているかを確認します。
対象となるのは、入力前、入力途中、送信後の3つです。

 

入力前の離脱が多ければ、項目数や所要時間の案内を見直します。入力途中なら、エラーや自動入力を確認します。送信後なら、サーバーや外部システムとの連携を調べます。

 

Web担当者の役割は、数字から問題のある場所を見つけ、制作会社へ具体的な修正内容と完了条件を伝えることです。
集客を増やしても、最後の入力フォームでユーザーを取りこぼしていれば成果にはつながりません。
まずはGA4でフォーム内の行動を段階ごとに分け、数字が減っている場所を確認するところから始めてください。
計測、確認、改善、検証を繰り返すことで、すでに集めているアクセスを問い合わせや申し込みにつなげやすくなります。