Heatmaps Without Personal Data: What Behaviour You Can Still See

Heatmaps without personal data sound like a contradiction. The whole appeal of a heatmap is watching what people do — where they click, how far they scroll, what they ignore. So how do you get that picture without recording individuals?

Turns out you get most of it. I’ve run both kinds of setups, and the honest summary is that aggregate behaviour data answers the questions I actually had, while session recordings mostly answered questions I found interesting but never acted on. Here’s what survives when you strip the personal data out, and what genuinely doesn’t.

What a Heatmap Actually Records

Before deciding what’s safe, it helps to know what these tools collect. A typical heatmap script captures far more than a coloured overlay suggests.

• Click coordinates — where the pointer was when it fired
• Scroll depth — how far down the page each visit reached
• Mouse movement paths — the cursor trail, sampled many times per second
• Viewport and device — screen size, browser, sometimes OS
• Session replay — in many tools, a full reconstruction of the visit

The first four are behavioural signals that aggregate cleanly. The fifth is a different category entirely. A session replay is a recording of one identifiable person’s visit, including what they typed into forms unless the tool masks it correctly. That’s personal data by any reading, and it carries obligations to match.

Aggregate Heatmaps Are Not Personal Data

Here’s the distinction that decides everything. A heatmap that shows “38% of visits scrolled past this section” is a count. It describes the page, not a person. You cannot single anyone out from it, link it to another dataset, or infer anything about a specific individual.

A session recording of visitor #4812 is the opposite. It describes one person’s behaviour in sequence, and if they typed an email address into a form, it may contain that too.

So the practical rule is simple. Aggregate the data at collection time — count clicks per region, count scroll milestones, count nothing per person — and the output falls outside the personal data question entirely. I walked through why that distinction matters legally in this piece on GDPR compliant tracking, and the same logic applies here.

Where Consent Comes Into It

There’s a second question underneath the personal data one, and people routinely skip it.

Most heatmap tools work by storing an identifier on the visitor’s device so they can stitch a session together. The moment anything is written to or read from that device, you’re under the ePrivacy rule, which requires consent for storage that isn’t strictly necessary to deliver what the user asked for. Nobody visits a page to be heatmapped, so that exemption doesn’t apply.

This is why so many sites run heatmaps behind a consent banner — and why the data ends up skewed. You’re now measuring only the subset of visitors who click Accept, and there’s no honest way to correct for it afterwards. If banner-acceptance correlates at all with confidence, patience, or technical literacy, your heatmap is measuring those people, not your audience.

A tool that counts server-side, storing nothing on the device, avoids both problems at once: no consent trigger, and coverage of every visitor rather than the compliant minority. That trade-off is the same one I described for cookieless visitor measurement.

What You Can Still Learn

Here’s the practical part. Strip out per-person recording and this is what remains available.

The first six cover essentially every layout decision I’ve ever made. “Nobody scrolls to the pricing section” and “everyone clicks the non-clickable product image” are the findings that actually change a page — and both are pure counts.

That fourth row deserves a mention because it’s the most underrated. Clicks landing on things that aren’t links is the single clearest usability signal there is. People are telling you what they expect to be interactive. You don’t need a video to hear it.

What You Genuinely Lose

I’d rather name this than pretend the trade-off is free.

The hesitation story. Watching someone move the cursor back and forth over two options, then leave, tells you something a click count never will. That’s real, and aggregates don’t reproduce it.

Bug reproduction. When a user reports “the checkout broke”, a replay shows you exactly what they did. Without it you’re relying on error logs and guesswork.

Rage-click context. You can count repeated clicks on one element in aggregate, but you can’t see what state the page was in when it happened.

My rule: if you need any of these, run them as a bounded research exercise — a defined period, a specific question, explicit consent, deletion when the question is answered. Not as always-on collection on every visitor forever. That’s the difference between research and surveillance, and it’s also the difference between a defensible processing record and an awkward one.

How to Set This Up Without a Heatmap Tool

You may not need a dedicated product at all. Most of the signals above can be captured with a handful of custom events in an analytics tool you already run.

1. Scroll milestones. Fire an event at 25%, 50%, 75% and 100% of page depth — an Intersection Observer handles this in a few lines without scroll-event jank. Four events per page gives you a scroll curve without recording anything continuous.
2. Key element clicks. Attach an event to your primary buttons and links. Name them consistently — cta_click, pricing_click — and don’t attach anything personal.
3. Dead-click detection. Listen for clicks on non-interactive containers and fire one event with the element identifier. This is where the surprises live.
4. Form-field abandonment. Fire an event on first focus per field and one on submit. The gap between them shows exactly which field costs you people.

That’s four event types and maybe twenty lines of code. It collects no identifiers, needs no device storage, and answers the questions in the table above. If you’re not sure which events are worth defining at all, this guide to what to track and what to ignore is the place to start.

One warning: resist the urge to add a fifth, sixth and tenth event. Event sprawl is the reason most analytics setups become unreadable within a year. Four well-named events you look at beat forty you don’t.

Reading the Results Without Fooling Yourself

Three habits keep aggregate behaviour data honest.

Segment by viewport before concluding anything. A scroll curve mixing phones and desktops is an average of two different behaviours and describes neither. Mobile users scroll further and click differently; combining them hides both patterns.

Check the sample per page, not per site. Your homepage may have thousands of visits while the page you’re optimising has forty. A heatmap built on forty visits is decoration.

Treat it as a question generator, not an answer. Heatmap data tells you where to look. It does not tell you why. “Everyone stops at the pricing table” is the start of an investigation — the answer might be the price, the layout, the load time, or a broken element on one browser.

That last point is where most teams go wrong. They read a heatmap, invent a story that fits it, and redesign around the story. The counts were real; the explanation was made up.

Frequently Asked Questions

Do aggregate heatmaps need a cookie banner?

If the tool stores or reads anything on the visitor’s device — a cookie, localStorage, a fingerprint — then yes, under the ePrivacy rule, regardless of whether the data is personal. If it counts server-side and stores nothing on the device, that trigger doesn’t apply. Check what your specific tool does rather than trusting the marketing page.

Is session replay ever acceptable?

It can be, with informed consent, strict field masking, a short retention period and a documented purpose. What isn’t defensible is running it on every visitor indefinitely because it came bundled with your analytics plan.

How many visits do I need for a useful heatmap?

Rough floor: a few hundred visits to the specific page. Below that, one unusual visitor moves the pattern and you’ll optimise for noise.

Can I do this on a small site?

Yes, and small sites benefit most, because four events are easier to maintain than a heatmap subscription. The constraint isn’t tooling — it’s traffic. With very low volume, look at monthly totals and ignore weekly swings entirely.

Bottom Line

Heatmaps without personal data give you the layout answers and drop the surveillance. Scroll depth, click counts, dead clicks and form-field abandonment are all counts, they aggregate cleanly, and they cover the decisions you’ll actually make about a page.

What you give up is the individual story — the hesitation, the bug reproduction, the context behind a rage click. Those are real losses, and the honest answer is to buy them deliberately with a consented, time-boxed study rather than by default on every visitor.

Start with four events on your most important page and look at them after two weeks. If they don’t change a decision, you’ve learned something useful about your analytics too. For the wider argument on why starting from privacy produces a simpler system, see what privacy-first analytics actually means. Official guidance on the storage rule is worth reading directly — the EDPB guidelines and the ICO’s guidance on storage and access technologies both cover it in plain language.