Hunor.digital
← All writing
Compliance · Analytics honesty

The GDPR-compliant analytics checklist (verified, not assumed)

Six checks that separate actual compliance from a banner and a feeling. Each one is verifiable in an afternoon, and most sites fail at least two.

Lázár HunorDigital Fixer
The short answer

A GDPR-compliant analytics setup needs six things verified, not assumed: a consent banner that actually blocks tags, Consent Mode wired to real tag behavior, no personal data in URLs or parameters, appropriate data retention settings, a privacy policy matching observed behavior, and documentation of the transfer basis for any US tool.

Most companies' GDPR analytics compliance is a feeling. The banner is up, the agency said it is fine, the policy page exists, and nobody has looked underneath since. Then someone does look (a regulator, a complainant, an auditor like me), and the feeling turns out to have been load-bearing.

This checklist replaces the feeling with six checks. Each is verifiable, most take minutes, and together they cover the technical layer that any lawyer's compliance opinion silently assumes is true. The usual disclaimer, sincerely meant: I map what your setup actually does; what it legally must do in your situation is your counsel's call.

1. The banner actually blocks tags

Not "the banner is installed." Blocks. Fresh incognito session, decline everything, network tab open: no requests to analytics and marketing domains should fire, or only the legitimate consent-mode-limited kind you can explain. This is the check that fails most often, and most spectacularly; the failure pattern has its own anatomy lesson, and the fifteen-minute test procedure is here.

Why it fails so often: the banner tool and the tag container are configured by different people, on different weeks, and neither tests the other's assumptions. The banner records choices beautifully; nothing wired the choices to the tags.

2. Consent Mode reflects reality, in both directions

If you use Google's stack, Consent Mode is the bridge between the banner and Google's tags, and it must be wired to actual behavior: denied means denied signals arrive at the tags, and the tags respond correctly. Two failure modes to check: consent state never updates (everything runs in default-granted, the loud violation) and the subtle inverse, advanced-mode cookieless pings your privacy posture never signed up for. The Consent Mode explainer covers which mode does what; the check is confirming your site does what your DPO thinks it does.

3. No personal data rides along

GDPR follows the data, not the tool. The classics I find on audits: email addresses in URL parameters after form submissions or in newsletter links, user IDs or names in page paths, form values captured by enthusiastic event tracking, order confirmation pages leaking customer detail into page_location. Walk your own funnel with the network tab open and read the payloads. GA4's terms prohibit sending it personal data, so a leak here is simultaneously a GDPR problem and a Google terms problem, and it retroactively poisons stored data.

4. Retention is a decision, not a default

GA4 ships with a default event-data retention setting measured in months; your GDPR posture requires retention be proportionate and stated. Check what yours is set to, decide what it should be, and make the policy and the setting agree. Same for any other analytics tool, and for the raw exports: BigQuery tables and warehouse copies are also personal data with retention obligations, a detail that vanishes between teams.

5. The privacy policy describes the actual setup

Read your analytics section, then read your tag container. On most sites the policy describes an analytics setup from two redesigns ago: tools you removed, none of the ones you added, cookie lifetimes that changed. The policy is a legal statement about observed behavior; when behavior and statement diverge, you hold a document proving you knew the rules and described a different site. Re-align it whenever the container changes meaningfully, which means someone must be told when the container changes meaningfully, which is an ownership question, which is usually the real finding.

6. The transfer question has a documented answer

If your analytics data goes to a US provider, your file needs one paragraph: what the current legal basis is (the Data Privacy Framework adequacy decision, as of this writing) and that its stability is monitored, since the framework's history is turbulent. If sovereignty pressure is real in your market, the EU alternatives are the structural fix. Either answer is defensible; no answer is the only wrong state.

Score yourself honestly

Run all six this week. In my audit experience, a typical mid-size site fails two, usually numbers 1 and 5, and the fixes are days of coordinated work, not months. What turns compliance findings into compliance incidents is not the failing; it is the years of nobody checking. If you want the six checks run by someone who does this weekly, with network-log evidence attached to each finding instead of a feeling, that is exactly the shape of my Compliancy audit: a fixed-price look under the hood, and the report is yours whichever lawyer reads it next.