WebヒートマップでEC商品ページを改善｜購入前に見られる情報を調べる

WebヒートマップでECの商品ページを改善するとき、最初に見るべきものはボタンの色だけではありません。

購入を決めるための情報にたどり着けるか、選択した商品を迷わずカートへ追加できるかを確認します。

画像にクリックが集まっていても、魅力が伝わっているのか、細部が分からず何度も開いているのかは、色だけでは判断できません。

サイズや送料を調べている途中で、別のページへ移動している可能性もあります。

この記事では、商品画像、配送・サイズ・返品の説明、カート追加の前後を順に調べる手順を紹介します。

最後に、次の修正を決めるための商品ページの情報不足チェック表を作ります。

操作例にはClarityとGA4を使い、商品名・観察メモ・集計例は架空のものとして示します。

機能や計測の説明は、2026年10月5日に確認した公式資料に基づきます。

EC商品ページでヒートマップを見る目的

購入判断に必要な情報を整理する

最初に、商品を買う前に確認したいことを洗い出します。

アパレルなら、サイズ、着用感、素材、色の違いが候補になります。

家具なら、寸法、設置場所、搬入条件、送料を確かめたいでしょう。

商品ごとに違う問いを、一つの「商品説明が読まれたか」へまとめないようにします。

次の表は、架空のバッグの商品ページを調べる場合の例です。

購入前の問い	必要な情報	ページ上の確認場所
荷物が入るか	寸法、収納例	サイズ表、使用写真
重くないか	重量、素材	商品仕様
いつ届くか	発送予定、配送条件	配送の説明
総額はいくらか	商品価格、送料条件	価格付近、送料案内
合わなければどうするか	返品・交換条件	返品案内

Baymardの製品ページ研究でも、実物の大きさが伝わる画像や、購入前に確認できる費用・返品情報が扱われています（参考：Baymard Institute：商品ページUXの研究）。

ただし、その知見を自社の利用者全員の行動と置き換えることはできません。

まず調べる項目を決める参考にし、自社の記録と実画面で確かめます。

商品ページに情報がない場合と、あるのに見つけられない場合も分けましょう。

前者なら情報の追加、後者なら配置や導線の修正が候補になります。

商品閲覧と購入完了を分ける

商品ページの役割は、購入判断を助け、必要な選択を経て次の工程へ進めることです。

ページが見られた回数と、売れた個数は別の情報になります。

GA4では、商品詳細の閲覧、カート追加、購入手続きの開始、購入をそれぞれ別のイベントで扱います（参考：Google：eコマースの測定）。

工程	GA4のイベント例	確かめること
商品詳細を見る	view_item	対象の商品情報が表示されたか
カートへ追加する	add_to_cart	選んだ商品が追加されたか
購入手続きを始める	begin_checkout	手続きの入口まで進んだか
購入を完了する	purchase	正常な注文を計測できているか

これらは、ヒートマップを入れればすべて自動で正しく集計されるという意味ではありません。

現在のEC連携やイベント実装を確認し、商品ID、数量、送信タイミングを点検します。

クリックだけをカート追加成功として数えると、サイズ未選択などで止まった操作が混ざる可能性があります。

ClarityのEC向け機能にも利用条件があり、公式資料ではPurchasesはShopify、Checkout AbandonmentはShopify Plusのサイト向けとされています（参考：Microsoft Learn：E-Commerce Insights）。

自社で利用できる情報を確かめ、取得できない工程はGA4やEC基盤の集計で補います。

この記事では、主に商品詳細からカート追加までの画面を調査対象にします。

商品ページの集計条件をそろえる

在庫と販売期間を確認する

商品ページの反応を比べる前に、その期間に購入できたかを調べます。

在庫切れの商品と、全サイズが選べる商品では、カート追加の意味が変わります。

同じ商品でも、人気の色だけ売り切れている場合があります。

「商品は販売中」という情報だけでなく、選択肢ごとの在庫も確認してください。

架空の調査メモなら、次のように残せます。

対象商品：通勤用バッグA
対象期間：9月21日〜27日
販売状況：期間中は販売中
在庫の変化：25日午後からネイビーのみ在庫切れ
価格の変更：なし
配送条件：26日から発送予定日の表示を変更
画面の変更：なし

この場合、在庫切れの前後を一つにして、ネイビーの選択率やカート追加率を評価しないようにします。

Clarityの商品フィルターには在庫などの項目がありますが、Product JSON-LDの実装が前提になる項目があります（参考：Microsoft Learn：商品フィルター）。

表示されない場合は、取得条件を確認してください。

フィルターがある場合でも、すべてのバリエーションの在庫履歴を完全に表すと決めつけず、EC管理側の記録と照合します。

販売できなかった理由を、ヒートマップの反応だけでデザインの問題へ置き換えないことが大切です。

流入と端末を分ける

次に、どんな訪問を比べるかを決めます。

広告から特定の商品へ直接来た人と、商品一覧で比較してから来た人では、事前に知っている情報が違います。

新規訪問と買い足しの訪問でも、確認する内容は同じとは限りません。

まずは、商品、端末、期間をそろえ、必要に応じて流入条件を分けます。

条件	架空の設定例
対象ページ	バッグAの商品詳細URL
端末	スマートフォン
期間	在庫がそろっていた期間
流入	対象広告からの訪問
画面の版	同じ商品詳細テンプレート

Clarityを使う場合は、URLや端末に加え、参照元・UTMに関するフィルターの対象を確認します（参考：Microsoft Learn：フィルターの概要）。

GA4と比較するなら、入口のページを絞っているのか、訪問途中に見たページを絞っているのかも対応させます。

スマートフォンの画面では、固定カートボタンやメニューが説明に重なっていないかを別に見ます。

商品数が多くても、最初から全商品をまとめる必要はありません。

一つの商品で手順を確かめてから、同じ構成の商品群へ広げます。

商品画像のクリックを調べる

拡大や切り替え操作を見る

クリックヒートマップでは、商品画像、サムネイル、拡大ボタンへの操作を確認します。

Clarityなら、Heatmapsで対象URLと端末を設定し、クリックマップを開きます。

どの要素にクリックがあるかを調べ、必要に応じてその要素を押した録画へ進めます（参考：Microsoft Learn：クリックマップ）。

画像へのクリックが多いときは、次の二つを分けて考えます。

• 画像から、必要な情報を確認しようとしている
• 画像の操作や表示が分かりにくく、押し直している

ヒートマップだけでは、どちらかは決まりません。

録画で、画像が切り替わったか、拡大されたか、その後にどこへ進んだかを見ます。

例えば、バッグの底面や内側の写真を繰り返し開く場面なら、収納や素材を調べている可能性があります。

これは原因の仮説であり、利用者が何を考えたかを断定するものではありません。

実際の商品写真に、寸法や使用時の大きさを判断できる材料があるかも点検します。

Baymardの研究では、既知の大きさの物や人との比較で、商品のサイズを把握しやすくする画像が紹介されています（参考：Baymard Institute：大きさが分かる商品画像）。

画像を増やすこと自体を目的にせず、最初に挙げた購入前の問いに答えられるかを確認してください。

操作後に戻る動きを確認する

商品画像を開いた後の動きも、調査対象です。

拡大画面を閉じられるか、元の位置へ戻るか、選択済みの色やサイズが保たれるかを確認します。

次のように、観察を操作単位で書くと、実機で試しやすくなります。

観察する操作	確かめること
サムネイルを押す	対応する画像へ切り替わるか
画像を拡大する	見たい細部を確認できるか
拡大画面を閉じる	元のページへ戻れるか
別の色へ切り替える	写真と選択表示が対応するか
商品選択へ戻る	前の選択が意図せず失われないか

画像を閉じた直後にページが大きく移動するなら、元の情報を探し直している可能性があります。

反対に、次の写真へ進んでからカート追加へ向かうなら、確認のための自然な操作かもしれません。

録画の表示が崩れている場合は、実際のページでも再現するかを先に確かめます。

Clarityの録画はCSSなどの取得状態により、実際の画面と異なる再現になる場合があります（参考：Microsoft Learn：録画表示のトラブルシューティング）。

画像操作の故障と、録画側の再現の問題は分けて記録してください。

修正の依頼には、端末、ブラウザ、選択した商品、押した順番を添えます。

配送・サイズ・返品の説明を点検する

説明への到達を確認する

画像を確認したら、購入条件の説明へ進みます。

まず、サイズ、配送予定、送料、返品条件が、どこに置かれているかを実画面で確かめます。

そのうえで、スクロールヒートマップで対象位置への到達を調べます。

Clarityのスクロールマップでは、ページ上の位置と到達割合を対応させて確認できます（参考：Microsoft Learn：スクロールマップ）。

ただし、折りたたまれた説明の見出しまで到達したことと、中身を開いたことは別です。

到達、展開、内容の確認を一つの「読まれた」にまとめないようにします。

情報	見出しへの到達	中身を開いたか	次に確認すること
サイズ表	ヒートマップで確認	クリックや録画で確認	単位や測り方の説明
配送予定	表示位置を確認	折りたたみなら確認	日付と条件の分かりやすさ
返品条件	案内への到達を確認	リンク遷移を確認	対象外条件と戻る導線

Baymardは、商品ページの段階で送料の見通しを示す必要性を、利用者調査に基づいて説明しています（参考：Baymard Institute：商品ページの送料情報）。

自社でも、購入直前まで総額の条件が分からない構成になっていないかを調べます。

送料をまだ確定できない場合は、分かる範囲と、金額が決まる条件を伝える方法を検討します。

実際の販売条件と異なる「送料無料」や「即日発送」を、反応を取るために強調しないでください。

説明を探す動きを録画で見る

配送や返品の情報は、商品ページの本文以外から探されることもあります。

Baymardの研究では、フッターから送料や返品への直接リンクを探す行動も報告されています（参考：Baymard Institute：送料と返品への導線）。

そのため、本文の到達だけで「調べていない」と判断しないようにします。

録画では、商品ページからどの案内へ進み、どこへ戻ったかを確認します。

例えば、サイズ表を開き、商品ページへ戻って色を選び直しているなら、選択が保持されているかを点検します。

フッターのFAQから配送説明へ進んでいるなら、商品ページの近い場所にも案内が必要かを検討できます。

次の表を使って、情報不足と導線の問題を分けてください。

観察した事実	原因の仮説	追加確認
サイズ表へ何度か往復	商品との対応を確かめにくい可能性	選択中のサイズと表の関係
フッターへ移動して配送案内を開く	本文の案内に気づきにくい可能性	上部の表示とリンク文言
返品案内から戻ると選択が消える	比較の作業をやり直している可能性	実機で選択の保持を確認

これは架空の観察例です。

往復があることだけで、不満や迷いが確定するわけではありません。

必要に応じて、購入前の問い合わせ内容やユーザビリティテストも照合します。

録画で推測したことと、利用者に確認できたことは、報告書でも分けて残しましょう。

カート追加ボタンの前後を確認する

選択必須項目を調べる

カートボタンが押されているのに追加されない場合は、色やサイズなどの選択状態を確認します。

購入可能な選択肢が見えるか、必須項目が分かるか、未選択のときにどんな案内が出るかを調べます。

Baymardの研究では、サイズ選択肢や在庫がメニュー内に隠れ、確認しづらくなる問題が扱われています（参考：Baymard Institute：サイズ選択の見え方）。

自社の画面では、表示形式を変える前に、次の状態を実機で試します。

1. 必須項目を選ばずにカート追加を押す
2. 一部だけ選び、残りを未選択にする
3. 在庫がある組み合わせを選ぶ
4. 在庫切れの選択肢がどう表示されるか確認する
5. 選択後に画像や説明を開き、戻った状態を確認する

本番で注文を確定する必要はありません。

テスト可能な環境や、実際の購入が発生しない範囲で操作してください。

エラー時は、赤い枠だけでなく、何が足りないかを文字で伝えているかを確認します。

W3Cのエラー識別の解説でも、入力エラーの対象を特定し、内容をテキストで説明する考え方が示されています（参考：W3C：Error Identification）。

スマートフォンでは、案内が画面外に出たり、固定ボタンの下に隠れたりしていないかも見ます。

録画に選択値が表示されない場合は、マスキングされた情報を無理に読み取ろうとせず、実機で状態ごとに確認します。

追加成功の表示を確認する

次に、正常に追加できたときの表示を確認します。

ボタンを押した後、カート件数、追加した商品、選択した色やサイズが分かるかを見ます。

画面上の反応が弱いと、処理中なのか、失敗したのかを確かめるために再度押す可能性があります。

ただし、連続クリックがあるだけで、必ず不具合や不満があるとは言えません。

操作の直後に何が表示されたかと、実際のカート内容を照合します。

状態	実機で確認すること
処理中	待機状態が伝わるか
追加成功	商品・選択肢・数量が正しいか
追加失敗	理由と次の操作が分かるか
再度押す	意図せず数量が増えないか
カートへ進む	元の商品と選択が一致するか

成功表示は、目で見えることに加えて、支援技術を使う場合にも伝わる設計を確認します。

W3Cのステータスメッセージの解説には、カートの件数が変わったことをスクリーンリーダーへ伝える例があります（参考：W3C：Status Messages）。

ヒートマップだけでは、読み上げによる操作の使いやすさまで評価できません。

実際のキーボード操作や読み上げで、追加後の状態を確認する作業も必要です。

また、GA4のadd_to_cartが単なる押下ではなく、意図した追加を表しているかを確認します。

画面の成功表示と、計測上の成功をそれぞれ点検してください。

商品ページの改善を評価する

同じ商品条件で比べる

修正前後の比較では、商品ページ以外に変わった条件も記録します。

価格、在庫、広告、配送予定が同時に変わっていれば、結果の差をページ修正だけの効果とは言えません。

次のチェック表を、担当者との確認に使えます。

確認項目	問題候補	次に行う確認
商品画像	大きさや内部が分からない	必要な写真と操作を点検
サイズ	表や選択肢が見つからない	表示位置と未選択時の案内
配送・送料	条件の確認に遠回りする	商品ページからの導線
返品	対象条件が分かりにくい	要約と詳細へのリンク
カート追加	成功したか分からない	状態表示と実際の内容
比較条件	在庫や価格が変わった	対象期間を分けて集計

この表は、商品ページの情報不足チェック表として、調査した事実を追記して使います。

問題候補には、録画で確認した操作や、実機で再現できた現象を添えます。

最初の修正は、一つの問いに対応する範囲へ絞ると、後から確認しやすくなります。

例えば「選択し忘れたサイズへ戻れるか」を調べるなら、エラーの案内と移動を修正対象にします。

その時点で画像や価格表示まで一斉に変えると、結果の理由を調べにくくなります。

効果の比較が必要で、十分な対象と実施条件があるなら、A/Bテストも検討します。

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

購入までの結果を追う

修正後は、まず同じ操作で問題が解消したかを確認します。

次に、対象商品の閲覧、カート追加、購入完了を分けて追います。

例えば、カート追加が増えても、決済前の離脱が増えていれば、売上が増えたとはまだ言えません。

商品の返品やキャンセルが増えていないかも、EC側の記録と合わせて確認します。

集計するときは、回数、人数、数量を混ぜないようにします。

一人が同じ商品を複数回追加した場合、追加イベントの回数と追加した利用者数は違います。

GA4のファネルデータ探索を使う場合も、どのステップをどの順番で通った人を対象とするかを定義します（参考：Google：ファネルデータ探索）。

サイト全体の購入が増えたかだけでなく、今回調べた商品の条件に対応しているかを確認してください。

同じ商品でも、色やサイズの単位が計測とEC管理側で一致していないことがあります。

商品IDの対応を残し、何の改善を評価しているかが分かる状態にします。

調査の最後は、次のような短い記録にまとめられます。

問い：サイズ未選択時に、選択へ戻れるか
事実：録画で押し直しを観察し、実機でも案内が画面外に出た
修正：未選択項目の近くに説明を表示
確認：スマホで選択へ戻り、正しい商品を追加できた
計測：同じ商品・在庫・流入条件で、その後の工程を集計
未確定：売上への効果は、購入完了と件数を継続確認

これは架空の報告例です。

Webヒートマップは、購入を妨げているかもしれない箇所を見つける手がかりになります。

色やクリック数だけで結論を出さず、必要な情報、操作の前後、購入までの結果を順に確かめてください。