The GDPR-Compliant Analytics Checklist for 2026

Why 2026 Is Different From 2018

The early GDPR years were a land-grab for data protection authorities. They went after the obvious targets: adtech, large publishers, Meta. Since 2024, enforcement has moved down-market. Austrian, Dutch, and Irish DPAs have issued findings against mid-sized SaaS companies. The 'we're too small to matter' argument is not a legal defence, and DPAs have made that clear. The other shift is consent fatigue. Studies consistently show that users dismiss consent banners in under 2 seconds. More relevant to you: the EU's updated ePrivacy enforcement guidance treats dark patterns (pre-ticked boxes, buried reject options, consent walls) as automatic violations regardless of your cookie notice wording. If you're running a standard Google Analytics setup with a Cookiebot banner, you are probably still non-compliant in at least three member states.

Step 1: Choose Your Lawful Basis Before You Choose Your Tool

This sounds obvious. Almost nobody does it. The lawful basis determines every other decision: which tool you can use, whether you need a banner, what your retention period should be, how you respond to a subject access request.

• Consent (Article 6(1)(a)): required whenever you use persistent identifiers (cookies, fingerprints, localStorage) to track behaviour. Valid consent must be freely given, specific, informed, and unambiguous. Pre-ticked boxes are invalid. Bundled consent ('accept all to use the site') is almost certainly invalid.
• Legitimate interests (Article 6(1)(f)): possible for analytics that don't involve cross-site tracking and where you've run a genuine LIA (Legitimate Interests Assessment). Not a magic escape hatch: the 'balancing test' must actually be documented.
• Strictly necessary: not a lawful basis for analytics. This applies to session cookies that make your site function, not your pageview counter.

For most bootstrapped founders doing first-party analytics only, legitimate interests is viable, but you have to document it. A one-paragraph internal note is enough for most DPAs. Write it down, date it, store it somewhere you can find it.

Step 2: Actually Minimise the Data You Collect

GDPR Article 5(1)(c) says you must collect the minimum data necessary for your stated purpose. This is where most analytics setups fail, not in banner design. Here is the practical checklist.

1. Do not store full IP addresses. Truncate to /24 (IPv4) or /48 (IPv6). If your tool stores the full IP even temporarily before hashing, that is still a data collection event under GDPR.
2. Do not create persistent cross-session identifiers unless you have explicit consent. A cookieless tool that generates a daily-rotating hash of IP + user agent is fine. A tool that writes a UUID to localStorage and keeps it for 2 years is not.
3. Disable user-ID tracking unless you have a contractual basis (i.e., logged-in users in your own product). Mixing anonymous browsing data with user-level data is a common mistake.
4. Set an explicit data retention period and enforce it. 90 days of session data is enough for most funnel analysis. 13 months is the max most DPAs will accept without scrutiny.
5. Audit any custom events you're sending. Every property you attach to a custom event is personal data if it can be combined with other data to identify someone. Do not send email addresses, user names, or internal IDs through your analytics layer.

Step 3: Check Your Data Processing Agreements

If you use a third-party analytics tool, they are a data processor and you need a signed DPA (Data Processing Agreement) on file. Most SaaS analytics vendors provide these in their account settings or legal pages. Sign it. Keep a copy. The second issue is data transfers. If your analytics vendor stores data in the US and you have EU visitors, you need a transfer mechanism. Standard Contractual Clauses (SCCs) are the practical answer for most vendors. Check that your vendor has current SCCs in their DPA. Anything signed before June 2021 uses the old SCCs, which are no longer valid. Plausible, Fathom, and most EU-hosted tools avoid this entirely by staying in the EU. Google Analytics 4 with US data storage technically requires SCCs and a Transfer Impact Assessment, and several European DPAs (Austria, Italy, France) have found that even with SCCs in place, GA4 does not meet the standard. That is a real legal risk, not a theoretical one.

Step 4: If You Do Need a Consent Banner, Do It Right

If you're running retargeting pixels, affiliate tracking, or any cross-site analytics, you need real consent. Here is what that actually requires in 2026.

• Reject must be as easy to click as Accept. Same visual weight, same number of steps.
• No pre-selected categories. Everything off by default.
• Granular categories: analytics cookies and advertising cookies must be separate choices.
• Record consent with a timestamp, the banner version shown, and what the user chose. Store this log.
• Honor the Global Privacy Control (GPC) signal automatically. Firefox, Brave, and DuckDuckGo send this by default. Several US states now require you to respect it, and the EDPB has signalled it should be treated as a valid opt-out in the EU too.
• Make it genuinely easy to withdraw consent. A link in your footer to re-open the consent manager is the minimum.

If your current setup does not meet all six of those criteria, you are running an invalid consent mechanism regardless of what your Cookiebot plan says.

Step 5: Consider Whether You Need Cookies at All

For most SaaS and ecommerce products, you don't. Cookieless analytics tools have matured significantly. They track pageviews, referrers, UTM parameters, conversions, and revenue attribution accurately without persistent identifiers. The main things you lose compared to a cookie-based setup are cross-device user stitching, very long return-visitor windows beyond about 24 hours, and A/B test identity consistency. Those are real limitations, but they matter less than most people assume for the day-to-day analysis that drives decisions. I built Conclick to be cookieless by default because I wanted to use it on my own products without the consent overhead. It does revenue attribution by connecting directly to your payment processor (Stripe, Paddle, Polar, Lemon Squeezy, Dodo) and matching payment events to the source, campaign, and funnel that preceded them, without needing to track users across sessions with a cookie. For most bootstrapped teams, the question worth asking is not 'which cookie tool complies?' but 'do I actually need cookies to answer the questions I care about?' Usually the answer is no.

Step 6: Update Your Privacy Policy to Match Reality

Your privacy policy is a legal document under GDPR Articles 13 and 14. It must accurately reflect what you actually collect. Boilerplate privacy policies that list every possible cookie under the sun when you've switched to cookieless analytics are not just useless; they're a liability, because they assert things that aren't true. Check that your policy accurately names the analytics tools you use, states your lawful basis for each purpose, gives the data retention period, and names your data processor (the analytics vendor). A subject access request will expose a mismatch between your policy and reality immediately.

Step 7: Build a 30-Minute Annual Review Into Your Calendar

GDPR is not a one-time project. Once a year, spend 30 minutes checking: have you added any new third-party scripts? Have any vendor DPAs expired or changed? Did you add any new custom event properties that include personal data? Has your data retention actually been enforced, or is your database holding three years of session data because nobody set up the deletion job? Most small teams fail compliance audits not because of their initial setup but because of drift.