Heatmaps

A heatmap in StorePilot is a page template × a device class × a date range. Never a session, and never one visitor's visit — those are what session recordings are for.

It is under Analytics → Heatmap in a site's menu, and the Most clicked pages widget on Home opens it.

Choosing what you are looking at

Press the page name to open the picker. It searches every page this site has data for — not only the ones with clicks, so a page people read and never clicked is in the list — and each row shows what was recorded and whether the page already has an image to draw on. Pages that already have an image are listed first, in a block of their own, and the heatmap opens on the busiest of them.

If the page you want is not there, paste its address into the field at the bottom. That works for a page with no data at all: the address is reduced to the page template it belongs to (so campaign parameters do not matter), and the next few visitors of that page are asked for a picture of it.

• Page — a template, not a URL. /product/917 and /product/918 are the same page here, because the question "where do people click on a product page" is not answered by one product.
• Device — desktop, tablet and mobile are separate maps. They have to be: the same click is at a completely different position in a layout that reflows.
• Range — closed days come from pre-aggregated cells and today is computed live, so the most recent data is never missing while yesterday's is instant.

The map is the page without filters

A listing filtered by category or re-sorted by price is a different layout from the plain listing — the products are in other places. So a click made on an address carrying a filter, a sort or a page number (?orderby=price, ?prodcat=hats, ?paged=2) is not drawn on the map, and the image is always taken from a visit to the page without them. Those clicks are still counted: the Clicks, Rage and Dead totals include them, and a line under the totals says how many were left off the map.

Campaign and tracking parameters (utm_*, fbclid, gclid and similar), WooCommerce's add-to-cart links and a search (its term and the search form's own fields) do not change the layout, so clicks on those addresses are drawn as usual. Days counted before this rule existed may still include filtered clicks in the map.

Reading it

Clicks are placed against the width of the page's content column, not the width of the browser window. That is not a detail — the same click sits at 0.26 of a 2560px window and 0.03 of a 1280px one, and only the column-relative figure means anything across both. It also means the overlay needs the recorded geometry of that column to place a click, which is why an unrendered background sometimes delays the dots.

Scroll depth is measured down the whole document in fixed bands, against an absolute reference rather than the content column. The background is a picture of the entire page, and the top of the content moves between visitors — an admin bar, a cookie banner — so a column-relative band drew every click a header's height too high.

Element ranking lists what was actually clicked, by selector, with counts. This is the part that survives when there is no picture, and it is often the faster read: "nobody clicks the second CTA" is a sentence, and a heatmap is a thing you have to interpret.

It counts people's clicks only — automated traffic is left out — and on a shop that reports its orders through the WordPress plugin each element also shows what the visits that clicked it went on to pay: how many orders, from how many visits, and the money. By money puts the element with the most revenue behind it first. The money belongs to the whole visit, whatever else it clicked, so it is a sign of what sells rather than proof that a click made the sale — two buttons the same buyer pressed both carry that sale. The busiest 50 elements of each page are kept per day.

After this page

Under the element ranking, After this page shows where visits went from the page you are looking at: the next pages, and how many visits ended here. It covers every device — a path is about the visit, so the device picker above does not narrow it. Each next page is a link to its own heatmap.

The shares are of the moves away from the page, so they add up to 100%. A visit that left the page twice by two different routes counts twice; a visit that went round in a loop between the same two pages counts that move once. Ended here means this was the visit's last page in the chosen window, which today includes visits that are still under way.

The two maps

Clicks shows where people pressed, and the metric buttons switch between ordinary clicks, rage clicks and dead clicks.

The click map counts visits, not clicks: a spot ten different people pressed is hotter than one a single visitor pressed forty times. Hovering a spot shows both numbers. Three things are left off the picture by default, and the line under the colour scale counts each and offers a switch to draw it:

• Scattered clicks — a square touched by only one visit, or by less than 1% of the hottest spot.
• Clicks on empty space — a press on something the page does not offer as clickable (plain text, a blank area). These stay collected: they are where dead clicks come from, and the rage and dead maps keep showing them.
• Clicks from automated traffic are never on the map.

On mobile, positions down the page are measured in screen widths rather than pixels, because a phone layout grows with the screen: the same button sits lower on a large phone than on a small one. The map places every phone's clicks on the one picture accordingly.

Individual clicks are kept for 30 days; their daily totals keep the map, the rankings and the page list for longer periods. A funnel step that counts clicks says when a longer window reaches past that.

Scroll depth shows how far down the page people actually got: the page darkens towards the point where visitors stopped, and a dashed line marks the depth half of them reached. It is measured in percent of the page, and it needs no background image at all — on a page with no picture it still draws as a labelled scale, which for most pages is the more useful of the two.

One caveat is worth knowing, and the screen repeats it: depth is a share of each visitor's own page height, laid over one picture of that page. A page whose height moves between visitors — a cart with several items, lazy-loaded reviews, an endless list — will not line up exactly. That is why the line is labelled in percent and never in pixels.

You choose which pages get a picture

The background is a PNG the platform renders itself, and it renders one only for pages you ask for. There are two places the picture can come from:

• A copy of the page from a visitor's own browser. When you ask for an image, the request goes out to your site within a minute, and the next few visitors of that page each send one serialised copy of it. This is how most pages get a picture, and it works whether or not session replay is switched on.
• A frame from a recorded session, if the page happens to have one.

The steps:

1. Open the heatmap for a page and press Render an image of this page.
2. Wait. If a recorded visit exists this is quick; otherwise it takes as long as it takes for a few visitors to reach that page at that width.
3. You are offered up to three pictures, from three different visits. Pick the one that looks like the page.
4. Only then is the heat drawn on top of it.

Clicks, scrolls and rage clicks are collected for every page the whole time, whether or not it has an image — asking for a picture changes what you can see, never what is measured.

Approval exists because a render can be subtly wrong in a way only somebody who knows the page can see: a consent dialog covering the hero, a carousel caught between slides, a lazy image that had not arrived in the frame. Heat drawn over a wrong picture is a confident statement about where people clicked that happens to be false. If the image comes out wrong, press Render it again instead of approving it.

Asking again does not take the current picture down: the new renders are offered beside it and the one in use stays on screen until you choose a replacement.

When there is no background image

It is optional and its absence is not an error:

• Nobody has asked for one for this page yet.
• Somebody has asked, and the platform is still waiting for a visitor to reach that page at that width. A page with little traffic on an unusual screen size can wait a while.
• A deployment without the optional rendering support never produces one.

In every case the overlay falls back to the scroll scale, the element ranking and a vertical band chart. Everything except the picture still works.

Screenshotting your live site was considered and rejected twice over: the platform cannot see pages behind a login, and fetching a URL that arrived in an ingest payload is a server-side-request-forgery by construction. The renderer navigates nowhere. It replays events we already stored, into a blank page, with page JavaScript disabled — and the masking rules were applied by the collector at record time, so the frame was already masked before the platform ever saw it.

Why the picture can look slightly out of date

An approved image is refreshed on its own once it goes stale, and a picture rendered from an older recorded visit is as old as that visit. A background from last Tuesday under this week's clicks is the normal state; if the page has been redesigned, ask for it again — the new pictures are offered beside the one in use, never instead of it, so nothing disappears from your screen while you decide.

What heatmaps need

Clicks and scroll depth come from the interactions collector, which deliberately carries no session-replay code — so both keep working on a site that has recordings switched off.

The background no longer needs recordings. It used to: a picture could only be rendered from a recorded visit of that exact page at that exact width, which on a real shop covered about one page in nine. A page image is now asked for from the page's own visitors, so any page with traffic can have one.

What the copy contains is governed by the same masking rules as session replay, applied in the visitor's browser before anything is sent, and a visitor who declined tracking or whose browser sends a Global Privacy Control signal sends nothing at all. The copy is deleted as soon as it has been turned into a picture.