Heatmaps Needed a Rebuild, Not a Fix

A heatmap is only as good as the screenshot underneath it. If the background doesn’t match your live page (elements are cut off, layout is shifted, or dynamic content is missing), the click and scroll data drawn on top of it is meaningless. You’re looking at a broken approximation of your page.

For teams running dynamic sites, that was their experience of Heatmaps. We heard it enough times that we stopped patching and started over.

When the canvas is wrong

On SPAs, Angular apps, and pages with hover states or dynamic elements, the captured screenshot often had little resemblance to the live page: elements were cut off, layouts were shifted, and content was missing entirely. The screenshot is the canvas every click dot and scroll gradient gets drawn on, so when it’s wrong, everything on top of it is wrong too. You end up staring at data you can’t trust on a page you barely recognize.

Patching individual issues wasn’t going to fix that. The problems were too interconnected—screenshot capture, element placement, device handling, URL targeting—and each fix exposed the next one. So we rebuilt the whole thing.

A screenshot that actually matches your page

There are now two ways to capture a screenshot for a heatmap: directly from your live site or from a replay. Direct capture, available now to all customers on the latest SDK, is the more significant change. It captures exact page states (hover menus open, navigation expanded, dynamic content loaded) that replay-based capture historically missed or flattened into a default view. You get the page as users actually see it, rather than a stabilized version of it at rest. We also mapped each heatmap to exactly one screenshot, removing a persistent source of confusion about which background the click data was plotted against.

Clicks that land where they should

Even when the screenshot was right, the click data placement sometimes wasn’t. Heatmaps previously positioned data using pixel coordinates, which worked well enough on static pages but broke predictably on anything that shifted between loads, breakpoints, or viewport sizes. Selector-based placement fixes this by anchoring data to the element itself, rather than its position at a specific moment. On responsive layouts and dynamic pages, the dots land where they should regardless of how the page reflows.

Less setup, more analysis

A lot of the friction in Heatmaps was everything you had to navigate before getting there. Manual device selection that produced the wrong screenshot if you guessed wrong. A URL dropdown with enough edge cases that customers had learned to route around it. A scrollmap that showed you the data but made you work to interpret it.

Device detection is now automatic, so you’re not making a choice that affects the output. The URL handling has been fixed and simplified. The scrollmap has a new design with a clearer fold line and a more readable drop-off curve, so you can see where users stop scrolling without having to decode the gradient. And the UI has been cleaned up overall, with unnecessary fields and states removed, to shorten the path between opening Heatmaps and having something worth looking at.

Heatmaps you can trust

Before this rebuild, using Heatmaps on a dynamic site meant working through a checklist of things that might be causing what you were seeing: Was the screenshot captured from the right state? Did the device type affect the layout? Are the click dots actually landing on the right elements? By the time you’d ruled those out, the analysis had become a debugging exercise.

The rebuild eliminates that checklist. Screenshot capture is more reliable, placement is anchored to elements ratheThe value of a heatmap is simple: see where users engage, spot what's working and what isn't, and make a better decision about the page. This rebuild makes sure the screenshot, the placement, and the setup are no longer what stand between you and that answer.