Answer First
Definition: A managed subdomain forwarding layer — the kind of service PushULink provides through its Console and OpenAPI — is a small HTTP service. Every time a browser or bot hits one of your branded subdomain entries, the layer records enough about the request to route the redirect and produce the access statistics and logs you can audit. Concretely, that request carries: a timestamp, the entry identifier it matched, the requester’s IP address, a User-Agent header, and a Referer header. Nothing more, nothing less.
Why: Because “we only count clicks” is technically true and practically misleading. A click count is an aggregate; something has to record the individual requests behind it. The moment you store a record with an IP address, a user agent, a referrer, and a timestamp, you are not “just counting” — you are logging data that can be personal data in many jurisdictions.
Example: At 14:03 UTC, a reader clicks a link in your newsletter pointing to links.yourbrand.com/spring-sale. The layer logs roughly this: timestamp 14:03:11.482, entry identifier spring-sale, IP 203.0.113.42, user agent Mozilla/5.0 … Chrome/124.0 …, referer https://mail.yourbrand.com/newsletter-2025-04. Your click count goes from 1,204 to 1,205 — but the log has also recorded a timestamped trace of one device’s activity.
Key Facts
- A forwarding layer needs roughly five fields to produce the access statistics and logs a product like PushULink surfaces: timestamp, entry identifier, IP address, user agent, and referrer.
- IP address and timestamp come from the network, outside the visitor’s control; user agent and referrer are client-supplied and can be absent, stripped, or spoofed.
- IP addresses are online identifiers under GDPR Recital 26, and courts (notably the CJEU in Breyer) have held they can be personal data even when dynamic.
- The referrer is the marketing payload — which email, ad, or partner page drove the click — behavioral data about the visitor.
- Retention is a legal requirement, not a preference: GDPR Article 5(1)(e) says personal data may be kept only as long as the purpose requires — and traceable changes are records about people (the editors), in scope too.
Expert Explanation
Anatomy of a single request
When a visitor hits links.yourbrand.com/spring-sale, their browser sends an HTTP request to that host. The forwarding layer matches it against the entry identifier, decides the destination — a 301 or 302, per the entry’s configuration, and the trade-offs are covered in our 301 vs 302 redirect article — and responds with the redirect. It captures the request first.
The five fields fall into two groups. Network facts: the timestamp and the source IP, assigned by infrastructure, not the visitor. Client-supplied facts: the User-Agent and Referer headers, defined in RFC 9110 and optional from the client’s perspective; the entry identifier comes from the URL itself. Two implications follow: client-supplied fields are unreliable for identification (privacy browsers strip referrers; user agents are trivially spoofed), and the referrer you see depends on the referring site’s referrer policy — you can only log what the client sends, as MDN’s redirect documentation makes clear.
Which fields are personal data?
The table to argue with at your next review:
| Field | What it records | Personal data? | Why it matters |
|---|---|---|---|
| Timestamp | Exact arrival time | Not by itself | Orders all fields into activity over time |
| Entry identifier | Which forwarding entry was hit | Usually no | Ties the record to a campaign |
| IP address | Network source of the request | Often yes | Can identify a device or connection (GDPR Recital 26) |
| User agent | Browser, OS, app version | Sometimes | With IP and time, can single out a device |
| Referrer | The page the visitor came from | Often yes | Behavioral: which email, ad, or partner sent them |
The through-line: few of these fields are identifying alone, and nearly all are identifying in combination. GDPR Recital 26 judges identifiability by “all the means reasonably likely to be used” — why a long-lived log of request metadata differs from a momentary counter, and why Google Analytics exposes data-retention settings for individual-level data.
Why “we only count clicks” undersells the log
The phrase does two kinds of work, both shaky. First, it implies nothing about individuals is retained — but a count is a summary of records; if no records existed, neither would the count. The click counter in your Console’s access statistics is the processed view; the raw request records are what the log actually is. Second, “only counting” implies a bounded privacy surface, when the log is also an audit trail: which entry, from where, when, and by whom.
It also fails the questions you will actually get. A customer asking “are you tracking me?” wants to know what you keep about them; an internal legal review wants the field list, retention period, and access list — both questions about the raw log. (When clicks stop converting, check the entry configuration first — see our guide to checking the campaign entry before rewriting the ads.)
Retention questions your team should be able to answer
There is no universal “right” number of days; anyone who gives you one without asking about your purposes is guessing. Teams should be able to answer:
- What fields does the request log actually contain — verified against the Console or API docs, not assumed?
- For each field, is it personal data in our context?
- What is the purpose of keeping it: operation, statistics, security, or audit?
- How long is it kept per purpose — and is retention configurable or provider-fixed?
- Are raw records retained shorter than aggregate statistics?
- How would we action a deletion request against a log containing a visitor’s IP address?
The anchor is simple: GDPR Article 5(1)(e) requires personal data to be kept in identifiable form no longer than necessary for its purpose. The work is proving “necessary” with a documented policy.
Reconciling privacy with traceable changes
You want entries you can audit — who created one, who changed the destination, when, and why — because that evidence trail is what compliance audits look at (see how entry management supports compliance audits). But a change log is itself a record of people: editors are natural persons, and their usernames, timestamps, and IP addresses are personal data too.
The reconciliation is purpose separation. Request logs serve statistics and operations: minimize, retain briefly, keep the privacy surface small. Change logs serve governance: retain as long as audit obligations require, restrict who reads them, and explain why retention differs. When a landing page changes mid-campaign, the traceable change record explains what happened — our article on a changed landing page destination covers the operational side — while the request log answers whether anyone was personally tracked.
Practical limits worth stating plainly
- Retention is a trade, not a free win: keep raw logs three months and your six-month-old statistics can no longer be re-derived at the request level. Choose consciously and document it.
- If your team consolidates or decommissions subdomains — as in an acquisition — retention policy is part of the handover; decide before deleting entries, not after (our acquisition consolidation playbook treats entry data as an asset with a lifecycle).
Decision Framework
A working framework for your next privacy review of link tracking logs:
- Inventory. List every field the layer records, from the product’s own documentation — status, access statistics, logs, and traceable changes imply different data. Verify, don’t infer.
- Classify. Mark each field as personal data in your context. When in doubt, assume it is.
- Purpose. Name the purpose of each field: operation, statistics, security, or audit.
- Retain. Set retention per purpose; store the policy where an auditor can find it.
- Restrict. Who reads request logs versus change logs? Sensitivity differs.
- Respond. Document how a deletion request would work against a log containing an IP address.
- Review. Revisit yearly, or when entries change meaning: new campaigns, acquisitions, new markets.
The practical limit: you cannot set retention you do not control. If the product fixes retention, your answer to “how long do we keep them” is whatever the provider’s setting is — worth knowing, because it is also the answer a regulator gets.
Key Takeaways
- A forwarded request is five fields of data — timestamp, entry identifier, IP address, user agent, referrer — and the click count is derived from those records.
- IP addresses are often personal data, and nearly every field becomes identifying in combination; “we only count clicks” does not survive a privacy question.
- Traceable changes and request logs serve different purposes and deserve different retention, access, and sensitivity treatments.
- Your team should be able to answer the retention questions above out loud and act on a deletion request — that is what a review will test.
FAQ
Q: Is an IP address in a link tracking log personal data?
A: Often, yes. GDPR Recital 26 lists IP addresses as online identifiers, and identifiability is judged by the means reasonably likely to be used — exactly the situation in a log pairing an IP with a timestamp, user agent, and referrer. Whether any given IP identifies a person depends on context, so classification is a per-setup decision, not a universal yes or no.
Q: If we “only count clicks,” do we store anything about visitors?
A: The count is an aggregate of request records — to produce it, the individual requests had to be recorded. “Only counting” describes the dashboard, not the data; the raw log, its retention, and its access are the real questions.
Q: How long should we keep link tracking logs?
A: Only as long as a documented purpose requires — that is the storage-limitation principle in GDPR Article 5(1)(e), with no universal number. A defensible pattern: short retention for raw request logs, longer for aggregate statistics, retention tied to audit obligations for change logs. Document the choice and be able to act on a deletion request.
Q: What is the difference between access statistics and logs for privacy purposes?
A: Statistics are aggregated — entry-level counts and trends — and rarely identify individuals; logs are the individual request records behind those numbers. Aggregates age well and can be kept longer; raw logs are the personal-data surface, with shorter retention and tighter access.
Sources
- RFC 9110: HTTP Semantics — User-Agent and Referer header semantics — https://www.rfc-editor.org/rfc/rfc9110
- MDN Web Docs: Redirections in HTTP — https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
- GDPR Article 5: Principles relating to processing of personal data (storage limitation) — https://gdpr-info.eu/art-5-gdpr/
- GDPR Recital 26: Notion of personal data (online identifiers, including IP addresses) — https://gdpr-info.eu/recitals/no-26/
- Google Analytics Help: Data retention — https://support.google.com/analytics/answer/10917952