ヒートマップとセッション録画完全ガイド|違い・分析方法・ECサイト改善への活用手順
Webサイトのアクセス数、購入率、離脱率といった数値を確認すると、どのページで問題が発生しているかは把握できます。しかし、利用者がページ内のどこを見て、どこを押し、どの操作で迷ったのかまでは、一般的なアクセス解析だけでは十分に分かりません。購入率が低いことは分かっても、商品画像が見られていないのか、送料情報が見つからないのか、購入ボタンが押しにくいのかを判断するには、ページ内の行動をより細かく確認する必要があります。
ヒートマップは、多数の利用者のクリック、スクロール、移動などを集計し、色の分布として表示する分析方法です。セッション録画は、一人ひとりのページ閲覧や操作の流れを、画面上の再生形式で確認する方法です。どちらも利用者の行動を理解するために使われますが、得られる情報、分析単位、適した課題が異なります。
本記事では、ヒートマップとセッション録画の違い、取得できる情報、標準的な導入手順、分析方法、ECサイトやランディングページへの活用方法を詳しく解説します。単に画面を眺めるのではなく、仮説を立て、問題を分類し、UI改善と効果測定へつなげるための実務的な進め方を紹介します。
1. ヒートマップとセッション録画とは
ヒートマップとセッション録画は、Webサイト内で利用者がどのように行動しているかを可視化する分析方法です。一般的なアクセス解析がページ単位の訪問数や購入率を示すのに対し、これらはページ内の具体的な行動を確認するために使われます。
ただし、取得された行動だけで、利用者の考えや感情を完全に理解できるわけではありません。行動データから考えられる原因を仮説として立て、アンケート、問い合わせ、ユーザビリティテストなどと組み合わせることが重要です。
1.1 ヒートマップとは
ヒートマップとは、複数の利用者が行ったクリック、タップ、スクロール、ポインター移動などを集計し、反応が多い場所を色で示す分析方法です。一般的には、反応が多い場所を暖色、少ない場所を寒色で表現します。
一人の操作を詳しく追うのではなく、多数の行動をまとめて確認できるため、ページ全体の傾向を把握するのに適しています。どの要素が多く押されているか、どこまで読まれているか、意図しない場所が操作されていないかを短時間で確認できます。
1.2 セッション録画とは
セッション録画とは、特定の利用者がページ内で行ったスクロール、クリック、入力、ページ移動などを時系列で再現する分析方法です。実際の動画をそのまま録画する方式ではなく、取得した画面構造と操作情報をもとに再構成する仕組みが一般的です。
一人の行動を開始から終了まで確認できるため、クリック前の迷い、同じ場所を何度も押す行動、フォーム入力後の離脱などを理解しやすくなります。集計結果だけでは分からない、操作の順序と文脈を確認できます。
1.3 アクセス解析との関係
アクセス解析では、ページ表示数、流入元、滞在時間、購入率、離脱率などを確認できます。これらは、問題があるページや利用者層を特定するために重要です。
ヒートマップとセッション録画は、アクセス解析で見つけた問題の原因を深く調べるために使用します。購入率が低いページをアクセス解析で特定し、そのページのクリック分布やセッション録画を確認するという順序が有効です。
| 分析方法 | 主に確認できる内容 | 主な役割 |
|---|---|---|
| アクセス解析 | 訪問数、購入率、離脱率 | 問題ページの特定 |
| ヒートマップ | クリック、スクロールの集計 | 行動傾向の確認 |
| セッション録画 | 一人の操作の流れ | 迷いや障害の発見 |
| アンケート | 意見、理由、要望 | 行動理由の確認 |
| ユーザビリティテスト | 課題中の発言と操作 | 原因の直接観察 |
1.4 行動データから分かること
行動データからは、利用者が実際に行った操作を確認できます。例えば、購入ボタンより商品画像が多く押されている、送料説明の手前で多くの利用者が離脱しているといった傾向を把握できます。
一方、「なぜその操作をしたか」はデータだけでは確定できません。画像が多く押されている理由は、拡大したいからか、画像がリンクに見えるからか、商品詳細へ移動できると思ったからかもしれません。行動と理由を分けて考える必要があります。
1.5 導入前に決めるべき目的
導入時には、「利用者の行動を見たい」という曖昧な目的ではなく、改善したい指標や調べたい課題を明確にします。商品ページのカート追加率、フォーム完了率、キャンペーンページのスクロール率など、対象を具体化します。
目的がないまま大量の録画を確認すると、珍しい操作だけに注目しやすくなります。仮説、対象ページ、対象利用者、確認期間を決めてから分析を開始します。
2. ヒートマップとセッション録画の違い
ヒートマップとセッション録画は、同じ利用者行動分析に分類されますが、分析する単位と得られる理解が異なります。ヒートマップは多数の行動をまとめた傾向、セッション録画は一つの訪問内での操作の流れを示します。
どちらか一方が優れているわけではありません。問題の規模を把握するヒートマップと、問題が起きる流れを確認するセッション録画を組み合わせることで、より具体的な改善案を作れます。
2.1 分析単位の違い
ヒートマップは、一定期間に集まった複数の訪問を一つの画面へ重ねて表示します。そのため、多くの利用者に共通する行動を見つけやすい方法です。
セッション録画は、一回の訪問または一人の利用者単位で再生します。個別性が高く、集計では見えない操作順序を理解できます。
| 比較項目 | ヒートマップ | セッション録画 |
|---|---|---|
| 分析単位 | 多数の訪問を集計 | 一回の訪問 |
| 確認方法 | 色の分布 | 時系列で再生 |
| 得意な分析 | 共通傾向 | 個別の行動過程 |
| 分析時間 | 比較的短い | 一件ずつ確認が必要 |
| 主な用途 | 問題箇所の発見 | 問題原因の深掘り |
2.2 得られる情報の違い
ヒートマップでは、クリックされた位置、読まれた深さ、反応が集中する場所などを把握できます。どの要素が強く注目されているかを確認するのに適しています。
セッション録画では、操作前に何度も上下へスクロールした、入力後に説明へ戻った、ボタンを押した後に反応を待ったといった流れを確認できます。
| 確認内容 | ヒートマップ | セッション録画 |
|---|---|---|
| 多く押される場所 | 確認しやすい | 複数件の確認が必要 |
| 操作の順番 | 分かりにくい | 確認しやすい |
| 迷っている時間 | 分かりにくい | 確認しやすい |
| ページ全体の読了傾向 | 確認しやすい | 個別確認になる |
| 特定エラー発生時の行動 | 限定的 | 確認しやすい |
2.3 分析速度の違い
ヒートマップは、一つの画面を見るだけで多数の行動傾向を把握できます。最初の問題発見や、改善前後の比較に向いています。
セッション録画は、再生時間と分析時間が必要です。すべての録画を見るのではなく、購入失敗、フォーム離脱、繰り返しクリックなどの条件で絞り込みます。
| 分析段階 | 適した方法 | 理由 |
|---|---|---|
| 問題箇所の初期確認 | ヒートマップ | 全体を短時間で確認できる |
| 特定行動の原因調査 | セッション録画 | 操作前後を追跡できる |
| 改善案の優先順位 | 両方 | 規模と深刻さを判断できる |
| 改善後の傾向比較 | ヒートマップ | 分布変化を比較しやすい |
| 例外的な不具合調査 | セッション録画 | 発生過程を確認できる |
2.4 問題発見方法の違い
ヒートマップでは、反応が集中している場所や、反応が少ない重要要素を探します。多数の利用者がリンクではない場所を押している場合、見た目が操作可能に見えている可能性があります。
セッション録画では、通常とは異なる行動を探します。短時間で何度も押す、同じ範囲を往復する、入力直後に離脱するなどの行動が問題の手掛かりになります。
2.5 適切な使い分け
最初にヒートマップでページ内の問題箇所を見つけ、その箇所を操作したセッション録画を確認する流れが効率的です。例えば、送料リンクがほとんど押されていないことをヒートマップで確認し、購入を中断した録画で送料情報を探す動きを確認します。
反対に、問い合わせや障害報告から具体的な問題が分かっている場合は、セッション録画から開始しても構いません。目的に応じて分析順序を変えます。
3. ヒートマップの種類
ヒートマップには、クリック、スクロール、ポインター移動、注目時間など、複数の形式があります。すべての形式が同じ意味を持つわけではないため、調査目的に合ったものを選びます。
複数のヒートマップを同時に確認すると、より正確に判断できます。クリックが多いだけでなく、そもそも表示された割合が高いかをスクロール情報と合わせて確認します。
3.1 クリックヒートマップ
クリックヒートマップは、パソコンでのクリックやスマートフォンでのタップが発生した位置を集計します。ボタン、リンク、画像などが実際に操作されているかを確認できます。
重要な購入ボタンに反応が少ない場合でも、ボタン自体の問題とは限りません。ボタンまで到達した人数が少ない可能性があるため、スクロール情報と組み合わせます。
| 確認項目 | 発見できる可能性がある問題 |
|---|---|
| 非リンク部分への反応 | 操作可能に見える |
| 購入ボタンへの反応不足 | 位置、文言、価値訴求が弱い |
| 小さなリンクへの集中 | 主要情報が不足している |
| 同じ場所への繰り返し反応 | 処理遅延、反応不足 |
| 閉じる操作への集中 | 表示内容が不要、邪魔になっている |
3.2 スクロールヒートマップ
スクロールヒートマップは、ページ内の各位置まで到達した利用者の割合を示します。ページ上部は多くの利用者が見ていますが、下へ進むほど到達率は低下します。
重要情報が到達率の低い位置にある場合、配置変更が必要です。ただし、下部まで到達しないことが必ずしも問題ではありません。上部だけで購入判断が完了している可能性もあります。
| 到達状況 | 考えられる状態 |
|---|---|
| 上部で急激に低下 | 第一表示領域が期待と一致していない |
| 特定位置で低下 | 内容の区切り、長文、表示問題 |
| 購入ボタン前で低下 | 商品価値や条件が不足 |
| 購入後の情報まで到達しない | 上部で判断が完了している可能性 |
| 下部まで高い到達率 | 内容への関心が高い、情報を探している |
3.3 移動ヒートマップ
移動ヒートマップは、パソコン利用者のポインターが移動した場所を集計します。利用者が読んでいる部分とポインター位置が一致する場合もありますが、必ず一致するわけではありません。
視線計測と同じものとして扱ってはいけません。ポインターを画面端へ置いたまま読む利用者もいるため、クリックやスクロール情報の補助として使用します。
3.4 注目時間ヒートマップ
注目時間ヒートマップは、各領域が画面内に表示されていた時間などをもとに、どの部分が長く見られた可能性があるかを示します。
長く表示された領域が、必ず高く評価されているとは限りません。内容が分かりにくく、読むのに時間がかかった可能性もあります。理解しやすさを判断するには、セッション録画や利用者テストを組み合わせます。
3.5 端末別ヒートマップ
パソコン、スマートフォン、タブレットでは、画面構成と操作方法が異なります。すべての端末をまとめたヒートマップでは、問題が平均化される可能性があります。
スマートフォンではタップ位置、固定ボタン、画面下部の操作を重点的に確認します。パソコンではマウスを重ねた反応や横方向の配置も確認します。
| 端末 | 重視する確認項目 |
|---|---|
| パソコン | クリック、横配置、固定領域 |
| スマートフォン | タップ、縦スクロール、固定ボタン |
| タブレット | 画面方向、タップ領域 |
| 小型画面 | 文字の重なり、操作密度 |
| 大型画面 | 余白、視線の分散 |
4. セッション録画で確認できる行動
セッション録画では、単なる操作位置だけでなく、操作が行われるまでの流れを確認できます。利用者が何度も同じ場所を見たり、入力後に前の説明へ戻ったりする行動は、情報不足や不安を示す可能性があります。
一件だけの珍しい行動で大きな変更を決めず、同じ傾向を持つ複数の録画を確認します。問題の頻度と事業への影響を合わせて判断します。
4.1 迷いを示す往復スクロール
ページ内を何度も上下へ移動する行動は、必要な情報を探している可能性があります。商品仕様を見た後に価格へ戻り、再び配送条件へ移動する場合、情報配置が分散していることが考えられます。
ただし、複数の商品を慎重に比較しているだけの場合もあります。購入完了した録画と離脱した録画を比較し、問題行動か通常行動かを判断します。
4.2 反応しない場所へのクリック
利用者がリンクではない画像や見出しを押している場合、見た目と機能が一致していません。商品画像を押しても拡大しない、カード全体が押せそうに見えるのに商品名だけがリンクであるといった問題が考えられます。
一回の誤クリックではなく、複数回の繰り返しや複数利用者での発生を確認します。必要に応じてリンク化するか、操作可能に見えないデザインへ変更します。
4.3 短時間の繰り返しクリック
同じボタンを短時間で何度も押す行動は、処理が受け付けられたことが伝わっていない可能性があります。カート追加、フォーム送信、クーポン適用などで発生しやすい問題です。
押下直後の状態変化、処理中表示、完了通知を追加します。重複注文や数量の意図しない増加を防ぐため、処理中の再操作も制御します。
4.4 フォーム入力後の離脱
入力途中または送信直前の離脱を確認すると、どの項目で負担が増えているかを推測できます。住所入力、電話番号、会員登録要求などが原因になる場合があります。
入力内容そのものを閲覧する必要はありません。どの項目で停止したか、エラーが発生したか、説明へ戻ったかを確認します。個人情報や機密情報が記録されない設定を徹底します。
4.5 戻る操作と再確認
商品詳細から一覧へ戻り、別の商品を開く動きは通常の比較行動です。しかし、購入直前に何度も送料や返品条件へ戻る場合、重要な不安が解消されていない可能性があります。
戻る操作を減らすこと自体を目的にせず、利用者が必要な情報へ短時間で到達できるかを評価します。
| 行動 | 考えられる原因 |
|---|---|
| 上下の往復 | 情報が分散している |
| 同じ場所を連続で押す | 反応が遅い、状態が伝わらない |
| 非操作部分を押す | 見た目と機能が不一致 |
| 入力後に説明へ戻る | 条件が分かりにくい |
| 購入直前に離脱 | 価格、送料、信頼への不安 |
5. ヒートマップが適している課題
ヒートマップは、ページ全体で多くの利用者に共通する行動を確認したい場合に適しています。改善対象が明確でなく、まず問題箇所を広く探したい段階で役立ちます。
一方、特定の利用者がなぜエラーになったか、どの操作順序で離脱したかを確認するには、セッション録画の方が適しています。
5.1 重要要素が操作されているか確認する
購入ボタン、資料請求、商品画像、検索、絞り込みなど、主要要素への反応を確認できます。制作側が重要だと考えている要素と、利用者が実際に操作する要素を比較します。
反応が少ない場合は、表示位置だけでなく、その操作を行う価値が伝わっているかを確認します。ボタンを大きくするだけでは解決しない場合があります。
5.2 情報配置を評価する
スクロール到達率から、重要情報が適切な位置にあるかを確認できます。送料、返品、商品特徴などがほとんど見られていない場合、上部へ移動することを検討します。
ただし、すべての情報を上部へ集めると、第一表示領域が複雑になります。購入判断への影響が大きい情報を優先します。
5.3 不要な要素を見つける
表示面積を大きく使っているにもかかわらず、ほとんど反応されていない要素は、削減候補になります。大型バナー、装飾画像、長い説明などが対象です。
反応がないことだけで不要と判断してはいけません。信頼性を高めるロゴや保証説明など、クリックされなくても役割を持つ情報があります。
5.4 改善前後を比較する
ボタン位置、見出し、商品画像などを変更した前後で、クリック分布やスクロール到達率を比較できます。
期間、流入元、端末、キャンペーン条件をそろえなければ、デザイン変更以外の影響が混ざります。可能な範囲で同じ条件に分けて比較します。
5.5 複数ページの傾向を比較する
商品カテゴリ、ランディングページ、記事ページなど、同じ構造を持つ複数ページの反応を比較できます。特定ページだけに起きている問題か、共通部品の問題かを判断できます。
ページ内容や流入意図が異なる場合は、単純な数値比較を避けます。同じ目的を持つページ間で比較します。
6. セッション録画が適している課題
セッション録画は、行動の順序や問題発生前後を確認したい場合に適しています。特に、フォーム、購入手順、検索、絞り込みなど、複数の操作が連続する画面で役立ちます。
録画数が多い場合は、目的に合った条件で絞り込みます。すべてを順番に見る方法では、重要な問題へ到達するまでに時間がかかります。
6.1 購入失敗の原因を調べる
商品をカートへ追加したものの購入しなかった訪問を抽出し、どの段階で迷いや離脱が発生したかを確認します。
決済画面だけでなく、商品ページでの情報確認から追跡します。送料への不安が商品ページで発生し、決済画面で離脱している場合があります。
6.2 フォームエラーを調べる
エラーが発生した録画を確認し、入力形式、エラー文、フォーカス移動、修正操作を分析します。
同じ項目で複数人がエラーになる場合、入力例や形式制限が分かりにくい可能性があります。利用者の注意不足として処理せず、設計上の改善を検討します。
6.3 検索失敗を調べる
検索語入力後に結果が表示されない、条件変更を繰り返す、検索後すぐ離脱するといった行動を確認できます。
検索語と結果の関係、候補表示、表記揺れなどを見直します。検索結果がゼロの場合は、別の語句やカテゴリへ導く仕組みを用意します。
6.4 不具合を再現する
問い合わせで「ボタンが押せない」「表示が崩れた」と報告された場合、該当条件の録画があれば発生時の画面状態を確認できます。
録画だけで技術的な原因が分かるとは限りません。端末、ブラウザ、通信、エラーログなどを合わせて調査します。
6.5 新しい利用方法を発見する
想定していなかった使い方や情報の探し方が見つかる場合があります。利用者が商品比較のために画像を何度も切り替える、説明文を別画面と行き来するなどの行動です。
例外的な一件ではなく、同様の行動が複数あるか確認します。実際の需要がある場合は、比較機能や情報配置を改善します。
7. 標準的な導入プロセス
ヒートマップとセッション録画は、計測タグを設置しただけでは成果につながりません。目的設定、計測範囲、個人情報保護、分析、改善、再測定までを一つのプロセスとして設計します。
特に、取得できるからという理由ですべてのページと操作を記録しないようにします。必要な範囲に限定し、管理権限と保存期間を決めます。
7.1 改善対象を決める
売上や利用者への影響が大きいページから対象を選びます。商品詳細、カート、決済、問い合わせ、主要なランディングページなどが候補です。
アクセス数が少なすぎるページでは、ヒートマップの傾向を判断できない場合があります。その場合は、セッション録画や利用者テストを優先します。
7.2 仮説を設定する
「送料情報が見つからず購入を中断している」「商品画像がリンクに見える」といった仮説を設定します。
仮説があると、確認するヒートマップや録画条件を絞れます。分析後に仮説が間違っていた場合も、その結果を記録します。
7.3 計測条件を設定する
対象URL、端末、流入元、利用者種別、保存期間などを決めます。公開環境と検証環境を混ぜないようにします。
会員ページや管理画面など、個人情報を多く含むページは、記録対象から除外することを検討します。
7.4 データを一定期間収集する
曜日、広告、キャンペーンなどの影響を考慮し、十分な期間を設定します。アクセスが多いページでは短期間でも傾向を把握できますが、アクセスが少ないページでは長い期間が必要です。
期間中に大きなデザイン変更や販売条件変更を行った場合は、変更前後のデータを分けます。
7.5 改善後に再測定する
改善を公開した後、同じ条件でヒートマップとセッション録画を確認します。行動の変化だけでなく、購入率、完了率、エラー率も測定します。
クリックが増えたことだけで成功と判断しません。購入完了や問い合わせ削減など、最初に設定した事業指標へつながったかを確認します。
| 工程 | 主な作業 | 出力 |
|---|---|---|
| 対象選定 | 重要ページを決める | 分析対象一覧 |
| 仮説設定 | 問題原因を予想する | 仮説文 |
| 計測設定 | 範囲、端末、除外条件 | 計測仕様 |
| 行動分析 | 傾向と個別行動を確認 | 発見事項 |
| 改善実施 | UIや情報を変更する | 改善版 |
| 再測定 | 指標と行動を比較する | 効果評価 |
8. 分析前に仮説と指標を設定する方法
仮説を設定せずに行動データを見ると、目立つ操作や珍しい録画へ注意が偏ります。改善したい指標と、それを妨げている可能性がある要因を文章化します。
一つのページに複数の問題がある場合でも、最も事業影響が大きい仮説から確認します。すべてを同時に変更すると、改善効果の原因が分からなくなります。
8.1 事業指標を決める
ECサイトでは、カート追加率、購入完了率、平均注文額、返品率などを設定できます。ランディングページでは、問い合わせ率や資料請求率が対象になります。
ページ内のクリック数は中間指標です。最終的な事業成果へつながっているかを確認します。
8.2 行動指標を決める
購入ボタンへの反応、送料説明の表示、入力エラー、ページ内検索など、改善仮説と関係する行動を決めます。
取得できる指標だけを使うのではなく、仮説の確認に必要な指標を選びます。必要に応じて独自の行動イベントを追加します。
8.3 対象利用者を分ける
新規訪問者と既存顧客、スマートフォンとパソコン、広告流入と検索流入では、行動目的が異なります。
全体平均だけを見ると、特定利用者層の問題が隠れます。主要顧客層を先に分析し、その後に他の層と比較します。
8.4 成功基準を決める
「購入ボタンへの反応率を上げる」ではなく、「カート追加率を現在値から一定範囲改善する」のように基準を設定します。
行動の変化だけでなく、悪影響の上限も決めます。カート追加率が上がっても返品率が増える場合は、商品説明が不足している可能性があります。
8.5 記録形式を統一する
仮説、証拠、改善案、優先度、担当者、効果を同じ形式で記録します。録画への内部参照やヒートマップ画像も関連付けます。
分析担当者の感想だけでなく、発生件数や対象利用者を記載します。後から意思決定の理由を確認できる状態にします。
仮説記録の例
対象ページ:商品詳細ページ
事業指標:カート追加率
仮説:送料と到着予定日が購入ボタンから離れているため、購入前に利用者が不安を解消できていない。
確認する行動:・送料説明付近のクリック・購入ボタン前後の往復スクロール・カート追加前の滞在時間・送料ページへの移動後の離脱
改善案:購入ボタンの近くへ送料と到着予定日を表示する。
確認する結果:カート追加率、送料ページ移動率、購入完了率
9. ECサイトへの活用方法
ECサイトでは、商品発見から購入完了まで複数のページと操作があります。ヒートマップとセッション録画を使うと、どの段階で判断が止まり、何を探しているかを確認できます。
購入率だけを高めるのではなく、誤購入、返品、問い合わせを増やさない改善が必要です。利用者が正しい情報を理解したうえで購入できるかを評価します。
9.1 商品一覧を分析する
商品カード、絞り込み、並び替え、ページ移動などへの反応を確認します。利用者がどの情報を使って商品を比較しているかを把握できます。
商品画像ばかり押され、価格や評価がほとんど見られていない場合、画像中心で選ばれている可能性があります。反対に、詳細ページを何度も往復している場合は、一覧情報が不足している可能性があります。
9.2 商品詳細を分析する
商品画像、価格、レビュー、サイズ、送料、購入ボタンへの行動を確認します。購入前に何度も見直されている情報は、不安の大きい要素である可能性があります。
重要情報が下部にある場合は、上部へ概要を移動します。ただし、詳細説明をすべて第一表示領域へ詰め込まないようにします。
9.3 カート画面を分析する
数量変更、削除、クーポン、送料確認、購入手続きへの反応を確認します。購入ボタン以外の操作が集中している場合、条件確認や価格調整が必要とされています。
カート画面で戻る操作が多い場合、商品情報や配送情報を再確認している可能性があります。必要な情報をカート内に表示することを検討します。
9.4 決済画面を分析する
入力エラー、支払方法変更、配送先修正、規約確認などを追跡します。決済画面は個人情報を多く扱うため、記録対象とマスキング設定を特に慎重に管理します。
フォーム離脱だけでなく、同じ項目への再入力やエラー修正時間も確認します。入力支援、形式例、自動補完を改善します。
9.5 購入完了後を分析する
注文完了画面で、注文番号、配送予定、会員登録、買い物継続などが確認されているかを分析します。
注文が成立したか分からず、ページを再読み込みしたり戻ったりしている場合は、完了表示が不十分です。装飾よりも注文結果を優先して表示します。
| EC画面 | 主な分析対象 |
|---|---|
| 商品一覧 | 比較情報、絞り込み、商品カード |
| 商品詳細 | 画像、価格、送料、購入操作 |
| カート | 数量、削除、クーポン、合計金額 |
| 決済 | 入力、エラー、支払、配送 |
| 完了画面 | 注文成立、配送予定、次の行動 |
10. ランディングページとフォームへの活用方法
ランディングページでは、広告メッセージとページ内容の一致、訴求の順序、申込導線を確認できます。フォームでは、入力負担やエラーの発生箇所を詳しく分析できます。
ページが長い場合は、スクロール到達率だけでなく、どの内容を確認した後に申込へ進んだかを録画で確認します。
10.1 第一表示領域を確認する
利用者が最初に見る見出し、画像、主要ボタンへの反応を確認します。下へ進まず離脱している場合、広告から期待した内容と一致していない可能性があります。
スクロールが少ないことだけで問題と判断せず、第一表示領域のボタンから申込が完了しているかを確認します。
10.2 訴求の順序を確認する
商品利益、事例、価格、保証など、どの情報が読まれた後に申込操作が行われるかを分析します。
重要情報を早く見せれば必ず改善するわけではありません。利用者が理解するために必要な順序を維持します。
10.3 長文の読まれ方を確認する
スクロール到達率と注目時間から、長文のどこで関心が低下しているかを確認します。大きな画像や余白によって、内容が終了したと誤解される場合もあります。
見出し、要点、図解を使って読みやすくします。単純に文章量を減らすだけで、必要な説明まで失わないようにします。
10.4 フォーム開始率を確認する
フォームが表示された人数と、最初の入力を始めた人数を比較します。フォームを見た時点で項目数や個人情報要求に負担を感じている可能性があります。
必要項目を減らし、入力目的を説明します。任意項目は明確に区別します。
10.5 項目別の離脱を確認する
どの入力欄で操作が止まったか、どのエラーが繰り返されているかを確認します。
入力内容そのものを分析する必要はありません。項目の開始、完了、エラーといった状態だけでも改善材料になります。
11. ヒートマップを分析する手順
ヒートマップは色が強い場所だけを見るのではなく、ページの目的、表示された人数、端末、流入元を考慮して分析します。
反応が多い場所を「人気」、少ない場所を「不要」と単純に判断しないことが重要です。行動の意味を仮説として記録します。
11.1 端末と利用者層を分ける
最初にスマートフォンとパソコンを分けます。レイアウトと操作方法が異なるため、同じ画面として分析できません。
新規と既存、広告と自然検索など、目的が異なる利用者層も必要に応じて分けます。
11.2 スクロール到達率を確認する
ページ上部から下部まで、到達率がどのように変化するかを確認します。急激に低下する位置を探します。
低下位置の直前に、大きな余白、広告、長文、区切り線などがないか確認します。ページが終了したように見えていないかを評価します。
11.3 クリック分布を確認する
主要操作、補助リンク、非リンク部分への反応を確認します。意図した優先順位と実際の反応を比較します。
利用者が必要としている操作が別の場所に集中している場合、主要導線を見直します。
11.4 表示割合とクリックを合わせる
ページ下部のボタンは、クリック数が少なくても、表示された利用者の中では高い割合で押されている可能性があります。
全訪問数だけで割らず、対象要素が表示された訪問数を基準に考えると、より正確に評価できます。
11.5 改善候補を優先順位付けする
多くの利用者へ影響し、事業指標との関係が強く、修正可能な問題を優先します。
色の強さだけで優先度を決めず、発生規模、購入への影響、実装負担、確認の確実性を評価します。
| 評価項目 | 確認内容 |
|---|---|
| 発生規模 | 何人に影響しているか |
| 事業影響 | 購入や申込を妨げるか |
| 深刻度 | 誤購入や操作不能につながるか |
| 確実性 | 複数の証拠があるか |
| 修正負担 | 改善に必要な工数 |
12. セッション録画を分析する手順
セッション録画は、すべてを順番に再生するのではなく、目的に合う訪問を条件で抽出します。録画を見る前に、探す行動と分類方法を決めます。
一人の行動に強く影響されず、同じ問題を示す複数件をまとめます。正常に完了した録画との比較も重要です。
12.1 条件で録画を絞り込む
購入未完了、フォームエラー、長い滞在、特定ページ訪問、繰り返しクリックなどの条件を使用します。
対象を狭くしすぎると、別の原因を見落とす可能性があります。最初は広い条件で確認し、共通傾向が見つかったら絞り込みます。
12.2 操作前後を確認する
問題が発生した瞬間だけでなく、その前に何を確認していたか、発生後にどう対応したかを見ます。
購入ボタンを何度も押した原因が、ボタン自体ではなく、直前の選択項目が未完了だったという場合もあります。
12.3 正常な録画と比較する
購入できなかった録画だけを見ると、すべての行動が問題に見えます。購入完了した利用者が同じ操作をしているか比較します。
正常利用者にも共通する往復スクロールであれば、商品比較の通常行動である可能性があります。
12.4 行動を分類する
迷い、誤クリック、繰り返し操作、エラー、表示不具合、情報探索などの分類を使用します。
一つの録画に複数の問題がある場合は、主な問題と補助的な問題を分けます。分類規則を分析者間で共有します。
12.5 証拠を記録する
録画の内部参照、発生位置、端末、流入元、発生した行動、考えられる原因を記録します。
個人を識別する情報や入力内容を報告書へ含めないようにします。改善に必要な行動だけを記録します。
録画分析の記録例
対象:スマートフォンの商品購入未完了セッション
観察した行動:・サイズ選択後に購入ボタンを3回タップ・エラーメッセージが画面上部に表示・利用者はエラーへ気付かず再操作・その後、商品一覧へ戻って離脱
考えられる問題:エラー表示が操作位置から離れており、画面内に表示されていない。
改善案:購入ボタン付近にエラー概要を表示し、問題のある選択肢へフォーカスを移動する。
追加確認:同じエラーが発生した録画件数と端末条件
13. ヒートマップとセッション録画を組み合わせる方法
ヒートマップは問題の規模を示し、セッション録画は問題が起きる過程を示します。両方を組み合わせると、改善案の根拠を強くできます。
さらに、アクセス解析、問い合わせ、利用者テストを加えることで、行動、結果、理由を異なる角度から確認できます。
13.1 ヒートマップから録画へ進む
クリックヒートマップで非リンク部分への反応を見つけたら、その場所を押した録画を確認します。
一度押してすぐ別操作へ進んでいるのか、何度も押して困っているのかによって、問題の深刻さが異なります。
13.2 録画からヒートマップへ戻る
セッション録画で問題行動を見つけたら、ヒートマップで同じ場所に反応が集中しているか確認します。
一人だけの例外か、多数に共通する問題かを判断できます。
13.3 アクセス解析と組み合わせる
問題があるページの購入率、離脱率、端末別成果を確認します。行動上の問題が、実際の事業指標へ影響しているかを評価します。
ヒートマップ上の変化が大きくても、購入率が変わらない場合、事業成果との関係が弱い可能性があります。
13.4 問い合わせと組み合わせる
「送料が分からない」「ボタンが反応しない」などの問い合わせ内容を、行動データで確認します。
問い合わせ件数が少なくても、多くの利用者が問題に遭遇して黙って離脱している場合があります。
13.5 利用者テストと組み合わせる
行動データから作った仮説を、利用者テストで直接確認します。参加者に課題を実行してもらい、考えていることを聞きます。
セッション録画では推測しかできなかった理由を確認できます。ただし、テスト環境と実際の訪問では行動が異なる可能性も考慮します。
| 組み合わせ | 分かること |
|---|---|
| ヒートマップ+録画 | 規模と行動過程 |
| アクセス解析+ヒートマップ | 成果とページ内傾向 |
| 録画+問い合わせ | 問題の再現と利用者の説明 |
| 録画+利用者テスト | 行動と考えた理由 |
| 改善前後の全データ | 行動変化と事業効果 |
14. 計測実装とプライバシー保護
行動分析では、利用者の入力や画面状態を扱うため、プライバシーと安全性を最優先にします。取得できる情報をすべて保存するのではなく、分析目的に必要な最小限の範囲へ限定します。
利用するサービスの設定、適用される法令、組織のプライバシーポリシー、利用者への説明を確認します。決済情報、認証情報、健康情報などの機密性が高い内容は記録しない設計が必要です。
14.1 入力欄をマスキングする
氏名、メールアドレス、電話番号、住所、カード情報、パスワードなどの入力内容を記録しないようにします。
サービス側の自動マスキングだけに依存せず、HTML属性、除外設定、実際の録画確認を組み合わせます。
コード例:記録対象外を示す属性
<label for="customer-email"> メールアドレス</label>
<input id="customer-email" name="customer-email" type="email" autocomplete="email" data-recording-mask="true"/>
<label for="card-number"> カード番号</label>
<input id="card-number" name="card-number" inputmode="numeric" autocomplete="cc-number" data-recording-block="true"/>
14.2 特定領域を記録対象から除外する
会員情報、注文履歴、管理画面、問い合わせ内容などを含む領域は、ページ全体または部分的に除外します。
CSSクラスやデータ属性で除外領域を定義し、新しい画面を追加した際にも確認します。
コード例:機密領域を明示する
<section class="account-information" data-recording-block="true"> <h2>登録情報</h2> <p>氏名、住所、電話番号などを表示します。</p></section>
14.3 同意状態に応じて計測する
必要な場合は、利用者の同意状態を確認してから計測を開始します。拒否した利用者へ計測コードを実行しない設計が必要です。
同意状態を一度取得した後も、利用者が設定を変更できるようにします。
コード例:同意後に分析を開始する
function startBehaviorAnalytics() { if (window.behaviorAnalyticsStarted) { return; }
window.behaviorAnalyticsStarted = true;
const script = document.createElement("script"); script.src = "/analytics/behavior-tool.js"; script.async = true;
document.head.appendChild(script);}
const consent = localStorage.getItem( "behavior-analytics-consent",);
if (consent === "accepted") { startBehaviorAnalytics();}
14.4 保存期間と権限を設定する
録画と行動データを必要以上に長期間保存しないようにします。分析周期と問題調査に必要な期間をもとに削除条件を決めます。
閲覧権限も限定します。マーケティング、開発、外部委託先など、誰が何の目的で閲覧できるかを管理します。
14.5 独自イベントを追加する
ページ表示やクリックだけでは、業務上重要な状態を判断できない場合があります。商品選択完了、クーポンエラー、在庫切れなどの独自イベントを記録できます。
個人情報をイベント名や値へ含めないようにします。商品識別子なども、必要性と管理方法を確認します。
コード例:匿名化した行動イベント
function trackBehaviorEvent( eventName, eventProperties = {},) { const allowedEvents = new Set([ "product_option_selected", "cart_add_succeeded", "cart_add_failed", "checkout_validation_error", ]);
if (!allowedEvents.has(eventName)) { throw new Error( "許可されていないイベントです", ); }
window.behaviorAnalytics?.track( eventName, { ...eventProperties, pagePath: window.location.pathname, recordedAt: new Date().toISOString(), }, );}
trackBehaviorEvent( "cart_add_failed", { reasonCode: "option_not_selected", },);
15. 継続的な改善へ定着させる方法
ヒートマップとセッション録画は、一度分析して終わるものではありません。新しい商品、キャンペーン、画面変更、端末環境の変化によって、利用者行動も変わります。
定期確認だけでなく、購入率低下、エラー増加、問い合わせ発生などの変化をきっかけに調査する運用を作ります。
15.1 定期的な分析時間を設ける
毎週または毎月、重要ページのヒートマップと対象録画を確認します。目的なく長時間見るのではなく、確認項目を固定します。
新しい問題、継続中の問題、改善済み問題を分けて管理します。以前修正した問題が再発していないかも確認します。
15.2 分析対象を優先順位付けする
売上影響、利用者数、エラー件数、問い合わせ件数などから、分析するページを選びます。
アクセス数が多くても購入と関係が弱いページより、決済や商品選択の問題を優先する場合があります。
15.3 発見事項をチームで共有する
分析担当者だけが録画を見て終わらず、デザイナー、開発者、マーケター、カスタマーサポートへ共有します。
録画そのものを広く共有するのではなく、個人情報を含まない要約、発生条件、改善案を共有します。
15.4 改善結果を記録する
変更前の問題、実施した改善、公開日、行動変化、事業指標の変化を記録します。
成果が出なかった改善も残します。同じ案を繰り返したり、失敗理由を忘れたりすることを防げます。
15.5 数値と行動を両方評価する
購入率が改善しても、繰り返しクリックやフォームエラーが増えている場合があります。反対に、操作が分かりやすくなっても、商品価格や需要によって売上が変わらないこともあります。
事業指標と行動品質を分けて評価し、両方が改善しているかを確認します。
| 運用指標 | 確認内容 |
|---|---|
| 分析実施数 | 継続的に確認できているか |
| 発見問題数 | 重要な問題を特定できたか |
| 改善実施率 | 発見が実装へつながったか |
| 再発率 | 同じ問題が戻っていないか |
| 事業指標 | 購入率や完了率が改善したか |
| 行動品質 | 迷い、誤操作、エラーが減ったか |
継続改善の記録例
対象:スマートフォンの商品詳細ページ
発見:購入ボタンを押した利用者の一部が、処理完了前に同じボタンを複数回押していた。
証拠:・クリックヒートマップで購入ボタンへ反応が集中・対象録画20件中7件で繰り返し操作・カート内の数量重複に関する問い合わせあり
改善:・押下直後に処理中表示へ変更・処理中は再操作を無効化・追加完了メッセージをボタン付近に表示
結果:・繰り返し操作率が低下・カート数量修正率が低下・カート追加完了率は維持
次の確認:低速通信環境での処理時間と離脱率
おわりに
ヒートマップとセッション録画は、アクセス解析だけでは分からないページ内の行動を理解するための有効な分析方法です。ヒートマップでは、多数の利用者に共通するクリックやスクロールの傾向を確認できます。セッション録画では、一人の利用者がどの順番で操作し、どこで迷い、どの状態で離脱したかを確認できます。
分析では、色が強い場所や珍しい録画を眺めるだけでは不十分です。改善したい事業指標を決め、仮説を立て、端末や利用者層を分け、正常な行動と問題行動を比較する必要があります。ヒートマップで問題の規模を確認し、セッション録画で操作の流れを深掘りすることで、改善案の根拠を強くできます。
さらに、行動分析ではプライバシー保護が欠かせません。入力情報のマスキング、機密領域の除外、保存期間、閲覧権限を設定し、必要最小限のデータだけを利用します。行動データ、アクセス解析、問い合わせ、利用者テストを組み合わせ、改善後に再測定することが、ECサイトやWebサービスの継続的な使いやすさ向上につながります。
EN
JP
KR