GDPR and link tracking: what a redirect is allowed to record

Two different rules get confused in every conversation about this, and separating them makes the rest straightforward.

The cookie rule — Article 5(3) of the ePrivacy Directive — governs storing information on, or reading information from, a visitor's device. It applies whether or not the information is personal data, and consent is generally required unless the storage is strictly necessary for a service the user asked for.

The personal data rule — the GDPR — governs processing information about an identified or identifiable person, wherever that information lives.

A redirect can engage one, both or neither, depending entirely on what it does.

What a redirect has to do, and what it chooses to do

A redirect must read the request line and return a status code with a Location header. Everything else is a choice.

The choices we made, and what each one costs:

Field	What happens to it
IP address	Held in memory to compute a rate-limit key and a salted hash. Never written to the event, never logged.
User agent	Truncated and stored on the raw event, parsed later off the hot path into device, OS and browser.
Country, region, city	Read from a header the network edge adds. No lookup runs on our side.
Referrer	Stored as a hostname and a category.
Cookies	None are set. There is no Set-Cookie on the redirect response.
Browser storage	None. The response has no body, so no script runs.

Because the response is a status line and headers — no document, no script, no storage — Article 5(3) is not engaged by the redirect. That is not a clever reading; it is what the response contains.

The visitor identifier, precisely

Counting unique visitors needs some way to tell one from another. The available options are a cookie, an IP address, or a hash.

We use a hash: SHA-256 over three inputs — a rotating salt, the IP address and the user-agent string — truncated to 32 hexadecimal characters. The salt is derived from a server secret and a time period that advances every 24 hours.

Three properties follow, and each is a deliberate trade.

Within one day, one visitor counts once. That is the point, and it also means the value permits singling out within that day's data. Under Recital 26 that makes it pseudonymous, not anonymous, and we do not describe it otherwise.

Across days, nothing links. When the salt rotates, every previously computed identifier becomes uncomputable. The same person tomorrow is an unrelated string. There is no cross-day profile because there is no way to build one.

The inputs are not kept. The address and the user agent that fed the hash exist for the microseconds it takes to compute it. Neither is written to the event, and the logging configuration redacts credentials and never records raw addresses.

The cost of this design is real and we would rather state it than hide it: we cannot answer "who clicked this link", we cannot deduplicate a visitor across a week, and unique counts are estimates rather than exact. Those are the prices of not holding a list.

Where a shortener still needs care

The referrer that travels onward. The redirect sets a referrer policy of no-referrer-when-downgrade, which is the browser default: your destination receives the referring page for https-to-https navigations. That is normal web behaviour, but it means the URL someone came from can reach a third party's server. If your referring URLs contain anything sensitive, that is a problem to solve at the source.

UTM parameters you put in the link. These travel to the destination and are stored on the event. A campaign parameter containing an email address or a customer identifier turns an anonymous event into a personal one instantly. Do not put identifiers in UTM values.

Custom domains and controllership. Running short links on your own subdomain does not change who the controller is. It changes whose reputation the domain carries.

The practical checklist

1. 1

   Write down what you actually need to measure

   Most campaigns need volume, source and geography at country level. That is satisfiable without anything identifying anyone, and Article 5(1)(c) expects you to have asked the question.

2. 2

   Keep identifiers out of URLs

   No email addresses, customer numbers or order references in a UTM value or a path you pass through. This is the single most common way a tracking setup acquires personal data by accident.

3. 3

   Get the processing agreement in place before the campaign

   Not after your first data subject request. The document should name the retention period, the sub-processors and the deletion process.

4. 4

   Check the destination separately

   The redirect may set nothing, but your landing page probably sets plenty. The banner belongs there.

5. 5

   Say what you do, in the words you actually mean

   A privacy notice claiming "fully anonymous tracking" for a system that can single out a visitor within a day is worse than one that describes a daily rotating pseudonym honestly.

Deletion, and what it can and cannot reach

Deleting a workspace removes its links, its pages and its aggregates. What it cannot do is remove one visitor from analytics, because there is nothing in the analytics store that identifies a person — no row to find, no key to search on. That is an awkward answer to give a data subject request and it is the honest consequence of the design: the data that would let us comply with a deletion request precisely is the data we chose not to collect.

Raw events expire on their own after 400 days through a database-level time to live. Unique-visitor sketches in the cache expire after three days. Neither needs a job to run or a person to remember.

For the current, complete statement of what is stored and for how long, read the privacy policy rather than this guide — that page is written from the same code and is the one that gets updated when the code changes. The rest of what a branded link does is unaffected by any of it.