Safari 26 Strips GCLID From 20% of Sessions and Google Ads Has No Native Fix

Safari 26's tracking protection strips the GCLID parameter from Google Ads URLs in private browsing, which is roughly 20% of Safari sessions. Without GCLID, Google Ads cannot match the click to the conversion, and Smart Bidding starts misreading Safari traffic as unprofitable. The working fix is renaming GCLID to a custom parameter Safari does not recognize, then reconstructing the _gcl_aw cookie in Google Tag Manager.

This has been live since Safari 26 shipped with iOS 26 in September 2025, but most accounts still have not changed anything. The reason it's worth your morning today is that the bid strategy has been quietly recalibrating around the loss for seven months, and the longer you wait, the more aggressively Smart Bidding will pull spend away from Safari placements you actually want.

What Safari is actually stripping, and when

The exact mechanism matters because Apple shipped two different protections in Safari 26 and the marketing coverage keeps blending them together. Vasco Meerman's teardown at Billy Grace is the cleanest read on this. Two settings, two different blast radiuses.

Advanced Fingerprinting Protection (AFP). Enabled by default in all browsing, including regular tabs. Restricts known fingerprinting scripts. Does not, on its own, strip URL parameters.

Advanced Tracking and Fingerprinting Protection (ATFP). Enabled by default only in Private Browsing. This is the setting that strips gclid, fbclid, and similar click identifiers from URLs before navigation. ATFP is the one breaking Google Ads attribution today.

So in normal Safari tabs, GCLID still passes through. In private tabs, it does not. Per PPC Land's reporting, private browsing accounts for roughly 20% of Safari sessions, and the All Browsing default is already live in Safari Technology Preview. That last part is the prediction bomb.

If ATFP graduates from Private Browsing to default behavior in Safari 27, the impacted share of Safari sessions goes from 1 in 5 to all of them. Based on the Technology Preview status, I'd put even odds on that landing this fall, which would convert this from a 20% problem to an 80%+ problem on consumer-facing accounts.

One detail almost nobody is talking about: GBRAID and WBRAID are not stripped by the same mechanism. Apple draws a line between user-level click IDs and aggregated or app-level click IDs, and those second two pass through cleanly. If you're running App campaigns or iOS web-to-app, you have less exposure than a standard Search advertiser.

Why Smart Bidding misreads the loss as Safari being unprofitable

This is where I see most accounts make the wrong move.

When Safari strips GCLID before the click hits your site, the conversion still fires (assuming your tag setup catches the user), but it cannot be attributed to the original Google Ads click. From Google Ads' perspective, you're spending money on a Safari click that produced nothing, and you're getting a conversion later that came from somewhere else (direct, organic, or whatever your last-touch fallback is). Both halves of the truth are wrong.

The downstream effect is what hurts. Smart Bidding does not see attribution noise as noise. It sees lower observed conversion rates on Safari users, and it starts bidding them down. PPC Land's writeup cited one account that lost 90% of reported conversions after a Consent Mode V2 misconfiguration, which is the upper bound of how bad this can get. The more common pattern reported by tracking specialists is a 10 to 20% conversion shortfall on Safari-heavy campaigns, especially in DTC apparel, beauty, and anything with a young iOS audience.

Even at the low end, that's enough to flip a campaign from scaling to "pause for review" without any actual change in user behavior.

And honestly, the worst part is that the loss compounds. Smart Bidding pulls spend away. Safari conversions drop further because the campaign is now under-served on Safari. The model interprets that as confirmation that Safari traffic was the problem. You're feeding it a loop.

The Nugteren workaround, in plain English

The fix making the rounds is from Luc Nugteren, a tracking specialist who released a Google Tag Manager template called Restore GCLID in August 2025. His original write-up is on LinkedIn, and PPC Land covered the release.

The logic is straightforward. Safari strips known click identifiers by name, so you rename it. Two steps:

1. In Google Ads, set an account-level URL suffix: lnid={gclid}. This appends the GCLID value to every ad URL under a parameter called lnid (basically Luc Nugteren's initials). Safari does not recognize lnid as a click identifier, so it leaves the parameter alone.
2. In GTM, install Nugteren's "Restore GCLID" tag template. On page load, the tag reads lnid from the URL and writes it into the _gcl_aw cookie that Google Ads requires for conversion linking. The template also checks ad_storage consent before writing, which keeps you compliant with Consent Mode V2.

That's it. Google Ads gets its GCLID back through the side door, attribution rebuilds, and Smart Bidding stops penalizing Safari traffic. Implementation runs about 30 minutes if your GTM is reasonably organized, longer if you've got a multi-domain setup that needs the cookie scoped properly.

One quiet caveat. Taggrs has a good explainer on the same approach being adapted for Microsoft Advertising's MSCLKID, which has the same vulnerability. The renaming trick is platform-agnostic in principle, even if Nugteren's specific template is Google Ads only.

What this absolutely does not fix

The headline coverage on this story has been generous. The actual scope of the workaround is narrower than the headlines suggest.

This works for Google Ads only. Meta does not let you append fbclid via a custom URL parameter in Ads Manager. TikTok's ttclid is in the same boat. LinkedIn's li_fat_id, same. Any platform that doesn't expose a URL suffix template the way Google Ads does is going to need a server-side measurement workaround instead, which is a substantially bigger project.

Read coverage on Stape or any of the tag management vendors and the pitch leans toward server-side GTM as the durable fix. They're not wrong about that being the long-term direction. But for most accounts running Google Ads as the primary paid channel, the lnid rename buys you maybe 80% of the attribution recovery for 5% of the engineering cost. That math is hard to argue with this quarter.

This also doesn't fix the Smart Bidding signal that's already been corrupted. Once you ship the rename, expect 7 to 14 days of recalibration before Safari conversions show up at expected rates again. The model has learned the wrong lesson and needs fresh data to unlearn it.

A 30-minute audit before the next bid cycle

If you manage Google Ads accounts and you have not looked at Safari attribution since iOS 26 shipped, here's the working list:

1. Pull a Safari vs Chrome conversion-rate split for the past 90 days. If Safari is meaningfully below Chrome (say, more than 30% lower), you're almost certainly seeing the GCLID strip in your data.
2. Set the account-level URL suffix to lnid={gclid} in Google Ads. Tools, Setup, Account settings, Tracking. Five minutes.
3. Install the Restore GCLID GTM template, configure it to write to _gcl_aw, gate it on ad_storage consent.
4. QA in a Safari Private Browsing window with debug. Confirm the cookie writes after click, confirm the GCLID matches what Google Ads logged.
5. Annotate Smart Bidding with the change date. Give it 14 days before evaluating impact, not 3.

This slots in next to the same kind of integrity work as a Google Ads exclusion-list audit. Both are silent measurement problems where the platform isn't going to send you a notification.

The mismatch you don't get to wait out

Apple shipped this in September. Google has not produced a native counter, and given how the GCLID has historically been Google Ads' attribution backbone, I don't think they're planning to. Apple owns the browser, sets the rules, and the rules are getting stricter at every minor version.

The renaming trick is duct tape on a structural problem. It's also the only thing that works today without rebuilding your measurement stack. From what I've seen in the coverage so far, most teams will treat this as a side quest until their reporting starts looking visibly broken, and by then the bid model will have spent six months learning around the wrong data. Worth the half hour now.

Notice Me Senpai Editorial