iOS 27 Link Tracking Protection and Click IDs: Will iOS 27 Impact Your Attribution?

Short answer: not in the way most headlines suggest. iOS 27 (released 14 September 2026) did not switch on click-ID stripping for everyday Safari browsing. What it did do, according to independent code reviews, is quietly widen what gets stripped and which scripts get restricted. If you run paid campaigns on X, YouTube or Threads, use a CDP like Segment or Tealium, or rely on the LinkedIn Insight Tag, you have more exposure than you did in iOS 26.

Most coverage treats this as a landing-page problem. This piece looks at it the way a mobile engineer would: where the click ID sits in the URL, which layer of Safari touches it, how to catch it happening on a real device, and what changes when the link opens an app instead of a web page.

TL;DR

• Apple's docs: Safari 27 release notes list no Link Tracking Protection (LTP) change. Default stripping still covers Messages, Mail and Private Browsing only.
• Normal Safari tabs: gclid, fbclid and friends still arrive unless the user opts into "All Browsing" protection.
• Under the hood (vendor-reported): X, YouTube and Threads params added to the strip list; LinkedIn Insight Tag, Segment and Tealium flagged as fingerprinting; some blocking moved to the network layer.
• The real shift: Apple's rule lists reportedly update without a Safari release, so silence in the release notes proves nothing.
• The fix: stop letting attribution depend on the URL. Own your link IDs, read click IDs first-party, and deliver conversions server-to-server.

Which Safari features affect click IDs?

"Link Tracking Protection" gets blamed for everything, but Safari hits attribution at four different layers. Knowing which one is biting tells you which fix to use.

A lot of the panic traces back to iOS 26. Apple's WWDC25 messaging about fingerprinting protection "in all browsing" was widely read as "gclid is gone everywhere". Several agencies published exactly that. But the shipped Safari 26 release notes only listed fingerprinting protection for known tracking scripts, and independent testers (TAGGRS, Billy Grace, BBCCSS) found click IDs still passing through in normal tabs. A Link Tracking Protection entry seen during the beta reportedly didn't make the final build.

iOS 27 follows the same pattern: nothing in Apple's announcement or the Safari 27 release notes about query parameters. The Safari headline features were things like tab organisation, page-change alerts and a Safari MCP server for coding agents.

Where do click IDs actually get stripped today?

Two details from WebKit's own write-up are worth knowing:

1. 1Only query parameters and the URL fragment are in scope. The path is not. Stripping happens before navigation, so the value never reaches your server.
2. 2Campaign-level params are allowed through. WebKit's rule targets parameters used to track individual users or clicks. UTM tags are the same for every visitor in a campaign, so they're kept. Every serious test so far agrees.

There's also a second, quieter effect in Private Browsing: after a cross-site click, third-party scripts that read location.href or document.URL get the URL with no query string at all, and document.referrer is hidden from them. So even parameters that survive can be invisible to vendor tags.

What did vendors find in the Safari 27 code?

Apple doesn't publish its strip list, so the best evidence comes from people reading WebKit's open-source code and testing betas. Two server-side tagging vendors, TAGGRS and Stape, published independent reviews in July 2026. Treat these as strong leads, not specs.

1. More click IDs on the strip list

Added in the Safari 27 cycle:

Google (gclid), Meta (fbclid) and Microsoft (msclkid) were already covered. Stape says its own testing confirmed twclid being stripped in Private mode. Note that si isn't a paid-click ID; it's a share identifier on YouTube links, so its removal mostly hits organic share attribution.

2. More scripts classified as "fingerprinting"

Reportedly now on the AFP list: the LinkedIn Insight Tag, Segment, Tealium, DPG Media and Blueconic. AFP isn't a simple block. Apple can revoke specific permissions per script: reading query params, reading the referrer, cookies, localStorage, canvas, screen metrics and so on.

The CDP piece is the sneaky one. If Segment or Tealium is restricted, every tag that fires through it inherits the same restrictions. Your Google Ads tag might be fine on its own, and still lose the click ID because of how it's deployed.

3. Blocking at the network layer

TAGGRS reports that Safari 27 can now check the destination IP of outgoing connections against known ad-network ranges (Bing UET was their example). If that holds up, the usual tricks, like serving scripts from a first-party subdomain or renaming files, stop working, because the data still has to travel to the ad platform's servers. This is not in Apple's release notes, so file it under "watch closely".

4. Rules that update without a browser release

Both reviews point to the same finding: the lists of stripped params, flagged scripts and blocked ranges live in a separate system library. Apple can push new rules silently. That's the real story of iOS 27. You can't rely on release notes to tell you when your attribution breaks.

What does iOS 27 mean for deep links and apps?

Almost every write-up on this topic is about landing pages. But a big share of iOS clicks don't end in a web page. They open an app through a Universal Link, or hit an App Store redirect for a deferred deep link. A few things to think through:

Links shared in Messages and Mail. Apple says LTP removes tracking info from the shared link itself. So if someone texts a friend your Universal Link with an fbclid on it, expect the app (or the web fallback) to receive the cleaned URL. Referral and share-attribution flows that depend on a known click param in the query string are exposed. Test it on a real device.

In-app browsers. Instagram, Facebook, TikTok and LinkedIn open links in their own web views, not Safari. Apple's LTP docs don't describe it running there, and the Safari "All Browsing" setting is a Safari setting. Today, that means ad clicks inside those apps are probably less affected than Safari clicks. "Probably" is doing work in that sentence, so verify.

Put identifiers where LTP doesn't look. WebKit scopes LTP to query parameters and fragments. A link that carries its own first-party ID in the path (for example go.yourbrand.com/c/abc123) and resolves it on your own server keeps your link-level and campaign-level data intact regardless of what's appended to the query. This isn't a way to smuggle user-level IDs past Apple, and you shouldn't try: renaming gclid to dodge the list is fragile and against the spirit of the feature. It's about not letting your own campaign data ride on parameters that were never meant to survive.

Apple's own attribution rails. AdAttributionKit (and Web AdAttributionKit, formerly Private Click Measurement) is Apple's answer to lost click IDs. WWDC26 brought no significant AdAttributionKit or SKAN changes, per Adjust — our SKAdNetwork 5 guide covers the current rules — so whatever you've built there carries over into iOS 27 unchanged.

How do you see it happen on a real device?

Reports and parameter lists go stale. The faster route is to watch Safari do it.

On the web

• Plug the iPhone into a Mac, turn on Web Inspector (Settings › Apps › Safari › Advanced), and inspect your landing page from Safari's Develop menu.
• In the console, check location.search. Then look at the network request your ad tag actually sends. ID in the console but not in the request → AFP. ID in neither → LTP.
• Watch for "Blocked connection to known tracker" console messages. WebKit logs these when it blocks a tracker request.
• Log the raw request line at your edge (CDN logs, a Cloudflare Worker) so you have ground truth that no script can interfere with.

In the app

• Log the full incoming URL in your Universal Link handler (application(_:continue:restorationHandler:), SwiftUI onOpenURL, or the React Native Linking listener).
• Send the same tagged link to yourself through Messages, Mail, Notes and WhatsApp. Tap it from each and diff the logged URLs.
• Repeat with the app deleted, so you see what the web fallback and your deferred deep link flow receive.

Keep a survival matrix: one row per context, one column per parameter. Re-run it after every iOS point release, because the rules can change without one.

How do you build attribution that doesn't depend on the URL?

Think of the fix in four layers, mirroring Safari's.

1. Link layer: own your identifiers. Route paid and shared links through a domain you control. Keep campaign, creative and link IDs in the path or in campaign-level params, resolve them server-side, and log the click before redirecting. Platform click IDs become a bonus, not the backbone.

2. Collection layer: read with your own code. AFP restricts flagged third-party scripts, not first-party code. Read whatever click IDs did arrive (gclid, gbraid, wbraid, fbclid, msclkid, twclid, ttclid) on your server or in your own JS and attach them to the session and the CRM record. In apps, persist them from the deep link handler rather than a web SDK.

3. Delivery layer: go server-to-server. Browser calls to endpoints like bat.bing.com and snap.licdn.com are the ones reportedly being cut. Use Google enhanced conversions or offline uploads, Meta Conversions API, LinkedIn Conversions API and Microsoft offline conversions. Google explicitly recommends sending conversions even with no gclid, using consented user-provided data. If your CDP is on the fingerprinting list, switch to its server-side destinations.

4. Feedback layer: watch the platforms' match scores. Meta's Event Match Quality and Google Ads' enhanced conversions diagnostics show how well your server events match real users. A drop right after an iOS update is your earliest warning. Back it up with periodic geo or holdout tests, the kind our incrementality guide walks through, so click-level data isn't your only source of truth.

Which channels are most exposed?

A rough read of the reported changes by channel. This is judgement, not a measured number.

Where does LinkTrail fit?

LinkTrail links are built the way the link layer above recommends. A link's identity is its slug, in the path of a URL on your own domain, and its destination and custom data are configured on the link rather than carried in the query string — so nothing LinkTrail depends on sits where Link Tracking Protection looks. The click is recorded when the link resolves, before any redirect.

The deferred path doesn't ride on URL parameters either. On iOS, deferred attribution recovers a click token through a paste control; on Android it uses the Google Play Install Referrer; and the SDK never reads the IDFA. How each match is made, and what it records, is on our methodology page.

FAQ

Is renaming gclid to a custom parameter a good workaround?

Maybe short-term, not long-term. Apple targets per-click identifiers and can update its lists silently. A renamed click ID is still a click ID. Build on first-party link IDs and server-side conversions instead.

Does this affect Android?

No. LTP is an Apple feature, so Android App Links and Chrome on Android pass parameters as normal.

Why is my iOS email traffic showing up as "direct" or unattributed?

Mail is a default LTP context, so click-level parameters in email links can be removed. UTMs survive, so make sure every email link carries them.

How will I know if Apple changes the rules again?

Probably not from release notes. Re-run your survival matrix after each iOS point release and watch your platforms' match-quality scores.

Does iCloud Private Relay strip click IDs?

No. Private Relay hides the user's IP address; it doesn't rewrite URLs. It does weaken IP-based matching, which is one more reason to send consented first-party data server-side.

Sources

• Safari 27 Release Notes – Apple Developer
• WebKit Features for Safari 27.0 – WebKit
• Private Browsing 2.0 – WebKit
• WebKit Features in Safari 26.0 – WebKit
• Safari 27 tracking protection – TAGGRS
• Safari 27 update beta – Stape
• Safari 26 tracking changes explained – TAGGRS
• Safari 26 will not automatically remove gclid or fbclid – BBCCSS
• Safari on macOS & iOS 26 tracking changes – Billy Grace
• WWDC26 for mobile marketers – Adjust
• Upload offline conversions – Google Ads API