EFOとは?フォーム完了率の測り方と入力離脱を減らす7つの改善

EFO(Entry Form Optimization)は、問い合わせや申込みなどの入力フォームを使いやすくし、必要な情報を正確に送れるようにする取り組みです。項目を減らすだけでなく、入力の説明、エラーからの復帰、送信成功の確認まで含めて改善します。完了率には複数の分母があるため、まず何を測っている数字かをそろえることが出発点です。
EFOは入力フォームを使いやすくする取り組み
入力フォームでは、利用者は「何を入力するか」「なぜ必要か」「この操作で送れたか」を判断しています。EFOでは、この判断に必要な情報を近くに置き、入力や操作の負担を減らします。英語ではform optimizationという表現が自然で、EFOは日本のWebマーケティングで使われる呼称として理解するとよいでしょう。
目指すのは数字の上昇だけではありません。営業が対応できる問い合わせ情報を受け取りつつ、誤送信や重複を減らすことも目的です。必要な本人確認や希望条件まで削ると、入力しやすくなっても、その後の対応が難しくなる場合があります。
フォーム完了率の一律の平均値を目標にする前に、自社の利用目的、必要情報、対象端末を整理してください。設計の基本は、W3Cのフォーム作成チュートリアルでも確認できます。
到達・開始・送信成功を分けて完了率を測る
フォームを表示した段階、入力を始めた段階、システムが送信を受理した段階を別々に記録します。同じ期間・対象・集計単位にそろえた架空例で、フォーム到達500件、入力開始300件、重複を除いた受理成功90件なら、次のようになります。
指標 | 計算 | 値 |
|---|---|---|
到達から開始 | 300 ÷ 500 | 60% |
到達から受理成功 | 90 ÷ 500 | 18% |
開始から受理成功 | 90 ÷ 300 | 30% |
開始者の未完了 | (300 − 90) ÷ 300 | 70% |
この例では、集計対象の開始300件を同じ判定期間で成功・未完了に分類できると仮定しています。未観測の送信、日をまたぐ完了、再訪による重複があると、そのまま70%を離脱率とは呼べません。「1 − 完了率」が成り立つのは分母と判定条件が同じ場合です。
GA4の拡張計測機能にはform_startとform_submitがありますが、実装やフォームの方式によって取得状況は異なります。form_submitをサーバーでの受理成功や登録人数と置き換えず、GA4の拡張計測の仕様と実際の受理記録を照合します。
自社フォームの離脱箇所と入力エラーを調べる
最初に、自分でスマートフォンとパソコンから入力してください。長い選択肢、わかりにくい必須表示、戻ると消える入力内容、画面外のエラーなど、操作で再現できる問題を探します。分析ではフォーム全体の率だけでなく、端末、流入元、フォームの用途ごとに同じ条件で比較します。
エラーは件数と発生箇所、表示したメッセージ、修正後に成功できたかを確認します。必須電話番号で止まる場合でも、入力形式が厳しいのか、利用目的が伝わらないのか、電話連絡を望まないのかで対策は変わります。個々の入力値やメールアドレスを分析ツールへ送って原因を探す方法は避け、必要な集計項目だけを設計します。
入力負担と操作の迷いを減らす7つの改善
以下は、症状に応じて選ぶ7つの改善候補です。すべてを一度に変更せず、再現できた問題に対応するものから試します。
改善 | 変更候補 | 手動確認と監視 |
|---|---|---|
1. 必須・任意を整理 | 受理後の対応に使わない項目を任意にし、必要な項目は理由を示す | 未入力でも受理できるか/問い合わせ品質 |
2. ラベルと説明を見える位置に置く | 入力後も消えないラベルと、迷いやすい項目の説明を付ける | 入力中に項目名がわかるか/同じ質問の件数 |
3. 入力補助を適切に使う | 内容に合うautocompleteやinputmodeを開発担当と確認する | 端末のキーボード・補完結果/入力ミス |
4. 形式とエラーを見直す | 許容できる空白や記号を受け付け、直す箇所を具体的に示す | 修正後に進めるか/同じエラーの反復 |
5. 複数ステップの進捗を示す | 現在位置と残る工程、戻る操作をわかりやすくする | 戻っても入力が残るか/各工程の完了 |
6. モバイルとキーボードに対応する | 拡大・タブ移動・フォーカス・送信ボタンを点検する | マウスなしで操作できるか/端末別成功 |
7. 成功状態と再送を整える | 受理結果と次の案内を示し、意図しない重複を抑える | 二重クリック・再読込/重複受理 |
入力途中に即座にエラーを出せば常によいわけではありません。まだ入力を終えていない人を遮らず、送信時や適切なタイミングで、何が問題でどう直せるかを伝えます。画面上の検証に加えてサーバー側でも検証する考え方は、W3Cの入力検証ガイドを参照してください。
送信成功・個人情報・アクセシビリティを検証する
確認用の送信を用意し、利用者への表示、受理記録、分析イベントを三つ並べて確認します。下表の期待値は実装に合わせて決めるもので、既存サイトがその動作になっているという意味ではありません。
ケース | 利用者への表示 | 受理・計測の確認 |
|---|---|---|
空欄 | 必須項目と修正方法がわかる | 不正な内容が受理されず、成功に数えられない |
形式エラー | 該当箇所を特定できる | 修正後に送信できる |
通信失敗 | 未送信か確認待ちかがわかる | 失敗を成功として計測しない |
正常送信 | 受理と次の行動がわかる | 受理1件と成功記録を照合する |
二重クリック | 処理中・完了状態がわかる | 重複受理と重複イベントを確認する |
再読み込み | 不用意な再送を避けられる | 同一成功の再計上を確認する |
分析への同意拒否 | 必要な申込み操作ができる | 同意に沿う計測になっているか確認する |
キーボードのみ | フォーカス・エラー・完了がわかる | 一連の操作が完結する |
利用規約、個人情報の説明、連絡手段など、判断に必要な情報を単に離脱防止のために隠さないでください。アクセシビリティの初期点検はW3Cの簡易チェックも参考になります。
同じ条件で改善結果と問い合わせ品質を比較する
変更前後は、フォームの対象、完了の定義、期間、端末と流入条件をそろえます。受理成功に加えて、有効な問い合わせ、重複、迷惑送信、対応に必要な情報の不足も見ます。送信だけ増えて有効な相談が減っていれば、目的に合う改善とは限りません。
A/Bテストを行う場合は、無作為な振り分け、主指標、必要なデータ量、終了条件を事前に決めます。件数が少ないときは短期間の割合を勝敗として扱わず、操作テストと実数を中心に確認します。まず一つのフォームで分母を明示した集計と上記8ケースの検証を行い、次の変更を決めてください。
関連記事




