CONSENTCHECK
← Blog

Session replay tools firing before consent? Check this

Jul 29, 2026

Session replay tools — Hotjar, Microsoft Clarity, FullStory, and similar — record real visitor sessions: mouse movement, clicks, sometimes form input. That makes pre-consent recording a meaningfully different situation than a pre-consent analytics pixel, and it's the tag category most directly named in current US wiretapping-style litigation. Here's how to check whether yours is actually gated.

Why these tools need the same manual gating as Meta Pixel

Like Meta Pixel, none of the major session-replay tools have a native integration with Google's Consent Mode API — that's a Google-specific spec that only Google's own tags check automatically. A site can have Consent Mode working perfectly and still record every visitor's session by default, because nothing is telling the replay tool to wait. See Meta Pixel fires before consent for the same underlying gating mechanism in more detail — the fix here is structurally identical, just applied to a different tag.

1. Check whether the tool is blocked by your CMP at all

How to check: in a fresh incognito window, open DevTools Network tab and reload without touching the banner. Watch for requests to hotjar.com (or .io), clarity.ms, or fullstory.com before you've made any choice. Then check your CMP's admin panel for which category the tool is assigned to.

The fix: if the tool isn't blocked at all, add it to your CMP's script-blocking configuration under an appropriate category — see check #3 below for which category actually matters here. If it's a hardcoded snippet or loaded through an app/theme integration rather than through your CMP's recognized script patterns, it likely needs manual blocking (rewriting the script tag so it only executes after consent) rather than relying on auto-blocking to catch it.

2. If loaded through GTM, check its Additional Consent Checks

How to check: open the tag in GTM and check its Consent Settings / Additional Consent Checks. If no consent type is required there, the tag fires purely on its trigger condition, unrelated to the CMP's state.

The fix: add the appropriate consent type to the tag's Additional Consent Checks, same as any other non-Google tag — this is covered in more detail in Meta Pixel fires before consent since the mechanism is identical.

3. Check which consent category the tool is actually assigned to

How to check: session-replay tools sometimes default into an "Analytics" or "Functional" category in CMP setup wizards, rather than "Marketing" or "Advertising" — check your CMP's category assignment specifically, not just whether the tool is blocked in general.

Why this matters: a visitor who accepts analytics cookies but declines marketing/advertising cookies would still get recorded if the tool is miscategorized as analytics — technically "gated," but gated behind the wrong consent choice for what the tool actually does (recording real session behavior, not aggregate analytics). Reclassify it if your CMP's default category doesn't match how the tool is actually being used.

4. Click Reject specifically, then recheck

How to check: reload in the same incognito session, click Reject, then check the Network tab again for the same domains. This is the same reject-specific check covered in how to check if cookies fire before consent — a tool that's silent before any interaction but still fires after an explicit Reject has a different bug than one that's simply ungated.

The legal context, briefly and without legal advice

Session-replay tools are named directly and repeatedly in current US wiretapping-style litigation under CIPA and comparable state statutes — this is a documented pattern in current filings, not a hypothetical risk. The technical distinction that matters in that litigation is specifically pre-consent recording, not use of the tool itself. None of this is legal advice — if you've actually received a demand letter, that's a conversation for a lawyer, not a blog post. What this article covers is the technical side: confirming whether your own site is actually gating these tools correctly, which is the thing you can verify and fix today.

If you'd rather have this checked automatically

A pre-consent scan checks Hotjar, Microsoft Clarity, and FullStory (along with 25+ other tracker signatures) for exactly this — whether they fire before consent, and whether they respect an explicit Reject — worth running as a first step regardless of where things stand legally.

— Petrus, founder of ConsentCheck. Session replay tools are the ones I flag first when triaging a new scan result, precisely because of what they actually record, not just that they're technically "a tracker."

FAQ

Is Hotjar (or Clarity, or FullStory) illegal to use?

Using a session replay tool isn't illegal on its own -- the legal exposure in current US litigation (CIPA and comparable state wiretapping-style statutes) centers specifically on recording a visitor's session before they've consented, not on using the tool at all. A properly consent-gated session replay setup is a fundamentally different situation than one that records every visitor by default -- this is a technical/compliance distinction, not legal advice, and worth confirming with a lawyer if you've actually received a demand letter.

Why does Microsoft Clarity show up in so many pre-consent scan findings?

Clarity is free, which means it gets installed on a much wider range of sites than paid session-replay tools, often by teams without a dedicated tracking-governance process -- and like Hotjar and FullStory, it has no native Google Consent Mode integration, so it needs the same explicit CMP-blocking or GTM consent-check setup as any other non-Google tag. The combination of high adoption and no automatic gating is why it shows up so often.

Does session replay recording get triggered differently than a normal tracking pixel?

Functionally it's gated the same way (CMP script-blocking or a GTM Additional Consent Checks setting), but it's worth checking session-specifically because the recording can start capturing before the tool's own script finishes loading in some implementations -- meaning a script that technically respects a blocking rule at the tag level can still begin buffering session data slightly before the block takes effect, depending on exactly how the snippet is implemented.

Do I need to gate session replay tools differently than ad pixels?

The gating mechanism is identical (CMP category blocking or GTM consent checks), but the category classification often isn't -- some CMPs default session-replay tools into an "Analytics" or "Functional" category rather than the stricter "Marketing"/"Advertising" bucket, which can mean a visitor who accepts analytics cookies but declines marketing cookies still gets recorded. Worth checking which category your session-replay tool is actually assigned to, not just whether it's blocked at all.

Want to know if your own site does this?

Scan your site free