Heatmaps, session recordings and cookie consent

Heatmaps show where people click and how far they scroll, and session recordings replay a visitor’s actions. Both need masked fields and consent.

Looking through a person’s eyes

The numbers of the earlier lessons show where people are lost: at the step “pressed the button” only 30% get through. But they don’t answer why. To see the cause you have to look at how people use the page. There are two tools for that.

Heatmaps. On a picture of the page, color shows where something happens.

• A click map: where people pressed, including places that weren’t links. Many clicks on an image with no link mean people expected it to do something.
• A scroll map: what share of visitors got as far as each place on the page (you saw it in the lesson on bounces and scrolling).
• A mouse-movement map: where they looked. The link with attention is approximate, so it’s trusted less.

Session recordings. A program records one visitor’s actions (mouse movement, clicks, scrolling) and replays them like a video. Microsoft’s Clarity is free; Hotjar and similar paid tools do the same, and Yandex Metrica has Webvisor. Recordings help you see what the numbers don’t show: a person pressing again and again on something that doesn’t work (“rage clicks”), looking long for a button, abandoning a form at the same field.

They are valuable, but they have a price. A recording is data about a particular person: what they pressed, what they typed, what they read. So the rest of the lesson is about how to look without doing harm.

How to watch to good effect

1. Start with a number. In the funnel find the weakest step (the last lesson) and watch only the recordings of those who stopped there.
2. Watch by plan. Twenty recordings at the weak step are worth more than two hundred random ones.
3. Look for what repeats. One person with odd behavior is an incident, five with the same difficulty is a find.
4. Write the conclusion as a hypothesis (the first lesson): “people don’t see the button under the image”, and then test it.
5. Remember devices. Maps and recordings on a phone and on a computer look different, and a conclusion from one can’t be carried to the other.
6. Don’t fit the facts. If you look for confirmation of your idea, you’ll find it in any recording. Formulate what will count as a refutation.
7. Remember small numbers. A map of forty visits isn’t statistics but a hint.

Maps and recordings don’t replace talking to people either. They show what the person did, not what they thought as they did it.

The privacy of a recording

Open the diagram. It’s an invented visitor filling in a form, and what gets into the recording. Switch rules on and off and see what the site’s owner sees.

PricesContact and requestTell us about your case

session recording is on the form fields are masked the page with the description of the case is not recorded

What the visitor does

Page: Contact and request

• Name: Ivan Peters
• Phone: +1 000 000 0000

What shows in the recording

• Name: Ivan Peters
• Phone: +1 000 000 0000

The recording contains the person’s personal details. The person doesn’t know, if you haven’t told them, and you are now responsible for this data.

The visitor and their words are invented. The principle is real: record behavior, not content.

The alarming thing in the diagram is that, unmasked, a recording shows the name, the phone and the particulars of someone’s case. Everyone with access to the dashboard sees such recordings, and they are kept until you delete them. So there are rules around session recording.

What to do.

• Record exactly what you need. Switch recording on not across the whole site but on the pages where you’re looking for a problem (the principle of data minimization: the amount of data should fit the purpose; it’s in GDPR Article 5 and in most privacy laws).
• Mask the fields. Clarity masks the content of input boxes in every masking mode, and you can mask other elements by a setting or with the data-clarity-mask attribute. Hotjar suppresses keystrokes in fields by default and has its own data-hj-suppress attribute for elements. Yandex Metrica uses the class ym-disable-keys for a field and ym-hide-content for a block. Never record passwords or payment details.
• Exclude sensitive pages: where a person describes their case, the customer account, pages with documents. If you’re an expert, an attorney or a doctor, you also have a professional duty of confidentiality: recording the description of someone else’s case isn’t acceptable.
• Set a retention period and a circle of people. A recording is needed while you work through the problem; then it’s deleted. Only those who need it for their work should watch. Retention in the service is limited by its settings (see the help), and the rules themselves you write into the policy.
• Tell the person. The privacy notice (the lesson on legal texts) must say that you record actions, why, for how long you keep them and who sees them.
• Where the data goes. Where a tool stores data matters. For visitors in the EU, transfers outside the EU have their own rules under the GDPR, and in Russia the personal data law requires the first recording and storing of Russian citizens’ data to happen in databases in Russia (the Russian edition covers it).
• Wiretapping claims in the US. Session replay has been the target of lawsuits that call it unlawful interception under state wiretap laws (California’s CIPA is a common one). Courts haven’t agreed on this, so the cautious practice is the same: tell visitors, ask for consent where the law might require it, and mask.

This is general information, not legal advice. Ask a lawyer, or the regulator: the ICO in the UK, your national data protection authority in the EU, the state attorney general or the FTC in the US.

Cookie consent: a banner that does not deceive

Cookies are small files a site stores in a person’s browser. Counters use them to tell a new visitor from a returning one. What the law says depends on where your visitors are:

• In the EU. The ePrivacy Directive (Article 5(3)) requires consent before storing or reading information on a person’s device, except for what is strictly necessary to provide the service they asked for. Consent has the meaning of the GDPR: freely given, specific, informed and unambiguous, by a clear affirmative act (Article 4(11), Article 7). A pre-checked box doesn’t count (the CJEU’s Planet49 judgment, 2019), refusing has to be as easy as agreeing, and a “cookie wall” that blocks access unless you accept is generally not acceptable, according to the European Data Protection Board. In 2022 the French regulator, the CNIL, fined Google €150 million and Facebook €60 million, in part because refusing cookies took more steps than accepting them. Some regulators let narrowly limited audience measurement run without consent, and the CNIL publishes the conditions.
• In the UK. The Privacy and Electronic Communications Regulations (PECR, regulation 6) say the same in substance, and the ICO enforces them. The Data (Use and Access) Act 2025 adds narrow new exceptions for some analytics cookies, so check the current ICO guidance before relying on one.
• In the US. There’s no general cookie-consent law. The state privacy laws work differently: in California, the CCPA as amended by the CPRA gives people the right to opt out of the “sale” or “sharing” of their personal data, which advertising cookies can amount to; a business that does this must post a clear opt-out link and honor the Global Privacy Control signal that a browser can send. Several other states have similar laws, and some require honoring such a signal too. Your banner may need an opt-out rather than an opt-in.
• For Russia, there’s no separate cookie law, but the personal data law applies to data that identifies a person.

Because the rules differ, the safest design is the strictest one that your audience might be covered by: two equal buttons, nothing pre-checked, nothing starting before consent, and an opt-out that works. This is general information, not legal advice; show your banner and policy to a lawyer.

Signs of an honest banner:

1. Two buttons of one look: “Accept” and “Reject”. If “Accept” is bright and refusal is a small link, that is a dark pattern (the lesson on the limit of manipulation).
2. Nothing checked in advance. The “allow analytics” box is empty.
3. The counter does not start before consent. A banner without blocking is decoration. For that the counter code is made “sleeping”: the browser doesn’t run type="text/plain", so it waits for the person’s answer.
4. Refusing is as easy as agreeing, and afterwards a person can change their mind (a “Cookie settings” link in the footer).
5. There is a link to the policy.
6. No “cookie wall”: refusing doesn’t shut the person out of the site.

How a “sleeping” connection looks in its minimal form. The analytics code is written like this:

<script type="text/plain" data-consent="analytics">
  ...the counter code...
</script>

And the one active script on the page runs it after consent:

<script>
  function allowAnalytics() {
    document.querySelectorAll('script[data-consent="analytics"]').forEach(function (s) {
      var n = document.createElement('script');
      n.text = s.text;
      document.head.appendChild(n);
    });
  }
  // on consent call allowAnalytics(), on refusal do nothing
</script>

This skeleton is simplified: in a real banner you also remember the person’s choice (in localStorage) and don’t ask again. If the project has several services, each has its own data-consent. Note that the Google tag’s own loader (gtag/js) must also sit inside the sleeping code, or it will fetch Google’s script before the person has answered. Google also offers a Consent Mode for its tags, and Clarity has one too: since 31 October 2025 Clarity requires a consent signal for visitors from the EEA, the UK and Switzerland.

Check yourself: how does “sleeping” counter code differ from ordinary code?

The sleeping code has the type text/plain, so the browser doesn’t run it and sends no data until the person has agreed: the loader runs it only after “Accept” is pressed. Ordinary code works the moment the page opens.

Practice

Fix the page and write the rules.

1. The banner: a dialog role, two equal buttons, a link to the policy, an empty box.
2. The counter: the analytics code in a “sleeping” script, the one active script being a loader without gtag(.
3. Masking: the data-clarity-mask attribute on the form fields.
4. Session recording rules: the pages from the brief, what is hidden, what is excluded, the retention as a number, who sees them, the text for the policy (and in Russian if the brief includes Russian).

The check looks at structure: the buttons, the empty box, the “sleeping” code, the masking attribute and the entries in the rules. Whether your banner is honest is for you to decide: open the page and ask yourself what a person would feel for whom refusing was harder than agreeing. Show the policy texts to a lawyer before publishing.