Most iOS 26 coverage tells you which parameters Safari currently strips. That is the wrong question. Apple maintains the stripped-parameter list server-side via the WebPrivacy service, which updates dynamically and is cached in WebKit (Blotout, 2026). Translation: any tracking parameter — gclid, fbclid, msclkid, or whatever clever backup name your team rolled out in 2026 — can be added to the strip list next Tuesday with zero iOS release notes. iOS 26 is not a finished event. It is a live service.

The Mechanism Most Coverage Missed

Apple shipped iOS 26 publicly on September 15, 2025, extending Link Tracking Protection beyond Private Browsing into all Safari sessions by default (Apple Newsroom). The initial wave of write-ups treated LTP like every previous Safari privacy change: a versioned rule set, baked into the OS, updated on point releases.

That model is wrong. The list of parameters Safari strips is delivered to devices through the WebPrivacy service — a server-managed blocklist that WebKit caches and refreshes on its own schedule (Blotout research, h/t Nejc Zdovc). Devices do not need an iOS update to pick up new entries. They need a network connection.

The blocklist is a service, not a setting. Apple updates it. You don’t get release notes.

That changes the threat model for every WooCommerce store running paid acquisition. Attribution is no longer a quarterly audit problem; it is a structural fragility. The parameter your Google Ads or Meta CAPI setup relies on today can be invalidated between Tuesdays.

What’s Currently Stripped (and What Isn’t)

The known stripped click IDs as of early 2026 include gclid, fbclid, msclkid, dclid, and twclid/ttclid, all removed from URLs before the page loads in affected contexts. Standard UTM parameters — utm_source, utm_medium, utm_campaign — remain unaffected, because WebKit classifies them as campaign metadata rather than user identifiers (WebKit Private Browsing 2.0 documentation).

Two details matter for the strategic picture. First, Safari accounts for approximately 24% of global browser traffic (Apple WebKit), so anything stripped on Safari knocks roughly a quarter of your paid acquisition signal out of attribution. Second, in Safari Technology Preview, gclid has already been observed being stripped in regular browsing — not just Private Browsing — ahead of any matching iOS public release (Billy Grace live testing). Technology Preview is the developer-channel signal of where the blocklist is heading.

For the deeper background on the click-ID strip behavior itself, see iOS 26 Is Stripping Your Google Ads Click IDs in Standard Browsing. This article extends that piece by explaining how Apple’s update mechanism actually works.

Why the Backup-Parameter Playbook Is a Bet

The 2025-2026 mitigation pattern that spread fastest in the WooCommerce community looks something like this: when a paid click hits your landing page, your tag manager rewrites the URL so that gclid=... is also mirrored as aclid=... (or acid=..., or some custom internal name). The theory: Apple stripped gclid by name, so a parameter Apple does not know about will pass through.

The theory holds — for now. There is no protocol-level reason it has to keep holding.

Every backup-parameter workaround is a bet that Apple’s next WebPrivacy push does not name your custom parameter.

Two architectural realities make this fragile. The WebPrivacy list is centrally managed, so adding a name takes Apple’s side roughly the effort of a config change — not an iOS release. And the list does not need to be public. Stores running an aclid mirror find out it stopped working when their conversion rate quietly drops, and an industry post explains why a week later.

This is the same pattern Safari has run before. Each iteration adds a constraint that the previous mitigation cannot solve. Server-Side GTM No Longer Beats Safari’s 7-Day Cookie Cap (Unless Your IP Address Matches) walks through the cookie-side version of exactly this dynamic.

The Only Structural Fix: Capture Before the URL Has to Survive

The fix does not live in the URL. It lives in your database.

The moment a visitor lands on your WooCommerce store with a click ID in the query string, that value should be captured server-side and persisted. Not into a browser cookie that Safari can later limit, and not into a JavaScript variable a tag manager later reads — into a session record that lives on your server, attached to the visitor’s identifier, and ultimately stamped onto the WooCommerce order as order meta when checkout completes.

Once the click ID is in the order record, no future Safari update can touch it. The parameter no longer needs to survive in a URL. It already lives in your database, ready to be sent to Google Ads via Enhanced Conversions, to Meta CAPI as a hashed identifier, or to BigQuery for offline analysis.

The question is not which backup parameter survives. The question is whether the click ID is in your database before Safari has a second chance at it.

The same principle applies to lead capture. Forms that record gclid as a hidden field at submission — captured server-side, written into the lead record before the URL is touched again — are the lead-gen equivalent of order meta capture. Walkthrough: How to Capture GCLID in WordPress Contact Forms for Google Ads Offline Tracking.

Where Transmute Engine™ Fits

Transmute Engine is a first-party Node.js server that runs on your subdomain (e.g., data.yourstore.com). The inPIPE WordPress plugin captures click IDs at the WooCommerce hook layer — the moment woocommerce_checkout_order_processed fires, the gclid, fbclid, and msclkid values that arrived with the visitor are pulled into the order record and sent via API to your Transmute Engine server. From there they fan out to Google Ads, Meta CAPI, BigQuery, and the rest. The values live in your store’s database before Safari has a chance to touch the URL again, which makes them immune to whatever the next WebPrivacy cloud push decides to name.

Key Takeaways

• Apple’s blocklist is cloud-managed. The WebPrivacy service updates the strip list dynamically and caches it in WebKit. No iOS release notes are required for new entries to take effect.
• The current list (early 2026): gclid, fbclid, msclkid, dclid, twclid/ttclid stripped; UTM parameters preserved. Safari Technology Preview already shows expansion ahead of public iOS releases.
• Safari is roughly 24% of global browser traffic (Apple WebKit). Anything Apple strips invalidates that share of your paid attribution signal.
• Backup parameters (aclid, acid, custom names) work only until Apple names them. No protocol-level guarantee makes them safe long-term.
• Server-side click-ID capture is the only structural mitigation. Once a value is persisted as WooCommerce order meta, it is no longer reachable by any future Safari update.

Frequently Asked Questions

Audit your click-ID capture path before Apple’s next WebPrivacy push. See how Seresa persists click IDs at the WooCommerce hook layer.