Email link tracking: privacy, UTMs, and GDPR

Email link tracking is not one technology. A direct link, a campaign-level UTM parameter, a unique recipient redirect, and a password-reset link may all appear blue and clickable in an inbox, but they collect different data and serve different purposes. Treating them as interchangeable produces weak privacy advice and brittle implementations.

The practical rule is to use the least identifying link that can do the job. Prefer direct links or shared campaign parameters for aggregate attribution. Reserve unique tokens for a necessary individualized function, separate authentication from analytics, and review the redirect, landing page, logs, cookies, vendors, retention, and downstream joins as one data path.

Five link designs that should not be confused

1. DIRECT DESTINATION
https://example.com/guide
  no email attribution in the URL

2. SHARED CAMPAIGN PARAMETERS
https://example.com/guide?utm_source=newsletter&utm_campaign=august
  same values for everyone in the campaign

3. UNIQUE ANALYTICS REDIRECT
https://click.example/r/K7p9Q...
  token resolves recipient + message + destination, then redirects

4. STABLE ID IN DESTINATION URL
https://example.com/guide?customer_id=12345
  identity can propagate through logs, analytics, history, and sharing

5. SIGNED ACTION LINK
https://accounts.example/action?token=<high-entropy-secret>
  authorizes a specific function; it is a credential, not an analytics tag

The first two designs can answer campaign-level questions without intentionally identifying which recipient clicked. The third deliberately creates an individual event. The fourth exposes a reusable identifier in a location that many systems record. The fifth may be necessary for account recovery, verification, invitations, or unsubscribing, but needs security controls that marketing redirectors do not provide.

What a tracked click actually does

EMAIL CLIENT
  requests https://click.example/r/K7p9Q
       ↓
EDGE / CDN / WAF
  may log time, IP address, user agent, path, and token
       ↓
REDIRECT APPLICATION
  looks up token → recipient, message, campaign, destination
  records a click-like request
  returns 302 or 303 Location: https://example.com/guide?...
       ↓
LANDING PAGE
  receives query values and request metadata
  may read or write cookies, local storage, and analytics IDs
       ↓
DOWNSTREAM SYSTEMS
  ESP, CRM, warehouse, ad platform, sales alerts, experimentation, support

A privacy review that stops at the ESP dashboard misses most of the system. Reverse proxies may retain the full token before the application runs. Landing-page analytics may capture the complete URL. A customer-data platform may join the event to purchases. A sales automation may trigger a message. Each recipient, purpose, field, recipient of the data, and retention period matters.

What the EDPB says about tracking links

The European Data Protection Board’s final Guidelines 2/2023 explain that tracking links can work like tracking pixels when an identifier unrelated to locating the requested resource is appended to the address. The Board says these links can be distributed through email and that both distributing the tracking information to terminal equipment and collecting the returned identifier fall within the technical scope of Article 5(3) of the ePrivacy Directive.

That guidance is about the Directive’s technical scope, not a universal verdict on every URL or purpose. Whether a use is permitted still requires a separate analysis of consent or an applicable exception, national implementation, and any GDPR processing. A plain destination path needed to locate content is not the same thing as appending an identifier for tracking.

Use a layered legal and technical review

LAYER 1 — THE MESSAGE
  Was the email itself permitted under the electronic-marketing rules?

LAYER 2 — TERMINAL EQUIPMENT
  Does link decoration or the landing flow store information on, or access
  information from, the device? Is consent required or does an exception fit?

LAYER 3 — PERSONAL DATA
  Can a token, IP address, account, cookie, or joined event identify or single
  out a person? Identify purpose, lawful basis, notice, recipients, and rights.

LAYER 4 — SECURITY
  Can the URL authorize an action, leak a credential, or become an open redirect?

LAYER 5 — EVIDENCE QUALITY
  Was the request made by a person, a security scanner, a preview service, or a bot?

Permission to send a message does not automatically authorize every tracker inside it. Conversely, removing tracking does not cure an unlawful message. Keep the send decision, storage-or-access analysis, personal-data processing, and security review separate so one convenient answer is not stretched across four different questions.

Are UTM parameters personal data?

There is no reliable yes-or-no answer based only on the utm_ prefix. Shared values such as utm_source=email, utm_medium=newsletter, and utm_campaign=summer-sale describe a traffic source. A value containing an email address, account number, stable customer hash, or tiny audience segment can identify or single out a person directly or when joined with other data.

SHARED CAMPAIGN CONTEXT
?utm_source=customer-newsletter
&utm_medium=email
&utm_campaign=product-launch-2026-08
&utm_content=primary-button

DO NOT PLACE IN ANALYTICS URLS
[email protected]
?customer_id=482019
?utm_content=alex-example-com
?user_hash=<stable-hash-of-email>
?segment=employees-facing-redundancy

A renamed or hashed identifier is still linkable. Hashing a predictable email
does not make it anonymous, and a sensitive segment can reveal more than a name.

• Use a documented, allowlisted vocabulary for source, medium, campaign, and content values.
• Make campaign parameters identical for everyone who receives the same creative and placement.
• Keep names, addresses, customer IDs, order numbers, health information, and internal segmentation out of URLs.
• Review whether a small or sensitive campaign name indirectly reveals information about a recipient.
• Prevent analytics and tag managers from copying full URLs into tools that do not need them.
• Set retention for campaign attribution and raw request logs instead of inheriting every vendor default.

Why identifiers in URLs leak farther than expected

URLs are copied and observed widely. They can enter browser history, email-client safety systems, DNS and network infrastructure, CDN and web-server logs, observability traces, analytics page-location fields, support tickets, screenshots, chat messages, bookmarks, and forwarded emails. If the recipient shares the link, another person may inherit both the identity and the apparent click history.

Referrer behavior deserves deliberate configuration. The modern strict-origin-when-cross-origin default generally limits a cross-origin referrer to its origin, but same-origin navigation can still include the path and query. Older or weaker policies can expose more. Set an explicit Referrer-Policy appropriate to the page, strip unnecessary parameters, and never rely on referrer behavior as the only protection for a secret token.

Referrer-Policy: no-referrer
Cache-Control: no-store
Content-Security-Policy: default-src 'self'; frame-ancestors 'none'

Use no-store for sensitive action pages, not automatically for every public page.
A campaign landing page may choose strict-origin instead of no-referrer when
legitimate origin-level referral data is necessary.

Unique redirect tokens create person-level events

A common ESP replaces each destination with a unique tracking-domain URL. When requested, the service resolves the token, writes an event tied to a recipient and message, and redirects to the destination. The visible token may be random, but the lookup makes the event identifiable inside the system.

• Enable unique click tracking only for a defined purpose, audience, and retention period—not as an account-wide default no one owns.
• Do not append the recipient token to the final destination unless the individualized function requires it.
• Keep the token opaque, high entropy, scoped to one message and destination, and unavailable through predictable enumeration.
• Minimize IP address, user agent, geolocation, and device data; do not collect fields merely because the redirect request exposes them.
• Prevent raw click events from automatically becoming lead scores, ad audiences, or sales alerts without their own review.
• Provide truthful notices and consent or objection controls required by the applicable implementation and purpose.

Security scanners make click counts noisy

Corporate gateways and mailbox security products may request links before delivery, follow redirects, render a destination, or revisit it later. Preview services, accessibility tools, malware sandboxes, and automated browsers add more non-human traffic. A click can therefore occur before an open-like event, seconds after send, or from infrastructure far from the recipient.

RAW LINK REQUESTS
  every request observed by redirect infrastructure

SUSPECTED AUTOMATION
  classified using timing, repetition, network, headers, and known scanner signals

UNCLASSIFIED REQUESTS
  insufficient evidence to call human or automated

CONFIRMED FIRST-PARTY OUTCOMES
  authenticated or otherwise validated action in the product or checkout

Never rename “not recognized as a bot” to “human click.” Classification is
probabilistic, scanners change behavior, and real people may resemble automation.

• Do not treat a link request as proof that the recipient read, understood, or consented to anything.
• Do not trigger irreversible actions—purchase, deletion, acceptance, password change—on a GET request alone.
• Require an authenticated or explicit confirmation step for consequential actions.
• Report raw, suspected automated, unclassified, and confirmed outcome counts separately.
• Document classifier changes so a dashboard shift is not mistaken for a change in audience behavior.

Action links need a different architecture

Verification, password-reset, invitation, magic-login, and unsubscribe links may need a recipient-specific token to perform the requested function. That necessity does not turn the token into an analytics identifier. Treat it as a bearer credential: whoever possesses it may be able to perform the scoped action.

TOKEN          cryptographically random or properly signed; never predictable
SCOPE          one user, purpose, audience, and intended action
EXPIRY         short enough for the threat model and user workflow
REPLAY         one-time where practical; invalidate after successful use
DESTINATION    server-side route or allowlisted ID, never an arbitrary redirect URL
LOGGING        redact token from application, proxy, analytics, and error logs
RESPONSE       verify state, then require confirmation for consequential actions
REFERRER       no-referrer on sensitive pages
ANALYTICS      record a minimized outcome separately; do not reuse the secret as identity

Avoid open redirects. Do not accept a destination parameter and forward to any supplied URL. Map an allowlisted destination ID on the server or validate the scheme, host, and path against a strict allowlist. Otherwise a trusted email domain can become a phishing hop.

A privacy-preserving redirect architecture

EMAIL
+  direct URL shared by the campaign
+  coarse source + medium + campaign + placement
-  no recipient ID, address, stable hash, or unique redirect
       ↓
LANDING EDGE
+  collect only operational security logs
+  truncate or minimize addresses where appropriate
+  short raw-log retention and restricted access
       ↓
LANDING APPLICATION
+  allowlisted parameter values
+  optional 303 to a clean canonical URL after first-party attribution
+  explicit Referrer-Policy
-  no nonessential storage before the required choice or consent
       ↓
REPORT
+  aggregate visits and first-party outcomes by campaign
-  no recipient click timeline

A clean redirect after recording campaign context can reduce query-string propagation, but it is not retroactive anonymization. The first request still reached the edge and application, and any storage, logs, or joins at that step still count. Configure the whole path rather than relying on a clean address bar at the end.

Measure email without unique click tracking

Many important decisions do not require knowing that a particular recipient clicked. Shared campaign links can compare traffic sources. First-party product events can measure completion by an eligible experimental cohort. Replies, bookings, purchases, renewals, complaints, unsubscribes, and controlled holdouts often provide better evidence than an individual redirect request.

Audit your ESP and analytics stack

CONTROL        Can click tracking be disabled by stream, campaign, or message?
TOKEN          What does the redirect token resolve to, and is it appended onward?
REQUEST DATA   Are IP, user agent, location, and device data recorded?
SCANNERS       How are automated requests detected, labeled, and retained?
COOKIES        Does the landing or tracking domain set or read identifiers?
VENDORS        Which CDN, security, analytics, and subprocessors receive requests?
REUSE          Does the provider benchmark, enrich, advertise, or train on the data?
EXPORTS        Which CRM, warehouse, ad, and sales tools receive click events?
RETENTION      Can raw and person-level events be shortened or deleted?
RIGHTS         Can access, deletion, objection, and consent withdrawal propagate?
DOMAINS        Can you use an authenticated branded domain with secure TLS and DNS?
EVIDENCE       Can the provider document configuration, changes, and processing?

A migration plan for existing tracked links

• Inventory every rewrite rule, tracking domain, UTM template, action token, landing tag, data export, and retention setting.
• Classify each link as navigation, campaign attribution, person-level analytics, or necessary account action.
• Remove email addresses, stable hashes, customer IDs, order details, and sensitive segment names from URL templates.
• Replace unique marketing redirects with direct or shared campaign links where individual identity does not change a decision.
• Separate action-token services from analytics redirectors and redact secrets throughout the observability stack.
• Configure explicit referrer, cookie, consent, destination allowlist, bot-reporting, access, and deletion controls.
• Test forwarding, link scanning, expired tokens, replay, malformed destinations, consent states, and analytics leakage before rollout.
• Update notices, records, processor terms, retention schedules, and dashboards to match the deployed behavior.

Frequently asked questions

Is email click tracking GDPR compliant?

It can be, but not merely because the email was permitted or the identifier is opaque. Review ePrivacy or national storage-and-access rules, then any personal-data processing under the GDPR. Purpose, necessity, consent or another valid condition, transparency, minimization, security, vendors, retention, and rights all depend on the actual design.

Are UTM parameters GDPR compliant?

UTMs are a naming convention, not a compliance status. Shared campaign values can support lower-data aggregate attribution. Values that identify, single out, or reveal sensitive information about a person create greater risk, especially when joined with cookies, accounts, logs, or CRM data. Keep personal and stable identifiers out of URLs.

Is a hashed email address safe in a tracking URL?

No. A stable unsalted hash of a predictable email can be guessed, and any lookup token that your system can resolve remains linkable. Hashing may be one security control, but it does not make recipient-level tracking anonymous or stop the URL from being copied into logs and third-party systems.

Does clicking a link mean the user consented to tracking?

No. A click expresses an instruction to follow that link in context. It is not automatically specific, informed, unambiguous consent to additional profiling, advertising storage, cross-service joining, or unrelated reuse. Obtain any consent the applicable rule requires through a valid process and record what it covers.

Why does an email show clicks before it shows opens?

A security gateway or preview system may request the link while scanning the message, while images are blocked, proxied, cached, or fetched later. Neither sequence proves what a person did. Label automation probabilistically and rely on confirmed first-party outcomes for consequential decisions.

Can email links work without a tracking redirect?

Yes. Link directly to the destination. If aggregate attribution is necessary, use shared campaign parameters that do not identify the recipient. Individualized action links can also go directly to a secure first-party endpoint without passing through a marketing click tracker.