LPのヒートマップを広告別に比較する方法｜同じページでも反応が違う理由を探す

広告Aはクリックされるのに、問い合わせにつながらない。

広告Bはクリックが少ないのに、申込まで進む人がいる。

同じLPへ送っていても、このような差は起こり得ます。

LPのヒートマップは、広告で期待したことと、訪問後に見つけた情報のつながりを調べるために使います。

ページ全体の赤い場所を見るだけでは、どの広告から来た人の行動なのかが混ざってしまいます。

この記事では、広告の訴求を整理し、計測条件をそろえ、ファーストビューからフォーム完了まで確認する方法を解説します。

操作例にはMicrosoft Clarityを使い、広告別LP分析の条件表も紹介します。

数値や広告文は説明用の架空例であり、特定サービスの改善実績ではありません。

LPのヒートマップを広告別に見る理由

広告を分ける目的は、勝ち負けを色で決めることではなく、次に調べる違いを見つけることです。

広告で伝えた内容を並べる

ヒートマップを開く前に、比較する広告の見出し、画像、動画の冒頭、説明文を並べます。

各広告が何を約束しているかを、1行で書いてください。

たとえば、広告Aが「費用を抑えて始める」、広告Bが「毎月の作業を減らす」と伝えている場合です。

Aから来た人には、料金や無料で試せる範囲が気になる可能性があります。

Bから来た人には、実際に減らせる作業や操作の流れが気になる可能性があります。

ただし、これは観察前の仮説であり、広告をクリックした人全員の心理ではありません。

比較項目	広告Aの例	広告Bの例
伝えた価値	費用を抑えて始める	月次の作業を減らす
最初に探しそうな情報	料金、無料枠、利用条件	操作手順、成果物、必要な準備
LPで確かめる場所	料金への案内	デモや作業手順への案内
観察で確認したいこと	料金説明へ到達しているか	操作例を見つけられているか

Googleの広告ガイドでも、広告で示した内容と関連する情報を、遷移先で見つけられることが重視されています（参考：広告とランディングページの最適化）。

この対応表があれば、ヒートマップで確認する場所を先に決められます。

同じLPの中で比較する

最初の比較では、できるだけ同じページの同じ版を使います。

広告Aは旧LP、広告Bは新LPへ送っていた場合、広告の違いとページの違いが混ざるためです。

同じURLでも、途中で見出しやCTAを変えていれば同じ条件ではありません。

変更日と表示内容を記録しておきます。

また、広告の配信対象が異なれば、同じページでも行動は変わる可能性があります。

新規の人向けの広告と、以前サイトを見た人向けの広告を、同じ関心度だと扱わないでください。

広告別の観察は、そのままランダムに振り分けたA/Bテストになるわけではありません。

広告ごとに入札、配信量、対象、掲載面が異なる場合は、その条件も残します。

分析のためだけにキャンペーンを新しく分ける必要はありません。

既存の構成の中で、広告を識別する情報と流入後の行動が対応しているかを整えるところから始めます。

広告別ヒートマップの計測を整える

どの広告から来たかが分からなければ、後からヒートマップだけで正確に分けることはできません。

UTMの命名をそろえる

広告のリンク先には、流入を区別するUTMパラメータを設計します。

utm_source は参照元、utm_medium は媒体の種類、utm_campaign はキャンペーンの識別に使います。

クリエイティブを区別する用途には utm_content を使えます（参考：GoogleのUTM設定ガイド）。

次は、同じキャンペーンの中で広告A・Bを区別する例です。

項目	広告A	広告B
utm_source	facebook	facebook
utm_medium	paid_social	paid_social
utm_campaign	autumn_service	autumn_service
utm_content	price_v1	workflow_v1

名前は、広告管理画面のIDや社内台帳と対応させます。

同じ広告を担当者によって別名にしないよう、小文字や区切り文字のルールもそろえます。

個人の氏名やメールアドレスを、識別用のURLへ入れる必要はありません。

広告URLを作ったら、遷移後のページに識別情報が残っているかを確認します。

途中のリダイレクトで消えている場合は、分析を始める前に修正してください。

ClarityのTrafficフィルターには、UTMのsource、medium、campaignが用意されています（参考：Clarityのフィルター一覧）。

utm_content を使うこの例では、入口URLの条件で広告を分ける方法を検討します。

Entry URLの「Matches regex」で、次のように値を区別できます。

広告A: [?&]utm_content=price_v1(&|$)
広告B: [?&]utm_content=workflow_v1(&|$)

これは、パラメータが実際の入口URLに保持されている場合の設定例です。

ClarityにはURLフィルター用の正規表現テスターがあるので、記録されたURLを使って一致を確認します（参考：ClarityのURL条件と正規表現）。

price_v1 を含むだけの条件では、price_v10 などまで拾う可能性があるため、境界も確かめてください。

期間と端末を固定する

Clarityでは、対象のLPをHeatmapsで開き、期間と端末を指定します。

広告流入から始まったセッションを見るときはEntry URLを使い、サイト内の途中でLPを見たセッションも含めたい場合はVisited URLを使います。

この2つは、対象が同じではありません。

今回の分析では、入口の広告とLPのつながりを調べるため、入口条件をそろえます。

まず広告Aの条件を適用し、対象URL・期間・端末・広告の識別条件をメモします。

次に、同じ条件を保ったまま広告Bの識別条件へ切り替えます。

ClarityのCompareでは、同じプロジェクト内のヒートマップを左右に並べて比較できます（参考：Clarityのヒートマップ比較）。

比較画面は既定の期間が直近3日なので、分析対象の期間に直してください。

左右のページ、端末、期間、ヒートマップの種類をそろえ、広告の条件だけを変えます。

繰り返し使う条件は、通常画面でセグメントとして保存しておくと便利です（参考：Clarityのセグメント保存）。

Compare画面ではセグメントの新規保存や共有・ダウンロードに制限があるため、保存操作は通常画面に戻って行います。

PCとスマートフォンは別々に確認し、必要に応じてブラウザや掲載面の違いも記録してください。

広告別にファーストビューを確認する

最初に見るのは、広告をクリックした直後の画面です。

広告の約束と見出しを照合する

LPの最上部を、広告の内容と並べて見ます。

費用を訴求した広告から来たのに、LPの冒頭が抽象的な理念だけなら、料金の確認先を見つけにくいかもしれません。

操作の簡単さを訴求した広告から来たのに、長い機能一覧から始まっていれば、実際の使い方が伝わりにくい可能性があります。

ただし、すぐに広告ごとのLPを大量に増やす必要はありません。

まず共通LPの見出し、補足説明、料金やデモへの案内を点検します。

確認するもの	問いかけること
冒頭の見出し	広告で伝えた価値に答えているか
補足説明	対象者と利用条件が分かるか
最初のCTA	押した後に何が起こるか分かるか
デモや画像	広告の説明を具体化しているか
スマートフォン表示	大事な文が隠れたり、切れたりしていないか

ヒートマップ上の背景が、分析対象のページ状態と一致するかも確認します。

Clarityではスクリーンショットを切り替えて表示状態を選べますが、画像を変えるだけで分析期間を分離したことにはなりません（参考：Clarityのスクリーンショット切り替え）。

改修前後を比べるなら、ページの変更日も使って期間を分けてください。

早い戻りを録画で見る

広告Aの訪問が冒頭で終わっているように見えたら、対象を絞って録画を確認します。

ページが表示された直後、スクロールを始める前、CTAを押した後など、どの場面で操作が終わるかを記録します。

見るのは「興味がなかったはず」という解釈ではなく、実際に観察できた操作です。

ClarityのQuick backsは、新しいページへ進んだ後、短時間で前のページへ戻る行動を調べる手掛かりです（参考：Microsoftの行動指標）。

ただし、Quick backsを「広告から来てすぐ離れたすべての人」と同じ意味にはできません。

広告アプリ側へ戻った後の行動など、サイトの記録範囲外は見えない場合があります。

録画で確認する項目は、次のように具体化します。

• 最初の画面で主要な内容が表示されていたか
• Cookie表示や別のパネルがCTAを覆っていなかったか
• 押せそうな画像をタップして反応がなかったか
• 次へ進んだ直後に戻っていたか
• 読み込み待ちやエラーらしい状態があったか

Clarityの録画は、画面そのものの動画ではなく、HTMLと操作情報などをもとに再構成した表示です（参考：Clarityの録画方式）。

崩れて見える箇所があれば、実際のページでも同じ問題が起こるかを確かめてください。

LP内の情報への到達を比べる

冒頭の次は、広告で関心を持った情報まで進めているかを見ます。

料金と実績の位置を見る

スクロールヒートマップを使い、料金、導入事例、操作デモなどの位置を確認します。

Clarityのスクロールマップでは、ページ内の位置ごとに到達した割合を見られます（参考：Microsoftのスクロールマップ）。

料金を訴求した広告Aでは料金説明、作業削減を訴求した広告Bでは操作例というように、確認箇所を対応させます。

同じ50％の深さでも、PCとスマートフォンでは別の内容が置かれていることがあります。

割合だけでなく、その位置にある見出しを記録してください。

また、料金表の付近まで到達しても、料金を理解したとは限りません。

必要な情報を探して通過しただけかもしれないためです。

料金の前後で戻る操作や、説明リンクのクリックなども確認します。

導入実績の部分がよく見られている場合も、それだけで「安心して申込んだ」と断定しないようにします。

利用者が比較材料を探している可能性と、説明が分かりにくく確認している可能性の両方を残してください。

CTA到達前の減少を調べる

CTAのクリックが少ないときは、まずCTAまで到達しているかを確認します。

到達していない人が多ければ、ボタンの色を変えるだけでは、その人には届きません。

CTAの前に必要な説明が続いているのか、関係の薄い情報が長く挟まっているのかを見ます。

一方、CTAに到達しているのに押されない場合は、文言や条件、押した後の流れを点検します。

Clarityのクリックマップでは、要素ごとのクリック数や、リンクではない場所へのクリックを確認できます（参考：Microsoftのクリックマップ）。

クリックの割合は、広告のCTRや訪問者単位の申込率と同じではありません。

同じ人が何度も押した場合もあるので、赤さや総クリック数だけで比較しないでください。

観察できたこと	次に確かめること	改善案の例
CTA手前まで届いていない	途中の見出しと情報量	必要な説明の直後にも案内を置く
CTAまで届くが押されない	文言、条件、次画面とのつながり	押した後の内容を具体的にする
ボタンでない画像が押される	リンクだと誤認しそうな表現	実際の導線を設けるか見た目を直す
同じCTAが何度も押される	反応、待ち時間、遷移先	操作への応答を実ページで検証する

これらは原因の確定ではなく、次の調査と修正の候補です。

広告ごとの差が見つからない場合は、無理に別の説明を作らず、共通の課題として扱います。

LPのクリック後も広告別に調べる

CTAを押すところまで進んでも、受付や購入が完了したとは限りません。

フォーム到達と完了を分ける

LPの次の段階を、「フォーム表示」「入力開始」「送信操作」「受付成功」に分けます。

GA4の拡張計測にはフォームの操作イベントがありますが、送信操作の記録と、事業側の受付成功は区別してください（参考：Googleのフォーム操作の拡張計測）。

実際の完了は、システムが受付を成功させたときのイベントなど、業務に合う条件で確認します。

フォームのURLを直接開いただけで、成果が増える設定になっていないかも確かめます。

段階別に見る場合は、GA4のファネル探索で順序を定義できます（参考：Googleのファネルデータ探索）。

ただし、ファネルは指定した順序を踏んだユーザーを数えるため、単純な各イベントの合計とは一致しません。

途中から入る人を含めるか、最初のLP訪問から追うかを決めてください。

広告AとBを比べるときは、この定義を同じにします。

クリックした人の録画を見たい場合は、Clarityの通常のクリックマップから対象要素のView recordingsを開けます。

Compare画面ではこの操作が使えないため、通常画面へ戻して広告の条件を再確認します。

外部フォームへ移る場合は、計測できる範囲がどこまでかを先に確認してください。

外部フォームの内部が見えないことを、途中離脱がなかった証拠にはしません。

母数の少ない広告を保留する

次の表は、母数の違いを説明するための架空例です。

同じ集計で得たLP訪問ユーザーと、そのうちの受付完了ユーザーを使っています。

広告	LP訪問ユーザー	受付完了ユーザー	完了ユーザーの割合
A	300	12	4％
B	30	3	10％

Bの割合は高く見えますが、1人の結果が全体へ与える影響も大きい状態です。

Bに1人完了が増えるだけで、割合は約13.3％になります。

この差だけで、BのLP体験が優れていると確定することはできません。

ヒートマップでも、訪問の少ない広告は、一部の人の操作が強く見えることがあります。

必要な件数は、調べたい差や普段の完了率などによって変わるため、全サイト共通の件数で決めないでください。

情報が足りない場合は、「観察継続」と記録します。

ただし、少数の録画でも送信ボタンが動かないなどの不具合を再現できた場合は、件数が増えるのを待つ必要はありません。

明確な不具合の修正と、広告間の優劣の判定を分けて扱います。

ヒートマップの差を広告施策へ変える

最後に、観察した違いを、修正する箇所と次に確かめる結果へ結び付けます。

訴求とLPの対応を修正する

広告Aだけで料金説明を探すような操作が見られたら、料金への案内を改善候補にします。

広告Bで操作例に届いていなければ、デモへの入口を分かりやすくする案を検討します。

広告そのものが誤った期待を生む表現なら、LPに説明を足すだけでなく、広告文を直す必要があります。

「無料」と伝えていて、実際には無料で使える範囲が限定されているなら、その条件を広告とLPでそろえます。

提供できない成果を、クリックを増やすために約束しないでください。

改修は、観察結果に対応する小さな単位で進めます。

例として「料金への案内を1か所追加する」「デモの場所を冒頭から分かるようにする」といった形です。

広告、見出し、価格、フォームを同時に変えると、どの変更が影響したかを切り分けにくくなります。

共通のLPに追加した案内は、他の広告から来た人の邪魔にならないかも確認します。

訴求ごとにページを分ける判断は、共通ページでは解決しにくい違いが見つかってからでも遅くありません。

次のテストで条件を維持する

次回の確認に備え、広告別LP分析の条件を1枚にまとめます。

以下は、社内で使うための記入例です。

項目	広告別LP分析の条件表
対象LP	サービス紹介ページの現行版
広告の違い	Aは費用、Bは作業削減を訴求
識別方法	utm_contentと入口URL条件
固定する条件	期間、端末、LPの版、計測定義
追加で記録	配信対象、掲載面、予算や設定の変更
観察箇所	冒頭、料金、操作例、CTA、フォーム
観察と仮説	Aで料金説明への到達を確認したい
修正候補	冒頭に料金への案内を追加
成果指標	同じ分母での受付完了ユーザー率
判定を保留する条件	データ不足、計測漏れ、ページの版の混在

ヒートマップを保存するときは、色だけの画像にせず、条件表も一緒に残してください。

広告のCTR、CPC、受付完了率は、それぞれ別の段階を表します。

ヒートマップの改善でCPCが必ず下がるとは言えません。

クリック後の行動を直した結果は、問い合わせの完了や獲得単価まで確認して評価します。

厳密な効果判定が必要な場合は、観察で立てた仮説を、適切に設計したA/Bテストへ進めます。

まずは同じLPで広告AとBを分け、違いが出た1か所を、録画と実ページで確かめてください。

広告の約束と、その後の操作をつなげて見ると、修正すべき場所を具体的に決められます。