Every analytics implementation I’ve audited for EU-based SaaS companies in the past two years has had at least one GDPR violation. Usually more. The fines are no longer theoretical — the French data protection authority (CNIL) hit Criteo with a €40 million penalty, and smaller companies are increasingly in the crosshairs.
The problem isn’t that companies don’t care about privacy. It’s that GDPR-compliant tracking requires changes across your entire analytics stack — consent management, data collection, server-side processing, vendor agreements, and retention policies. Miss one piece and you’re exposed.
I’ve spent the last three years helping SaaS teams implement privacy-first analytics that actually work. This guide walks through every step, based on what I’ve seen succeed (and fail) across 20+ implementations.
What GDPR Actually Requires for Analytics Tracking
Before touching any configuration, you need to understand what GDPR demands. The regulation doesn’t ban analytics — it regulates how you collect and process personal data. For tracking, three principles matter most.
Lawful Basis for Processing
Under Article 6 of the GDPR, you need a lawful basis to process personal data. For analytics, you have two realistic options:
- Consent (Article 6(1)(a)): The user explicitly agrees to tracking. This is required for Google Analytics, Meta Pixel, and any tool that sets third-party cookies or shares data with advertising platforms.
- Legitimate interest (Article 6(1)(f)): You can argue that basic, anonymized analytics serves a legitimate business purpose. This works for privacy-first tools like Plausible or Matomo (self-hosted) that don’t set cookies or share data externally — but you must document your legitimate interest assessment.
The critical distinction: if your analytics tool sets cookies, collects IP addresses, or transfers data outside the EU, you almost certainly need explicit consent.
Data Minimization
Article 5(1)(c) requires that you collect only data that is “adequate, relevant, and limited to what is necessary.” In practice, this means you need to audit every data point your analytics collects and justify why you need it. Collecting user IDs, precise geolocation, or device fingerprints without a documented purpose violates this principle.
Consent Requirements
When consent is your lawful basis, the ICO’s guidance is clear: consent must be freely given, specific, informed, and unambiguous. Pre-checked boxes, cookie walls that block content, and “by continuing to browse you consent” banners all fail this standard. Users must be able to reject tracking as easily as they accept it.
Step 1: Implement a Consent Management Platform
Your CMP is the foundation of GDPR-compliant tracking. Every other component depends on it working correctly.
CMP Requirements
A compliant CMP must:
- Display before any tracking scripts fire
- Offer granular choices (analytics, marketing, functional cookies separately)
- Make “reject all” as prominent as “accept all”
- Store consent records with timestamps
- Support the IAB Transparency and Consent Framework (TCF) v2.2
- Allow users to withdraw consent at any time
I’ve tested most major CMPs. For SaaS companies, Cookiebot (now Usercentrics CMP), CookieYes, and Osano handle EU requirements well. If you’re using Google Tag Manager, Cookiebot integrates natively with Consent Mode v2.
Consent Mode v2 Configuration
Google’s Consent Mode v2 is now mandatory for serving personalized ads in the EU. But even if you don’t run ads, it’s the cleanest way to handle conditional tracking in Google’s ecosystem.
Consent Mode v2 introduces two new parameters beyond the original:
- ad_user_data: Controls whether user data can be sent to Google for advertising
- ad_personalization: Controls whether personalized ads can be shown
- ad_storage: Controls advertising cookies
- analytics_storage: Controls analytics cookies
The default state must be “denied” for all parameters. Your CMP then updates these to “granted” only after explicit user consent.
When consent is denied, Google tags still fire — but they send cookieless pings instead of full tracking data. Google then uses behavioral modeling to fill the gap, recovering an estimated 70% of conversion data according to their documentation. In my experience, the actual recovery rate varies between 40-80% depending on traffic volume and consent rates.
Step 2: Set Up Server-Side Tracking
Client-side tracking sends data directly from the user’s browser to analytics vendors. Server-side tracking routes that data through your own server first. For GDPR compliance, this gives you a critical control point.
Why Server-Side Matters for GDPR
- IP anonymization before export: Strip or truncate IP addresses on your server before data reaches any analytics vendor
- PII filtering: Automatically remove email addresses, names, or other personal data that might accidentally appear in URLs or form submissions
- Data residency control: Your server-side container can run in an EU data center, ensuring data doesn’t leave the EU before being cleaned
- Vendor independence: If a DPA is violated or a vendor changes their data practices, you can cut off data flow at your server without touching client-side code
Server-Side GTM Implementation
Google’s server-side Tag Manager (sGTM) is the most practical option for most SaaS companies. Deploy it on Google Cloud Run or AWS in an EU region (eu-west-1 for AWS, europe-west1 for GCP).
Key configuration steps:
- Set up a first-party subdomain (e.g., data.yourdomain.com) pointing to your sGTM instance
- Configure the GA4 client to strip IP addresses before forwarding
- Add a transformation rule to remove any URL parameters containing PII
- Enable the consent checking feature so server-side tags also respect consent state
The cost is modest — typically $30-50/month on Cloud Run for a SaaS company with under 1 million monthly pageviews.
As Max Schrems, founder of noyb and the privacy advocate behind landmark GDPR cases, has stated: “The problem with most analytics setups isn’t the tool itself — it’s the data flows. If personal data reaches a US server before any protection is applied, no amount of consent can fix the fundamental transfer issue.”
Step 3: Configure First-Party Data Collection
Third-party cookies are effectively dead in the EU compliance context. Safari and Firefox already block them, and even Chrome’s approach requires explicit consent. First-party data collection is the only sustainable path forward.
First-Party Cookie Strategy
- Set cookies from your own domain: Using server-side GTM with a first-party subdomain means your analytics cookies come from your domain, not google-analytics.com
- Limit cookie lifetime: CNIL’s guidelines recommend a maximum 13-month cookie lifetime. Configure your first-party analytics cookies accordingly
- Document each cookie: Your privacy policy must list every cookie, its purpose, and its expiry. Automate this with your CMP’s cookie scanning feature
First-Party Data for Attribution
With consent-dependent tracking, you’ll lose visibility into a significant portion of user journeys. First-party data fills the gap:
- Capture UTM parameters server-side and store them in your own database
- Use form submissions to connect anonymous sessions to known users (with consent)
- Build attribution models from your CRM data rather than relying entirely on analytics platforms
Step 4: IP Anonymization and Data Minimization
IP addresses are personal data under GDPR. Full stop. The European Court of Justice confirmed this in the Breyer case (C-582/14). Every analytics tool you use must either anonymize IPs or have explicit consent to collect them.
IP Anonymization by Platform
- Google Analytics 4: IP anonymization is on by default — GA4 doesn’t log full IP addresses. However, the IP is still transmitted to Google’s servers before anonymization, which is why the Austrian and French DPAs flagged it
- Matomo: Offers 1-byte, 2-byte, or 3-byte IP masking. For GDPR, use at least 2-byte masking (last two octets zeroed)
- Plausible / Fathom: Never store IP addresses at all — fully compliant by design
- Server-side GTM: Add a custom variable that truncates the IP before it’s sent to any downstream tag
Beyond IP: Other Data to Minimize
Audit these common data leaks in analytics implementations:
- Email addresses in URL parameters (e.g., password reset links)
- User IDs or names in page titles
- Form field values captured by enhanced measurement
- Cross-site tracking identifiers
In GA4, use the data redaction feature in your data stream settings to automatically filter email-like patterns from URLs and events.
Step 5: Set Data Retention Policies
GDPR’s storage limitation principle (Article 5(1)(e)) requires that you don’t keep personal data longer than necessary. For analytics, this means configuring retention limits on every platform.
- GA4: Set user-level data retention to 2 months (the minimum) or 14 months. For most SaaS companies, 14 months gives you year-over-year comparison while staying within reasonable bounds
- Matomo: Configure automatic log purging. Raw visit logs should be deleted after 3-6 months; aggregated reports can be kept longer since they contain no personal data
- Your own databases: If you store analytics data in your data warehouse, implement automated deletion jobs. This is the one most companies forget
Document your retention periods in your privacy policy and in your Records of Processing Activities (ROPA), which you’re required to maintain under Article 30.
Step 6: Execute Data Processing Agreements
Under Article 28, you must have a Data Processing Agreement with every vendor that processes personal data on your behalf. For analytics, this typically includes:
- Your analytics platform (Google, Adobe, Matomo Cloud, etc.)
- Your CMP provider
- Your tag management provider (if separate from analytics)
- Any CDN or hosting provider that handles analytics data
- Data warehouse or ETL providers
Dr. Lukasz Olejnik, an independent privacy researcher and former member of the W3C Technical Architecture Group, notes: “DPAs aren’t just legal paperwork — they define the technical and organizational measures your vendor must implement. If your DPA doesn’t specify data residency, encryption standards, and breach notification timelines, it’s not doing its job.”
DPA Checklist
- Specifies the nature, purpose, and duration of processing
- Lists categories of personal data processed
- Includes Standard Contractual Clauses (SCCs) for non-EU transfers
- Details technical security measures
- Defines breach notification procedures (72-hour maximum)
- Confirms the vendor will delete data upon termination
Google’s DPA for GA4 is available in your Admin settings. Sign it. I’ve audited companies that have been running GA4 for over a year without accepting the DPA — that’s a compliance gap that takes 30 seconds to close.
Step 7: Evaluate Cookie-Less Alternatives
If you want to avoid the consent requirement altogether for basic analytics, cookie-less tools offer a clean path. They trade granularity for simplicity and compliance.
- Plausible Analytics: Open-source, EU-hosted, no cookies, no personal data collection. Fully GDPR-compliant without consent. Limited to pageviews, referrers, and basic events
- Fathom Analytics: Similar approach — privacy-first, cookie-less, EU data processing available. Slightly more feature-rich than Plausible
- Matomo (cookie-less mode): Can run without cookies by using session hashing. You lose returning visitor recognition but keep most other features
- Simple Analytics: No tracking cookies, no personal data, EU-hosted. Designed specifically for GDPR compliance
The tradeoff is real. Cookie-less tools give you 90% less data granularity than a fully consented GA4 implementation. For many SaaS companies, especially early-stage ones, that’s perfectly fine. You don’t need user-level cohort analysis when you’re trying to understand which blog posts drive signups.
My recommendation: run a cookie-less tool as your baseline (always-on, no consent needed) alongside a consent-dependent tool like GA4 for deeper analysis when users opt in. This hybrid approach gives you complete traffic visibility without compliance risk.
GDPR Compliance Audit Checklist
Use this checklist quarterly. GDPR compliance isn’t a one-time project — it’s an ongoing process that requires regular audits as tools update, regulations evolve, and your analytics stack changes.
Consent and Legal Basis
- CMP banner displays before any tracking scripts fire (verify with browser dev tools)
- Reject option is as prominent and accessible as accept
- Consent records are stored with timestamps and can be retrieved
- Consent Mode v2 default state is “denied” for all parameters
- Legitimate interest assessment documented for any tracking without consent
Data Collection and Processing
- IP anonymization confirmed active on all analytics platforms
- No PII leaking through URL parameters or page titles
- Server-side tracking filtering data before it reaches vendors
- First-party cookies only, with documented purposes and expiry dates
- Enhanced measurement settings reviewed (disable what you don’t actively use)
Vendor and Legal Compliance
- DPAs signed and current with all analytics vendors
- SCCs in place for any non-EU data transfers
- Data retention configured to minimum necessary periods
- Privacy policy accurately reflects current tracking practices
- Records of Processing Activities (ROPA) up to date
- Data subject access request (DSAR) process tested and functional
Common Mistakes I See in GDPR Tracking Implementations
After auditing dozens of SaaS analytics setups, these are the violations that come up most often:
- Loading Google Analytics before consent: The most common mistake. GA4 tags fire on page load before the CMP has collected consent. Fix this by ensuring Consent Mode defaults are set before any Google tags load
- Ignoring the “reject” state: Companies implement CMPs but don’t actually block tracking when users decline. Test this by rejecting cookies and checking network requests — you’d be surprised how often tracking scripts still fire
- Missing DPAs: Using analytics tools without signed Data Processing Agreements. Google’s DPA must be explicitly accepted in the Admin panel
- Cookie walls: Blocking content access until users accept cookies. CNIL explicitly considers this non-compliant in most cases
- No data retention limits: Keeping analytics data indefinitely. Set explicit retention periods and automate deletion
- Transferring data to the US without safeguards: The EU-US Data Privacy Framework helps, but you still need to verify your specific vendor is certified and your DPA references it
Making It Work: A Practical Implementation Timeline
Based on implementations I’ve done for SaaS companies with 10K-500K monthly visitors, here’s a realistic timeline:
- Week 1: Audit current tracking setup, identify all data flows and vendors, review existing DPAs
- Week 2: Deploy CMP, configure Consent Mode v2, set default deny state
- Week 3: Set up server-side GTM, configure IP anonymization and PII filtering
- Week 4: Deploy cookie-less analytics as baseline, configure data retention policies, sign missing DPAs
- Week 5: Update privacy policy, complete ROPA, run full audit against checklist above
Five weeks from start to compliant. It’s not quick, but it’s not the multi-month project some consultancies will quote you either.
The companies that maintain compliance long-term build it into their workflow: quarterly audits, mandatory privacy review for any new tracking implementation, and a designated owner (even if it’s not a full-time DPO). GDPR-compliant tracking isn’t a checkbox — it’s a practice.
Frequently Asked Questions
Is Google Analytics 4 GDPR compliant?
GA4 can be GDPR compliant, but it requires proper configuration. You need Consent Mode v2 with default-deny, a signed DPA, IP anonymization (on by default), EU data storage settings, and appropriate data retention limits. Without these configurations, GA4 is not compliant out of the box. Several EU DPAs have ruled against improperly configured Google Analytics deployments.
Do I need a cookie consent banner if I use Plausible or Fathom?
No. Cookie-less analytics tools like Plausible and Fathom don’t set cookies or collect personal data, so they don’t require consent under GDPR or the ePrivacy Directive. However, you should still mention them in your privacy policy for transparency, and if you run any other tracking (ad pixels, heatmaps, etc.), you’ll still need a consent banner for those.
What happens to my analytics data when a user withdraws consent?
When a user withdraws consent, you must stop collecting new data from them immediately. For previously collected data, the regulation is less clear — most DPAs accept that anonymized, aggregated data can be retained. However, any data that can be linked back to that specific user should be deleted. GA4 handles this partially through its data retention auto-deletion, but you may need manual processes for data warehouse copies.
How much traffic data do you lose with consent-based tracking?
Typical consent rates in Europe range from 30-70%, meaning you lose visibility into 30-70% of your traffic with consent-only tracking. Consent Mode v2’s behavioral modeling recovers some of this through modeled conversions. Running a cookie-less analytics tool alongside your consent-dependent tool ensures you always have complete traffic counts, even if the granular behavioral data is limited to consented users.
Does GDPR apply to my SaaS if my company is based outside the EU?
Yes. GDPR applies to any company that processes the personal data of individuals in the EU, regardless of where the company is based (Article 3(2)). If EU residents visit your website and you collect analytics data on them, GDPR applies. The only exception would be if you can somehow ensure no EU visitors ever reach your site, which is practically impossible for any web-based SaaS.
