セッションのタイムアウト設定、
正しくできていますか

ウェブサイトの予約フォームや購入フォームで、セキュリティの担保などのために設定する「セッションをタイムアウトにする時間」。
サイトによって20分や30分など定めているかと思います。
貴社サイトではこの時間を、根拠を持って正しく設定できていますか?

2017年12月13日
セッションのタイムアウト設定、正しくできていますか

セッションタイムアウトの悲劇

ある、カウンセリングの予約サイトでは、その時間を10分と定めていました。具体的には、予約の日時をクリックすると、当日の連絡方法や、事前に相談の概要を記入してもらうフォームが表示され、ユーザは10分以内に入力・送信を完了することで予約が成立するようになっていました。
このフォームのセッションのタイムアウト時間を10分に設定していたのは、Google Analyticsでのフォームの平均滞在時間が5分強だったためです。

10分あればフォーム送信までたどり着けるはずであることと、もし予約完了しなくても、10分後には他のユーザーが予約をできるようにしてあげたいという考えもありました。
もちろん、たまにフォームの滞在時間が10分より長いユーザーはいたのですが、ブラウザを閉じないまま、実質は離脱しているのではないかと担当者は捉えていたのです。
しかし、ウェブサイト上で各ユーザがどのページを何秒閲覧していたのかを可視化できるツール「ユーザグラム」を確認したところ、事前の想定とは異なる事態が起きていました。

図のように、予約フォームで10分以上かけて、相談内容の詳細を記入していたのに、「予約の確定」ボタンを押そうとしたら、セッションが切れたというエラー画面が表示され、再度初めから予約手続きを行っているユーザーが一定数いたのです。
セッション切れになると「最初から入力をやり直してください。」というユーザーにとっては絶望的な気持ちになるエラーメッセージが表示されます。ユーザーが戸惑ったり、怒ってもおかしくない状況です。
再度初めから予約手続きを行ったユーザーがいた一方で、きっと、セッションタイムアウトなってしまったことで「もういい!」と利用を諦め、離脱したユーザも多くいたことは容易に想像できます。

ユーザグラムでこのデータを見たサイトの担当者は、急いでフォームのセッションタイムアウトの設定時間の延長を行ったそうです。

数値の「塊」ではなく「個」のユーザの観察から解釈を

今回のケースでは、担当者は、全体のユーザの平均滞在時間が設定しているセッション時間よりも短かったことから、セッション時間は10分で良いと判断していました。しかし、個のユーザの行動を見てみると、10分では時間切れになり、不満を抱えながら離脱してしまっているユーザーがいる可能性が高いことが明らかとなりました。

「平均」はあくまで全体の「平均」。
本例の通り、塊の「数値」では、誤った解釈をしてしまうケースがあります。
平均やボリュームなどから優先度をつけたりする時には数値の「塊」を見るべきですが、サイトの課題を発見したり、改善施策を検討する時には、一人一人の行動を紐解いて見ることが近道になることが多くあります。
まずは、貴社のセッションタイムアウトの設定によって、せっかくサイトを利用しようと思ったユーザの離脱を招いていないか、一度、ユーザグラムで確認してみるのはいかがでしょうか。

「ユーザグラム」をさらに知りたい方はこちら