There is no lawful number of months to keep click data. Article 5(1)(e) of the GDPR asks that personal data be kept in identifiable form no longer than necessary for the purpose, and leaves the period to you, as the text makes plain. What a supervisory authority examines is not the figure you chose but whether you can explain it.
That is easier than it sounds, because click data is not one thing. It arrives as a raw request, becomes an event with most of the identifying material removed, and ends as a count that identifies nobody. Each of those deserves a different window, and separating them is most of the work. For the wider obligations around a shortener, GDPR for URL shorteners is the cornerstone this sits under.
Why the Question Has No Single Answer
Storage limitation is a principle, not a schedule. Three inputs decide the period, and all three are yours to determine.
The purpose comes first. Data collected to report on a campaign is necessary until the campaign has been reported on and compared against its predecessor, which is a year at most for many teams and three months for some. Data collected to detect abuse of a redirect is necessary for as long as an investigation could plausibly start, which is usually far shorter.
The lawful basis comes second. Analytics running on legitimate interests must survive a balancing test, and a long retention window makes that test harder to pass. Anything collected on consent has to go when consent is withdrawn, promptly, with no other basis quietly picked up in its place.
Third, obligations that pull the other way. Tax rules, contractual commitments to a client, an active dispute or a regulatory hold can all require you to keep something longer than minimisation would suggest. Those are legitimate and they are also specific, which means they belong in the record as named exceptions rather than as a general reason to keep everything.
Three Tiers, Three Windows
The practical structure that survives an audit separates click data by how identifying it is.
| Tier | What it contains | Typical window | Why |
|---|---|---|---|
| Raw request log | full IP, user agent, headers, timestamp | days | operational debugging and abuse only |
| Click event | truncated network prefix, country, device, campaign | about 12 months | reporting and year-on-year comparison |
| Aggregate | counts by day, link, country, referrer | indefinite | anonymous, no longer personal data |
The middle tier is where most teams over-retain without noticing, usually because the reporting tool defaults to keeping everything and nobody changed it. Twelve to fourteen months is the window that lets you compare this September against last September and then stops. If your reporting genuinely needs three years of row-level detail, that is a decision to write down and defend rather than an accident of configuration. Whatever window you set here is also the ceiling on what a later export can recover, since a pull run today only surfaces rows that retention already let survive. Export short link data covers that link between the two decisions, including how to confirm a thin pull is retention working as intended rather than a broken export.
The top tier is where most teams under-think. A full IP address in a request log is personal data, and a log kept for a year because nobody set a rotation is a year of exposure bought for nothing. Truncating at collection, before the event is written, removes the problem at the source. What is worth measuring in short-link analytics covers which metrics survive that truncation, and the answer is nearly all of them.
Aggregation Is the Retention Strategy
The most useful move available is not choosing a shorter window. It is arranging matters so the thing you keep forever is no longer personal data.
Roll click events up into counts by day, link, country, referrer and device class, then delete the rows they came from. What remains answers nearly every question a marketing team asks: how the campaign performed, which region responded, whether mobile share moved. What it cannot answer is anything about an individual, which is exactly the point.
Two cautions. Anonymisation has to be irreversible, so keeping a mapping table that could rebuild the rows means you have pseudonymised rather than anonymised, and the data stays in scope. And small groups betray individuals: a link sent to five people, counted per minute, is re-identifiable by anyone who knows the five. Aggregate at a granularity that keeps groups large, and suppress cells that fall below a threshold.
Setting this up once beats revisiting it annually. Elido's link analytics truncates the address before the event is stored and reports on the aggregate, so the retention decision is about the middle tier only.
What an Erasure Request Actually Reaches
Article 17 gives a data subject the right to erasure, and the honest answer for well-designed click data is often that there is nothing to erase.
If an event carries a truncated network prefix, a country, a device class and a campaign, no operation on your side can connect it to the person asking. Say so, explain the design, and the request is satisfied. Regulators are not hostile to that answer when the architecture supports it.
The answer changes the moment clicks are tied to a person. A shortener that records which contact opened which link, or a CRM that writes click events onto a record, holds personal data with a name attached, and an erasure request reaches all of it. That is a legitimate way to work; it just moves the obligation. If you forward clicks into a CRM, the retention decision belongs to both systems, and the one with the longer window sets the real answer. Forwarding link clicks into a CRM timeline shows what that integration actually writes.
Writing It Down So It Survives an Audit
A retention schedule that lives in someone's head is not a control. Four artefacts make it real.
- The record of processing. Article 30 asks for retention periods per category of data. Fill the column with the three tiers above rather than a single figure, because a single figure for all click data is either wrong for the raw logs or wrong for the aggregates.
- A deletion mechanism you can point at. A configured expiry on the analytics store, with the setting visible, beats a documented intention. If deletion is a scheduled job, keep its run history.
- Backups, stated explicitly. Say how long backup generations live and what happens on restore. The EDPB's published guidelines are the reference point for how supervisory authorities frame these questions across member states.
- Alignment with your processor agreements. If your shortener's contractual retention is longer than your policy, the contract wins in practice. Read the DPA before you write the policy, not after.
One more piece that people forget: exports. A CSV pulled into a spreadsheet, a warehouse sync, a dashboard tool with its own cache. Each copy carries the retention obligation with it, and none of them respect the expiry you configured upstream. Name them in the schedule or accept that the schedule describes only part of reality.
A Default You Can Defend
If you need somewhere to start, this is a position that holds up: raw request logs rotated within days, click events kept about a year so seasonal comparison works, aggregates kept indefinitely and genuinely anonymous, anything consent-based deleted on withdrawal, and every deviation named with its reason.
Then review it once a year against what the team actually looks at. Nearly every retention window I have seen shortened after that review, because reporting past thirteen months turned out to be something people said they needed rather than something they opened. EU data residency for marketing teams covers the other half of the conversation, which is where the data sits while you are keeping it.
Read the Cornerstone Series
This post sits in the compliance cluster. GDPR for URL shorteners is the cornerstone, and the SOC 2 evidence guide covers the audit artefacts that sit alongside a retention schedule.
Related on the Blog
Frequently asked questions
How long can I keep click tracking data under the GDPR?
For as long as you can justify against the purpose you collected it for, and no longer. Article 5(1)(e) sets storage limitation as a principle rather than a number, so there is no lawful maximum to point at. What a regulator asks for is your reasoning, written down, and evidence that deletion actually happens on the schedule you wrote.
Is an IP address in a click log personal data?
Yes, in the ordinary case. An IP address identifies a subscriber line with the help of information a network operator holds, which is enough to make it personal data even when you never obtain that information yourself. Truncating it at collection, before anything is written, is what takes the field out of that category.
Do aggregate click counts fall under the GDPR?
Not once they are genuinely anonymous, meaning no one can single out an individual from them by any means reasonably likely to be used. A daily count of clicks per country clears that bar comfortably. A count of clicks per link per minute for a link sent to four people does not, because the group is small enough to re-identify.
What retention period should I set for link analytics?
A defensible default is short for raw request logs, around a year for pseudonymised click events so year-on-year comparison still works, and indefinite for anonymous aggregates. Adjust for your own purposes: a legal hold, a contractual commitment or a fraud investigation all justify longer, and each of those reasons belongs in the record.
Does a deletion request cover click data?
It covers whatever is linked to the person. If your click events carry a truncated network prefix and no identifier, there is nothing to find and nothing to erase, and you should be able to explain why. If clicks are tied to a contact record in a CRM, that link is exactly what an erasure request reaches.
Do backups have to be deleted too?
They have to be covered by the schedule, which is not the same as being purged on the day. The workable position is that backups age out on a fixed cycle, that restored data is re-filtered before use, and that the whole arrangement is written down. Silence about backups is what turns a routine question into a finding.
Try Elido
Paste a URL, get a working short link
No signup. Link lives for 30 days. Sign up to keep it forever.
Free, no signup required · 2 per day