レイジクリック・デッドクリックとは？｜クリックの異常が教えてくれるUXの詰まり

クリック数やページビュー(PV)の折れ線グラフは、ウェブサイトの調子を測る定番の指標です。ただ、それらの集計値は訪問者が快適に進めたかまでは教えてくれません。

同じ場所を何度もクリックしている、押しても何も起きない要素を繰り返しタップしている——そんなクリックの異常は、離脱率が悪化する前に現れる、いわば早期警報です。この記事では、その異常を指すレイジクリックとデッドクリックという2つの概念を、定義・原因・検出方法・改善への活かし方まで一通り解説します。

専門ツールを使い慣れていない方にも伝わるよう、専門用語は初出のたびにかみ砕きます。数字の裏で何が起きているかを具体的にイメージできるようになることを目指します。

クリック数だけでは「詰まり」が見えない理由

コンバージョン率(CVR)や直帰率は、結果としての数字です。訪問者が途中でどれだけイライラしたか、何度クリックし直したかは、その数字の裏側に隠れたままになります。

直帰率が高いページを見つけても、原因がそもそも興味がないからなのか、ボタンが反応せず諦めたからなのかは、集計指標だけでは区別がつきません。原因を取り違えたまま改善しても、見出しの文言を変えるような的外れな施策になりがちです。

ここで役に立つのが、クリックという最も細かい単位の行動に注目し、その中の異常値を拾い上げるという考え方です。ページ単位の平均を見るのではなく、一回一回のクリックが意図通りに機能したかを問うところが出発点になります。

似たような発想は、実務の現場では以前から使われてきました。カスタマーサポートにボタンを押しても反応しないという問い合わせが来て初めて不具合に気づいた、という経験がある方も多いのではないでしょうか。

異常クリックの計測は、その気づきを問い合わせが来る前に得られるようにする試みです。しかも、問い合わせをしてこない大多数の訪問者についても同じように把握できる点に価値があります。

レイジクリックとデッドクリックとは何か

どちらも、訪問者の操作ログから検出される行動シグナルです。呼び方や検出ロジックの細部はツールによって多少違いますが、業界で広く使われている定義を紹介します。

レイジクリックの定義

レイジクリックとは、短い時間の中で同じ要素、もしくはごく近い座標を何度も連続してクリックする行動を指します。目安としては、数秒以内に3回以上の連続クリックが集中した場合に検出されることが多く、これは人が「押したのに反応がない」と感じて無意識に押し直す動きに近いと考えられています。

名前の通り、背後には苛立ちがあることが多いものの、必ずしも怒りだけが原因とは限りません。読み込みが遅いだけで、実際にはあと数百ミリ秒待てば正常に動いていたというケースも珍しくなく、原因の見極めが重要になります。

デッドクリックの定義

デッドクリックとは、クリックしても画面上で何の変化も起きない要素へのクリックを指します。見た目はボタンやリンクのように見えるのに、実際にはただの画像やテキストで、リンク先が設定されていない場合などに起こります。

レイジクリックが連打という頻度の異常であるのに対し、デッドクリックは1回のクリックそのものが無効という質の異常です。両者は同時に起きることも多く、反応しない要素を連打した結果がレイジクリックとして記録される、という関係にあります。

なぜ2つを区別する意味があるのか

一括りに異常クリックとして扱わず、あえて2種類に分けるのには理由があります。レイジクリックは訪問者の心理的なストレスの強さを、デッドクリックは実装上の欠陥の有無を、それぞれ別の角度から教えてくれるからです。

同じページで両方が多発している場合は、単なる遅延ではなく要素そのものが機能していない可能性が高く、調査の初手を絞り込みやすくなります。逆にレイジクリックだけが多い場合は、実装よりも表示速度やローディング表現を疑うところから始めるとよいでしょう。

何が引き金になるのか、よくある原因のパターン

異常クリックは偶然のノイズではなく、多くの場合サイト側に共通の要因があります。ここでは代表的な3つのパターンに分けて見ていきます。

見た目はボタンなのに反応しない要素

もっとも多いのが、視覚的には押せそうに見えるが実際は押せない要素です。影付きの見出し、下線のないテキストリンク、無効化されたままのボタンなどが典型例として挙げられます。

CSSでボタン風の装飾だけを施した要素にクリックイベントが実装されていない、という実装漏れもよく見られます。デザインとエンジニアリングの間で、この要素は押せる想定かという前提の共有が漏れると起きやすい問題です。

フォームの送信ボタンやモーダルの閉じるボタンのように、押せなければ次に進めない要素で起きた場合は、ページ全体の離脱に直結しやすい点にも注意が必要です。

期待と結果のズレ

要素自体は正しく動作していても、訪問者が期待した結果と違う挙動をすればレイジクリックの原因になります。新しいタブが開いたのに気づかず元のタブで連打する、モーダルが画面外に表示されて見えていない、といったケースです。

読み込みに数秒かかる重い処理も同様です。処理中であることを示すローディング表示がなければ、訪問者は反応していないと判断して押し直すため、体感速度を示すUIの有無が結果を左右します。

モバイルとPCで現れ方が違う

同じ要素でも、指でタップするモバイルと、マウスで狙うPCとでは異常の出方が異なります。モバイルはタップ判定の範囲が指の面積より狭いと外れやすく、意図せず隣のリンクを押してしまう誤タップがデッドクリックとして記録されがちです。

一方PCでは、ダブルクリックの癖がある訪問者や、反応の遅い要素を確実に押そうとする人がレイジクリックを生みやすい傾向があります。集計を見るときはデバイス別に分けて確認すると、原因の見当がつけやすくなります。

デザイン変更やリリース直後に急増する

異常クリックの発生率は、常に一定というわけではありません。新しいデザインへの切り替えや機能リリースの直後に、それまで発生していなかった箇所で急に増えることがあります。

これは、変更前後でボタンの位置や見た目が変わり、訪問者が以前の記憶のまま操作してしまう学習のズレが一因です。リリース直後の数日だけ発生率が高く、その後は自然に落ち着くパターンもあります。

一方で、実装そのものに不具合が残っていて発生率が高止まりするパターンもあります。この2つは見た目が似ているため、リリース直後は特に注意して数字を追い、数日経っても下がらないようであれば実装の不具合を疑うという判断基準を持っておくと安心です。

検出の仕組みと使い分け

異常クリックの見つけ方には、大きく分けて2つのアプローチがあります。それぞれ得意なことが違うため、組み合わせて使うのが実務的です。

しきい値による自動検知

一つ目は、一定時間内のクリック回数がしきい値を超えたら自動でフラグを立てる集計的な方法です。ページ単位・要素単位で発生率を出せるため、サイト全体からまず怪しい場所を絞り込むのに向いています。

ただし、しきい値だけでは前章で触れた誤検知(癖やタップ精度由来の連打)を完全には除けません。件数が多い箇所ほど優先して調べる、というスクリーニングの役割だと考えるのが妥当です。

考え方を単純化すると、集計はおおよそ次のような条件でフラグを立てています。要素とセッションと時間窓の3つを組み合わせて、異常な集中を見つけているだけで、特別な仕組みではありません。

if クリック対象の要素が同一 and 直近3秒以内のクリック数 >= 3:
    そのセッション×要素を「レイジクリック候補」として記録する

if クリック後もページのDOMや遷移に変化が無い:
    そのクリックを「デッドクリック候補」として記録する

セッションリプレイでの目視確認

二つ目は、実際の訪問の様子を録画のように再生して確認するセッションリプレイです。何回クリックされたかという数字だけでなく、その直前に何を見て、何を期待していたのかという文脈まで追えるのが強みです。

MonaLensのセッションリプレイは入力内容を完全にマスクした状態で記録するため、個人情報を扱う不安なく、クリックの異常が起きた瞬間の画面遷移を確認できます。自動検知で絞り込んだ候補を、少数のセッションだけ目視で裏取りする、という使い分けが現実的な運用です。

ヒートマップとの役割分担

似た用途のツールに、クリックの密集度を色の濃淡で示すヒートマップがあります。ヒートマップはどこが多くクリックされているかを面で俯瞰するのに向いていますが、1回1回のクリックが正常に機能したかまでは教えてくれません。

異常クリックの検知は、その面の情報を個々のクリックの成否という点の情報まで掘り下げるものだと捉えると、両者の違いが理解しやすくなります。全体像はヒートマップで、疑わしい箇所の詳細はセッションリプレイで、という役割分担が基本になります。

どちらか一方だけを導入すればよいというものでもありません。ヒートマップだけではクリックが集中している理由まではわからず、セッションリプレイだけでは全ページを目視で追うのは現実的ではないからです。

両方を持っている場合は、まずヒートマップかしきい値検知で候補を絞り、そこから先だけをセッションリプレイで深掘りする流れが効率的です。

見つけた後の優先順位づけと改善のまわし方

異常クリックは見つけて終わりではありません。すべてを同時に直す余裕はないため、どこから着手するかを決める視点が必要です。

発生率×影響度で並べる

同じ発生率でも、購入ボタンで起きているデッドクリックと、フッターの装飾要素で起きているデッドクリックでは、事業への影響がまったく違います。発生件数だけでなく、そのページがLP改善や購入導線のどこに位置するかを掛け合わせて優先順位をつけます。

N1分析の考え方と同じで、まず一人の訪問者の詰まりを具体的に理解してから、それが他の訪問者にも共通するパターンかを確認する順番が有効です。数だけを追うと、影響の小さい箇所に時間を使いすぎてしまいます。

修正して終わりにしない

要素を修正したら、同じ場所で異常クリックの発生率が下がったかを再計測します。デザイン変更が別の場所に新しい詰まりを生むこともあるため、一度直して終わりではなく、仮説→修正→再計測を小さく回す前提で臨むのが安全です。

あわせて滞在時間の変化も見ておくと、クリックの詰まりが解消された結果として、ページ内での行動がスムーズになったかどうかを裏付けられます。件数が減っても離脱が減らなければ、まだ見えていない別の原因が残っている可能性があります。

チームでの運用に落とし込む

一人が気づいたときだけ調べる、という運用では見落としが増えます。週次のミーティングで発生率トップ数件を眺める時間を数分だけ確保するなど、小さくてもいいので定期的に見る仕組みを持つほうが長続きします。

誰が数字を見て、誰が修正の判断をするのかを決めておくことも重要です。プロダクトマネージャーが優先度を判断し、エンジニアが実装を直し、再計測して締めるという役割分担を先に決めておくと、見つけた異常が放置されにくくなります。

数値で見る影響のイメージ

ここからの数値はあくまで説明用の仮の例で、実在の計測結果ではありません。感覚をつかむための計算として読んでください。

月間1万セッションが訪れる購入ボタンで、デッドクリックの発生率が3%だったとします。単純化のため、発生したセッションのうち一定割合が離脱すると仮定すると、次のような試算になります。

10,000 × 3% × 30% で、月間およそ90セッションがこの一箇所の詰まりで離脱している計算になります。1つの要素だけならわずかに見えても、サイト内の複数箇所で同じことが起きていれば、積み上がって無視できない規模になり得ます。

なお、この試算はあくまで一つの仮定の置き方に過ぎません。実際には離脱する割合も、そのセッションが持っていた本来の価値もページごとに異なるため、優先度づけの参考値として使い、絶対値として一人歩きさせないことが大切です。

まとめ

レイジクリックとデッドクリックは、直帰率やCVRのような結果指標では見えない途中のストレスを教えてくれるシグナルです。連打という頻度の異常と、無反応というクリック自体の異常を区別して捉えると、原因の切り分けがしやすくなります。

しきい値による自動検知で候補を絞り込み、セッションリプレイで文脈を確かめ、影響度の大きい箇所から直して再計測する。この一連の流れを小さく回し続けることが、数字の裏にあるユーザー体験を地道に磨いていく近道です。

大きなリニューアルをしなくても、こうした小さな詰まりを一つずつ取り除いていくだけで、体感的な使いやすさは着実に積み上がっていきます。まずは発生率が高い上位数件だけでもよいので、実際のセッションを見るところから始めてみてください。