Reading time: 9 min · Last updated: February 2026
If you’re running analytics on a European audience, you’ve almost certainly asked this question: which events am I actually allowed to collect? The short answer is — it depends entirely on what data those events carry. The long answer is what this article is about.
I’ve spent the last five years helping European companies untangle their GA4 setups after GDPR audits. The same mistakes come up again and again — teams either over-collect (and expose themselves to regulatory risk) or under-collect (and lose the insights they need to grow). GDPR-compliant event tracking isn’t about tracking less. It’s about tracking smarter.
Here’s what you’ll learn in this guide: what GDPR actually requires, how to categorize your events, which ones need consent and which don’t, how to handle the gray zones, and how to build a compliant schema from scratch.
What GDPR Actually Says About Analytics Data
GDPR doesn’t mention “analytics” once. What it does is define personal data — any information that relates to an identified or identifiable natural person (Article 4(1)). If your event data falls under that definition, the regulation applies. If it doesn’t, you have considerably more freedom.
The core principle to understand is lawful basis (Article 6). You need at least one of six bases to process personal data. For analytics, the two that matter most are:
- Consent (Article 6(1)(a)) — the user gives a clear, freely given, specific, and informed opt-in. This is what your cookie banner handles.
- Legitimate interest (Article 6(1)(f)) — you have a genuine business need that isn’t overridden by the user’s rights. This one’s contested terrain for analytics — more on that below.
There’s also the ePrivacy Directive (often called the Cookie Law), which sits on top of GDPR and specifically governs the storing of information on a user’s device. Under ePrivacy, cookies and similar trackers that aren’t strictly necessary require prior consent — full stop. This is stricter than GDPR’s legitimate interest path and explains why most European lawyers recommend consent for anything involving persistent identifiers.
Key takeaway: The question isn’t “does GDPR apply to my analytics?” — it almost certainly does if you have EU users. The question is “which legal basis covers each piece of data I collect?”
One more thing worth mentioning: the data minimization principle (Article 5(1)(c)). You should only collect data that’s adequate, relevant, and limited to what’s necessary. This isn’t just a legal box to tick — it’s good analytics practice. Bloated event schemas are harder to maintain and easier to misuse.
Personal Data vs Anonymous Data in Event Tracking
This distinction is the foundation of everything. Whether an event requires consent often comes down to whether it carries personal data — directly or indirectly.
Here’s how to think about it in practice:
| Data Type | Examples | Personal Data? | Consent Needed? |
|---|---|---|---|
| Direct identifiers | Email, name, phone, user ID | Yes | Yes |
| Persistent device IDs | Cookie ID, GA client_id, fingerprint | Yes | Yes |
| IP addresses | Full IPv4/IPv6 | Usually yes | Depends on use |
| Behavioral aggregates | Page views per session (no user link) | No | No |
| Truly anonymous data | Click counts, feature usage totals | No | No |
The tricky part is that data which looks anonymous often isn’t. A combination of page URL, rough geolocation, browser type, and timestamp can be enough to re-identify a user. The GDPR’s definition of personal data explicitly covers indirect identification — so if there’s a reasonable chance someone could be identified from the data, treat it as personal.
When I implemented GA4 for a German e-commerce client last year, we found they were passing hashed email addresses as a custom dimension on every purchase event — thinking hashing made it anonymous. It doesn’t. A hash is still a unique identifier linked to a person. We had to remove it and rethink the whole user identification strategy using server-side pseudonymization instead.
Events You Can Track Without Consent
Good news: there’s a meaningful set of events you can collect without a consent banner — as long as you do it properly. The key conditions are: no persistent identifiers, no cross-session linking, and data that can’t reasonably re-identify a person.
Tools like Plausible Analytics and Fathom are built around this model. But you can apply the same principles to GA4 with the right configuration — specifically, enabling Consent Mode v2 with analytics_storage set to denied, which tells GA4 to use cookieless pings with no persistent client IDs.
Events that are generally safe without consent:
| Event Name | What You Collect | Why It’s OK |
|---|---|---|
page_view |
Page URL, referrer (anonymized) | No user ID, no cookie, no cross-session link |
scroll |
Scroll depth percentage | Aggregate metric, no individual linkage |
click (outbound) |
Link URL, link text | No personal parameters sent |
file_download |
File name, file extension | Content interaction only, no identity |
search |
Search term (if not personally identifiable) | Aggregated content signal |
video_start / video_complete |
Video title, duration | Content engagement, no user link |
The critical condition for all of these: no parameters that contain or could reveal personal data. That means no user_id, no email fragments in page URLs (common with SaaS apps where /account/[email protected]/settings ends up in the path), and no UTM parameters that contain email addresses.
Pro tip: In GA4 with Consent Mode v2, cookieless pings still let Google model some behavior even without consent. You won’t get full data, but you get directional signals — and you stay compliant. It’s a reasonable trade-off for many European teams.
Events That Require Explicit Consent
Certain events are inherently tied to identifying users across sessions — that’s their whole purpose. For these, you need a valid consent signal before you fire them. No consent, no event. That’s the rule.
These always require consent:
- Purchase and conversion events with user_id —
purchasewith auser_idparameter links a transaction to a specific person across sessions. Without that parameter it’s more defensible; with it, you need consent. - Login and signup events —
loginandsign_upinherently involve identity. These events confirm you know who the user is. - Personalization events — any event that triggers or records content personalization based on a persistent user profile.
- Remarketing events —
add_to_cart,view_item,begin_checkoutwhen used to build remarketing audiences. Without a remarketing use case some of these may be defensible; with one, you need consent. - Cross-device tracking signals — anything involving
client_id,user_id, or external IDs passed to advertising platforms.
The consent signal must be granular. Under GDPR and the guidance from most EU Data Protection Authorities, users should be able to consent to analytics separately from advertising. Bundling them together invalidates consent for both.
In GA4 terms: your GTM or tracking code should check analytics_storage consent before firing standard analytics tags, and ad_storage and ad_user_data before anything advertising-related. GA4’s Consent Mode v2 handles this gating automatically — but only if your CMP is correctly sending the consent state before the page fires any tags.
The Gray Zone: Legitimate Interest
Legitimate interest (LI) is GDPR’s most debated lawful basis. The argument goes: companies have a genuine business interest in understanding how their product is used, and this interest isn’t overridden by users’ privacy rights — so consent isn’t needed.
In practice, this gets complicated fast. Here’s the honest picture:
| Use Case | LI Argument | Risk Level |
|---|---|---|
| Security monitoring (anomaly detection) | Protecting site integrity | Low |
| Error tracking (crash reports) | Technical necessity | Low |
| Basic session analytics (no persistent ID) | Improving user experience | Medium |
| Full GA4 with persistent client_id | Business optimization | High |
| Behavioral targeting / remarketing | Commercial interest | Very High |
The French DPA (CNIL) and the Austrian DPA have both ruled that using Google Analytics without proper safeguards — even under a legitimate interest claim — violates GDPR because of data transfers to the US. The German DSK has taken a similarly strict view. In 2023, the Irish DPC fined Meta €1.2 billion partly over LI misuse for advertising purposes.
My take, from working with German and Austrian clients: don’t rely on LI for anything involving a persistent tracking identifier or cross-session behavioral data. The regulatory environment is too hostile, and a consent-based approach is more defensible in an audit.
Watch out: Legitimate interest requires a balancing test — you must document why your interests outweigh the user’s rights. If you can’t write that down clearly and defend it, you don’t have a valid LI basis.
Building a GDPR-Compliant Event Schema
Here’s where theory meets implementation. A compliant schema isn’t about removing events — it’s about building a two-tier system: a consent-free baseline that always fires, and a consent-gated layer that only activates when the user opts in.
Here’s the pattern I use for e-commerce clients:
| Tier | Events | Parameters Allowed | Fires Without Consent? |
|---|---|---|---|
| Baseline | page_view, scroll, click, search |
page_location, page_title, search_term |
Yes |
| Analytics | view_item, add_to_cart, purchase |
item_id, value, currency (no user_id) |
Analytics consent only |
| Advertising | purchase (with user_id), remarketing events |
user_id, transaction_id, hashed emails |
Ads consent only |
In GTM, implement this with trigger conditions that check the consent state variable for the relevant consent type. In GA4 with Consent Mode v2, the gtag('consent', 'update', {...}) call from your CMP updates the consent state and automatically gates the relevant tags.
One thing I always add to schemas: a data classification field in your documentation, not in the events themselves. Every event in your tracking plan should have a “GDPR tier” column. When someone adds a new event, they need to decide which tier it belongs to before it goes live. This prevents compliance debt from accumulating silently.
For the baseline tier specifically: make sure your GTM configuration strips query parameters that might contain personal data from page_location. Things like ?email=, ?token=, and ?user= are common in SaaS apps and will inadvertently carry personal data into your analytics. A simple GTM variable that sanitizes the URL before it hits GA4 is worth the 30 minutes it takes to build.
Common Mistakes European Teams Make
After reviewing analytics setups across more than 40 European companies, I see the same problems over and over. Here are the ones that carry the most compliance risk:
1. Firing GA4 before the consent banner loads
This is the most common mistake. If GA4 fires on page load before the user has seen or interacted with your CMP, you’re collecting data without consent. The fix: implement Consent Mode v2 with default denied state, so no cookies are set and no identifying data is sent until consent is given. Many teams skip this because it requires proper CMP integration with GTM — but it’s non-negotiable.
2. Passing email addresses in event parameters
Emails, even hashed, are personal data. I’ve seen teams pass them in login events, purchase events, and even URL parameters that end up in page_location. Audit every event parameter for this — a quick scan of your GA4 DebugView is a fast starting point.
3. Using a consent banner that doesn’t actually gate tags
Some older CMPs just show a banner and log consent — they don’t actually communicate with GTM to gate tag firing. If your CMP isn’t using Consent Mode v2’s gtag('consent', 'update') API, your tags are probably firing regardless of what the user clicks. Test this in GTM’s preview mode with the network tab open.
4. Treating Google’s data retention settings as a GDPR safeguard
Setting GA4 data retention to 2 months doesn’t make your data collection compliant. The data still flows to Google’s servers — you’ve just reduced how long Google keeps it. The legal issue isn’t the retention period; it’s the collection and transfer itself.
5. No records of consent
GDPR Article 7(1) requires you to be able to demonstrate that consent was given. If a DPA asks for proof that users consented to your analytics tracking, can you provide it? Your CMP should be logging consent decisions with timestamps and the version of the consent text shown. If it isn’t, that’s the most urgent fix on this list.
FAQ
Does GDPR apply to GA4 if I anonymize IP addresses?
IP anonymization reduces risk but doesn’t remove GDPR obligations. GA4 still sets a persistent _ga cookie that links sessions to a device — that’s personal data. You need a valid lawful basis regardless of IP anonymization settings. The French CNIL and Austrian DSB have confirmed this position in formal decisions against companies using GA4 without proper consent.
Can I use server-side tracking to avoid GDPR requirements?
No — GDPR applies to the data you collect and process, not to where your tracking code runs. Server-side tracking can reduce what data reaches third parties like Google, but if you’re still identifying users across sessions and passing that data to GA4, the same compliance rules apply. Server-side setups genuinely improve your privacy posture when combined with data minimization, not as a compliance workaround on their own.
What counts as valid consent for analytics under GDPR?
Consent must be freely given, specific, informed, and unambiguous (Article 7 + Recital 32). For analytics this means: a clear opt-in action (not a pre-ticked box), a plain-language description of what’s collected and why, granular separation from advertising consent, and the ability to withdraw as easily as it was given. Implied consent — like “by continuing to browse this site” — is not valid under GDPR.
What’s the safest analytics setup for a European audience today?
The lowest-risk setup combines an EU-hosted privacy-first tool (self-hosted Matomo or Plausible) for cookieless baseline tracking with GA4 Consent Mode v2 for users who opt in. This gives you reliable aggregated data for all visitors without consent, richer behavioral data for opted-in users, and a clean audit trail. It requires more setup than GA4 alone but significantly reduces regulatory exposure for European companies.
Key Takeaways
GDPR-compliant event tracking doesn’t mean gutting your analytics. It means building a schema that separates what you can collect from everyone from what you can only collect with consent — and then enforcing that separation in your actual tag configuration, not just on paper.
- GDPR applies whenever you process personal data — and “personal data” is broader than most teams assume. Persistent IDs, IP addresses, and combinations of behavioral signals all count.
- A two-tier schema works — a consent-free baseline (page views, clicks, scrolls with no identifiers) plus a consent-gated analytics and advertising layer.
- Consent Mode v2 is your friend — properly configured, it gates tag firing and sends cookieless pings for behavioral modeling before consent is given.
- Legitimate interest for standard analytics is risky in the EU — several national DPAs have rejected it for behavioral tracking with persistent identifiers. Consent is the safer path.
- Audit your event parameters, not just your events — the event name is rarely the problem. What you pass as parameters is where personal data sneaks in.
If you’re starting fresh, build the GDPR tier into your tracking plan template from day one — it’s a column, not an afterthought. If you’re retrofitting an existing setup, start with an audit of what’s firing before consent and work from there. The goal isn’t perfect compliance on paper; it’s a setup you can actually defend when someone asks.