Why does GA4 say 'Campaign data accuracy is affected by missing URL parameters' for my Google Ads clicks?
Because some of your Google Ads landing page URLs lose their gad_source, gad_campaignid or GBRAID parameters before the GA4 tag can read them. GA4 added this diagnostic on July 30, 2026. These "aggregate identifiers" let GA4 credit a paid click when it can't use the GCLID, which happens when a visitor denies ad_user_data consent. When they're stripped, GA4 reports those visits as "(not set)" or "organic." Click View URLs in the alert to see the pages, make sure your redirects keep every URL parameter, and allow 24 to 48 hours for the fix to show.
Ask Tofu next
Pick a question and Tofu Ads Agent answers it in chat.
- Check whether my Google Ads landing pages keep gclid and gad_source through redirects
- How do I capture GBRAID and gad_campaignid in my HubSpot forms?
- Why don't my Google Ads and GA4 conversions match?
- How does consent mode change my Google Ads conversion tracking?
- Which of my Google Ads campaigns drove pipeline last quarter?
As of October 2026.
What changed in July 2026?
GA4 started flagging properties where these parameters go missing. Google's What's new page for July 30, 2026 says properties where "aggregate identifiers (GBRAID and gad_) are missing from the URL will see a new diagnostic," with the problem URLs and ways to fix them. The alert's description starts: "Some URLs are missing one or both of the aggregate identifiers (GBRAID and gad_)." In reports, Google says it shows in the Data quality indicator when GBRAID or gad_ parameters are missing from URLs that have a GCLID. Anyone with access can see it; you need Editor access or higher to act on it.
Why do my Google Ads clicks show up as organic or (not set)?
Usually because GA4 had no click information it could use. GA4 credits a Google Ads visit with the GCLID that auto-tagging adds. When a visitor denies ad_user_data consent, GA4 can't use the GCLID, so it falls back on the aggregate identifiers. If those were stripped too, Google says the visit shows "(not set)" or "organic." A second cause is a server that changes the GCLID's upper and lower case: GA4 then still knows the visit came from google / cpc but shows campaign, ad group and keyword as "(not set)." For other gaps between the two tools, see why Google Ads and GA4 show different conversions.
What are gad_source, gad_campaignid and GBRAID?
They're URL parameters Google adds to ad clicks so it can measure campaigns without tying the data to one person.
| Parameter | What it tells Google | Good to know |
|---|---|---|
| gad_source | Where the ad ran, such as Google Search or the Display Network | You can't customize it; every advertiser gets the same value for the same source. It used to be called gad |
| gad_campaignid | The campaign that drove the click | The same for all conversions from one campaign |
| gbraid | Campaign-level click data, measured "in a non-unique fashion (like Campaign ID)" | Case sensitive, so it must not be changed to upper or lower case |
| gclid | The individual click (this one isn't an aggregate identifier) | Added when auto-tagging is on, which it is by default for new accounts |
Google's pages disagree on one point. Its gad_* page says "any URL coming from a Google ad now has &gad_source," but a note on the same page says gad_source "will be rolled out in the coming months" and some advertisers may not see it yet. PPC Land points out that the alert could then flag a parameter Google isn't adding to your URLs yet.
What strips these parameters from my URLs?
Google names these causes:
- Redirects. Google says to keep gad_* parameters in your redirect, because its tags "expect to observe the gad_* parameter as top-level parameter on the page where tags are loaded." Any redirect that doesn't pass the query string on to the new URL drops them.
- Sites that reject unknown parameters. A small share of sites serve an error page when a URL has parameters they don't expect.
- Case changes. A rewrite rule that lowercases URLs breaks GBRAID, gad_ parameters and the GCLID, which are all case sensitive.
- Tags inside iframes. A tag in a frame can't read the address of the page around it, so it can't see the click parameters.
PPC Land, which covered the diagnostic on August 2, 2026, adds canonical URL rules, locale redirects, security filters and CDN filtering as things that could drop a parameter. Google doesn't list those.
How do I find which pages lose them?
- Start with the alert. Click View URLs in the diagnostic to see the problem page paths.
- Test a landing page. In Google Ads, open Campaigns, then Insights and reports, then Landing pages. Copy a landing page URL into your browser and add
?gad_source=1(or&gad_source=1if the URL already has a?), before any#. Load it, and check that the page loads and the parameter is still in the address bar. - Trace redirects. In Chrome Developer Tools, open the Network tab before you load the test URL. Look for 301 or 302 responses, and check each Location header to see where the parameter drops.
How do I fix it?
Make every URL parameter reach the page where your Google tag loads:
- Point your ads at the final URL, not one that redirects.
- If a redirect has to stay, set your server to pass query parameters on to the new URL.
- Allow arbitrary URL parameters, and don't rewrite their case.
- Put the Google tag on every landing page, not only inside a frame.
Google says implementation changes take 24 to 48 hours to take effect, and the alert may stay for up to 48 hours after you fix the issue.
Is gad_source the same as utm_source?
No. Google adds gad_source by itself, and you can't set its value. UTM parameters are tags you add. Adding UTMs won't clear this alert, which looks for GBRAID and gad_ parameters, and Google says GA4 gives auto-tagging priority over manual tagging anyway. Keep auto-tagging on. If you also need UTMs in your CRM, see why UTM fields are blank on Salesforce leads.
Can I remove these parameters to keep my URLs clean?
No. Google says: "don't remove or block aggregate identifiers from your landing page URL." If a plugin, cache or security rule on your site removes query parameters, exempt gad_ parameters, gbraid and gclid.
Does this matter for offline conversion imports from my CRM?
Yes, if you import leads or deals back into Google Ads. The Google tag picks up gad_* parameters with website conversions on its own. For offline imports, Google says you have to capture them from your landing pages, store them with each lead and send them with your conversions. This matters most when there's no GCLID or user-provided data. Google's GBRAID guide likewise says to add a hidden form field for GBRAID next to the GCLID and store it in your lead system. For the import itself, see how to send offline conversions to Google Ads with the Data Manager API. Google says that since February 2, 2026, the Google Ads API no longer accepts new adopters of session attributes, which carry gad_source and gad_campaignid, in conversion imports, and recommends the Data Manager API instead.
Sources
- What's new in Google Analytics (Analytics Help), checked October 31, 2026
- Troubleshoot diagnostics for parameter stripping (Analytics Help), checked October 31, 2026
- About aggregate identifiers (Analytics Help), checked October 31, 2026
- About gad_* URL parameters (Google Ads Help), checked October 31, 2026
- Troubleshoot data issues with diagnostics in Google Analytics (Analytics Help), checked October 31, 2026
- Check if Google Ads auto-tagging works (Analytics Help), checked October 31, 2026
- About auto-tagging (Google Ads Help), checked October 31, 2026
- Set up offline conversions using GBRAID (Google Ads Help), checked October 31, 2026
- About session_attributes (Google Ads Help), checked October 31, 2026
- Google Ads clicks lose paid attribution when GBRAID and gad_ get stripped (PPC Land, August 2, 2026), checked October 31, 2026