Data retention is the analytics question almost nobody asks until a regulator or a security review forces it. Teams obsess over what to collect and how to model it, then quietly keep every raw event forever “just in case.” Under the GDPR, that default is backwards. The law’s storage-limitation principle says you may keep personal data only as long as you actually need it — and “forever, in case it’s useful someday” is not a retention policy. It’s a liability.
This guide explains what the GDPR requires, how long different analytics data should live, and how to set a retention policy that satisfies both your analysts and your compliance team.
What the GDPR Requires
The relevant rule is the storage-limitation principle in Article 5(1)(e): personal data must be kept “no longer than is necessary” for the purposes it was collected for. There’s no fixed number in the law — it depends on your purpose. But there is a clear obligation: you must define a retention period, justify it, and delete or anonymize data once that period ends.
Crucially, most analytics data is personal data. A pseudonymous event tied to a user or device still counts, as I cover in pseudonymization vs anonymization. So the storage-limitation principle applies to your event stream, not just your CRM.
The GDPR doesn’t tell you how long to keep data. It tells you that “indefinitely” is never the answer, and that you must be able to justify whatever period you choose.
How Long Should Analytics Data Live?
The trick is to stop treating “analytics data” as one thing. Raw, person-level events and aggregated reports have completely different retention needs.
| Data type | Typical retention | Why |
|---|---|---|
| Raw person-level events | 2–14 months | Personal data — minimize exposure |
| Pseudonymous user profiles | Tied to account lifetime + grace | Needed while the relationship exists |
| Aggregated reports | Indefinite (once anonymized) | No longer personal data |
| Consent & audit logs | Per legal obligation | Proof you need to retain |
This split is the whole strategy. You keep raw personal data for a short, defensible window, roll it up into anonymous aggregates you can keep forever, then delete the raw layer. Your long-term trends survive; your liability doesn’t.
The GA4 Example
GA4 makes this concrete. Its user- and event-level data retention is configurable to either 2 months or 14 months, after which Google deletes the granular records. Your aggregated reports remain. That’s the model in miniature: short retention on the personal layer, permanence only for the anonymous one. Set it deliberately rather than leaving the default.
The Retention Lifecycle
A clean policy moves data through three stages on a schedule.
- Collect & use. Raw events arrive and power your day-to-day analysis — funnels, cohorts, debugging. This is when person-level detail earns its keep.
- Aggregate. Before the retention window closes, roll the data into anonymous aggregates: weekly actives, conversion rates, trends. These carry the long-term value forward.
- Delete or anonymize. When the window ends, the raw personal records are deleted or irreversibly anonymized. The aggregates remain; the liability is gone.
Automate this. A retention policy that depends on someone remembering to run a deletion job is a policy that will fail an audit. Schedule the deletion, log that it ran, and you have both compliance and proof of it.
Setting Your Retention Period
To choose a defensible number, answer three questions for each dataset:
- What’s the purpose? Debugging needs weeks; cohort analysis needs months; trend reporting needs anonymized aggregates, not raw data. Match the period to the real use.
- Is there a legal obligation? Some data — tax records, consent logs — has a mandated minimum. That overrides minimization for those specific records.
- Can the purpose be met with less? If a report works on aggregates, you don’t need the raw events. Default to the shortest period that still does the job.
Document the answer for each dataset. That documentation is your retention policy, and it’s exactly what a privacy audit will ask to see.
Common Mistakes
- Keeping raw events indefinitely. The most common and most expensive default. Indefinite retention of personal data violates storage limitation outright.
- One retention period for everything. Raw events and anonymized aggregates have opposite needs. A single blanket period is either too long or too short.
- Manual deletion. If deletion isn’t automated and logged, it won’t happen reliably — and you can’t prove it did.
- Forgetting backups. Data “deleted” from production but living forever in backups isn’t deleted. Your retention policy must reach the backups too.
FAQ
How long can I keep analytics data under the GDPR?
As long as you can justify against your stated purpose — and no longer. There’s no fixed limit, but raw person-level data typically lives months, not years, while anonymized aggregates can be kept indefinitely because they’re no longer personal data.
Does the GDPR set a specific retention period?
No. Article 5(1)(e) requires data be kept “no longer than necessary” without naming a number. You define the period based on purpose, document the justification, and delete or anonymize when it expires.
Can I keep aggregated analytics forever?
Yes, once it’s genuinely anonymized. Aggregated data with no path back to an individual is no longer personal data, so storage limitation doesn’t apply. The key word is genuinely — small or re-identifiable aggregates still count as personal data.
What retention period should I set in GA4?
Choose 2 or 14 months based on how long you truly need event-level detail, not the default. Fourteen months suits year-over-year cohort work; two months suits teams that rely mainly on aggregated reports.
The Bottom Line
Data retention is where minimization meets the calendar. The GDPR won’t hand you a number, but it will hold you to one rule: keep personal data only as long as you genuinely need it. Split your analytics into a short-lived raw layer and a permanent anonymized one, automate the deletion between them, and document your reasoning for each dataset. Do that and you keep every trend worth having while shedding the risk of hoarding events you’ll never use. “Forever, just in case” was never a strategy — it was a breach waiting for a date.