Safari has been stripping Google Click Identifiers from ad URLs for some time now, and a growing number of digital advertising professionals are only beginning to understand the full scope of the problem. On April 21, 2026, Luc Nugteren, a tracking and analytics specialist, published a detailed breakdown on LinkedIn explaining precisely how Apple's browser handles the GCLID parameter - and what advertisers can do about it before the situation worsens.

The post has drawn significant attention, accumulating 43 reactions and 8 comments within days. It touches on a technical issue that sits at the intersection of privacy engineering and campaign measurement accuracy, one with real consequences for Google Ads attribution.

What the GCLID actually is

The Google Click Identifier, or GCLID, is a URL parameter that Google Ads automatically appends to destination URLs whenever a user clicks on a paid ad. According to Google Ads Help documentation, the parameter "identifies the campaign along with other attributes of the click associated with the ad for ad tracking and campaign attribution." It is activated by enabling the auto-tagging setting in a Google Ads account and is required for website conversion tracking to function correctly. The GCLID also serves as the bridge that links Google Ads data with Google Analytics, and it underpins offline conversion tracking workflows.

When a user clicks an ad and lands on a page, the URL looks something like this: www.example.com?gclid=TeSter1234abc. According to the Piwik PRO glossary, "when a user clicks on a Google ad, the landing page URL is automatically appended with a GCLID parameter." The cookie created on the user's browser - named _gcl_aw - stores this value, allowing Google's systems to connect the original click with any subsequent conversion event, even if that conversion happens minutes or hours later on a different page.

Without the GCLID, the conversion path breaks. Reported conversions fall. Bidding algorithms that rely on conversion signals receive degraded inputs. Campaign optimisation suffers as a consequence.

How Safari interferes

Apple introduced tracking protections into Safari incrementally. The browser's Intelligent Tracking Prevention, first launched in 2017, set an early precedent for restricting cross-site tracking. Since then, each major version of Safari and iOS has tightened those controls further.

The specific mechanism Nugteren describes in his April 21 post involves a Safari setting called "Advanced Tracking and Fingerprinting Protection," accessible via Settings > Safari > Advanced > Advanced Tracking and Fingerprinting Protection. By default, this setting is configured to "Private Browsing" mode. In that state, Safari strips the GCLID parameter from URLs during private browsing sessions. According to Nugteren's post, private browsing is estimated to account for approximately 20% of all Safari sessions. That means roughly one in five Safari users is already browsing without transmitting a usable GCLID, even under the current default configuration.

The situation is more severe for users who have manually changed the setting to "All Browsing." For those users, the GCLID is stripped regardless of whether they are in a private or a standard browsing session. This is not the default today - but it is the default in Safari Technology Preview, Apple's experimental build of the browser used by developers and early adopters. Testing conducted on iOS 26 beta builds in September 2025 showed that GCLID parameters remained intact in regular browsing under the standard beta, but preview builds exhibited stripping across all sessions. That divergence has fuelled discussion about whether "All Browsing" will eventually become the default for all Safari users.

Nugteren's post is direct on this point: "I feel like almost everyone is going to be using the default 'All Browsing' option then, without touching the settings."

PPC Land reported in August 2025 that Apple's Safari 26 update, launching alongside iOS 26 and macOS 26 in September 2025, introduced Advanced Fingerprinting Protection as a default for all browsing sessions. The two protections - Advanced Fingerprinting Protection and Advanced Tracking and Fingerprinting Protection - are distinct, but their convergence in the same browser version has increased the complexity of the measurement picture.

GBRAID and WBRAID are treated differently

One technical detail in Nugteren's post deserves particular attention. While the GCLID is subject to stripping under Safari's tracking protection settings, the GBRAID and WBRAID parameters are not. According to the post, "both GBRAID and WBRAID parameters are never removed" by the same privacy mechanism.

This is not accidental. GBRAID handles attribution for iOS app conversions originating from Google Ads. WBRAID covers web conversions from iOS devices in scenarios where the GCLID is unavailable. Google's Ads API introduced simultaneous support for both GCLID and GBRAID in a single conversion upload in July 2025, with the change taking effect on October 3, 2025. The dual-field capability was designed precisely to address the fragmented attribution environment that iOS privacy restrictions have created.

The practical implication is that iOS users whose GCLID is stripped by Safari end up attributed solely through GBRAID or WBRAID, provided those parameters are present. For advertisers who have not implemented the appropriate tracking infrastructure, those users may appear as unattributed conversions - or not appear at all.

A two-step workaround via Google Tag Manager

Nugteren outlines a two-step approach in his post for advertisers who want to preserve GCLID-based attribution even when Safari's privacy settings would otherwise strip it.

The first step involves modifying the Google Ads account-level URL suffix to add a secondary parameter containing the GCLID value. Nugteren recommends using "lnid={gclid}" as the URL suffix. This means the GCLID is transmitted in a differently named parameter alongside, or instead of, the standard gclid= format. Because Safari's tracking protection targets known parameter names, renaming the parameter in this way can allow the value to pass through in situations where the standard form would be blocked.

The second step uses a custom Google Tag Manager template that Nugteren has made available through his website. The template, called "Restore GCLID," is configured in GTM with the cookie name set to _gcl_aw and the URL parameter name set to lnid. When the tag fires - triggered on all page views - it reads the lnid parameter from the incoming URL and uses it to reconstruct the _gcl_aw cookie that Google Ads relies on for attribution. The tag is also configured to check the ad_storage consent signal, which ensures the cookie is only written when the user has provided the appropriate consent.

PPC Land covered the initial release of the Restore GCLID template in August 2025, when Nugteren first published it ahead of anticipated Safari 26 changes. The April 2026 post revisits the same approach, updated with a clearer articulation of the underlying Safari settings and their estimated impact on session volumes.

The tag configuration screenshot shared in the LinkedIn post shows the GTM interface with four permissions listed, the _gcl_aw cookie name, the lnid URL parameter name, and the ad_storage consent check confirmed. The trigger fires on all pages as a page view event.

The ad_storage consent check in the tag configuration connects this workaround directly to a broader compliance context. The ad_storage parameter is part of Google's Consent Mode framework, which controls whether advertising cookies and identifiers are collected based on user consent signals.

Starting June 15, 2026, Google is restructuring how consent controls work across GA4 and Google Ads. The Google Signals setting in GA4 will lose its authority over advertising data collection. From that date, the ad_storage parameter in Consent Mode - managed through Google Ads - will be the sole control governing whether advertising cookies and device identifiers are collected. That change means the ad_storage signal carries more operational weight than it did before. If the _gcl_aw cookie is being restored via the Nugteren template, and ad_storage is denied, the cookie will not be set. The consent check in the template is therefore not optional from a compliance perspective - it is the mechanism that prevents the tag from writing advertising data for users who have declined.

PPC Land reported in July 2025 on cases where incomplete Consent Mode V2 implementation caused conversion data to collapse, with one account losing 90% of reported conversions overnight. The combination of Safari's parameter stripping and an improperly configured Consent Mode implementation represents a compounding risk.

Limitations of the approach

Nugteren himself is explicit about the constraints of this workaround. It functions only for Google Ads. Meta Ads, TikTok Ads, Microsoft Advertising, and other platforms that rely on their own click identifiers - fbclid, ttclid, msclkid - cannot be restored through the same method. According to the post, "with Meta and other ad platforms you're not able to append click IDs via custom URL parameters."

The comment thread on the LinkedIn post reflects a range of professional views on the value and durability of the approach. Stefan H., identified as a Digital Implementation Specialist, expressed scepticism: "I really don't think this is worthwhile. Apple / Safari are not stupid. They will always have the upper-hand in this game of cat-and-mouse." He elaborated further: "We're going to be at a point soon(ish) where Safari does heuristic analysis of loading scripts to identify known trackers, run regex against all URL parameters to find 'hidden' click IDs and eventually we're going to be out of options, relying on UTMs, hashed PII sharing and other dark magic."

Md Monirul Islam, identified as a Tracking Specialist, pointed to a server-side alternative: "Stape has a great power up feature to restore click id. They've made it very easy to use. I've been using this for some time. Working well." Nugteren confirmed in reply: "Definitely! If you run sGTM, that's a great option." The server-side Google Tag Manager approach routes tagging through advertiser-controlled infrastructure, which browsers treat differently from third-party domains - a technical distinction that Google's tag gateway feature, expanded with GCP integration in January 2026, is designed to exploit.

Why this matters for the marketing community

The GCLID stripping issue is not new. In July 2021, Google stopped sending the GCLID for traffic from several Google apps on iOS following Apple's release of App Tracking Transparency in iOS 14.5. That episode marked the first major disruption to GCLID-based attribution at scale and prompted advertisers to begin exploring GBRAID and WBRAID as alternative signals.

What the April 2026 discussion highlights is that the problem has moved from app traffic to Safari's web browser itself, and that the scope is expanding. An estimated 20% of Safari sessions already run in private browsing mode, and the possibility that "All Browsing" protection could become the default raises that share substantially. On mobile devices, where Safari is the dominant browser across iOS, the proportion of affected traffic can be significant.

For marketing teams that rely on Google Ads conversion data to optimise campaigns and justify budget allocation, the accuracy of GCLID attribution directly affects the signals available to automated bidding systems such as Target CPA and Target ROAS. Degraded attribution data feeds degraded optimisation decisions. The problem compounds in accounts that have not implemented offline conversion tracking or enhanced conversions, where the GCLID may be the only available attribution signal.

The auto-tagging mechanism that generates GCLIDs was enabled by default for Display & Video 360 advertisers in September 2024, signalling Google's continued reliance on the parameter as a core measurement instrument. That dependence makes the Safari stripping issue more consequential, not less, as default protections evolve.

Timeline

Summary

Who: Luc Nugteren, a tracking and analytics specialist described on LinkedIn as "helping marketers level up their tracking and analytics," authored the April 21, 2026 post. The issue affects Google Ads advertisers, marketing technology professionals, and digital measurement teams using Safari-exposed web traffic.

What: Safari's Advanced Tracking and Fingerprinting Protection setting strips the GCLID parameter from ad destination URLs. Under the current default - private browsing - this affects an estimated 20% of Safari sessions. Users who enable the "All Browsing" mode lose the GCLID in all sessions. Nugteren's workaround uses a renamed URL parameter (lnid) combined with a custom GTM template called Restore GCLID to reconstruct the _gcl_aw cookie that Google Ads attribution depends on.

When: The LinkedIn post was published on April 21, 2026. The Restore GCLID template was originally released on August 13, 2025. The Safari stripping behaviour has been active for some time, with the "Private Browsing" default already covering an estimated 20% of sessions.

Where: The workaround operates inside Google Tag Manager's web container. The URL suffix modification is made at the Google Ads account level. The solution applies to web traffic only and does not extend to Meta Ads or other advertising platforms.

Why: Accurate GCLID attribution underpins conversion tracking, bidding signal quality, and campaign optimisation in Google Ads. As Safari's default privacy settings evolve toward broader parameter stripping, advertisers without a backup attribution mechanism face growing gaps in their measurement data. The workaround provides a client-side interim measure while the broader industry continues to develop server-side and first-party alternatives.

Share this article
The link has been copied!