First-Party Link Tracking: What It Is and Why It Matters After iOS 17

Safari ITP and iOS 17 link-tracking protection now block or degrade attribution on roughly 27% of all web traffic — the share that flows through Apple's browser across iPhone, iPad, and Mac. Third-party cookies are dead in most browsers; iOS 17's link-tracking protection strips tracking parameters from URLs in Messages, Mail, and Safari private browsing. If your tracking depends on a vendor script setting a cookie on someone else's domain, you are losing 25–55% of attribution depending on the channel. First-party link tracking is the only attribution method that still works on Safari, iOS 17+, Firefox with ETP, and Brave. This guide explains what first-party tracking is, what iOS actually broke, and how to implement it.

Why This Matters for Your Revenue

Losing 27% of traffic to attribution blindness is not an even, harmless tax — it falls hardest on the channels you can least afford to misjudge. Apple-device users skew toward higher income and, in many SaaS categories, higher lifetime value; they also cluster in exactly the channels that depend on Apple's apps — email opened in Apple Mail, links shared in iMessage, articles read in Safari. So third-party tracking systematically undervalues the channels reaching your best customers, because a disproportionate share of their clicks simply never get credited.

The downstream decision is the dangerous part. A newsletter whose audience is 45% Safari can show only half its real conversions, look unprofitable, and get cut — defunding the exact channel that was quietly producing your highest-LTV signups. First-party tracking closes that gap, recovering attribution to within a few percent of reality so budget decisions reflect the revenue a channel actually drives, not just the slice that survived ITP. For the broader numbers, see our attribution benchmarks, and for the Stripe side of the join, our guide to attributing Stripe revenue to channels.

What first-party tracking means

First-party tracking means the cookie tracking a visitor's journey is set by your own domain — not by a third-party script from an analytics vendor or ad network.

If your site is yourbrand.com and the cookie is set on .yourbrand.com, that's first-party. If the cookie is set on bit.ly or google-analytics.com or any vendor domain, that's third-party. Browsers treat these radically differently.

First-party cookies are the basis of how the web works — they remember your login, your cart, your language preference. Browsers cannot kill them without breaking every site. Third-party cookies are the basis of cross-site ad tracking — and browsers have been killing them off for the better part of a decade.

What Safari ITP and iOS 17 actually broke

Apple's privacy timeline matters because each step changed what marketers could and could not track.

The ITP and iOS milestones that matter

Five releases reshaped what attribution can rely on. Each one closed off a tactic that vendors were still selling at the time.

• ITP 1.0 (2017) — third-party cookies expire after 24 hours of no interaction with the originating site.
• ITP 2.0 (2018) — third-party cookies blocked entirely for cross-site tracking.
• ITP 2.3 (2019) — first-party cookies set by JavaScript capped at 7 days. Cookies set by HTTP Set-Cookie header still persist.
• iOS 14 (2020) — App Tracking Transparency. IDFA blocked unless user opts in.
• iOS 17 (2023) — link-tracking protection. URL parameters used to identify users (gclid, fbclid, etc.) are stripped when a URL is pasted into Messages, Mail, or Safari private browsing.

What ITP did to third-party cookies

The arc from ITP 1.0 to 2.3 was a steady tightening: first a 24-hour expiry on dormant third-party cookies, then an outright block on cross-site ones, and finally a 7-day cap on first-party cookies set by JavaScript. That last step is the one most teams miss — even a cookie on your own domain only survives a week if your JavaScript wrote it. The escape hatch is the HTTP Set-Cookie header: cookies issued by your server in the response, rather than by a script in the browser, are not capped and persist for the full attribution window.

What iOS 17 link-tracking protection actually strips

iOS 17 targets known tracking parameters — gclid, fbclid, and a maintained list of others — and removes them when a link is opened from Messages, Mail, or Safari private browsing. Your own utm_* parameters are not on Apple's strip list today, but relying on that is fragile: the list grows, and any identifier appended to a third-party domain is exposed. The durable answer is to redirect the click through a domain you own and log it server-side before any stripping can apply, so the identity is captured the instant the click happens.

iOS 17 broke the assumption that has held since the dawn of paid traffic: that an ad click and a landing visit will agree on who the visitor is. With link-tracking protection, the parameters that ad platforms use to identify the click are removed before the visitor lands on your site. Third-party pixel tracking on Apple devices loses meaningful attribution data.

First-party tracking sidesteps this entirely. When a visitor clicks your branded short link, the click goes through your domain. The cookie is set by your server's HTTP response, on a path your own JavaScript controls. Nothing for Safari to strip.

Browser support — what tracks where

The split between browsers determines what you can and cannot rely on. Below is the current market share by traffic, paired with each browser's tracking posture.

How first-party tracking works technically

Three architectural choices distinguish first-party from third-party tracking.

Your domain sets the cookie. The click goes through a redirect on a domain you own — go.yourbrand.com/promo, not bit.ly/promo. The redirect endpoint reads the URL, logs the click server-side, and issues a Set-Cookie header for .yourbrand.com before redirecting the visitor to the destination.

The cookie lives on your apex. Setting the cookie on .yourbrand.com (with the leading dot) makes it readable by every subdomain — your marketing site, your app, your checkout. The visitor moves between subdomains and the cookie follows; this is what makes first-party tracking survive cross-subdomain checkout flows.

The redirect runs server-side. Client-side redirects (a JavaScript window.location hack) lose data because Safari can strip parameters from the URL before the script runs. Server-side redirects capture the parameters before the browser does anything.

Why client-side redirects fail under ITP

A window.location redirect runs after the browser has parsed the URL — which gives Safari and any browser extension a window to strip tracking parameters before your script ever reads them. A server-side 302 captures the parameters in the same HTTP request that issued the redirect, so there is no in-browser execution window to interfere with. This is why production first-party tracking is always a server-side redirect, not a JavaScript bounce.

Why the cookie has to live on your apex

Setting the cookie on .yourbrand.com rather than on a single subdomain is what lets attribution survive the journey from marketing site to app to checkout. A buyer who clicks a link on www.yourbrand.com, signs up at app.yourbrand.com, and pays at checkout.yourbrand.com stays a single identifiable visitor because every subdomain can read the apex cookie. Scope it to one subdomain and the identity resets at each hop — and the click that started the journey is lost by the time the charge lands.

Why server-set beats script-set on Safari

Two cookies on your own domain are not equal. A cookie written by JavaScript is capped at 7 days under ITP 2.3 — shorter than most SaaS decision windows — so by the time a considered buyer converts, the click is gone. A cookie issued by your server in the redirect response carries no such cap and lives for the full window you set. The practical rule: never depend on a JavaScript-set cookie for attribution that has to survive longer than a week. For the full trade-off, see server-side click tracking vs client-side pixels.

First-party tracking vs server-side tracking — the difference

First-party tracking refers to whose domain sets the cookie. Server-side tracking refers to which side — browser or server — records the event. The two are not the same thing, but they pair naturally.

First-party + server-side is the strongest combination: the cookie is yours, the event is logged before the browser can interfere. First-party + client-side (a JavaScript pixel on your own domain) is acceptable but loses data to ad-blockers. Third-party + anything is increasingly broken.

For a full technical breakdown, see the related post on server-side click tracking vs client-side pixels.

What you lose without first-party tracking

Based on attribution data across TrackRev workspaces, channels that skew heavily toward Apple devices lose 30–55% of attribution accuracy with third-party tracking. Below are conservative estimates of the loss, by channel.

Attribution loss by channel and Apple device share

The channels with the highest Apple-device concentration are the same channels that tend to produce the highest-LTV customers — email, social, and QR/direct. Third-party tracking systematically undervalues exactly the sources you can least afford to misjudge.

How to implement first-party tracking

Three concrete steps move you from third-party to first-party.

Step 1 — Use a branded short domain you own. Set up go.yourbrand.com (or any subdomain you control) and point it at your tracking tool. The redirects then run from a domain that belongs to you, not from bit.ly's apex.

Step 2 — Install a first-party pixel. One script tag in your site's layout. It should read the click context from the URL or cookie and bind it to the visitor's session on your domain. No third-party domains involved.

Step 3 — Ensure the redirect runs server-side. The redirect endpoint should issue an HTTP 301 or 302, with the cookie set via Set-Cookie header in the response. JavaScript redirects fail under ITP and ad-blockers.

How to verify the setup actually works

Open a fresh Safari Private Browsing window — the strictest environment your visitors will hit. Click your branded short link, confirm a cookie appears on .yourbrand.com with the expected attribution values, close the browser, reopen, and check whether the cookie survived. If it did, your server-set cookie is passing ITP. If it didn't, your pixel is setting the cookie via JavaScript and you need to move it to the redirect response header. Run this test on every new tracking domain and after every pixel update; a silent regression here bleeds attribution for weeks before anyone notices.

DNS and certificate setup for the branded subdomain

Point a CNAME from go.yourbrand.com at your tracking provider and issue a TLS certificate covering the subdomain (most providers handle this automatically once the CNAME is verified). Keep the redirect endpoint on the same apex as your marketing site so the cookie scope includes both — the moment you split tracking onto a separate apex, you've recreated the third-party problem you were trying to escape.

TrackRev and first-party tracking

TrackRev is first-party by design. Every branded short link redirects through your own domain. The attribution pixel sets cookies on your apex via server response headers, not via JavaScript — which means the cookie lives for the full attribution window, even on Safari with ITP active. Click logging happens server-side at the redirect step, so ad-blockers can't intercept it.

If you're choosing between approaches, the related post on server-side vs client-side tracking explains why the strongest setups pair both. For broader attribution model questions, see last-touch vs first-touch vs linear. TrackRev's free tier covers 1,000 events a month; the paid tier removes the cap.

External references: Apple WebKit ITP 2.3 announcement; Google Privacy Sandbox for the Chrome side of third-party deprecation; Statista digital ad spend for the scale of what's at stake.