iOS & Safari link tracking protection: what changed and what to do

Apple has spent years systematically dismantling the mechanisms ad attribution was built on: Safari caps the lifetime of the cookies pixels depend on, recent iOS versions strip click IDs like fbclid and gclid from links in certain contexts, and App Tracking Transparency removed the device identifier for most in-app measurement. None of this stops people buying from your ads. It stops the platforms from finding out. This post explains each mechanism, what it concretely does to your attribution and match quality, and the playbook that still works.

The timeline, conceptually

The exact version numbers matter less than the direction, which has been one-way for years. Three families of changes:

1. ITP: cookie and storage lifetime caps

Safari's Intelligent Tracking Prevention started by blocking third-party cookies and then went after first-party workarounds. The rule that hurts advertisers most: cookies set via JavaScript (which is how _fbp and _fbc are written) live at most seven days. Arrive on a URL carrying known ad decoration (an fbclid, a gclid) and the cap on that page's script-written cookies drops to 24 hours in many configurations. Later iterations extended similar caps to other script-writable storage, and countermeasures like CNAME-cloaking detection closed the popular loopholes as they appeared.

Practical effect: any customer whose consideration takes longer than a week returns to the site as a stranger, and high-ticket buyers are precisely the customers who take that long. The purchase happens; the cookie linking it to the ad died days earlier.

2. Link tracking protection: click IDs stripped in transit

More recent iOS and Safari versions go a step further: in Private Browsing, and for links opened from Mail and Messages, known click identifiers are removed from the URL itself before the page ever loads. The parameter never reaches your landing page, so there is nothing to capture, first-party or otherwise:

# The link the user tapped (in Mail / Messages / Private Browsing)
https://shop.example/spring-sale
    ?utm_source=facebook&utm_campaign=spring
    &fbclid=IwAR2xYzAbCdEfGh...

# What arrives at your landing page
https://shop.example/spring-sale
    ?utm_source=facebook&utm_campaign=spring

Two things worth noticing. First, the stripping is targeted: identifiers that single out a click (fbclid, gclid, ttclidand friends) are on the list, while campaign-level UTM parameters have generally been left intact, so aggregate attribution survives even though per-click attribution is gone. Second, the scope matters: normal Safari browsing from an in-feed ad click still delivers the click ID today. The loss is concentrated in email flows, link sharing and privacy-conscious users, which adds up to a meaningful slice of traffic rather than the whole pie. Google's iOS-specific alternatives to gclid (the gbraid/wbraid parameters) exist precisely because of this environment.

3. ATT: consent for the app-side identifier

App Tracking Transparency made the in-app advertising identifier opt-in, and most users decline. That gutted deterministic measurement inside the Meta and TikTok apps, which is where your ads are actually clicked, and pushed the platforms toward modeled conversions and toward leaning much harder on whatever signals advertisers can still supply from their own infrastructure. ATT is why the quality of your server-side data started mattering so much more.

What this does to attribution and EMQ

The compounding effect is the dangerous part. A missing fbc costs more than one attribution. It lowers the match rate of the event, which shrinks the pool of conversions the delivery algorithm learns from, which biases optimization away from Apple-device buyers entirely. That spiral is signal lossdoing its quiet work, and we've unpacked the downstream damage in What is signal loss?

The mitigation playbook

You cannot patch Safari, and trying to trick it is a losing arms race. What works is reducing your dependence on the things Apple keeps breaking: short-lived cookies and URL parameters.

1. Capture click data first-party, immediately. The moment the landing page loads, persist whatever arrived (fbclid, gclid, ttclid, UTMs, referrer) into your own storage, keyed to a durable visitor identity on your infrastructure. A click ID stored in your database has no expiry date; a click ID in a script-written cookie has seven days at best.
2. Deliver conversions server-side. When the order lands, whether on day 1 or day 30, rebuild the event with the stored click ID and send it via the Conversions API rather than hoping a browser cookie survived. This is the core of server-side tracking, and it directly neutralizes mechanism #1.
3. Lean on hashed identifiers where click IDs are gone. For traffic where link tracking protection stripped the click ID before you could capture it, matching falls back to who the person is: normalized, SHA-256-hashed email and phone from the order, a stable external_id. These fields don't recover the click, but they let Meta match the conversion to an account, which keeps optimization and audiences fed.
4. Serve tracking from a first-party domain.A tracking script loaded from your own subdomain (with proper DNS and SSL, not a disguised third party) is far less likely to be blocked by content blockers, and the data it collects is first-party by construction. Be honest about the limits: this helps against blocklists but does nothing against ITP's storage caps, which apply to your first-party scripts too. That is why step 1 moves the data off the device entirely.
5. Keep UTM hygiene. Since UTMs have generally survived where click IDs are stripped, disciplined utm_source/utm_campaignnaming is your fallback attribution layer. It won't feed a bidding algorithm, but it keeps your own reporting truthful when the click ID is gone.

Before and after, in storage terms

// Before: everything lives in script-written cookies on the device
document.cookie  // _fbc=fb.1.1777885951000.IwAR2xYz...  (max 7 days)
                 // _fbp=fb.1.1777885951000.1019141      (max 7 days)

// After: the device holds only a pointer; the substance lives server-side
document.cookie  // sig_vid=v_7f3a9c  (first-party visitor ID)

// Server-side record for v_7f3a9c, written at landing:
{
  "visitor_id": "v_7f3a9c",
  "first_seen": "2026-05-04T09:12:31Z",
  "click_ids": { "fbclid": "IwAR2xYz..." },
  "utm": { "source": "facebook", "campaign": "spring" },
  "landing_url": "https://shop.example/spring-sale"
}

// 19 days later the visitor orders. The browser cookie for _fbc is long
// dead; the server rebuilds it from the stored fbclid and sends via CAPI:
"user_data": {
  "fbc": "fb.1.1777885951000.IwAR2xYz...",
  "em":  ["a8f5f167f44f4964e6c998dee827110c..."],
  "external_id": ["9b74c9897bac770ffc029102a2..."]
}

That is the entire trick, and it is architectural rather than clever: move identity and click data off the device on first contact, match the conversion to it server-side, deliver the event with a deterministic event_id so it deduplicates against whatever the pixel still managed to report.

What to do this week

• Segment your conversion reporting by OS and browser. If iOS/Safari conversions are visibly underreported relative to their traffic share, you now know why, and roughly how much it is costing you.
• Check what share of your Meta events carry fbc, and your EMQ per event, in Events Manager. Low fbc coverage on ad-driven traffic is the link-protection signature.
• Get first-party capture and server-side delivery in place. Build it around the CAPI (our setup guide covers the payload rules), or let RoasProof handle the whole chain: capture, identity, rebuilt click IDs and delivery to Meta, with flat pricing and a 14-day trial to measure the difference on your own traffic.

Apple's trajectory has been consistent for the better part of a decade, and there is no reason to expect it to reverse. Teams that moved their measurement first-party and server-side largely stopped caring which parameter the next OS release strips. That is the position worth being in.