こんにちは。バナナデスクです。
料金表の近くが赤くなっている。これは関心が高いのでしょうか、それとも押せそうに見えて何度も触っているのでしょうか。ヒートマップの色だけでは、どちらかは決められません。
LPの改善に使う時は、まず何を数えた図なのかを確認します。そのうえで、観測した動きと、その理由として考えた仮説を分けます。色からすぐに文章の良し悪しを決めないことが出発点です。
クリックとスクロールは別の行動を表す
Microsoft Clarityのクリックマップの公式説明では、PCのクリックとモバイル等のタップを扱い、リンクでない場所への操作も含むと説明しています。スクロールマップは、ページのどの位置まで到達したかを示すものです。
| 見えるもの | その図だけでは分からないもの |
|---|---|
| クリックが集まる場所 | 好意、理解、購入したい気持ち |
| 繰り返された操作 | 不具合か、意図的な再操作か |
| 下の節までの到達 | 文章を読んだか、理解したか |
| 申込ボタン付近の操作 | 送信成功、受付、契約の成立 |
クリック数を人数へ置き換えないでください。一人が同じ場所を何回も押せます。スクロールの到達も、そこで十分に読んだ時間とは別です。
先に揃えるのは、URL・版・期間・端末
同じURLでも、途中で料金表を移動していれば、古い配置と新しい配置の操作が混ざることがあります。比較する時は、表示しているページの版とデータ期間を確認します。
| 記録する条件 | 記入例 |
|---|---|
| 対象 | 架空相談LP／テストページのみ |
| 版 | v01。料金表は範囲説明の後 |
| 期間 | 取得開始と終了の日時を日本時間で記録 |
| 端末 | PCとモバイルを分ける。表示幅も必要に応じ記録 |
| 母数 | ツールが表示するページビュー・訪問者・クリックの単位をそのまま記録 |
| 目的 | 収集の動作確認か、実際の読者行動の観察か |
公式の機能と制約の説明には、動的な要素やスクロール対象などの制約もあります。画面に見えない箇所を「誰も操作していない」とすぐに判断せず、取得対象かどうかを確認します。
観測から、次に確かめることを書き出す
次の表は、見方を練習するための仮例です。実際のヒートマップを取得した数値や観測結果ではありません。
| 仮の観測 | 仮説 | 次に確認するもの |
|---|---|---|
| 画像の料金表に操作が集まる | 表を拡大したい、詳しい条件へ進めると思っている | 表示幅で文字を読めるか、リンクに見える装飾か、該当操作の記録 |
| 相談の流れより下への到達が少ない | 途中で判断を終えた、情報が長い、表示が崩れた | 上部での行動、端末別の見え方、下に何があるかの案内 |
| 申込ボタンの操作はあるが受付がない | フォームの不備、条件不一致、計測漏れ | フォームエラー、実受付ID、対象期間の計測条件 |
仮説を一つに固定しないことが大切です。「料金が高いから」という理由なら価格を変えたくなりますが、実際にはボタンが別の場所へ飛ぶ不具合かもしれません。まず、確認できる画面と記録で切り分けます。
動作確認の数件と、改善判断の標本を分ける
テスト担当者が指示どおりにクリックすれば、データを収集できるかは確かめられます。しかし、その数件から、一般の読者がどこに迷うかや、LP全体の反応率は判断できません。意図して押したテスト操作を、自然な訪問者の行動と混ぜないようにします。
少数の観察でも、ボタンが動かない、文字が重なるといった具体的な不備を見つけることはあります。一方、「赤いから人気」「青いから削除」といった評価には進めません。どの判断に使えるデータかを先に決めます。
修正後も、同じ条件で確認する
料金表の文字を直したなら、まず同じ幅で読めるかを確認します。その後、同じ対象・期間の長さ・計測定義で、該当箇所の操作や受付を見ます。流入元やキャンペーンが変わっていれば、その違いも残してください。
公開する分析例からは、顧客名、入力内容、個人を識別できる情報を除きます。色の図を見せるために、非公開の問い合わせ画面を載せる必要はありません。
ヒートマップは、読者の心を直接表示するものではありません。どこを確かめるかを決める手掛かりとして使い、実際の画面と受付の記録へつなげると、改善の理由を説明できます。