離脱分析で困らないために、ポップアップの計測を見直そう

会員登録や購入手続きに進むボタンを押すと、その場にログイン・登録の画面がふわっと重なって開く。資料をダウンロードしようとすると入力フォームが開く。会員限定コンテンツを読もうとするとログインを求められる。こうした作りのサイトは少なくありません。

こうした窓の前で、一定数の人が引き返しています。ただ、その離脱は初期設定のままだとほとんど記録に残りません。これはアクセス解析の限界というより、記録する対象にこの窓を含めていないことが原因です。作り込んでいるサイトでは、この離脱もきちんと記録に残せています。

実際、次のようなケースはよく見られます。「商品ページのアクセス数は先月より増えているのに、会員登録の完了ページへの到達数はほとんど伸びていない」。原因を探ろうとしても、ログイン・登録の窓の表示や離脱は記録されていません。そこで何人が離脱したのか、確かめる術がないのです。

「商品ページのアクセス数」と「会員登録の完了ページへの到達数」の差は、原因を確かめる手立てがないため、「登録が面倒だったのだろう」という説明で済まされ、それ以上深掘りされずに終わりがちです。しかし実際には、その差の大部分が、フォームに入力し始める前、つまりポップアップが開いた時点や会員登録そのものをためらった時点で止まっているケースが多いのです。「入力項目が多いから離脱している」のか「そもそも登録を求められた時点で離脱している」のかは、まったく別の問題であり、対策も変わります。前者ならフォームの項目を減らせばよく、後者なら、会員登録なしで先に進めるようにする、登録の手間そのものを減らすといった対策が必要になります。

そもそも「ポップアップ」「モーダル」とは何か

まず言葉を揃えておきます。ここで扱うのは、ページを移動せずに画面の上に重なって開くタイプの窓です。

窓が開いても背景のページがそのまま残り、URLが変わらなければ、ページ遷移ではなくポップアップ／モーダルです。会員登録・購入手続きの直後に出る「ログイン／新規登録」の窓は、たいていこのタイプにあたります。

補足:URLが変わるかどうかが、記録の分かれ目です /login のような別ページに切り替わる作りなら、ページの切り替わりとして記録が残ります。URLが変わらずその場に重なって開くモーダルは、そのままでは記録が発生しません。実機で窓を開いた瞬間にアドレスバーが変わらなければ、記録から漏れやすいタイプだと判断できます。

なぜポップアップの離脱は記録されないのか

多くのアクセス解析は、ページが表示されたことを単位に記録を積み上げています。ページを移動するとURLが変わり、それが1回の記録として残ります。

ところがポップアップはURLが変わりません。表示された瞬間も、閉じて離脱した瞬間も、そのままでは記録が発生しないのです。表示・入力開始・離脱をそれぞれ記録の対象に加えない限り、痕跡は残りません。ボタンを押す手前と、登録後の完了ページは見えているのに、その間のポップアップ区間だけが記録からすっぽり抜け落ちる。これが「見えない離脱」の正体です。

事例:見積依頼の導線で、ポップアップが最大の離脱ポイントだった

BtoB製造業のA社(匿名)を支援した際も、まさにこの状態でした。A社のサイトの導線はこうなっていました。

1. 商品ページに来る

2. 「見積依頼」ボタンを押す。未ログインの場合、その場にログイン・会員登録を求めるポップアップが開く(既ログインの場合はポップアップを経由せず、そのまま3に進む)

3. ログイン・会員登録を済ませた人(またはもとからログイン済みの人)は、見積内容(数量や納期など)を入力するフォームに進む

4. 送信すると、見積受付完了ページに遷移する

このうち、記録が残るのは「1. 商品ページへのアクセス」「3. 見積フォームへの到達」「4. 完了ページへの到達」でした。「2. ボタンを押した後のポップアップ」だけはURLが変わらない画面のため、そもそもボタンが押されたことも、その後の離脱も、記録には残っていませんでした。1・3・4を見れば「見積フォームへの到達数が、商品ページのアクセス数に対して大きく落ち込んでいる」ことまでは分かります。しかし、その間にあるポップアップの状況が見えないため、なぜそこまで落ち込むのか、原因を特定できずにいたのです。

そこで、商品ページの「見積依頼」ボタンがクリックされた瞬間に、そのときユーザーが未ログインか、すでにログイン済みかという状態とあわせて、クリックの記録がログに残るようにしました。追加した記録はこれだけです。未ログインでクリックした人数が分かれば、そのままポップアップに遭遇した人数として扱えます。見積フォームへの到達や、完了ページへの到達(見積送信完了)はもともとページとして記録されていたので、これらとボタンクリックの記録を突き合わせるだけで、ポップアップでの離脱がどれだけ起きているかを計算できるようになりました。

※本記事内の数値は、A社の特定を避けるため加工しています。

記録を取り直してみると、見積依頼ボタンを押した226件のうち77.4%にあたる175件が未ログインでのクリックで、ポップアップに遭遇していました。このうち140件、全体の6割以上が、ログインや会員登録に進まないままポップアップの時点で離脱しており、見積フォームにたどり着けたのは残りの35件にとどまります。既ログインの51件とあわせても、見積フォームへの到達は86件です。フォーム側の離脱は20件にとどまっており、ポップアップでの離脱(140件)の方がはるかに規模が大きいことが分かります。フォームの入力項目を減らす対応をしていたら、的外れな改善になっていたはずです。

サイト改修なしで、どこまで直せるか

ボタンが押された、フォームが送信されたといった画面上の操作を記録するだけなら、既存のHTMLを変更しなくても対応できることが多く、実装は数日で終わります。ボタンや入力欄にすでについているclass名やid(HTML上の目印)を手がかりに、そのクリックや送信を検知できるため、ページ自体を作り替える必要はありません。今回のA社のケースも、見積依頼ボタンのクリックとその時点のログイン状態を記録する、この範囲で対応しました。

一方、見積金額や会員ランクなど、画面のclassやidだけでは分からない情報まで記録に含めたい場合は、話が変わります。これらの値はたいてい画面上にそのまま表示されておらず、サーバー側が内部で保持しているだけです。記録に使うには、まずサーバー側の処理を直してその値をページ内(data属性やJavaScript変数など)に渡してもらい、そのうえで渡された値をログ送信時にあわせて読み取るコードを追加する必要があります。表に出ていない値を新たに出してもらう工程が入る分、開発チームとの連携が前提になります。まず離脱の場所を可視化する段階であれば、大がかりな改修を待たずに着手できます。

記録できるようになって、初めて打ち手が選べる

離脱の場所が特定できると、施策は数字に基づいて選べるようになります。A社の場合も、ポップアップでの離脱が最大の離脱ポイント(140件)だと分かったことで、会員登録の壁をどう下げるかという次の検証に、根拠を持って進められるようになりました。

逆に、記録ができていない段階でいきなり施策を議論しても、効果を測る土台がありません。ポップアップのように標準では見えない区間こそ、施策より先に記録できる状態にする価値が大きい領域です。

加えて、記録は仕込んだ時点からしか貯まりません。過去に遡って取得することはできないため、対応を先送りにした分だけ、判断に使えるデータが揃うタイミングも遅れます。気づいた時点でなるべく早く記録を仕込んでおくことが、結果的に打ち手の判断を早めることにつながります。

まとめ

ログイン・会員登録を求めるポップアップは、URLが変わらないというだけの理由で、多くのサイトで離脱が記録されないままになっています。入口ページのアクセス数と完了ページへの到達数だけを見て「フォームのせいだろう」と決めつける前に、その間にポップアップがないか、あるならそこでの離脱が記録されているかを確認してみてください。数字が少ないのではなく、そもそも記録されていないだけかもしれません。記録は仕込んだ時点からしか貯まらないため、対応は早いほど良い判断材料につながります。