GDPR enforcement against analytics practices has moved from theoretical to routine. The Austrian, French, and Italian data protection authorities have each issued decisions against the use of Google Analytics that found the tool's data transfers to the US violated GDPR requirements. More enforcement actions have followed. The posture of waiting to see what happens is no longer available.
The five steps below won't make every decision for you — GDPR compliance involves judgment calls specific to your organization — but they establish the foundation that everything else depends on.
Step 1: Understand what personal data your analytics collects
GDPR defines personal data broadly: any information relating to an identified or identifiable natural person. For analytics, this includes IP addresses, device identifiers, cookie values, and any user-provided information that gets passed into your analytics platform. It also includes data that can be combined with other information to identify someone — which is a wider category than most analytics teams initially assume.
Understand your data subjects' rights under GDPR: the right to access their data, to correct it, to have it deleted, and to have it ported to another service. Your analytics implementation needs to support those rights operationally, not just acknowledge them in a privacy notice.
Step 2: Map what you collect, where it goes, and who touches it
Data mapping is unglamorous work that most organizations skip or do incompletely. The result is that when a regulator asks what personal data you collect, how long you retain it, where it's stored, and which third parties process it — which are standard questions in any enforcement inquiry — you can't answer from documented records.
For analytics specifically, that map includes your analytics platform, your tag management system, any third-party pixels or SDKs that fire alongside your analytics tags, your BigQuery or data warehouse destination if you have one, and any BI tools that query the data. Each of those is a processing activity under GDPR, and each needs to be documented.
Step 3: Collect only what you actually need
Data minimization is a GDPR principle, not just good hygiene. Collect the data that is necessary for the specific purposes you've defined. If you're collecting user-level identifiers that don't serve a purpose you can articulate, you're carrying both a compliance risk and a liability you don't need.
For most analytics implementations, this means reviewing every custom dimension and event parameter you're collecting and asking whether each one serves a documented purpose. The ones that don't have a clear answer are the ones to remove.
Step 4: Get consent right — and make it easy to withdraw
GDPR consent must be freely given, specific, informed, and unambiguous. Pre-ticked boxes don't count. Consent for analytics must be separate from consent for other purposes. And the user must be able to withdraw consent as easily as they gave it — a one-click opt-out, not a buried settings menu.
Your consent mechanism — the cookie banner and the underlying consent management platform — needs to actually reflect what fires when a user consents or declines. That means your tags need to be conditional on consent signals, not firing by default and relying on opt-out. Consent-mode implementations vary significantly in how well they achieve this; the difference between a compliant implementation and a non-compliant one isn't visible to the user, but it is visible to a technical audit.
Step 5: Conduct Data Protection Impact Assessments for high-risk processing
A DPIA is required under GDPR when processing is "likely to result in a high risk" to individuals. For analytics, that threshold is reached by large-scale processing of behavioral data, systematic monitoring, or use of new technologies whose privacy impact hasn't been established. If you're using GA4 with full user-level tracking at any significant scale, you're likely in DPIA territory.
A DPIA isn't a one-time document. It needs to assess the necessity and proportionality of the processing, evaluate the risks to data subjects and the measures you're taking to address them, and be revisited when your processing changes materially. Organizations that have done one DPIA and filed it away are not in ongoing compliance.