ユーザー行動分析の進め方｜GA4・ヒートマップ・Web録画をどう組み合わせる？

GA4の数字は見ているし、ヒートマップも開いている。

それでも「次に何を直すか」が決まらないときは、ツールごとに違う課題を見ている可能性があります。

ユーザー行動分析は、一つの問いに対して、集計・ページ内の傾向・操作の順序を重ねていくと進めやすくなります。

GA4で対象を絞り、ヒートマップで確認する場所を探し、Web録画で前後の動きを調べます。

この記事では、架空のサービス紹介ページから相談フォームへ進む導線を例に、分析設計書を作る手順を説明します。

数値例は計算と判断のための架空データであり、特定のツールによる改善実績や、業界平均ではありません。

製品の機能を順番に使うことより、最初に決めた問いへ答えられるかを重視します。

ユーザー行動分析の目的を決める

分析の出発点は、利用者に完了してほしい操作です。

「サイトを使いやすくする」という目標を、画面と工程に分けて書きます。

改善したい成果を選ぶ

ECなら注文の成立、問い合わせサイトなら受付の成功、SaaSなら利用開始に必要な設定の完了などを選びます。

クリックが増えたことと、利用者が目的を達成できたことは分けます。

相談フォームのボタンが多く押されても、入力エラーで受付できなければ、成果を確認できたとは言えません。

まず、対象の成果を社内でどう確認しているかを整理します。

受付システムの記録、成功イベント、完了画面の表示など、根拠になるものを挙げます。

GA4の拡張計測にはform_startやform_submitがありますが、これらの名前だけで、自社の受付処理が成功したと判断しないようにします（参考：GA4の拡張計測イベント）。

自社のフォームでどの操作を検知しているか、テストデータを使って確かめてください。

架空のサービスでは、最終成果を「相談の受付が正常に完了したこと」と定義します。

その手前を「紹介ページを開く」「相談フォームへ進む」「入力を始める」「受付が完了する」に分けます。

成果に近い工程を分けると、どこまで進んだ記録が必要かを決めやすくなります。

計測がない工程は、存在しないことにせず、未計測として残します。

答える問いを一つにする

次に、今回調べる問いを一つに絞ります。

架空の例では「スマホでサービス紹介ページに来た人が、相談フォームへ進めているか」を扱います。

料金を理解できたか、入力できたか、営業担当の対応に満足したかは、関連していても別の問いです。

最初からすべてを調べると、必要なデータと判断基準が増えすぎます。

今回の問いに必要な証拠を、三つに分けて整理します。

調べたいこと	主に使う情報
どの条件でフォーム到達が少ないか	GA4などの工程別集計
ページのどこまで到達し、どこを押すか	ヒートマップ
その場所で何が起きたか	Web録画・セッションリプレイ

この分け方は、どれか一つが原因を自動的に教えてくれるという意味ではありません。

集計で見つけた差を、次に調べる場所へつなぐための順序です。

分析設計書の先頭には、問い、対象ページ、対象端末、成果の定義を書きます。

判断したいことも「相談ボタン付近を修正する必要があるか」のように、一行で置きます。

途中で別の問題を発見した場合は、次回の調査候補として分けて残します。

ユーザー行動の計測を整理する

ツールを行き来する前に、同じページと操作を見ているか確認します。

ツール間で数字を一致させる作業と、同じ課題を調べる作業も区別してください。

各ツールの対象をそろえる

期間、タイムゾーン、URL、端末、流入条件、ページの公開版をそろえます。

GA4では先月全体、ヒートマップでは直近一週間、録画では今日だけを見ていると、別の条件が混ざります。

同じURLでも、途中でボタンの位置を変えていれば、公開版を分ける必要があります。

URLに付いた広告用パラメータを含めるか、ページ本体でまとめるかも決めます。

調査対象の対応表は、次のように作れます。

調査の条件	架空の記入例
対象ページ	サービス紹介ページの指定URL
端末	スマートフォン
対象期間	同じ公開版だった期間
次の工程	相談フォームの表示
最終成果	相談受付の成功
除外する記録	社内試験と対象外の別フォーム

各工程に、実際のURLやイベント名を追加します。

独自イベントを作る場合は、名前だけでなく、送信する条件と確認担当も記録します。

GA4のDebugViewでは、デバッグ対象の端末で発生したイベントやパラメータを確認できます（参考：DebugViewでのイベント確認）。

Tag Assistantなどで自分の試験端末を対象にし、管理のデータ表示からDebugViewを開いて、操作とイベントの順序を照合します。

同意やプライバシー設定によって見えない場合もあるため、未表示をただちに実装不良とは決めません。

取得できない範囲を残す

外部の予約画面、別ドメインの決済、埋め込みフォームなどでは、後半の操作を同じ条件で記録できない場合があります。

見えない区間を「そこで全員が離脱した」と推測で補わないようにします。

対象URLにタグがない、同意条件が違う、記録の保存期間を過ぎているなどの可能性も整理します。

計測できるページ、イベントだけ取れる工程、結果しか分からない工程を分けてください。

ClarityとGA4を連携しても、GA4のセグメントがそのまま使えるわけではなく、Clarityから再生URLをGA4へ送る連携も提供されていないと公式資料で説明されています（参考：ClarityのGA4連携の範囲）。

連携したことを、利用者ごとの行動が自動的に完全一致したことと扱わないようにします。

別ツールではユーザーやセッションの識別方法、同意、除外条件が異なり得ます。

日時と端末が似ているだけで、別のツールの記録を同じ人だと断定することも避けます。

分析設計書には「同じ条件で傾向を比較する」「個別の記録の一致は確認していない」といった限界を残します。

数値が合わない場合は、原因を補正するための係数を適当に掛けず、定義と対象を確認します。

計測対象そのものを整理したい場合は、セッションリプレイ導入前の確認票も使えます。

GA4で問題の範囲を絞る

まず集計から、どの条件を詳しく調べるかを選びます。

サイト全体の平均だけを見て、すべてのページに同じ改善を当てはめないようにします。

流入と端末を比較する

GA4のレポートからトラフィック獲得を開き、セッションの参照元・メディアなどで流入を確認します（参考：トラフィック獲得レポート）。

今の訪問の流入を調べる場合は、最初のユーザー獲得を表す指標と混ぜないようにします。

端末別にも分け、同じページでPCとスマホの差を見ます。

標準のメニューにレポートが見当たらない場合は、編集者や管理者にコレクションの表示を確認します。

比較のときは割合だけでなく、元になる件数を並べます。

架空の例として、同じ定義の集計で次の値が出たとします。

対象	紹介ページを含むセッション	その後フォームへ進んだセッション
PC	200	60
スマホ	400	40

この定義であれば、フォームへ進んだ割合はPCが30%、スマホが10%です。

これは架空の計算例であり、GA4の標準レポートを開けば、この順序条件の表が自動的に出るという意味ではありません。

実際に同じ表を作るには、対象ページから次の工程へ進んだことを判定する集計条件が必要です。

この差だけで「スマホのデザインが悪い」とは決めません。

広告の内容、流入する利用者、ページの表示、計測条件など、調べる候補を出す材料にします。

工程別の減少を確認する

GA4の探索でファネルデータ探索を作ると、指定した工程を順に完了したユーザーを調べられます（参考：ファネルデータ探索）。

ステップに、紹介ページの表示、相談フォームの表示、入力開始、受付成功に対応する条件を設定します。

途中から入る利用者も含めるかを、オープンとクローズドの設定で決めます。

各工程を直接続く操作にするか、間に別の操作が入ってもよいか、制限時間を設けるかも確認します。

ここで表示されるユーザー数を、前の例のセッション数と同じ分母として扱わないでください。

また、受付成功のイベントが未実装なら、最後の工程を推測で埋めず、計測の準備から行います。

設計した順序から外れた人が減少として表れることもあるため、減った数がそのままサイトを去った人数とは限りません。

結果を見る際は、どの条件による減少なのかを説明できる状態にします。

架空の例で紹介ページからフォームへの移動が課題と分かったなら、次は紹介ページのスマホ表示を調べます。

入力開始後の受付成功に問題が集中しているなら、フォーム側の操作を優先します。

ファネルの減少位置を、次に見る画面を決めるために使ってください。

ヒートマップでページ内の傾向を見る

対象ページが決まったら、情報の配置と操作される場所を調べます。

ページ全体の色を見るだけでなく、今回の問いに関係する要素を選びます。

情報への到達を確認する

ClarityのHeatmapsで対象URLを指定し、端末と期間をそろえ、Scrollの表示を開きます。

スクロールマップではページの位置ごとの到達状況を確認できます（参考：Clarityのスクロールマップ）。

架空の例では、相談条件の説明と相談ボタンがある位置を確かめます。

その場所まで到達していない記録が多ければ、情報の位置や、その手前の内容を調べる候補になります。

ただし、到達したことは、内容を読んで理解したことと同じではありません。

目次や固定ボタンから直接移動した場合も、ページの流れを上から読んだとは限りません。

スクリーンショットが分析期間中のページと一致しているかも確認します。

大きな画像の追加や見出しの移動があれば、同じ高さでも示している内容が変わります。

GA4の標準scrollは90%の深さが見えたときのイベントであり、各見出しへの到達を細かく表すものではありません（参考：GA4のscrollイベントの条件）。

特定の要素を見たかを計測したい場合は、スクロール距離だけで代用せず、目的に合う追加計測を検討します。

スクロールの設定と解釈は、GA4のスクロール率の確認方法で詳しく説明しています。

クリックの偏りを調べる

次にクリックマップへ切り替え、相談ボタンと、その周囲のリンクや説明を確認します。

Clarityはリンク以外の場所へのクリックも表示し、スマホではタップを扱います（参考：Clarityのクリックマップ）。

ボタンが押されていない場合は、そこまで到達していないのか、到達しても押されないのかを分けます。

反対に押せない見出しや画像が繰り返し操作されている場合は、リンクに見える表現や、操作への期待を調べます。

クリック数の割合は、利用者の割合や受付成功率と同じではありません。

同じ人の繰り返し操作が含まれる可能性もあるため、色の強さだけで人気や満足度を決めないようにします。

架空の紹介ページでは、相談ボタン付近の説明画像へのタップが目立ったとします。

その段階の観察は「画像付近のタップが見られる」であり、「相談ボタンを見つけられない」とはまだ言えません。

Clarityでは要素を選んでView recordingsから、その要素をクリックした録画へ進めます。

適用された条件を確認し、画像への操作の前後を調べます。

ここで初めて、ページ内の色と、一つの訪問で起きた順序をつなぎます。

Web録画で操作の順序を確認する

Web録画は、集計だけでは見えない画面の状態を確認するために使います。

気になる場面を見つけたら、直前と直後を合わせて確認します。

問題の前後を見る

ClarityのRecordingsでは、対象ページ、端末、期間、流入などの条件を使って記録を絞れます（参考：Clarityのフィルター）。

ヒートマップから移動した場合も、意図した条件が残っているかを確認します。

架空の相談導線なら、紹介ページを開いた位置から、画像へのタップ、相談ボタンの表示、フォームへの遷移までを追います。

固定のボタンが別の要素に隠れていないか、メニューが開いたままになっていないかも見ます。

繰り返しタップがあったときは、最初の操作に画面がどう反応したかを確かめます。

待ち時間を調べる場合は、再生速度と無操作時間のスキップを確認してください。

Clarityのプレイヤーには、無操作部分を飛ばす設定があるため、再生された時間が実際の経過時間と一致するとは限りません（参考：録画プレイヤーの設定）。

問題があるように見える記録だけでなく、同じ条件でフォームへ進めた記録も見ます。

成功した人も同じ画像を押しているなら、その操作だけを失敗の原因とは扱えません。

技術的な問題が疑われる場合は、許可されたテスト環境で同じ順序を再現します。

録画で見えたことと、自分の試験で再現したことは、別々に記録してください。

事実と仮説を整理する

分析メモには、事実、仮説、未確認の情報を分けて書きます。

事実は、計測値や画面上の操作として確認できた内容です。

仮説は、その事実を説明する可能性です。

GOV.UKの調査分析ガイドでも、見聞きした観察を解釈と区別して記録する進め方が案内されています（参考：観察と分析の整理）。

架空の紹介ページなら、次のように整理できます。

区分	架空の記入例
集計で確認したこと	スマホのフォーム到達が比較対象より少ない
画面で確認したこと	説明画像へのタップ後に画面移動がない記録がある
仮説	画像が操作できる要素に見える可能性
未確認	その人が相談を希望していたか、何を期待したか
次の確認	表現の見直し案を作り、操作試験を行う

録画には、利用者が口にしていない理由までは映りません。

不安、怒り、興味などの心理を、動きだけで確定しないようにします。

選んだ録画の中で同じ行動が見つかった件数も、全利用者の発生率とは分けます。

偏りなく抽出したかを確認していない場合は、調査で観察した範囲として報告します。

行動の理由を知る必要があれば、ユーザビリティテストや聞き取りを追加します。

その進め方は、ユーザビリティテストとWeb録画の使い分けで確認できます。

ユーザー行動分析を改善へつなげる

調査の最後には、直す対象と、変化を確かめる方法を残します。

ツールのスクリーンショットを並べただけの資料で終わらせないようにします。

修正案と検証方法を決める

分析設計書には、問い、対象条件、証拠、仮説、対応、検証、担当、期限をまとめます。

以下は架空の改善案です。

設計書の欄	架空の記入例
問い	スマホで相談フォームへ進めているか
対象条件	指定の紹介ページ・同じ公開版・同じ期間
仮説	説明画像が操作できるように見える
修正案	画像とボタンの役割が分かる表現にする
実装の確認	ボタン操作とフォーム表示が正常に動くか
結果の確認	定義をそろえたフォーム到達と受付成功
担当と期限	制作担当が公開前に試験し、分析担当が次回確認

修正するのは、証拠と対応がつながる箇所です。

画像のタップを見たからといって、料金、広告、フォーム項目まで同時に変更すると、何が影響したか分かりにくくなります。

一方、再現可能な不具合が見つかった場合は、効果測定の準備を理由に必要な修正を先延ばしにしないようにします。

操作できる状態へ戻す確認と、その後の成果への影響を分けて進めます。

複数の表現案の効果を比較したい場合は、十分な設計と計測ができる条件でA/Bテストを検討します。

ヒートマップで仮説を作ることと、ランダムに割り付けて差を評価することは別です。

詳しい進め方は、ヒートマップ分析をA/Bテストに使う方法で説明しています。

変更後も同じ問いで見る

公開後は、最初に決めた問いと指標で確認します。

フォーム到達を調べていたのに、結果が期待どおりでないからスクロール率へ評価を差し替えると、改善したか判断できません。

途中で目的を変える必要がある場合は、その理由と、新しい評価条件を記録します。

変更後の集計を見る前に、イベントやタグが引き続き動いているかを確認します。

表示を修正した際に計測対象のIDが変わり、クリック数だけが減ったという可能性もあるためです。

GA4で対象工程の変化を見たら、同じ条件のヒートマップと録画で、想定した操作になっているかを確かめます。

画像へのタップが減っても、フォームへの到達や受付成功が変わらないなら、その範囲で結果を報告します。

新しい操作上の問題が出ていないかも確認してください。

前後比較では、流入量、広告配信、曜日、キャンペーン、他の改修など、同時に変わった条件を残します。

比較期間の数字が上がっただけで、修正が原因だと断定しないようにします。

判断がつかなければ、条件をそろえて調査を続ける、追加の操作試験を行うなど、次の行動を決めます。

GA4で調べる範囲を決め、ヒートマップで場所を探し、Web録画で順序を確認することで、一つの改善案へ根拠を集められます。

まずは一つの成果と一つの問いを選び、分析設計書の先頭を埋めるところから始めてください。