セッションリプレイとは？｜数字の裏にある行動を録画で読み解く

ファネル分析でコンバージョン率を追いかけ、離脱ページを特定し、A/Bテストで数字の変化を見る。ここまでは多くのチームがすでにやっていることだと思います。

けれど、数字がなぜそう動いたのかまでは、集計だけでは見えてきません。ある画面で3割前後が離脱しているという事実は分かっても、訪問者が実際に何を見て、どこで指を止め、何に戸惑って離れたのかは、グラフの向こう側に隠れたままです。

この数字の裏側を埋める手法として、この数年でウェブ解析の現場に定着しつつあるのが、セッションリプレイです。訪問者ひとりの画面操作を録画のように再生し、行動そのものを目で確認する計測手法を指します。

N1分析とはでは、一人の訪問者の行動ログを時系列で追う考え方を紹介しました。セッションリプレイは、このN1分析をさらに一歩進め、ログの数字ではなく画面の動きそのものを再生する手法だと考えると分かりやすいはずです。

ただし、便利さの一方で、他人の画面操作を録画するという行為には、プライバシー面での重い責任も伴います。便利さと責任は、常にセットで語られるべきです。

この記事では、セッションリプレイが何を明らかにしてくれる手法で、隣接するヒートマップとどう違うのか、そして何より、訪問者のプライバシーとどう両立させるべきなのかを整理していきます。

まずは、セッションリプレイという手法の中身から確認しましょう。

セッションリプレイとは何か

セッションリプレイとは、訪問者がブラウザ上で行ったクリック・スクロール・入力といった操作を裏側で記録し、あとから動画のように再生できるようにする計測手法です。

仕組みはシンプルです。ページに埋め込まれたスクリプトが、DOM(ページの構造を表すデータ)の変化とマウス・タッチの動きを差分データとして記録し、サーバーに送ります。

再生時には、この差分データを使ってブラウザ上でページを再構築します。動画ファイルを撮っているわけではなく、操作の記録から画面を再現しているという点が、実は後述するプライバシー設計にも関わってきます。

似た言葉に画面録画がありますが、画面録画が文字通りピクセルの動画を撮るのに対し、セッションリプレイは構造化されたデータの再生である点が異なります。この違いが、あとで説明するマスキングのしやすさにつながっています。

ピクセルの動画では、映り込んだ文字や画像をあとから伏せることは技術的にかなり難しくなります。構造化データであれば、特定の要素だけを狙って伏せるという処理が現実的な選択肢になるわけです。

構造化データであるということは、記録した後からでも、特定の要素だけを取り除いたり書き換えたりできるということでもあります。動画では不可能な、後からの加工がしやすいという性質は、意外と見落とされがちなポイントです。

用途もECサイトのカゴ落ち調査からSaaSのオンボーディング改善まで幅広く、業種を問わず使われています。共通しているのは、いずれも訪問者一人ひとりの文脈を知りたいという動機です。

差分データとはいえ、決済までの画面遷移が多い複雑な購入導線では、1セッションあたりの記録量が膨らみやすいため注意が必要です。あとで触れるサンプリング率の調整は、この観点からも重要になってきます。

なぜ数字だけでは分からないのか

ファネル分析はステップごとの通過率を教えてくれますが、なぜそのステップで離脱が集中するのかまでは語ってくれません。

離脱の理由は無数にあり得ます。次のような原因が、集計データの上ではすべて同じ離脱という1行に丸められてしまいます。

• フォームの必須項目が分かりにくく、何を入力すればよいか迷った。
• ボタンが小さい、あるいは反応が遅く見え、押したつもりで押せていなかった。
• 期待していた情報がそのページになく、探すのをやめてしまった。

以下はあくまで説明用の仮定であり、実データではありません。ここで、あるフォームの入力完了率が想定より低いと仮定してみます。

入力項目ごとの離脱率を見れば、特定の1項目で離脱が集中していることまでは分かります。ただ、その項目で訪問者が具体的に何をしていたかまでは、集計値から復元できません。

このとき、該当セッションのリプレイを数件見るだけで、原因の見当がつくことがよくあります。数字がどこでを教え、リプレイがなぜを補う、という役割分担だと捉えると整理しやすいはずです。

もう一つの仮の例として、同じ離脱率30%という数字でも、原因が入力欄の分かりにくさなのか、通信の遅さで画面が固まって見えたのかでは、打つべき対策がまったく違います。数字が同じでも、中身はまったく別物ということは珍しくありません。

この見分けにこそ、リプレイの価値があります。原因を取り違えたまま改修を進めると、労力をかけたのに数字が動かないという結果になりかねません。

ヒートマップとの違いを整理する

セッションリプレイとしばしば混同される手法に、ヒートマップがあります。この二つは似ているようで、得意な領域がはっきり分かれています。

ヒートマップは、多数の訪問者のクリック位置やスクロール到達率を1枚の画像に重ね合わせ、ページ全体の傾向を俯瞰する手法です。一方でセッションリプレイは、一人の訪問者の行動を時系列で追う手法であり、個別のつまずきを深掘りするのに向いています。

次の表に、両者と、これまでの記事で扱ってきたファネル分析を並べて整理しました。

三つは対立する手法ではなく、粗い網から細かい網へと段階的に絞り込んでいく道具だと捉えるのがよさそうです。まず数字で場所を絞り、次にヒートマップで傾向を確かめ、最後にリプレイで個別の事情を確認する、という順番になります。

順番を逆にすると、うまくいきません。いきなり全訪問者のリプレイを眺めても、どこに注目すればよいかの手がかりがなく、時間だけが過ぎていくことになりがちです。

手がかりを絞ってから見る、という順序そのものが技術です。この順序を飛ばしてしまうと、せっかくの手法も宝の持ち腐れになってしまいます。

プライバシーとどう両立させるか

ここまで読むと、他人の画面操作を録画するという行為に、抵抗を感じた方もいるかもしれません。それは自然な反応です。

Cookieを使わずに価値を出す解析のあり方が問われている今、セッションリプレイは、この問いが最も先鋭化する手法だと言えます。録画という言葉の響き自体が、訪問者の警戒心を刺激しやすいためです。

対策の基本は、記録する前の時点で、個人情報になり得る要素を伏せてしまうことです。パスワードやクレジットカード番号はもちろん、名前・住所・問い合わせ内容の自由記述といったテキストも、入力された文字をそのまま記録しないという設計が必須になります。

専任の法務担当がいない小規模なチームほど、この判断を後回しにしがちです。しかし、記録の仕組みそのものに関わる論点である以上、チームの規模にかかわらず、最初に決めておくべき事項だと考えたほうが安全です。

次の表は、マスキングの考え方を要素別に整理したものです。

重要なのは、この伏せ字化を再生する側の設定ではなく、記録する瞬間に行うことです。伏せた後のデータしかサーバーに送らなければ、そもそも生の入力内容がどこにも残りません。

再生時に隠すだけの実装だと、元データはサーバーのどこかに残ってしまいます。記録前にマスクするという設計思想の違いは、地味に見えて実はプライバシー設計の核心です。

加えて、記録したデータをいつまで保持するかも、あわせて決めておくべき論点です。役目を終えた記録を漫然と残し続けることは、リスクを増やすだけで得るものがありません。

必要な期間だけ残し、期限が来たら消すという発想を、最初の設計段階に組み込んでおくと後々の運用が楽になります。世界各地でウェブ上の個人データの扱いに関するルールが年々厳しくなっている流れを踏まえても、記録前提を控えめにしておくことは理にかなっています。

実務でどう使うか、三つの入口

概念が分かったところで、実務でどこから手を付けるとよいかを見ていきます。全セッションを片っ端から眺めるという使い方は、時間対効果が悪くお勧めできません。

一つ目の入口は、N1分析とはで扱った個別ユーザーの深掘りです。特定の訪問者の行動ログを見て気になる動きがあれば、そのセッションのリプレイを開いて答え合わせをする、という流れが自然です。

二つ目の入口は、離脱ページの見つけ方で特定した、離脱が集中しているページです。該当ページで発生したセッションのリプレイを数件サンプルで見るだけで、共通するつまずきのパターンが浮かび上がることがあります。

三つ目の入口は、滞在時間・エンゲージメントの正しい測り方で見た、滞在時間が極端に長い、または短いセッションです。長すぎる滞在は迷いや読み込みの多さを、短すぎる滞在は期待外れだった可能性を示唆しています。

どちらのケースも、実際のリプレイで裏を取る価値があります。いずれの入口でも、何十件も見る必要はなく、5件から10件も見れば、共通するパターンは意外と早く見えてくるというのが実務上の感覚です。

三つの入口に共通するのは、先に数字で対象を絞り込んでから、リプレイで少数を確認するという順序です。この順序を守るだけで、全件を眺めるよりずっと少ない労力で、多くの発見にたどり着けます。

見つけた発見をチームに共有するときも、一工夫が要ります。リプレイの映像そのものを会議で流すより、何が起きていたかを一文で要約し、その裏付けとしてリプレイを添えるという順番のほうが、議論が発散しにくくなります。

ファネル分析の基本で数字の異常に気づき、この三つの入口でリプレイに落とし込む、という流れを一つのセットとして覚えておくと、日々の運用に組み込みやすくなるはずです。数字とリプレイは、どちらか一方では完結しません。

よくある誤解を解いておく

セッションリプレイという言葉が独り歩きすると、いくつかの誤解が生まれがちです。ここで三つほど整理しておきます。

• 全訪問を録画しなければ意味がないという誤解。実際には、代表的な一部だけを記録するサンプリングでも、傾向をつかむには十分な場合がほとんどです。
• リプレイさえ見れば集計は不要という誤解。実際には逆で、ファネル分析の基本のような定量データが対象を絞り込んで初めて、リプレイは効率よく機能します。
• プライバシー対応は後から追加すればよいという誤解。実際には、記録の仕組みそのものに関わるため、後付けは設計のやり直しに近い手間がかかります。

いずれの誤解も、セッションリプレイを魔法の道具として捉えてしまうことから生まれます。実際には、既存の定量分析を補う、地道な確認作業の一つに過ぎません。

主役はあくまで定量データであり、リプレイは脇を固める役割だと捉えておくと、過度な期待も過度な軽視もせずに済みます。導入したばかりのチームほど、この期待値の置き方でその後の定着度合いが変わってきます。

導入前に確認しておきたいこと

最後に、実際に導入する前に確認しておきたい点を整理します。あれもこれも記録すればよいというものではありません。

まず、記録する対象のページを絞れるかどうかです。問い合わせフォームのように個人情報の入力が集中するページは、そもそも記録の対象から外すという判断もあり得ます。

次に、記録する割合、いわゆるサンプリング率ですが、すべての訪問を録画する必要は多くの場合ありません。むしろ、代表的な一部だけを記録するほうが、データ量を抑えつつ十分な数の事例を確保できます。

最後に、社内での閲覧範囲です。訪問者の操作記録である以上、誰でも自由に見られる状態にはせず、必要なチームに限定して運用するのが望ましいと言えます。

これは技術的な制約というより、組織としての運用ルールの問題です。誰が何の目的で見てよいかを、記録を始める前に決めておくことが、後々の無用なトラブルを避けます。

これら三点は、どれも導入後からでは直しにくい設計判断です。最初の設定でどこまで絞るかを決め切ってから、公開するくらいの慎重さがちょうどよいはずです。

Stride のセッションリプレイは、この記録前マスキングを前提に設計されており、入力内容や画像は常に伏せた状態でしか記録されません。製品を無理に売り込む記事ではありませんが、設計思想の一例として付け加えておきます。

セッションリプレイは、ファネルやN1分析が示すどこでという問いに、なぜという答えを添えてくれる手法です。ただし、その力は、記録する前の設計をどれだけ丁寧に作り込めるかにかかっています。

まずは離脱が集中しているページを一つ選び、伏せ字化を確認したうえで、数件のリプレイを見るところから始めてみてはどうでしょうか。数字だけを眺めていたときには気づかなかった発見が、案外すぐに見つかるはずです。