Privacy Modes and GDPR in Link Tracking

Every conversation about privacy in link tracking eventually reaches the same question from a client: what exactly do you know about the people who click our links? The answer is usually improvised, which is why it is usually wrong in one direction or the other — reassuring beyond what the system guarantees, or vague enough to sound evasive.

This article is the material for a better answer: what a click event contains, why the level of detail is decided at write time rather than filtered out of a report, what happens to the network address, how retention actually works, what consent covers, and the paperwork a client's compliance reviewer will ask for. It is not legal advice — obligations depend on your jurisdiction, your audience and what you do with the data afterwards.

What a Click Writes Down

At redirect time, before any page has loaded, the engine sees a request. From it the event can record the moment of the click, the link and domain, the destination, an approximate location derived from the network address, the device type, browser and operating system parsed from the user agent, the referring domain where one is sent, the browser language, and any campaign parameters on the URL.

Where the workspace has enabled the detailed layer, the same event can also carry region and city with their GeoNames identifiers, coordinates and an accuracy radius, the time zone and the visitor's local hour, the autonomous system number and provider name, and a traffic-type verdict with a quality score. What that layer is for is covered in the traffic rules documentation.

Two things are deliberately absent. The postal code is resolved by the geography database and then not recorded, because in dense housing a postal code is close to an address. And the network address itself is never written, which has its own section below.

What the event does not contain matters just as much. It does not identify a person, does not say whether the destination page loaded or a purchase followed, and carries no cross-site identifier. Everything beyond that requires a second data source on the destination side, as described in our guide to tracking link clicks.

Two Different Ways to Limit Data

Confusing these two is the most expensive mistake in this area, and vendors rarely separate them.

A plan limits how far back a workspace may look. The rows still exist; a larger plan shows more of them. That is a commercial limit, reversible by upgrading. A privacy mode limits what is written down at all: what it turns off never reaches storage, so no report, export, support request or future query can bring it back — and neither can a change of mind.

| | Plan retention | Privacy mode | | --- | --- | --- | | What it controls | How far back you may look | What is recorded at all | | Where it applies | At read time | At write time | | Reversible | Yes, by upgrading | No, for rows already written | | Who changes it | Whoever manages billing | Workspace owner or administrator |

Both apply at once, which is the part people miss. A workspace on a plan with two years of viewing depth that has set its own retention to 30 days keeps 30 days.

Detail Is Chosen at Write Time

The setting lives in Settings → Visitor data and privacy: three location levels plus three independent switches.

| Level | What the event carries | | --- | --- | | Full | Country, continent, region, city, GeoNames identifiers, coordinates, accuracy radius, time zone, local hour | | City without coordinates | Everything above except coordinates and accuracy radius | | Country only | Country and continent |

At country only the geography database is not queried for the event at all — country and continent already arrive from the CDN at no cost. The setting removes work as well as data, so the privacy-maximal choice is also the cheapest to run.

The switches are narrower. Store the visitor's network controls the autonomous system number and provider name; off, the Networks breakdown is empty. Store the full referring address controls only the path and query string of the referring page — the referring domain is always kept, because the Sources report is built on it. Detect traffic type turns off the checks themselves, not merely the fields: no range lookups, no reverse name checks, no behavioural counters.

One button applies the combination intended for strict jurisdictions: country only, network not stored, full referring address not stored, traffic-type detection off, retention 30 days. What survives is the aggregate layer — country, device, browser, operating system, referring domain, campaign tags, and the daily visitor fingerprint. That last is kept deliberately: without it the notion of a unique visitor disappears, along with every aggregate built on it.

Two consequences cut both ways. Saving rewrites the cached configuration of every link and published bio page in the workspace, so the next click is recorded under the new mode rather than at the next cache expiry — "I turned coordinates off and they were collected for another day" is not an acceptable answer for a setting whose purpose is not collecting. And the change is not retroactive: rows already written keep what they were written with. Filtering is unaffected either way: a traffic rule that routes by city still routes by city when the city is not recorded, because rules decide where a visitor goes, not what is stored about them.

The Address: Truncate, or Do Not Keep It

The common industry approach is truncation — zeroing the last octet of an IPv4 address, or a wider prefix for IPv6 — and it is better than storing the whole thing. It is also weaker than it sounds: a truncated address still identifies a network of limited size, still narrows a small-town visitor considerably, and can be combined with the other fields in the same row. Truncation reduces resolution; it does not remove the field from the system.

The alternative is not to keep it. Here the address exists inside a single function long enough to do exactly two things, then is discarded. The hash is one-way, over the address, the user agent, the link domain and a secret salt rotated daily at midnight UTC, with the previous salt discarded.

address + user agent + link domain + daily salt  ->  one-way hash  ->  stored
address                                          ->  range lookup  ->  country, city, network
address                                          ->  discarded

Two honest consequences follow, and both belong in the client conversation rather than a footnote.

First, the metric is unique visitors per day. Because the salt rotates nightly the same person is a different hash tomorrow, so a monthly figure is a sum of daily uniques rather than a count of distinct people. Any vendor reporting exact monthly uniques without cookies is either persisting an identifier longer than they admit or estimating.

Second, the address cannot be produced later for anyone — not for you, not for a support request. That is the point of the design, and also a limitation to know before promising a client an investigation that would require it.

The principle continues at the output boundary. A link's public statistics page receives only country and city from the geography layer: no networks, no traffic type, no quality score, no coordinates, enforced by a test on the response body rather than by convention. What each breakdown exposes is documented in geo analytics and on the geography and traffic quality page.

Retention Is a Workspace Setting

Leave the retention field empty for the platform maximum of 730 days, or set a number of days.

The mechanism matters more than the number. The value travels inside each event, and storage expiry is expressed in terms of that value. A row written under a 30-day setting is deleted after 30 days even if the workspace later switches to 730, because the setting that applied when the row was written governs it.

This is what makes retention a usable answer rather than a vague reassurance. "We keep 90 days" is defensible if the 90 is stamped on every row when it is written; it is not if it describes a report filter over rows actually kept for two years. When comparing platforms, ask not what the retention period is but where it is enforced — and separately what the plan's viewing depth is, since that limit also applies. Both are described in visitor data and privacy modes.

Consent Covers the Data, Not the Redirect

The most common confusion here is treating the redirect itself as the thing consent is about. A visitor who taps a short link has asked to be taken somewhere, and taking them there is the service. Consent questions attach to two other things: what is recorded about that visit, and any technology stored on the visitor's device that is not strictly necessary.

That framing has practical consequences. There is no cross-site measurement cookie, because the daily hash replaces the mechanism most consent regimes were written about. There is exactly one cookie in the redirect path — a first-visit marker on your own redirect domain — and it is set only when one of your rules actually asks whether this is a first or repeat visit. So the answer to "do your links set cookies" depends on a configuration you can point to rather than on a general policy.

Tracking pixels are the clear exception. When a workspace attaches a retargeting pixel to a link, that pixel and anything it sets belong to the pixel's owner and the third party, not to the redirect service. The link owner is the controller for that processing and is responsible for disclosing it and obtaining any consent required — an agency attaching pixels on a client's behalf should have this in the client agreement, not discover it during an audit.

Roles matter for the same reason. For click data the workspace or partner that created the link is the controller and the platform is the processor, so the lawful basis, the privacy notice and any consent are the link owner's responsibility. Agencies running links for clients are in that position more often than they expect, which our agency guide to branded links covers from the commercial side.

The Paperwork a Reviewer Will Ask For

Two documents do most of the work, and neither should be improvised.

A Data Processing Agreement governs processing carried out on your behalf. A reviewer reads it for a specific set of things: who is controller and who is processor for each category of data, the categories of data subjects and personal data, the security measures, the breach notification window, the transfer mechanism for data leaving the European Economic Area or the UK, audit rights, and what happens to data on termination. Our DPA sets out those terms, including a 72-hour breach notification window, Standard Contractual Clauses with the UK addendum where applicable, an annual audit right on notice, and deletion within 30 days of the end of the export window.

A subprocessor list names the third parties processing data on the platform's behalf, what each is used for, and where it holds data. It is part of the DPA rather than a marketing page, and the mechanism around it is what a reviewer evaluates: at least 30 days of notice before one is added or replaced, a documented right to object, and termination of the affected part without penalty where no reasonable alternative exists. Our subprocessor list publishes the current providers with purpose and data location; the general description is in the privacy policy.

If a vendor cannot produce both documents, or produces a subprocessor list with no notice mechanism attached, that is the finding — not the absence of a certificate logo.

A Checklist for the Client Conversation

1. Produce the field list for the mode actually in use — not the platform maximum, but what that workspace is writing today.
2. State the retention in days and where it is enforced, distinguished from the plan's viewing depth, and say which is currently binding.
3. Answer the address question in one sentence: stored in full, truncated, or not stored — and if not stored, explain the daily hash and the per-day nature of unique visitors.
4. List the cookies in the redirect path and what causes each to be set. "None unless a first-visit rule is configured" beats "essential cookies only".
5. Separate what you attach from what the platform does. Pixels, third-party tags and destination-side analytics are your processing, not the redirector's.
6. Hand over the DPA and the subprocessor list rather than summarising them, and note the notice period for changes.
7. Set the privacy mode to the strictest level your reporting can live with, then confirm which breakdowns went empty — that is how you find out whether a setting was chosen or merely defaulted into.

The uncomfortable part of this subject is that write-time decisions are permanent in both directions. Data you chose not to collect is not recoverable when someone later asks for a city breakdown, and data you did collect is not un-collectable when someone later asks why you have it. That is an argument for deciding deliberately at the start of an engagement rather than inheriting a default. Everything in analytics still works at the strict end of the range; what changes is how much of the visitor, rather than how much of the campaign, you can see.