フォームで有った怖い事
当サービスとは関係ないのですが、仕事柄で色々とメールフォームを見てきて有った困った点をまとめて見ました。
これは実話です。
ブラウザバックの恐怖？
ブラウザバック（ブラウザーの戻るボタン）の挙動については、Webアプリを作っている人はいつも悩む内容だと思います。
Webアプリでのフォームにしても、お問合せのフォームにしても偶に見られるのですが、情報修正や申し込みの完了後に、なにげにブラウザーの戻るボタンを選択すると、報告ページ（サンクスページ）が表示されたり、場合によっては確認ページや入力ページまで戻れてしまう場合が有ります。
ここまで来ると、Webアプリの場合の動作の正しさや、お問合せフォームに設置したコンバージョンの処理ってどうなの？と思ってしまいます。
なぜこの様な事が発生するのかですが、よくある原因として以下があります。
- セッション内でのステート管理を行って無い。
- 処理が完了したときに不要なセッションを削除してない。
- formのpost処理や表示制御を正しく行って無い。
この様な場合は、ステート管理とセッション管理に注意する必要があります。
まず、ステート管理ですが、一般的なお問い合わせフォームでは、以下のステートがあります。
- デフォルト
通常は初回表示時の未入力な状態で入力ページを開いている状態です。
Webアプリケーションの場合は、既存情報が設定済みの場合も有ります。
- 入力済み（エラー）
何らかの入力が行われたが、入力内容の確認で問題があり、エラーメッセージを表示しながら入力ページで再入力を促している状態です。
- 入力済み（ノーエラー）
何らかの入力が行われて、入力内容の確認して問題ない状態で、入力ページを開いている状態です。
確認ページから「入力内容の修正」やブラウザバックで入力ページに戻ったときに発生します。
- 確認済み
入力内容の確認が行われ、問題がない無い事が検証され、確定処理前の内容確認ページを開いている状態です。
お問い合わせフォームの構成によっては省略される場合も有ります。
- 処理済み
何らかの確定処理（お問い合わせフォームならデータ保存後にメール送信等）が行われた結果、処理が完了した事を報告するページを開いている状態です。
通常このページでコンバージョンの処理を行います。
例えば、デフォルトや入力済み（エラー）の状態で、確認ページのURLを指定されても状態が正しく無いのが判るので、入力ページに遷移をさせる事が出来ます。
また、何らかのお問い合わせフォームで申し込みの完了後に、他のページに遷移をした後にブラウザバックで、お問い合わせフォームの報告ページが表示されてしまう場合もあります。
この様な時は、報告ページを表示する直前に、ステートに報告済み的な状態を設定するか、いっその事、お問い合わせフォームで利用したセッション情報を削除した方が良いと思います。
そうすると、報告ページへの再度のアクセスが有っても、ステートによる状態の判断か、セッションの有無で、自動的に入力ページ等に遷移を行わ事が出来ます。
そうせずに、報告ページが普通に表示されてしまうと、コンバージョン処理はJavaScriptベースで行っているクライアントサイドの処理なので、再表示が対象に成っているのか成ってないのか判らない事になってしまいます。