GA4でヒートマップは見られる？クリック・スクロール計測との違いと併用方法

GA4には表の数値を色分けするヒートマップ表示がありますが、Webページ上にクリック位置やスクロール到達位置を重ねる機能とは別です。

「どのページで成果が少ないか」をGA4で探し、「ページのどこで操作が止まるか」をヒートマップや録画で調べると、確認する範囲を絞れます。

ただし、二つのツールを入れただけで同じ訪問者の記録が自動的につながるわけではありません。

クリック数、利用者数、ページの表示回数は、分けて扱う必要があります。

この記事では、GA4とヒートマップの使い分けから、計測条件のそろえ方、改善提案にまとめる手順まで解説します。

表の記入例と数値例は、説明のために作成した架空のものです。

2026年10月5日に確認したGoogleとMicrosoftの公式資料を基に、追加設定が必要な部分も区別しています。

GA4とヒートマップの違い

イベント集計と位置の可視化を分ける

まず、知りたいことを「数」「場所」「操作の順序」に分けます。

GA4でCTAのクリックをイベントとして計測すれば、設定した条件で操作が発生した回数を集計できます。

一方、クリックヒートマップは、ページ上のどの要素が押されたかを位置とともに確かめるために使います。

Clarityでは、リンクではない場所へのクリックも確認対象になります（参考：Microsoft Learn：クリックマップ）。

この違いを踏まえると、次のように役割を分担できます。

知りたいこと	最初に使う情報	補う情報
どの端末で申込完了が少ないか	GA4の端末別集計	対象端末の画面と録画
CTAのどの位置が押されるか	クリックヒートマップ	位置別のイベント集計
料金説明まで画面が進んだか	スクロールの到達情報	要素の表示計測
押した後に何が起きたか	セッションリプレイ	実ページでの動作確認

集計は調べる対象を絞るために、位置や録画は具体的な問題候補を探すために使います。

クリックの色が濃いだけで、問い合わせが増えたとは判断できません。

同じ人の押し直しが含まれる可能性もあり、回数の増加と利用者の増加は別です。

最終的には、受付完了や購入完了など、事業上の成果に対応した計測と照合します。

標準レポートと追加ツールを分ける

GA4の「探索」にある自由形式では、表のセルをヒートマップとして色分けできます（参考：Google：自由形式のデータ探索）。

これは、端末や流入元などの行・列に並べた数値を見比べる表示です。

サイトのスクリーンショットにクリックの色を重ねる表示ではありません。

操作の入口は、「探索」から「自由形式」を開き、可視化を表にする手順です。

行・列・値を設定したうえで、セルの種類をヒートマップへ切り替えます。

例えば、行にデバイスカテゴリ、値に総ユーザー数を置けば、端末別の人数の偏りを見やすくできます。

一方、ページ内の位置を調べる場合は、Clarityなどの対応ツールを別途導入します。

設置前の操作を、導入後にさかのぼって録画することはできません。

計測タグがどのページで動くか、どの情報を記録するか、管理できる担当者は誰かを先に確認してください。

録画を使う場合は、入力情報のマスキングと共有範囲も導入条件に含めます。

GA4でページ内の行動を計測する

クリック対象を定義する

GA4の拡張計測で取得する標準のclickイベントは、基本的に外部サイトへ移動するリンクが対象です。

同じサイト内のCTAをすべて自動計測する設定ではありません（参考：Google：拡張計測機能のイベント）。

自社サイトの「相談する」ボタンを調べたい場合は、その操作を別のイベントとして定義します。

ここでは、上部のCTAと下部のCTAを区別する架空の設計を考えます。

計測対象	イベント名の例	区別する値の例
上部の相談CTA	cta_click	cta_position = hero
下部の相談CTA	cta_click	cta_position = bottom
相談の受付完了	lead_complete	受付成功を確認できる条件

同じURLへ移動するボタンが複数あるなら、リンク先URLだけでは位置を区別できません。

対象に固有のIDや属性を設けるなど、どの要素を押したか判別できる条件を実装担当者と決めます。

GTMでは、クリックトリガーの「すべての要素」と「リンクのみ」で対象が異なります（参考：Google：クリックトリガー）。

リンク要素か通常のボタンかを確認し、対象に合うトリガーと条件を使ってください。

ボタン内の文字やアイコンを押したときも、意図した条件で一度だけ発火するか確かめます。

次に、GA4イベントタグへイベント名と必要なパラメータを設定します（参考：Google：GA4イベントを設定する）。

cta_positionのような独自パラメータを分析に使う場合は、必要なカスタムディメンションの登録も確認します（参考：Google：イベントスコープのカスタムディメンション）。

値には、メールアドレスなどの個人情報を入れないでください。

公開前にGTMのプレビューとGA4のDebugViewで、対象操作だけが記録されることを確認します（参考：Google：DebugView）。

スクロールの取得範囲を確認する

GA4の標準のscrollイベントは、ページの縦方向の90%が初めて表示されたときに発生します。

25%、50%、75%への到達が標準設定だけで細かく残るわけではありません（参考：Google：scrollイベントの条件）。

中間地点の到達を取りたい場合は、GTMのスクロール距離トリガーなどで追加設定を検討します（参考：Google：スクロール距離トリガー）。

その場合は、標準イベントと区別できる名前にして、どの閾値の記録かを残します。

ただし、ページの高さが変わると、同じ50%でも指す内容が変わります。

画像の読み込みや展開式の説明によって高さが変化するページでは、割合だけで料金表への到達を判断しないほうがよいでしょう。

短いページでは、読み込み時点で複数の閾値が表示範囲に入ることもあります。

「料金表が画面に入ったか」を知りたいなら、割合に加えて対象要素の表示を計測する方法があります（参考：Google：要素の表示トリガー）。

この場合も、表示割合や時間の条件を記録します。

要素が画面に出たことは、その内容を読んだ証拠ではありません。

設定する前に、知りたいのがページの深さなのか、特定の説明の表示なのかを決めてください。

詳しい追加設定は、GA4のスクロール計測の手順で解説しています。

ヒートマップで補う情報を決める

押された場所を確認する

ヒートマップを見る前に、GA4で計測しているCTAと画面上の位置を対応づけます。

同じ「相談する」という文言でも、上部・本文途中・追従ボタンでは見え方が異なります。

Clarityを使う場合は、Heatmapsで対象URL、期間、端末を選び、クリックマップを表示します。

要素ごとのクリック数や割合を見ながら、想定したCTAと、リンクではない場所への操作を確認します（参考：Microsoft Learn：クリックデータ）。

ヒートマップの「クリックの割合」を、GA4の「CTAを押したユーザーの割合」と同じ指標として並べないようにします。

分子と分母が違うからです。

例えば、100回のクリックのうち30回がCTAだった場合と、100人のうち30人がCTAを押した場合は、どちらも30%ですが意味が異なります。

これは架空の比較例です。

前者には、同じ人の複数回の操作が含まれる可能性があります。

押せない見出しにクリックが集まっているなら、リンクのように見える理由を実画面で確認します。

クリックが少ないCTAでは、色を変える前に、表示位置・周辺の説明・ほかの導線への分散を調べます。

ヒートマップで見えた場所を、そのまま修正箇所と決めず、次に確認する候補として記録してください。

到達位置を確認する

スクロールヒートマップでは、ページ内のどの位置まで到達した訪問があるかを見られます。

Clarityでは、到達割合に加えて、初期表示の平均的な境界を示すAverage foldも確認できます（参考：Microsoft Learn：スクロールマップ）。

まず、料金、導入条件、申込ボタンなど、判断に必要な情報の位置へ目を向けます。

その位置の到達情報と、実際の画面構成を並べて確認します。

ただし、デスクトップとスマートフォンを一つにまとめて結論を出さないでください。

折り返し位置、文章の行数、固定メニューの大きさが変わるためです。

同じページでも、スマートフォンではCTAに到達するまでの距離が長くなることがあります。

一方、上部のCTAで目的を達成した訪問なら、ページ下部へ進まなくても問題とは限りません。

「最後まで到達しない」という情報だけで、本文全体を短くする必要はありません。

料金表へ進む前に問い合わせる導線があるか、必要な情報を上部で得られるかも見ます。

改善候補として残すのは、「到達が少ない場所」ではなく「必要な情報に出会えない可能性がある場所」です。

見出し単位のリライトを検討する場合は、記事のヒートマップ分析も参考になります。

GA4とヒートマップの条件をそろえる

URLと期間を対応づける

二つの画面を開いたら、先に比較条件をメモします。

少なくとも、ページ、期間、端末、流入、画面の版をそろえる必要があります。

次は、架空の相談LPを調べる場合の記入例です。

条件	GA4での記録	ヒートマップでの記録
ページ	/consult/の表示を対象	同じページのVisited URL
期間	9月21日〜27日	同じ日付の範囲
端末	mobile	Mobile
流入	対象セッションの流入条件	対応する参照元・UTM条件
画面の版	9月20日公開版	その版に対応する画面

日付だけでなく、タイムゾーンや集計の区切りも確認します。

クエリ付きURLをまとめるか分けるかは、ページの内容によって決めてください。

UTMの違いだけなら同じ画面として扱う場合がありますが、商品IDや言語が変わるなら別の内容かもしれません。

ClarityのURL条件には一致方法があり、大文字・小文字や複数条件の指定にも注意が必要です（参考：Microsoft Learn：パスフィルターの演算子）。

また、ランディングページと、その訪問中に見たページは同じ意味ではありません。

GA4で入口を絞ったのに、Clarityでは対象URLを一度でも見た全訪問を集めると、比較対象がずれます。

入口を比べるのか、ページの利用状況を比べるのかを、表のページ欄に明記してください。

人数の一致を前提にしない

条件をそろえても、GA4とヒートマップの数値が完全に一致するとは限りません。

まず、比較している値がユーザー数、セッション数、ページビュー数のどれかを確かめます。

GA4では、レポート用識別子の設定や取得できる情報に応じて、利用者をまとめる方法が変わります（参考：Google：レポート用識別子）。

タグが動くページ、同意の状態、除外設定、利用している期間にも違いがあり得ます。

数が合わないときは、差をゼロにするために設定を変える前に、次の順番で確認します。

1. 指標名と分母が同じかを確認する
2. 対象URLと入口条件を確認する
3. 日付・端末・流入・画面版を確認する
4. タグの設置範囲と発火条件を確認する
5. 同意・除外・集計上の制約を確認する

GA4とClarityの連携も、二つのデータを無条件に一対一で結合する機能ではありません。

Microsoftの公式資料では、GA4のセグメントに未対応であり、再生URLをGA4へ送らない点が案内されています（参考：Microsoft Learn：GA4連携）。

そのため、「GA4で選んだ一人の録画が必ず開ける」という前提で手順を組まないでください。

まずは同じ条件の集団として傾向を比較し、個別記録との対応を確認できない部分は、そのまま明記します。

異なるツールの人数と完了数を組み合わせ、独自のCV率を作ることも避けましょう。

GA4の集計から録画へ進む

成果が低い条件を抽出する

調査対象は、成果と途中の操作を分けて選びます。

例えば、相談フォームへの移動は多いのに受付完了が少ないなら、フォーム以降の操作を確認する価値があります。

このとき、単にイベントの総数を割り算するだけでは、同じ人が順番に進んだか分かりません。

GA4のファネルデータ探索では、設定したステップを順番に進んだ利用状況を調べられます（参考：Google：ファネルデータ探索）。

架空の相談導線なら、「LPの表示」「フォーム開始」「受付完了」をステップ候補にできます。

ただし、途中から入った人を含めるか、ステップ間の操作を許すかによって結果は変わります。

分析時は、オープン・クローズドの別や、直接・間接の条件も保存します。

受付完了のイベントが実際の成功を表すかは、先に動作確認してください。

送信ボタンを押しただけで完了扱いになっていると、エラーで止まった人を見落とします。

そのうえで、端末や流入ごとに、どの工程を調べるか決めます。

人数が少ない条件で割合だけが大きく動いている場合は、母数も併記します。

「スマートフォンの申込率が低い」という集計結果は、画面の問題を確定するものではありません。

訪問目的や商品への関心の違いもあるため、録画で調べる問いへ置き換えます。

操作の順序を確認する

録画では、気になる操作の前後を確認します。

例えば、CTAの手前まで到達したのに押されない場面なら、別のリンクへ進んだか、説明を戻って見たかを調べます。

Clarityでは、クリックマップから対象要素を押した録画へ進む導線があります（参考：Microsoft Learn：View recordings）。

この導線で集まるのは、選択した要素を押した記録です。

押さなかった人の状況も知りたい場合は、別途、同じページ・端末などの条件で対象を選びます。

一部の目立つ操作だけを見て、すべての訪問者が同じ問題に遭っているとは判断しません。

次のように、観察と解釈を分けてメモすると、担当者へ渡しやすくなります。

種類	架空の記入例
見えた事実	料金見出しを押した後、下へスクロールした
原因の仮説	料金見出しがリンクに見えた可能性
追加確認	同じ端末で見出しの装飾と動作を確認
修正候補	移動できる見出しか、説明用見出しかを明確にする

録画上の停止時間だけで、「説明を熟読した」「迷っていた」と決めつけないようにします。

別タブへ移ったり、操作を中断したりしている可能性もあるからです。

表示崩れを見つけた場合は、実際のページでも同じ現象が起きるか確かめます。

録画の再現上の問題と、サイト自体の不具合を分ける作業が必要です。

詳しい観察メモの作り方は、Clarityの録画を改善につなげる手順で紹介しています。

GA4とヒートマップのレポートを作る

数字の出典を分ける

レポートには、数字と画面を並べるだけでなく、それぞれの取得元と条件を付けます。

次の表を、調査するページごとに埋めてください。

項目	記録すること
調査の問い	どの操作を確かめるか
GA4の集計	指標名、分母、期間、フィルター
ヒートマップ	種類、対象URL、端末、対象期間
録画の観察	選び方、確認した記録数、具体的な操作
分かったこと	データから直接確認できた事実
まだ分からないこと	原因、対象全体への広がり、効果
次の作業	実機確認、計測追加、修正、検証のいずれか

ここで避けたいのは、別々の集計を一つの母集団のように扱うことです。

例えば、GA4で1,000ユーザー、ヒートマップで200クリックが記録されていても、それだけでクリック率20%とは言えません。

これは架空の数値例であり、取得対象と集計単位が一致していないためです。

また、録画10件のうち3件に同じ操作があっても、全訪問の30%で起きたとは書けません。

その10件をどう選んだかによって、偏りが生じるからです。

レポートには「選んだ録画10件中3件で観察」と書き、全体の発生率と区別します。

発生率が必要なら、その操作を数えるイベントの定義と対象範囲を設計します。

出典と分母を残すことが、画面の印象を過大な結論へ変えないための基本です。

次に試す修正を一つ決める

最後に、確認できた問題から次の作業を一つ選びます。

「ヒートマップが青いのでCTAを赤くする」では、修正の理由が十分に説明できません。

「必要な料金条件がCTAの下にあり、確認のために上下へ移動する操作が見られた」なら、情報の配置を見直す仮説になります。

この場合も、移動の原因が料金条件だと断定せず、実機確認や追加観察で確かめます。

次は、架空の改善チケットの例です。

対象：スマートフォン版の相談LP
問い：申込前に料金条件を確認できるか
根拠：GA4の工程別集計と対象条件の録画
仮説：料金条件とCTAの距離が確認を難しくしている
修正案：CTAの近くに料金条件への案内を置く
確認：案内表示、リンク遷移、受付完了の計測
担当：ページ担当者
判定：同条件の操作と成果を、母数付きで比較

修正後は、画面が正常に動くことと、成果が変わったことを分けて確認します。

前後で広告や流入が変わっていれば、数値差をその修正だけの効果とは言えません。

比較できるだけの対象があり、実施条件を整えられる場合は、A/Bテストも選択肢になります。

考え方は、ヒートマップとA/Bテストの使い分けで解説しています。

GA4とヒートマップを併用する最初の一歩は、同じ条件で調べるページを一つ決めることです。

集計で対象を絞り、位置と録画で操作を確かめ、根拠のある一つの作業へつなげてください。