Why do gbraid and wbraid break my Google Ads attribution?
gbraid and wbraid are Google click identifiers that arrive in place of gclid on iOS traffic where Apple's privacy rules prevent the usual user-level identifier. They are not drop-in replacements: they identify a group of clicks rather than an individual, they cannot be combined with user-provided data the way gclid can, and capture code that names only gclid ignores them entirely. The result is a growing share of iOS conversions that never get uploaded, which looks like iOS performing badly rather than iOS not being measured. The fix is to capture all three parameters, store whichever arrived, and upload against the right one.
Free30 minutesNo obligation
gbraid and wbraid attribution issues · what breaks
What this looks like when it's happening to you — gbraid and wbraid attribution issues
- 01
iOS campaigns look far worse than Android
Not because they perform worse, but because a share of their conversions never gets recorded at all.
- 02
Offline uploads rejecting rows with no clear reason
Rows uploaded against the wrong identifier type fail, and the error text does not always make the cause obvious.
- 03
Identifier coverage that fell over time with no code change
As iOS traffic share grew, the proportion of clicks arriving with gclid shrank.
gbraid and wbraid attribution issues · the fix
What changes once it's fixed — gbraid and wbraid attribution issues
All three identifiers captured
gclid, gbraid and wbraid, with whichever arrived stored on the record.
Uploads sent against the correct identifier
Each row using the parameter that actually arrived, not a guess.
Honest reporting of what cannot be joined
gbraid and wbraid do not identify a person. Enhanced conversions for leads does not apply to them the way it does to gclid, and pretending otherwise produces silent failures.
gbraid and wbraid attribution issues · architecture
Why your conversion data was wrong in the first place — gbraid and wbraid attribution issues
Fixing this specific fault is worth doing. But it is worth understanding why it happened, because the same underlying weakness produces a different symptom every few months — and the reason your conversion data is wrong is almost never the tag itself.
- 1
Your conversion depends on a browser that is being restricted on purpose
A browser-side tag has to survive the page loading, the visitor staying, the script executing and the request leaving. Every one of those is now contested. The order in your database is certain; the browser event reporting it is not, and that gap is where wrong numbers come from.
- 2
Safari caps the cookie your attribution depends on
Intelligent Tracking Prevention limits cookies written by JavaScript to seven days, whatever expiry you set. Any customer who takes longer than a week to decide comes back as a stranger, so the sale is recorded and credited to nobody. A cookie your own server writes in an HTTP response is not subject to that cap — which is the single largest practical difference between browser-side and first-party server-side tracking.
- 3
Ad blockers remove the tag before it can run
A blocked pixel does not error, retry or warn anyone. The visitor buys, the order lands in your store, and no platform ever hears about it. First-party events sent from your own subdomain aren't filtered the same way, because they are not a third-party request.
- 4
Consent banners stop tags, sometimes when they didn't need to
Where consent is genuinely required, losing the event is correct. What is not correct — and what we find repeatedly on US-majority accounts — is an EU-style prior-consent banner applied to every visitor, discarding conversions no law asked you to discard. A server container enforces the real decision at the container rather than hoping each vendor script honours a flag.
- 5
The checkout can end somewhere your tag isn't
Wallets and hosted payment pages can be abandoned after the money moves. The customer paid; the confirmation page never rendered; the browser event never fired. Sending the purchase from the order record instead means the conversion arrives whether or not anyone came back to your site.
- 6
What that adds up to
Each of these is a separate route to gbraid and wbraid attribution issues, and they compound. First-party server-side tracking doesn't patch them one at a time — it moves the money event off the browser entirely, so the order in your backend is what gets reported. That is why we reconcile against your own order records and put 95%+ accuracy in writing: with the event sourced from the order, the number is checkable rather than hopeful.
gbraid and wbraid attribution issues · normal or broken
Some of this is supposed to happen — gbraid and wbraid attribution issues
Half the time nothing is broken and the number is being read wrong. Knowing which is which stops you paying to fix something that was never a fault.
Normal, not a fault
Working
Records carry whichever of the three identifiers arrived, with the type stored alongside, and uploads route by type.
Broken
Records carry gclid or nothing. iOS conversions look like they did not happen.
Broken but invisible
Coverage looks acceptable overall because desktop traffic dominates the average, while the iOS segment specifically is close to zero.
Actually broken
Capture code written before gbraid and wbraid existed
The overwhelmingly common cause. The code works, has always worked, and quietly stopped covering a growing share of traffic.
A third-party plugin or tag template that only knows gclid
Plenty of form and CRM integrations still capture one parameter. Check what yours actually reads rather than what its documentation implies.
Auto-tagging disabled
No identifier of any kind arrives. Worth ruling out first because it takes thirty seconds and explains everything at once.
Uploads sent with the value in the gclid field regardless of type
Rows fail and the failure is reported as unmatched rather than as a format problem.
Redirects or a landing page framework stripping query parameters
The parameter arrives and is discarded before anything reads it.
gbraid and wbraid attribution issues · diagnose
How we find out why do gbraid and wbraid break my google ads attribution
Always in this order. Each step eliminates a class of cause, so by the last one there is usually a single explanation standing.
- 01
Confirm auto-tagging is on in every Google Ads account
One setting, and switching it off removes conversion attribution, enhanced conversions and offline import together.
- 02
Pull your last few hundred records and count identifier types
How many carry gclid, how many gbraid, how many wbraid, how many nothing. That distribution is the whole diagnosis.
- 03
Read the capture code and check which parameter names it reads
If gbraid and wbraid are not in it, you have found the cause and can stop.
- 04
Compare the identifier distribution against your iOS traffic share
They should be broadly consistent. A large iOS share with almost no gbraid or wbraid means capture, not traffic.
- 05
Check the upload's failure rows, not its success count
A file can upload successfully and match nothing. The per-row errors say which.
- 06
Test a live iOS click end to end
Click an ad from an iPhone, complete a conversion, and follow the identifier through to the record.
gbraid and wbraid attribution issues · prove
How we prove it's actually fixed — gbraid and wbraid attribution issues
The tag firing again proves the tag fires. These prove the numbers are right.
Source of truth
Your own records, counted by identifier type, next to your Google Ads traffic split by device and platform
- The identifier type distribution measured across your last few hundred conversions, before and after the fix.
- A live iOS click followed end to end, with the parameter that arrived confirmed on the record and in the upload.
- Reconciled against your own records, counted by identifier type, next to your google ads traffic split by device and platform for a fully closed window, matched on ID rather than on totals.
- No record counted twice, checked across the whole window rather than spot-checked.
- The same check repeated 30 days later, because a fix that holds once and drifts is the harder failure to catch.
gbraid and wbraid attribution issues · free audit
What we check in the free audit
- Confirm auto-tagging is on in every Google Ads account
- Pull your last few hundred records and count identifier types
- Read the capture code and check which parameter names it reads
- Compare the identifier distribution against your iOS traffic share
- Check the upload's failure rows, not its success count
- Test a live iOS click end to end
Checked against
Your own records, counted by identifier type, next to your Google Ads traffic split by device and platform
Free30 minutesNo obligation
gbraid and wbraid attribution issues · when not to buy
When you don't need us for this — gbraid and wbraid attribution issues
Most of these you can do yourself, and we would rather you did.
- Confirm auto-tagging is enabled in every account. Thirty seconds, and it is a surprisingly common cause.
- Search your capture code for the string gbraid. If it is not there, you have your answer without any further investigation.
- Count the identifier types on your last hundred conversions. That single number tells you the size of the problem.
gbraid and wbraid attribution issues · what we deliver
What we do about it — gbraid and wbraid attribution issues
Widen the capture to all three parameters
One line of logic instead of one parameter name. This alone recovers most of the loss.
Store which type arrived
The upload needs to know whether it is sending a gclid, a gbraid or a wbraid. Storing the value without the type creates a problem later.
Route uploads by identifier type
Google's import accepts each, in its own field. Mixing them produces rejected rows.
Set expectations on what wbraid can and cannot do
It is a privacy-preserving aggregate identifier. Some user-level features are unavailable with it by design, and that is not a bug to work around.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
We fix the fault in your existing browser-side setup and verify it on a live transaction. Honest disclosure: this repairs what you have, it does not make it durable. If you spend $1K+/month on paid media, the fault will recur the next time Safari, a consent banner or a checkout change moves under you — the server-side tier is what stops that.
- Root cause found and fixed, not worked around
- Verified on a live transaction, not in preview
- Reconciled against your own order records
- Written handover documenting what changed and why
1st-party server-side
Recommended$800One-time fee · most popular
The tier that removes the whole class of failure rather than this instance of it. Your money events stop depending on the browser: they are sent from your order records through a first-party server container on your own subdomain, so iOS, ad blockers, consent banners and interrupted payment redirects can no longer take them away. Built in 2–4 days. You own the stack outright — no monthly SaaS.
- First-party server container on your own subdomain
- Purchases sent from your order records, not the browser
- Meta, Google, TikTok, Microsoft and LinkedIn all fed server-side
- Deduplicated on a shared event ID, verified at every destination
- First-party cookies beyond Safari's 7-day cap on JavaScript-set cookies
- 95%+ conversion accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid-media channel server-side, end to end, plus the offline loop. For advertisers whose spend makes an attribution leak more expensive than the build. Pay once, own everything.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop, so closed revenue reaches bidding
- Refunds and cancellations reversed at every destination
- Klaviyo identity stitching, BigQuery and Looker Studio
- Monitoring, so the next break surfaces in days rather than a quarter
FAQ
gbraid and wbraid attribution issues questions, answered
Both arrive on iOS traffic where a user-level identifier is not available. In broad terms they cover different traffic contexts — gbraid on app-related traffic and wbraid on web traffic under those privacy constraints. For implementation purposes the important part is that both are aggregate rather than user-level, both must be captured, and each must be uploaded in its own field. Check Google's current documentation for the precise definitions, which have been refined over time.
Not in the same way as with gclid. These identifiers are designed to avoid user-level joining, so combining them with user-provided data is restricted by design. Treat that as a constraint to report honestly rather than a limitation to engineer around.
Only within the import window, and only if the identifier was actually stored at the time. If your code never read gbraid, the value was never captured and there is nothing to recover. This is a fix that starts working forward, which is a reason to do it sooner.
They have their own iOS constraints, but not this specific one — this is a Google-specific mechanism. Meta's, TikTok's and Reddit's identifiers behave differently and fail differently.
Free · 30 min
Get gbraid and wbraid attribution issues diagnosed properly
WhatsAppFree30 minutesNo obligation
