ケース1：「エントリーフォーム」を改善する
まず最初に、以下のような資料請求サイトを例に説明していきます。通常であれば、いろいろデータを出して、最も改善幅が大きいところを模索し、そこから改修を進める手順が一番効果が出せるのですが、今回はその調査過程を割愛し、それぞれのケースでどのようなログを出力して改善していくのかを説明します。
以下の青い枠で囲んだ部分は、「エントリーフォーム」すなわち、利用者が資料請求を行う際に必要な情報を入力し、その入力内容を確認し、申し込みを完了するまでの画面遷移です。ここでは「各画面の遷移率」と「エラー発生項目・件数」に着目します。
ポイント1：確認画面から完了画面への遷移率向上
申し込みの確認画面から完了画面への遷移率が低いのは一番もったいないポイントです。開発の現場では、確認画面を作成する際、エンジニアが入力画面をもとにいくつかのテキストを追加し、そのまま確認画面としてリリースすることがあります。しかし本来は、次画面へ遷移しやすいようデザイナーが情報設計を考えて、ここで離脱が発生しないように配慮すべきです。このあたりは、Google アナリティクスの目標を設定することで簡単に確認することができます。
最大の施策は確認画面をなくしてしまうことですが、住所など誤りがあってはいけない項目がある場合、どうしても踏み切れないことがあります。逆に言うと、こうした資料請求以外の場合は省けるものは省いてしまった方がよいでしょう（例：SNSサイトのプロフィール入力など）。
ポイント2：入力画面から確認画面への遷移率向上
申し込み入力画面を表示した（＝申し込みの意思が生まれた）にも関わらず、離脱しているユーザーが多いということは、サイトにとって痛手となるのでしっかりチューニングしていきましょう。チューニングにあたって、必ず出力していただきたいのが「入力エラー」のログです。
たとえば、電話番号に誤りがあった場合は、「ERROR TEL」と言うように、どこでエラーが起こっているのかわかるようなログを出力します。こういうログの多いところは何かしらの問題があるので改善しましょう。
また、入力フィールドについては、以下のように、可能な限り入力項目を少なくし、入力ルールを緩くすることでエラー数は格段に減ります。
- 電話番号であれば、全角でも半角でもハイフンがあっても受け付けられるようにする
- 電話番号は3つに入力フィールドを分けずにひとつにする
- 姓名は問題なければ、姓名とフィールドを分けずにひとつにする
- 必要がなければフリガナの入力を求めない
こうすることで、入力項目、ユーザー操作を減らし、さらにそのエラー項目が少しでも減るように努力しましょう。こうしたノウハウは、ネットで「EFO（エントリーフォーム最適化）」というキーワードで検索すると多くの事例が多く出てきます。さらに詳しく知りたい人は試してみてください。
私が過去に一番苦労したのが郵便番号です。入力された郵便番号が実際に存在するかチェックしているプログラムがある場合、そのマスターデータに注意してください。市区町村合併の際に郵便番号は変わることがまれにありますし、大きな建物、事業所だと、その建物、事業所専用の郵便番号があります。これらがマスターデータに存在せずにエラーとなるケースがありました。皆さんも注意してください。
エントリーフォームにおける評価ポイント
- 入力画面から確認画面の遷移率の上昇
- 入力画面でのエラー発生率の抑制
- 確認画面から完了画面の遷移率の上昇
これらを個々に追いかけて、入力画面表示から完了画面表示までの遷移率を向上させましょう。
