A shopper opens a product page, taps the delivery text three times in under two seconds, then leaves. In the analytics report that visit is one session with no purchase, filed next to a few thousand others that look exactly the same. In a session recording it is a person trying to open something that was never built to be opened.
Ecommerce heatmap analysis, and the session recordings that usually sit beside it, are good at that second reading and weak at the first. They explain why a behaviour happens on a particular page, and they are a poor way of deciding which page deserves the attention. Read after the numbers have narrowed the question, they turn a drop-off into an explanation someone can act on. Read first, they turn into hours of watching strangers browse.
What These Tools Record, and What They Do Not
Microsoft describes a heatmap in its Clarity documentation as “a visualization tool that makes it easy to analyze aggregated information about how users interact with the website”. The word doing the work is aggregated. A map summarises many visits, so it can show that an element attracts clicks while saying nothing about who clicked it or what they expected. Clarity also notes there is “no minimum traffic limitation to generate a heat map”, which is convenient and slightly dangerous: a map built from forty visits looks as confident as one built from forty thousand.
Session recordings are misread in the opposite direction, as though a camera had been pointed at the customer. Clarity’s recordings documentation is explicit that sessions “aren’t actual recordings of the user experience, but rather a step-by-step visual reconstructions by capturing the HTML and user actions”. What plays back is a rebuild of the page from captured markup, so anything the tool could not capture is absent from the replay, which matters most when the missing element is the one under investigation.
The map types are frequently used interchangeably, although each answers a different question:
- Click maps show the most clicked elements. Clarity builds them from element-based clicks “instead of the absolute mouse position”, so they stay readable across viewport sizes where a coordinate-based map would smear.
- Scroll maps show how far down a page visitors reach, with an average fold, described as “the average location visible on a webpage before the user starts scrolling”. A section never reached is a different problem from one reached and ignored.
- Area maps “display the total clicks for all the elements within a selected area”, which suits a dense block such as a filter panel where individual controls are too small for a click map to separate.
- Conversion maps show “what clicks lead to best conversions, which elements caused highest purchase prices, and what parts of your page are less successful”. Reach for these when engagement and revenue disagree.
- Attention maps show “the amount of time users spent on each part of the page”, separating a block people scroll past from one they stop at without clicking.
None of these measures intent. HubSpot’s guidance on reading heat maps adds a caution that is easy to skip: “When using scroll maps, always look at metrics on different devices, including smartphones and tablets.” A blended map of a page whose mobile and desktop layouts differ describes a page nobody was actually served.
Vendor differences matter more than they appear. Adobe’s Activity Map in Adobe Analytics also produces “heat maps and overlay reports that show the most popular elements on a webpage”, but it models the page through Activity Map Link, Region and Page dimensions, so the analysis is closer to a report than to a picture. It also carries preconditions: “a report suite must have Activity Map enabled before you can start using it”, and the overlay “is not available for Web SDK implementations”. Worth confirming before planning work around it.
Why Ecommerce Heatmap Analysis Belongs After the Numbers
Quantitative data is better at locating a loss and worse at explaining it. Google’s funnel exploration in GA4 “lets you visualize the steps your users take to complete a task and quickly see how well they are succeeding or failing at each step”, which is the input a behavioural tool needs and cannot produce for itself. HubSpot’s guide to visitor behaviour analysis describes the same division of labour, combining “quantitative metrics, like page views and session duration, with qualitative insights pulled from heatmaps, session recordings, and user journey mapping”, on the grounds that “watching real users navigate a site exposes usability issues that metrics alone cannot reveal”.
The reason to insist on that order is economic. A funnel report takes minutes and covers every visit in the period. Recordings play close to real time, so an analyst who has watched thirty sessions has spent a morning on a sample no report would accept as representative. Spending that morning on the step where a fifth of qualified traffic disappears is defensible. Spending it on a list sorted by newest is how behavioural tooling ends up unused after two months.
The funnel narrows the question without settling it, and its own documented behaviour is worth knowing. GA4 states that when a user completes the steps several times in the date range, “only the first sequence of steps will be reported”, so a considered purchase made across visits is described by its first attempt. With a breakdown applied, “users are only attributed to the first instance of the breakdown value that applies to them”, which files a shopper who researches on a phone and buys on a laptop under the phone.
Google’s path exploration is the useful companion at this stage, since it is built to uncover “looping behavior which may indicate users becoming stuck”. That is the pattern most worth carrying into a recording, because a loop is a question the aggregate cannot answer on its own.
Reversing the order is sometimes reasonable. A page released last week has no trend to interrogate, and a few sessions may surface a broken control faster than waiting for figures to stabilise. A store with modest traffic may never accumulate enough sessions for a funnel breakdown to hold steady, in which case behavioural evidence is not the second step but the only one available.
The Frustration Signals Worth Filtering For
Most of the value in a replay tool comes from its filters rather than its player, because filters jump straight to sessions where something went visibly wrong. Clarity’s semantic metrics tag these automatically, and each carries a different weight of evidence.
Rage Clicks and Dead Clicks
A session is flagged with a rage click when “the user clicks multiple times in a clustered area in rapid succession”, and a click is dead when “a user clicks on an element but gets no feedback in a reasonable amount of time”. Clarity notes that a dead click “can signify broken elements, high latency requests, or misleading UX”. Those causes belong to three different owners: a developer, whoever manages infrastructure and third-party scripts, and whoever designs the page. The signal identifies a location reliably; it does not identify a cause, so a report presenting a rage-click cluster as a bug list will often route work to the wrong team.
On product pages the most frequent finding is not a defect at all. Clusters on a non-interactive image are usually a request for a zoom that was never implemented, and clusters on a specification line often mean a shopper expected a size chart. Both are design decisions rather than failures, and both are cheap to answer once visible.
Quick Backs and Excessive Scrolling
A quick back is a click that takes a user away from a page, after which they return “under a certain threshold of time”. A run of quick backs from a collection page into product pages usually indicts the listing rather than the products: images, prices or titles that promise something the destination does not deliver. Excessive scrolling flags sessions with “higher amounts of vertical scrolling than the expected average” and, in Clarity’s wording, “can be a strong indicator that a given page could be contributing to the site abandonment”. On a long collection page it may equally mean the filters exist but are not doing their job.
Click Errors
Click errors are the closest thing here to evidence rather than inference. Clarity defines them as “JavaScript errors that occur after a user click” and tags the session automatically each time one occurs. This names a defect and supplies the reproduction path in the same place. An error firing on one browser, one variant selector or one payment option stays invisible in aggregate reporting while removing a slice of orders, so findings here need a ticket rather than a test.
Where Heatmap Data Stops Being Reliable
Ecommerce heatmap analysis is only as reliable as the components the map can actually capture, and a map presents itself as a picture of the whole page. Clarity’s documented limitations tend to land on the interface a store argues about most:
- Clarity “doesn’t support capturing screenshots of different dynamic sections, such as a menu that opens as you hover/click. A heat map won’t display clicks or scrolls collected over these dynamic elements.” Mega-menus, filter drawers, mini-carts and variant modals are dynamic in that sense, so contested interface may be missing from the map rather than unused in it.
- “Clarity scroll maps are built for the <body> tag. Clarity can’t show scroll map inside the <div> container.” A collection page whose results scroll in their own container can return a map describing the frame instead of the list, which is worse than no map because it looks plausible.
- “Clarity can only render scroll maps for pages with a maximum height of 65,535 pixels.” Buying guides and infinite-scroll collections can exceed that, and those are the pages where scroll depth is the whole question.
- “Heat maps are limited to up to 100,000 page views per heat map.” A busy homepage may need a narrower range to stay inside the ceiling, and that narrowing changes what the map represents.
- Retention differs sharply by data type. Heatmap data “is retained for up to 9 months”, while Clarity “keeps recordings for 30 days” and afterwards keeps “1% of your recordings or 10 recordings per day, whichever is higher”. An investigation opened three months after a release finds the aggregate intact and the individual evidence thinned out.
- “You can’t use GA segments on Heatmaps.” Audience logic built in analytics does not travel, so it has to be rebuilt in the tool’s own filters, and the two definitions may not agree.
Page states deserve the same scepticism. An out-of-stock product page, a logged-in customer with a saved address and a first-time visitor on a promotional variant are three different pages sharing one URL, and a single map averages them into something nobody saw. Establishing once which components and states are visible is an afternoon’s work that stops the doubt being rediscovered in every review.
Checkout Is the Hardest Part to Watch on Shopify
The step most stores want to see is the one they are least likely to get. Shopify’s documentation on web pixels states that they “are loaded in a sandbox on a visitor’s browser, and are designed to give merchants and customers complete control over what data is accessible to app developers”, and that “some common features of pixels won’t work the same or won’t work at all. Specifically, these include any features that rely on scraping the DOM for information or attempting to write to the DOM.”
Session replay is built on reading the DOM. A store on Shopify may therefore observe its whole storefront and very little of its checkout, so the checkout has to be diagnosed from stage-level funnel data, the platform’s own reports and the behaviour immediately upstream. That is not a reason to skip the work, since a good share of checkout losses are decided earlier, in shipping expectations set on the product page or a cart that never made the total clear.
The comparison with other platforms is two-sided. On WooCommerce or Adobe Commerce the checkout belongs to the same theme, so recording it is a template decision rather than a platform restriction, and visibility can be deeper. The store then owns the privacy exposure that Shopify’s sandbox removes on its behalf, plus the cost of another script on the highest-value pages in the funnel. Neither arrangement is simply better; they allocate the same risk to different parties.
Internal expert input required: confirm which replay vendor the client uses and whether its Shopify integration captures any checkout step, before promising checkout-level visibility in a proposal.
Masking, Privacy and a Trade-off Few Teams Set Deliberately
Replay tools handle sensitive content by masking it before it leaves the browser. Clarity’s masking documentation states that it “masks sensitive content on your website by default and never captures anything that is masked or sent over the wire”. Three modes are offered: Strict, where “the entire content is masked”; Balanced, the default, where “only sensitive content is masked” and “we classify numbers and email addresses as sensitive content”; and Relaxed, where “no content is masked” although input boxes and dropdowns still are.
Read that against a real investigation and the tension is clear. Under the default mode, numbers count as sensitive, which can cover prices, quantities, delivery dates and any validation message containing a figure. Those are often the exact elements a team wants to read when it asks why a cart was abandoned. Relaxing the mode returns the detail and moves privacy exposure back onto the store, a decision for whoever owns data protection rather than whoever owns conversion.
One operational detail decides whether that choice can be revisited: masking changes “affect new recordings” and “can’t be applied retroactively”, so the configuration has to be right before the period you will want to examine. Clarity also notes that it “doesn’t mask content within style sheets or style tags”, which is worth checking on custom builds that inject values through generated stylesheets.
Internal expert input required: record the agreed masking mode, the consent basis under which replay runs, and who approved it, before enabling recordings on a client store.
Which Method Answers Which Question
| Method | The question it answers well | What it cannot tell you | Best used when |
|---|---|---|---|
| Funnel and path reports | Where visits are lost, and how much is lost at each step | Why any individual step fails | At the start of an investigation, and again to size a finding |
| Click, area and conversion maps | Which elements attract interaction, and which clicks precede revenue | What the shopper expected the element to do | When a page has traffic but the interaction pattern looks wrong |
| Scroll and attention maps | How far a page is read, and where time is spent | Whether unseen content would have changed the decision | On long pages, and after any layout or ordering change |
| Session recordings | What a specific journey looked like, including errors and hesitation | How common the behaviour is across all visits | After a step is isolated, filtered to a defined behaviour |
| Moderated usability testing | Why a person made a choice, in their own words | Anything about scale or your real traffic mix | When traffic is too low for the other methods to stabilise |
| A/B testing | Whether a change improves the outcome, within a margin of error | Anything at all until the sample is sufficient | When the fix is a judgement call rather than a defect |
Each row is weakest exactly where its neighbours are strongest, which is why single-method programmes stall predictably. Analytics-only teams collect accurate problem statements they cannot explain; replay-only teams collect vivid explanations they cannot size. Ecommerce heatmap analysis sits between the two, and HubSpot puts the reason plainly: heatmap tools “aggregate data from thousands of sessions to show statistically significant patterns while also allowing drill-down to individual sessions”. The aggregate is what makes the individual session worth watching.
Key takeaway: a heatmap or a recording is evidence of behaviour, not evidence of cause. It repays the time spent when it converts a number you already trust into a specific, testable explanation, and it wastes that time whenever it is asked to decide what matters.
A Working Sequence for Ecommerce Heatmap Analysis
The order below is deliberately slow at the start, because each early step reduces how much watching the later ones require.
- Quantify the loss first. Establish which step loses the most qualified traffic and what it is worth. Without that, findings compete on how interesting they looked rather than what they cost. Our guide to what a professional ecommerce CRO audit covers sets out how the baseline is assembled.
- Reduce it to one page and one question. “Why do people leave the product page” is not answerable by a tool. “Do mobile visitors reach the delivery information before they leave” is, and it determines which map you open.
- Read the aggregate before the individual. Maps cover every qualifying visit, so they are the cheapest way to see whether a pattern exists. Split by device first, and confirm the component you care about is one the map can capture.
- Filter recordings by behaviour, not recency. Filtering to rage clicks, dead clicks, click errors or an exit at the step in question raises the share of sessions containing what you are looking for.
- Write the hypothesis with a mechanism in it. “Shoppers cannot see the returns policy from the product page, so they leave to find it” can be checked and predicts what should change. “The product page needs improvement” predicts nothing.
- Decide between a fix and a test. A script error on a variant selector is a defect and should be corrected without ceremony. A change to how shipping cost is presented is a judgement call, and on a page with enough traffic it belongs in an experiment. Our overview of A/B testing experiments for ecommerce is a reasonable backlog for the second category.
- Re-measure the same map afterwards. Comparing the page before and after, on the same device split and a comparable period, is what turns a behavioural finding into a result rather than an anecdote.
Mistakes That Make Behavioural Data Misleading
Failures here are rarely technical. They come from reading the output more confidently than it deserves, and three patterns account for most of them.
The first is treating colour as a measurement. Clarity’s scale is relative to the page in view, where “red indicates hot areas where users interact more” and blue the least popular. A red element is the most clicked thing on that page, which says nothing about whether the number of clicks is adequate, and comparing the redness of two pages compares nothing at all.
The second is generalising from a handful of sessions. Watching six people struggle with a size selector is strong evidence that the selector can be struggled with, and no evidence about how often it happens. The correct response is to return to the aggregate and size it, rather than raise a ticket claiming lost revenue nobody measured. Replay is also unusually good at surfacing visible irritations on busy pages, which are not automatically the pages losing money, so ranking findings by expected value against implementation effort before anything enters a sprint tends to keep the loud problem from displacing the expensive one.
The third is changing several things at once. When a page is redesigned in response to five findings, the re-measurement cannot attribute the result to any of them, and the next round starts from the same position of not knowing. Sequencing changes is slower over a fortnight and faster over a quarter. Our analysis of why product pages receive traffic but fail to convert works through several of these causes at page level.
Who Should Run This Work
An internal owner is often sufficient, and it is worth saying so plainly. A store on a single platform, with one main market, a developer or designer who can act within a normal release cycle, and a named person with a few hours a week, can run ecommerce heatmap analysis without external help. The tooling is inexpensive and the documentation is public. Our review of CRO tools worth considering covers the practical options at that level.
External support becomes the better answer under different conditions: when findings are produced but never implemented, because the constraint is delivery rather than insight; when the store spans several markets or platforms, so each finding has to be checked for whether it generalises; and when the analytics layer itself is in doubt, since behavioural work built on unreliable measurement compounds the original error, and a technical audit is the more sensible first spend. A store with very low traffic to the pages in question may need neither, and may learn more from a few moderated sessions with real customers.
Turning Behavioural Findings into a Prioritised Backlog
The decision in ecommerce heatmap analysis is one of sequence rather than tooling. Numbers should establish where the loss is and what it is worth; maps and recordings should explain the behaviour at that point; the explanation should be written as a hypothesis with a mechanism, then settled by a fix or a test depending on whether it describes a defect or a judgement call. Every limitation covered above is a reason to check what the tool can see before trusting what it shows. We publish further ecommerce analysis on the WD Market LinkedIn page.
From Behavioural Findings to Tested Improvements
If findings are piling up faster than they are resolved, the useful next step is not another tool. Request CRO and growth support, and the engagement begins with a measured view of where qualified traffic is lost by device and step, a check of which key components your ecommerce heatmap analysis can actually see, and a prioritised list separating defects from candidates for testing, with an owner against each item.
To discuss a specific page, funnel step or platform constraint before committing to anything, get in touch through our contact page with the page and the question you want answered.
Frequently Asked Questions
How much traffic does a page need before a heatmap is worth reading?
Technically none, since Clarity documents no minimum traffic requirement to generate one. Interpretation is the constraint rather than generation. With few visits a map largely describes the individuals who happened to arrive, and one unusual session can dominate it. Treat a low-volume map as a source of questions to check elsewhere, and reserve confident conclusions for pages where the pattern holds across a longer period and separate device splits.
Can we watch what happens inside the Shopify checkout?
Usually not in the way teams expect. Shopify runs web pixels in a sandbox and states that features relying on reading or writing the page DOM will not work there, which is precisely what session replay depends on. A store can therefore observe the storefront thoroughly and the checkout barely at all. Diagnosis then rests on stage-level funnel data, the platform’s own reports, and close attention to what happened just before the checkout began.
Do heatmaps and recordings replace A/B testing?
No, and the two answer different questions. Behavioural tools describe what is happening now and suggest why. A test establishes whether a proposed change improves the outcome, and roughly by how much, within a stated margin of error. The relationship runs one way: behavioural evidence is a source of hypotheses, and testing is how a hypothesis becomes a decision. Where a finding is a clear defect, correcting it does not need an experiment first.
How long is this data kept?
It varies by data type, and the difference catches teams out. In Clarity, aggregated heatmap data is held for up to nine months, while full recordings last 30 days and only a thin sample survives beyond that. Sessions marked as favourites are kept for the longer window, so anything you may want to show a developer or a stakeholder later should be saved deliberately at the moment you find it.
What should we look at first on a product page?
Start with whether the information that answers a purchase objection is reached at all. A scroll map shows how far visitors get and where the average fold sits on each device, which frequently explains a weak add-to-cart rate on its own. Next, look for clicks landing on elements that do nothing, since those indicate an expectation the page created and did not meet. Only then move to recordings, filtered to sessions that exited without a cart addition.
Is session recording a privacy risk for the store?
It is a risk to manage rather than one that rules the method out. Clarity masks sensitive content before it leaves the browser and keeps input fields and dropdowns masked in every mode, with a default that also treats numbers and email addresses as sensitive. The operational point is that masking cannot be applied retroactively, so the configuration must be agreed before the period you will want to review. The choice of mode, and the consent basis for running replay, belongs with whoever owns data protection.