On 30 July, Google quietly added a new warning light to Google Analytics. It’s easy to miss, buried under “Data quality,” and it flags a problem that doesn’t show up as an error, a drop in traffic, or a red number anywhere in your account. Instead, it shows up as good news: your organic search performance looking a bit better than it should.
What’s actually changed
Google Analytics can now detect when two URL parameters, GBRAID and gad_, are missing from a click that should have carried them. Google calls these “aggregate identifiers.” They exist because the standard tracking parameter, GCLID, doesn’t always survive the journey from ad click to landing page. Two things break it. Safari strips GCLID from an estimated one in five sessions under its default privacy settings. And under Google’s Consent Mode, any visitor who declines “ad_user_data” consent on your cookie banner has their GCLID blocked outright.
When that happens, GBRAID and gad_ are supposed to step in as the backup. They don’t identify an individual visitor, just the campaign and source that sent them, but that’s enough for Google Analytics to correctly credit the session to Google Ads instead of guessing.
The problem is that backup only works if those parameters survive the trip too. A lot of local business websites have something sitting between the ad click and the final page: a redirect to a booking system, a locale or www/non-www redirect, a CDN rule, a security plugin. Any one of those can quietly drop the parameters. Google’s own troubleshooting notes point at redirects specifically as the main cause.
Why this should bother you more than a normal tracking bug
Most tracking problems make your numbers look worse. This one doesn’t. When GBRAID and gad_ get stripped, Google Analytics doesn’t just lose the session, it reclassifies it. The visit shows up as “(not set)” or, more often, as organic search.
That means a click you paid for starts looking like a free one. Your paid campaigns look like they’re converting worse than they are. Your organic search looks like it’s outperforming. If you’ve ever looked at a report and thought “why are we still paying for Google Ads when organic is doing all the work,” this is one of the reasons that thought can be completely wrong.
Who’s actually exposed
This isn’t really an enterprise problem, big retailers usually have a dev team checking this kind of thing. It’s the small local business site that’s more exposed, specifically anyone whose booking or enquiry flow runs through a third-party system: a wedding venue using an external booking calendar, a golf club running tee times through a separate platform, a salon or clinic using Fresha- or Rota-style booking software. Every one of those is a redirect, and every redirect is a chance for GBRAID or gad_ to fall off along the way.
It also connects directly to the CMP piece I wrote a couple of weeks back. Even a perfectly configured consent banner triggers exactly the condition (a visitor declining ad_user_data) that makes your site depend on these parameters surviving. Get the CMP right and lose the parameters in a redirect anyway, and you land in the same place: paid clicks quietly relabelled as free ones.
What to check this week
Open Google Analytics and look in Reports for a Data quality indicator or a banner reading “Campaign data accuracy is affected by missing URL parameters.” If it’s there, click through to View URLs to see exactly which pages are losing the parameters.
Click one of your own live ads (or add a test gclid to a landing page URL) and follow it through to the final page, including through any booking widget or third-party redirect. Check whether gbraid or gad_ are still in the URL when it lands.
If you use Google Tag Manager, check the parameter is still present at the point the tag fires, not just when the click first arrives on your domain.
If you find and fix a leak, be patient. Google says implementation fixes take 24-48 hours to register, and the diagnostic itself can take up to 48 hours to clear even after that.
The bigger point
None of this is a configuration mistake in the way a wrongly-set-up CMP is. It’s closer to plumbing: a redirect written years ago for a reason nobody remembers, quietly stripping a parameter nobody knew mattered. Nobody set the account up wrong. Google has changed what it depends on twice in the last two months, and a lot of local business plumbing hasn’t caught up.
If you want a second pair of eyes on whether your booking flow or redirects are doing this, that’s a quick thing to check. Drop me a line at will@sharpstonesmedia.co.uk.
