There is no lawful number of months to keep click data. Article 5(1)(e) of the GDPR says personal data may be kept in a form that permits identification of data subjects for no longer than is necessary for the purposes for which it is processed, and it leaves the period to you (text accessed 2026-10-25). A supervisory authority doesn't examine the figure you chose. It examines whether you can explain it and show that deletion happens.
That's easier than it sounds. Click data isn't one thing. It arrives as a raw request, becomes an event row, and can end as a count that identifies nobody. Each stage deserves a different window. The wider obligations around a shortener sit in GDPR for URL shorteners, the cornerstone for this post.
I'll also say where Elido stands today, because retention is a place where product pages and reality drift apart. It's tidier than it was, but not finished.
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.
The purpose comes first. Campaign data is necessary until the campaign has been reported and compared with its predecessor. A year at most for many teams. Three months for some. Data kept to detect abuse of a redirect is necessary only while an investigation could plausibly start, usually far shorter.
The lawful basis comes second. Analytics running on legitimate interests must survive a balancing test, and a long window makes that harder. Anything collected on consent goes when consent is withdrawn.
Third are obligations that pull the other way: tax rules, a contract with a client, an active dispute, a regulatory hold. They're legitimate. They're also specific, so they belong in the record as named exceptions, not as a general reason to keep everything.
What Elido Stores Today
Here is the current state, read from the code on 2026-10-25.
| Data | What is stored | Deletion today |
|---|---|---|
| Click events | Truncated IP address (IPv4 /24, IPv6 /48), full user agent, referrer, country, region, city, latitude and longitude, device, browser | Rows expire after the plan window: 90 days on Free, 1 year on Pro, 2 years on Business. Older history is being cleared gradually |
| Audit events | Who changed what in a workspace | Purged after 730 days by default, configurable per workspace (minimum 30 days) |
| Account erasure | The user record | Anonymised on request; click rows of workspaces the person owns alone can be erased too |
Two things stand out.
First, the IP address is truncated at the edge (IPv4 to /24, IPv6 to /48) before the click is stored, but country, region, city and approximate coordinates are derived first and kept with the click, and the full user agent is stored. A truncated IP plus city and user agent can still point at a person. Second, click rows expire after the plan window on the pricing page: 90 days on Free, one year on Pro and two years on Business, enforced by a storage rule stamped on each row at ingest. Any plan can shorten its window. History from before the rule is being cleared gradually, so some older rows can still be present.
Two practical consequences follow. If you need strict minimisation today, keep the identifying fields out of what you forward and export. If a data subject asks you to erase their clicks, send the request to [email protected]: staff can delete a visitor's clicks by truncated IP and user agent, but there is no self-serve tool for it yet.
Three Tiers, Three Windows
Separate click data by how identifying it is. This is the structure that survives an audit, and it's what I'd hold any provider to.
The raw request log, with full IP, user agent and headers, should live for days. It exists for debugging and abuse handling. Nothing else. The click event, with a truncated or dropped IP plus country, device and campaign, fits about twelve months: enough for September-over-September comparison, then it stops. The aggregate, counts by day, link, country and referrer, can live indefinitely because it's no longer personal data.
The middle tier is where teams over-retain without noticing, usually because the tool defaults to keeping everything. If your reporting genuinely needs three years of row-level detail, write that down and defend it. Whatever window you choose is also the ceiling on what an export can recover. Export short link data covers that link, including how to tell a thin export from a broken one.
A full IP in a request log is personal data, and a year of it kept because nobody set a rotation is exposure bought for nothing. What is worth measuring in short-link analytics shows which metrics survive without the raw address, and it's nearly all of them.
Aggregation Is the Retention Strategy
The best move isn't a shorter window. Arrange things so that what you keep forever is no longer personal data.
Roll events up into counts by day, link, country, referrer and device class, then delete the rows they came from. What remains answers most marketing questions. How did the campaign do? Which region responded? Did mobile share move? It can't answer anything about an individual, which is the point.
Two cautions. Anonymisation has to be irreversible; a mapping table that can rebuild the rows means you've pseudonymised, 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 small cells.
On Elido you can pull events through the analytics API or export them as gzip NDJSON to your own storage, then aggregate on your side and keep the aggregates as long as your policy says. Elido's expiry covers the raw rows, and your own copy is yours to document. Link analytics reports on the events as stored, so plan around that.
What an Erasure Request Reaches
Article 17 gives a data subject the right to erasure. For click data the answer depends on what a row contains.
If a row holds a full IP, a city and a user agent, it can often be linked to a person, and you should assume an erasure request reaches it. If your pipeline truncates the address at collection and keeps no identifier, there's nothing to find, and you can explain why. Regulators accept that answer when the architecture backs it up.
The answer also changes the moment clicks are tied to a named person, such as a CRM that writes click events onto a contact record. That is a legitimate way to work; it just moves the obligation. The retention decision then belongs to both systems, and the longer window sets the real answer. Forwarding link clicks into a CRM timeline shows what that integration writes.
Writing It Down So It Survives an Audit
A retention schedule in someone's head isn't a control. Four artefacts make it real, and none takes long to produce.
- The record of processing. Article 30 asks for retention periods per category. Fill the column with the three tiers rather than one figure, which is either wrong for raw logs or wrong for aggregates.
- A deletion mechanism you can point at. A configured expiry with the setting visible beats a documented intention. If deletion is a scheduled job, keep its run history. If your provider can't show you one, say so in the record and list the manual step.
- Backups, stated explicitly. Say how long backup generations live and what happens on restore. The EDPB's guidelines show how authorities frame these questions.
- Alignment with 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. Elido provides one on request.
Don't forget exports. A CSV in a spreadsheet, a warehouse sync, a dashboard with its own cache. Each copy carries the obligation, and none of them respects the expiry you set upstream.
Name every one of them in the schedule.
A Default You Can Defend
If you need somewhere to start: raw logs rotated within days, event rows about a year, aggregates indefinitely and truly anonymous, consent-based data deleted on withdrawal, and every deviation named with its reason.
Review it yearly against what the team actually opens. Nearly every window I've seen get shortened in that review was shortened because reporting past thirteen months turned out to be something people said they needed rather than something they used. EU data residency for marketing teams covers the other half, which is where the data sits while you keep it. The SOC 2 evidence guide covers the audit artefacts that sit alongside a schedule.
Related on the Blog
Frequently asked questions
How long can I keep click tracking data under the GDPR?
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, not a number, so there is no lawful maximum to point at. A regulator asks for your reasoning in writing and for evidence that deletion happens on the schedule you wrote.
Is an IP address in a click log personal data?
In the ordinary case, yes. An IP address identifies a subscriber line with help from information a network operator holds, which is enough even if you never see that information. Truncating or dropping it at collection, before anything is written, is what takes the field out of scope. Check whether your shortener does that: Elido truncates the address at the edge (IPv4 to /24, IPv6 to /48) before the click is stored, though city and user agent are still kept.
Do aggregate click counts fall under the GDPR?
Not once they're genuinely anonymous, meaning nobody can single out an individual by any means reasonably likely to be used. Daily clicks per country clear that bar. Clicks per link per minute for a link sent to four people don't, because the group is small enough to re-identify.
What retention period should I set for link analytics?
A defensible default is days for raw request logs, about a year for event-level click rows so year-on-year comparison still works, and indefinite for anonymous aggregates. A legal hold, a contract or a fraud investigation can justify longer, and each of those reasons belongs in your record.
Does a deletion request cover click data?
It covers whatever is linked to the person. Click rows that hold an IP address, a city and a user agent are personal data in many setups, so you need a way to find and remove them. Clicks tied to a contact record in a CRM are reached directly. Elido's erasure flow anonymises the user account, can erase the click rows of workspaces the person owns alone, and lets staff delete a visitor's clicks by truncated IP, optionally narrowed by user agent.
Do backups have to be deleted too?
They have to be covered by your schedule, which isn't the same as being purged the same day. The workable position is that backups age out on a fixed cycle, restored data is re-filtered before use, and the 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 account required. The free plan includes 25 links in total. Already have an account? Log in