Do Heatmaps Need Cookie Consent? What Each Tool Actually Sets

The short answer

If a heatmap tool stores an identifier on the visitor's device, and that storage is not strictly necessary to deliver the service the visitor asked for, then under the ePrivacy Directive you need consent before it runs. That is a storage question, not an analytics question, which is why "is it GDPR compliant" is the wrong thing to ask a vendor. The right question is: what exactly do you write to my visitor's browser, and how long does it live?

Two tools can both be honestly described as privacy-friendly and still land on opposite sides of that line.

What the major tools actually store

This is from each vendor's own documentation rather than from roundups. Check it yourself before you rely on it, because vendors change this and I would rather you verify than trust me.

• Microsoft Clarity sets _clck, which recognises a visitor across visits, and _clsk, which groups activity into a session. Microsoft began enforcing consent for visitors in the EEA, UK and Switzerland on 31 October 2025, and provides a Consent V2 API for signalling it. Without a consent signal, Clarity runs in a limited mode.
• Hotjar sets tracking cookies, and its own guidance is explicit that the site owner is the data controller and is responsible for obtaining consent. The compliance burden is yours, not theirs.
• Matomo does not set a cookie for heatmaps alone, but its own FAQ states that recording sessions sets a first-party cookie named _pk_hsr for the duration of the visit. Heatmaps and session recording are the same product but not the same legal question.
• Plausible's own page on when it is not the right fit (linked in the sources below) says it does not record individual visitor sessions, and lists mouse movement recordings, rage click detection and heatmaps among the things it deliberately leaves out. If you want heatmaps, it is not the tool.
• Conclick measures without cookies and without a cross-site profile. It does keep a first-party visitor identifier in the browser's local storage so a session holds together. That is not a cookie, but it is a persistent client-side identifier, and I would rather say so than let you assume otherwise.

Heatmaps and session replay are not the same question

Tools sell these together, which makes them sound like one feature with one compliance answer. Legally they are quite different.

An aggregate heatmap is a count. Four hundred people clicked in this region, the median visitor scrolled to sixty percent of the page. No individual is reconstructable from it. A session replay is a recording of one identifiable person moving through your site, including what they typed if you have not masked inputs correctly. The second is a much harder thing to defend, and it is the one that tends to attract regulator attention.

The CNIL's guidance on analytics exemptions is instructive here mostly for what it does not cover: its conditions are written for audience measurement and A/B testing, and it does not address session recording at all. Read that as a signal about where the safe ground is.

The real cost is biased data, not legal risk

This is the part that made me care about the question, and it has nothing to do with compliance.

If your heatmap only fires after someone accepts a cookie banner, you are not collecting less data. You are collecting a skewed sample. The people who click Accept are not a random subset of your visitors. They skew toward people who are less privacy-aware, less technical, on older browsers, in jurisdictions without a banner requirement at all. Those are exactly the differences that show up in where people click and how far they scroll.

So the heatmap you are staring at is not a picture of your visitors. It is a picture of your consenting visitors, presented as though it were the whole. You will make layout decisions on it and never see the error, because a biased heatmap looks exactly as convincing as an accurate one.

That is the argument for measuring without a banner where you legitimately can: not that it is more legal, but that it is more true.

How to decide for your own site

1. Open your site in a private window with devtools on the Application tab. Look at what is actually in Cookies and Local Storage after the page loads. This takes two minutes and beats any vendor claim.
2. Separate your requirements. If you need aggregate click and scroll behaviour, that is a lighter ask than replaying individual sessions, and you may not need replay at all.
3. Check whether the tool can run in a reduced mode without consent, and what you lose. Clarity's limited mode and Matomo's heatmap-without-replay configuration are both real options.
4. Ask what happens to visitors who decline, and whether your analytics silently drops them or counts them anonymously.
5. Get the answer reviewed by someone qualified in your jurisdiction before you remove a banner.

Where Conclick sits

I build Conclick, so treat this section as what it is. Conclick renders click maps and scroll depth over a real screenshot of the page rather than a reconstructed overlay, measures without cookies, and keeps data on our servers. It also ties payments from Stripe, Paddle, Polar, Lemon Squeezy and Dodo back to the source and campaign that produced them, which is the thing I actually built it for.

It is not the only privacy-positioned tool with heatmaps, and I would be lying if I said otherwise. Matomo has had them for years and is a genuinely good product, particularly if you want to self-host. TWIPLA, Piwik PRO and Clicky all belong in the conversation too. If your question is purely which heatmap respects privacy, several answers are defensible. If your question is which one also tells you that the visitor who scrolled to the pricing table later paid you forty-nine dollars, the field narrows considerably.

Conclick is built on the open-source Umami engine, which I mention wherever it is relevant rather than only where it flatters us.