assessing-heatmaps

ヒートマップを評価する

ヒートマップは、「ページ上で人々はどこを操作しているか？」に答えます。クリック、怒りのクリック、マウスの動き、そしてページをどこまでスクロールするかが分かります。データは純粋な幾何情報です。pointer_relative_x（ビューポートの幅に対する位置、0～1）、pointer_y（ページ上端からの絶対ピクセル位置）、および各地点のカウントです。何がクリックされたかは分かりません。「(0.5, 220) でクリックが多い」を「料金プランのナビゲーションリンクがよくクリックされる」に変えることが作業のすべてであり、そのためには同じ URL のオートキャプチャと照合します。

基本原則：座標＋意味

ページを見ることはできません。コンテキストにスクリーンショットがないためです。優れた評価では、2 つの情報源を組み合わせ、見えないレイアウトや要素の識別情報を補うためにオートキャプチャを活用します。

1. ヒートマップデータ — 操作が発生した場所と、ユーザーがどこまでスクロールしたか（heatmaps-list）。
2. オートキャプチャ — 同じページ上のホットスポットにどの要素があるか。要素のテキストやセレクターから特定します。座標に意味を与えるのはこれです。これがなければ、点しか分かりません。

ユーザーがヒートマップを 見たい 場合は、保存済みヒートマップを作成します（ステップ 4）。データを重ねた状態でページがレンダリングされ、ユーザーは PostHog で開いて確認できます。データから推論するのはあなたであり、画像を見るのはユーザーです。

手順

ステップ 1：ページと期間を確定する

正確な url_exact（単一ページ）または url_pattern（クエリ文字列をまたいで集計する正規表現）が必要です。URL が曖昧な場合は、ユーザーに確認します。デフォルトは過去 7 日間とし、データ量が少ない場合は 30 日間に広げます。ヒートマップデータの保持期間は 90 日間です。

ステップ 2：データを取得する

対象のシグナルごとに heatmaps-list を 1 回呼び出します（または SQL で heatmaps テーブルを直接クエリします。querying-posthog-data スキルの models-heatmaps を参照）。

• type: "click" — 「何が注目を集めているか」を示す主要なマップです。
• type: "rageclick" — いら立って繰り返しクリックした操作です。**「何かが壊れている、または誤解を招いている」ことを示す最も強いシグナルです。**意味のある怒りのクリックのまとまりは、必ず取り上げてください。
• type: "scrolldepth" — ユーザーがどこまでスクロールするかを示します。ファーストビューの境界を特定したり、大半のユーザーがスクロールする範囲より下にある CTA を見つけたりするのに使います。

クリック数ではなくユーザー数を確認したい場合は aggregation: "unique_visitors" を使います。total_count では、少数の頻繁にクリックするユーザーの影響が大きくなります。

クリック結果はホットな順に返され、limit（デフォルトは 500）で上限が設定されます。アクセスの多いページには、座標が何千もあることがあります。そのため、デフォルトのページと fold の概要で通常は十分です。分析の対象となるのは、ホットスポットです。すべてを要求しないでください。どうしても追加のデータが必要な場合に限り、limit を増やすか offset でページを移動し、リストが途中で切れているかを has_more で確認します。scrolldepth は limit を無視し、常にすべてのバケットを返します。

ステップ 2b：ファーストビューの下 — fold の概要を読む

クリックタイプの場合、heatmaps-list は results とともに fold オブジェクトを返します。

• pct_below_fold — 固定されていない操作のうち、ユーザーの初期ビューポートより下で発生した割合です（そこに到達するにはスクロールが必要です）。特に価値の高い発見のひとつです。ユーザーが積極的にクリックしているコンテンツがファーストビューより下にある場合、上に移動する有力な候補です。
• below_fold_count / total_count — 割合のもととなる実数です（固定位置の要素は常に画面上にあるため除外されます）。
• median_viewport_height — 典型的なファーストビューの境界を CSS ピクセルで示し、改善提案の基準になります。

たとえば、「大半の訪問者にとってファーストビューの境界は約 600px ですが、クリックの 35％ はその下で発生しています。つまり、ユーザーは操作する前にスクロールしており、このコンテンツは最初の画面に移動する候補です」のように具体的に報告します。viewport_width_min / viewport_width_max を使ってデバイスごとにセグメント化し（デスクトップとモバイルではファーストビューの境界が大きく異なります）、それらを混ぜずに各幅の範囲で fold を確認します。

単一の割合ではなく分布（たとえば、ファーストビューの境界からどれくらい下かでクリックを分類したもの）が必要な場合は、生の heatmaps テーブルに対して SQL を実行します。このテーブルには y と viewport_height が同じスケールの単位で含まれています。querying-posthog-data スキルの models-heatmaps を参照してください。

ステップ 3：ホットスポットにある要素の名前を特定する（自動キャプチャとの照合）

目立つクラスターごとに、実際に何があるのかを調べます。同じ URL で自動キャプチャをクエリします。exploring-autocapture-events スキルを使うか、直接クエリします。

SELECT properties.$el_text AS text, count() AS clicks
FROM events
WHERE event = '$autocapture'
  AND properties.$current_url = 'https://example.com/pricing'
  AND timestamp >= now() - INTERVAL 7 DAY
GROUP BY text
ORDER BY clicks DESC
LIMIT 25

elements_chain を使うと、同じテキストを持つ 2 つの要素を区別する必要がある場合に、セレクター／DOM パスを確認できます。自動キャプチャの上位要素をヒートマップのホットスポットの座標と照合します。リンクやボタンではないもの（通常のテキスト、画像、無効なコントロールなど）にクリックが集中している場合は、「クリックできるはずだとユーザーが思っている」という典型的な発見です。

ステップ 4：ユーザーが確認できるヒートマップを用意する（任意）

ページを見ることはできませんが、ユーザーは見ることができます。視覚情報があると調査結果を把握しやすくなる場合は、保存済みヒートマップを作成して、データを重ねたページを PostHog で開けるようにします。

1. ページの url を指定して heatmaps-saved-create を実行します（タイプの既定値は screenshot です）。これによりヘッドレスレンダリングがキューに追加されます。処理は非同期です。ステップ 2 で分析したビューポートの幅に合う widths を渡します。
2. 返された short_id で heatmaps-saved-get をポーリングし、status が completed になるまで待ってから、PostHog で確認できる状態になったことをユーザーに伝えます。

これはユーザーのためのものです。あなた自身の分析は、引き続きステップ 2 のデータとステップ 3 の自動キャプチャによる要素の特定に基づいて行い、画像には頼りません。

ステップ 5：ホットスポットを詳しく調べる（理由を知りたい場合）

意外なクラスターについては、heatmaps-events を使うと、特定の points の背後にある個々のセッションを取得できます。セッション ID を investigating-replay スキルに渡し、ユーザーが実際に何をしたかを確認します。

ステップ 6：要約して提案する

簡潔で具体的なレポートを作成します。

• ヒートマップが示していること — エンゲージメントが高い要素、反応のない領域、スクロール到達位置、折り返し線より上／下のクリック割合（例：「ほとんどの訪問者のビューポートは約 600px ですが、クリックの 35％がその下に集中しています」）。
• 問題点。シグナルの強さで順位付けします。まず連打クリックのクラスター、次に非インタラクティブ要素へのクリック、続いてスクロールの崖より下にある重要な CTA、最後に無視されている主要なアクションです。
• 根拠に基づく提案 — CTA を折り返し線より上に移動する、クリックされているのに反応しない要素を実際のリンクにする、連打クリックのクラスター付近にある競合要素を減らすなどです。各提案には、根拠となったシグナルを必ず示します。

シグナルの読み方

シグナル	考えられる意味	一般的な提案
要素への連打クリック	壊れている、遅い、またはクリックできそうに見えるが実際にはできない	ハンドラーを修正する、フィードバックを追加する、または実際に操作できるようにする
リンクではないテキスト／画像への多数のクリック	ユーザーがクリックできると期待している	リンク／ボタンにする、またはクリックできるように見える表現をなくす
主要な CTA のクリックが少ない	目立たない、コントラストが低い、または他の要素に埋もれている	上に移動する、コントラストを高める、周囲のノイズを減らす
重要なコンテンツの前にスクロールの崖がある	コンテンツ／CTA がユーザーのスクロール停止位置より下にある	上に移動する、またはスクロールする理由を追加する
折り返し線より下のクリック割合が高い	エンゲージメントの高いコンテンツが最初のビューポートの下にある。ユーザーは操作する前にスクロールしている	最もクリックされている要素を最初の画面に移動する
ナビゲーションのクリックは多く、本文の反応は少ない	ページが期待に応えておらず、ユーザーがナビゲーションに戻っている	ページの主要コンテンツを見直す

注意点

• ヒートマップは明示的に有効化する必要があります（Team.heatmaps_opt_in）。ページに明らかなトラフィックがあるのに heatmaps-list が何も返さない場合、記録がオフになっているか、URL が間違っている可能性があります。「エンゲージメントなし」と結論づける前に、両方を確認してください。
• 座標はストレージ内で 16 倍にスケーリングされています。API は CSS ピクセル単位の pointer_y と相対 x をすでに返すため、テーブルの生の列ではなく、API／ツールの値をそのまま使ってください。
• スクリーンショットを見ることはできません。 保存済みヒートマップのレンダリングは、ユーザーが PostHog で開くためのものです。ページを見たと主張しないでください。レイアウトに関する主張はすべて、視覚情報ではなく、オートキャプチャの識別情報と座標に基づけてください。
• 保存済みヒートマップのレンダリングは非同期です。 heatmaps-saved-create の後、status が completed になるまで heatmaps-saved-get をポーリングしてから、ユーザーに表示可能だと伝えてください。画像がレンダリングされるのは screenshot タイプのヒートマップのみです。iframe と recording タイプではレンダリングされません。
• ビューポートに注意してください。 デスクトップのクリックマップとモバイルのクリックマップでは、対象となるページの動作が異なります。混在させずに、viewport_width_min／viewport_width_max で絞り込んでください。