What happens to a Google Ads conversion when ad_user_data is denied
The conversion still happens, and your own systems still record it. What a denied ad_user_data removes is the user data Google receives alongside it, so Google can no longer join that conversion to a person or to a click. In Google Ads it stops being counted and starts being estimated.
The conversion happens either way
Worth saying first, because the panic usually starts in the wrong place. No consent choice reaches your checkout. The order is placed, the payment clears, the row lands in your database. What changed is one link in the chain running from your site to Google, and only Google's end went dark.
So the honest question is not how many conversions you lost, but how many Google can still see well enough to credit. The gap between those two quantities is where most of the confusion about Consent Mode lives.
What actually leaves the page
Two things decide what Google gets. The first is which flavour of Consent Mode you run, and if you are unsure, Basic and Advanced behave very differently on exactly this point. Under Basic, a denial means the tag never fires, so nothing at all is sent and there is no record of the event on Google's side. Under Advanced, the tag fires and sends a cookieless ping: Google learns that something happened, without learning who it happened to.
The second is which permission was denied. ad_storage governs whether Google's tags may keep advertising cookies, which is where a click identifier normally lives between the ad click and the conversion. ad_user_data governs whether user data may be sent to Google for advertising at all. The distinction between that signal and its neighbour is covered in ad_user_data and ad_personalization, and which one stops what, which matters here because a team can grant storage, deny user data, and still be surprised by the fall.
The click identifier itself is not erased by any of this. It is a URL parameter, your landing page receives it, and your own logs can keep it. What consent governs is Google's side: whether it may be stored for later, and whether user data may travel with the conversion.
Where it lands in Google Ads
An observed conversion is one Google can tie to a specific ad interaction. Deny the user data and it cannot, so the conversion moves into the modelled pool: Google estimates what the unobserved traffic produced from the behaviour of the traffic it can still see.
Modelling is not automatic, and this is the part the vendor posts skip. Google's own documentation sets an eligibility threshold of 700 ad clicks over 7 days, per country and domain grouping, alongside a correctly implemented Consent Mode or the IAB Transparency and Consent Framework. Above it, a portion of the missing conversions comes back as an estimate. Below it there is no modelled figure to receive, and the gap simply stays a gap. Note where the threshold applies: per country and domain grouping rather than to the account as a whole, so an advertiser spread thinly across several markets can clear it in one and miss it in the rest.
One reporting consequence is worth planning for. A modelled conversion is an aggregate estimate: it lands with a delay, it cannot be traced back to an individual click, and it will not reconcile row by row against your order table. A campaign you could once tie out to the last order will not tie out any more, and no amount of tag work restores that.
What stops working outright
Three things fail cleanly rather than degrading. Enhanced Conversions stop, because they send hashed first party data such as an email address for matching, and that transfer is precisely what ad_user_data permits. Remarketing and audience membership stop growing from denied visits, a slower problem than a conversion count and a more expensive one, which we took apart in what happens to remarketing audiences when visitors reject cookies. And any bidding strategy learning from conversions inherits the same thinner signal.
Before you accept the drop, rule out the wiring
A real refusal and a signal nobody configured produce the same missing data, and only one is a fact about your visitors. Ten minutes on a live request settles which.
Read a request from a real page load
Open the network panel on a clean session, filter for the collect endpoint, and read the consent parameters on a real hit rather than your tag manager's configuration screen. What a container intends and what a page sends are different claims, and only one is evidence.
Separate a denial from an absence
A signal that was never set through Consent Mode at all is not a denial, and it reads as one downstream. The parameter that distinguishes them is the subject of what the gcd parameter means, and finding an unset signal there usually ends the investigation, because nothing is wrong with the banner.
Check the order, not just the values
If the consent update arrives after the tags have fired, you get the same missing data as a denial while the banner looks perfectly healthy. Worth ruling out every time.
Compare the fall against your own records
Put the Google Ads number next to the order count from your own database over the same window. If your orders held and only Google's moved, this is a measurement change. If both moved, the cause is not consent.
The honest limits
Some of this is not recoverable, and any answer implying otherwise is selling something. A visitor who declines has made a choice, and the right response is to measure what remains accurately rather than route around them. In our own implementation work, recovering 20 to 40% of the conversions consent hides is the realistic range, and it comes from fixing wiring faults and running Advanced Consent Mode properly. Figures are measured ranges across Amplio Data client implementations, not a guarantee. Recovery depends on your traffic mix, your regions and how your tags are configured.
What you can fix reliably is everything upstream of the visitor's decision: signals that were never wired, updates arriving after the tags, categories that do not map to all four Google signals. Those look like consent loss and are not.
Velo sends all four Consent Mode signals from one category mapping you can read on a single screen, so the state a visitor chose is the state that leaves the page, and a drop in conversions means what it appears to mean. How it is wired is on the product page.
Common questions
What people ask about this topic.
What happens to conversions when ad_user_data is denied?
The conversion still happens and your own systems still record it. What changes is what Google receives. Under Advanced Consent Mode the tag still sends a cookieless ping, but it arrives without the user data and identifiers Google would need to join it to a click, so it stops being an observed conversion and becomes an input to modelling. Under Basic Consent Mode nothing is sent at all, because the tag does not fire.
Does a denied ad_user_data mean the conversion is lost?
Not necessarily, but it is no longer counted the same way. Google can model conversions to fill the gap, which is why your total rarely falls to match the denial rate exactly. Modelling has its own eligibility: Google states a threshold of 700 ad clicks over 7 days per country and domain grouping, alongside a correctly implemented Consent Mode or the IAB Transparency and Consent Framework. Below that threshold there are no modelled conversions to receive.
Will the gclid still reach Google if ad_user_data is denied?
The click identifier in the URL is not removed by a consent choice, and your landing page still receives it. What consent governs is Google's side: whether its tags may store that identifier and send user data alongside the conversion. With ad_storage denied there is no advertising cookie to keep it in, so a conversion on a later visit has nothing to look it up from.
Do Enhanced Conversions still work when ad_user_data is denied?
No. Enhanced Conversions send hashed first party data such as an email address so Google can match the conversion to a signed in user, and that transfer is exactly what ad_user_data governs. It surprises teams who granted ad_storage and assumed the identifier side was covered, because the two permissions are separate.
Why did my conversions drop more than my denial rate?
Usually because something denied alongside the visitor. A signal that was never configured reads downstream much like a refusal, and an update arriving after the tag has already fired produces the same missing data. Read a real request before you accept the drop as a consent floor, because a wiring fault is fixable and a consent floor is not.
Your banner, your consent,
your data — all in one place.
