Safari 26 Strips Click IDs: WooCommerce Attribution Needs a Server-Side Net
Safari 26 and iOS 26 strip click IDs like gclid, fbclid and msclkid from links opened in Private Browsing, Mail and Messages, and turn Advanced Fingerprinting Protection on by default for all browsing. Full click-ID stripping in regular browsing is not the default yet, but Apple has signposted it. For WooCommerce stores, the fix is a server-side safety net that captures the click identifier the moment a visitor lands, so attribution survives whether or not the parameter makes it through the browser.
What actually changed in Safari 26
Two separate changes get blurred together — keeping them apart is the whole game.
The headlines said Safari killed click tracking. The reality is more specific, and the specifics decide what you actually need to fix. Safari 26 strips click IDs such as gclid, fbclid and msclkid from links opened in Private Browsing, Mail and Messages, according to Opensend — behaviour that has existed in some form since iOS 17, now reaffirmed.
The genuinely new default is different. iOS 26 and Safari 26 rolled out from September 15, 2025, turning Advanced Fingerprinting Protection on by default for all browsing, per WITHIN. That’s the part that’s new for everyone — and it matters because Advanced Fingerprinting Protection blocks scripts from reading navigational state such as URL query parameters and document.referrer. Translation: even where the parameter survives in the address bar, the script trying to read it can be starved of the surrounding signals attribution relies on.
Safari 26 strips click IDs like gclid, fbclid and msclkid from links opened in Private Browsing, Mail and Messages, while standard UTM parameters pass through untouched.
You may be interested in: The 70% problem: why your traffic hides in the GA4 direct bucket
What didn’t change — and what’s coming
The honest version is less dramatic than the headlines, and more useful.
Here’s the thing: at public release, Safari 26 did not start stripping click IDs in regular, non-private browsing by default. Link Tracking Protection is still not on by default in regular Safari browsing, though click IDs were already stripped in Safari Technology Preview tests, signalling likely expansion, per ppc.land. Hands-on testers confirmed click IDs still pass through in normal browsing at launch.
And standard UTM parameters are not stripped in any mode, because Apple treats them as campaign-level rather than user-level identifiers. So the loss is specific: click IDs in private contexts now, possibly everywhere later.
The question isn’t whether Safari broke attribution today. The question is whether you want your measurement sitting on a parameter that Apple has openly signposted it may remove from all browsing with little notice.
| Parameter / context | Private Browsing, Mail, Messages | Regular browsing (at release) |
|---|---|---|
| Click IDs (gclid, fbclid, msclkid) | Stripped | Pass through — for now |
| UTM parameters | Pass through | Pass through |
| Advanced Fingerprinting Protection | On | On by default (new) |
Why this hits WooCommerce attribution
The damage isn’t one big break — it’s a steady erosion you can’t see in the dashboard.
For a WooCommerce store running paid acquisition, the click ID is how a purchase gets credited back to the ad that drove it. When that ID vanishes for a slice of traffic, those conversions don’t disappear from your revenue — they disappear from your attribution, which is worse, because your ad platform optimises on what it can see.
It also doesn’t arrive alone. Around 31.5% of internet users run ad blockers, per Statista, erasing client-side tags before they fire. Stack ad blockers, Safari’s private-context stripping, and fingerprinting protection together, and a meaningful share of your paid clicks land with their attribution already degraded.
A server-side safety net captures the click identifier the moment a visitor lands, so WooCommerce attribution survives whether or not the parameter reaches the page.
You may be interested in: Self-hosted vs managed: which WooCommerce event pipeline fits your store
The server-side safety net
Catch the identifier at the moment of landing, before anything can strip it.
The durable fix doesn’t try to out-argue Apple. It captures the click identifier server-side the instant a visitor lands, while the parameter is still present, and stores it as a first-party value tied to the session. When the order completes, that stored identifier is sent to the ad platform from your own infrastructure — not scraped from a browser that may have stripped it.
This is why server-side is the answer to a moving target rather than to one specific Safari release. Whether Apple expands Link Tracking Protection to all browsing next year or not, an identifier captured at landing and forwarded from your server isn’t waiting on the browser’s permission. You stop reacting to each privacy update and start being insulated from the category of change.
For WooCommerce specifically, Transmute Engine™ captures the click identifier at landing and forwards conversion events server-side from your own WordPress infrastructure to your ad and analytics platforms. The aim isn’t a Safari workaround; it’s not depending on a URL parameter surviving the browser at all.
Key Takeaways
- What changed: Safari 26 strips click IDs in Private Browsing, Mail and Messages; UTMs are untouched.
- The new default: Advanced Fingerprinting Protection is now on for all browsing, blocking scripts from reading navigational state.
- What didn’t change yet: regular browsing still passes click IDs at release, but Apple has signposted expansion.
- The compounding loss: ad blockers (~31.5% of users) stack on top of Safari’s stripping.
- The fix: capture the click ID server-side at landing, so attribution survives regardless of browser behaviour.
Yes, but only in specific contexts. Safari 26 strips click IDs such as gclid, fbclid and msclkid from links opened in Private Browsing, Mail and Messages. At public release it did not strip them in regular (non-private) browsing by default. Standard UTM parameters are not stripped in any mode.
No, not by default at release. What became a default for everyone is Advanced Fingerprinting Protection, which blocks scripts from reading navigational state. Apple has signposted that Link Tracking Protection could expand to regular browsing, but it is not the release default.
Capture the click identifier the moment a visitor lands, on your own server, and store it as a first-party value tied to the session. When the order completes, send that stored identifier to your ad platform server-side. Because the capture happens at landing and the send happens from your infrastructure, it doesn’t depend on the parameter surviving the browser.
Yes. Apple treats UTM parameters as campaign-level rather than user-level identifiers, so utm_source, utm_medium and utm_campaign pass through untouched. The stripping targets click IDs that tie a visit back to an individual ad click.
References
- Opensend — iOS 26, Click IDs, and the new attribution squeeze (2025). opensend.com
- WITHIN — iOS 26 Link Tracking Protection Explained (2026). within.co
- ppc.land — Safari 26 tracking changes to impact marketing measurement (2025). ppc.land
- Statista — Ad blocking user penetration worldwide (2024). statista.com
If paid acquisition is part of your revenue, don’t let a browser update decide what you can measure — see how a server-side event pipeline captures the click ID at the source.