Google Ads conversion tracking, and what consent does to it

On this page

1. The tag records the event; a cookie is what attaches it to a click
2. Denied is the obvious failure. Unresolved is the common one
3. A correctly configured tag and an accurate conversion count are different claims
4. The Ads status column has five values and none of them means consent
5. Where to actually start, in order

Short answer: conversion tracking has two moving parts, and consent takes out the one nobody looks at. The tag fires an event on your thank-you page. Something else entirely — a first-party cookie written when the visitor landed — is what ties that event back to the ad click that paid for it. ad_storage governs the cookie, not the tag. So a tag you configured correctly, that Google Ads reports as Active, can quietly stop producing attributed conversions, and no amount of work on the tag will bring them back. The repair is in the consent layer and the trigger configuration above it.

That's also why the Ads interface is a poor place to diagnose this. Its status column is built to tell you whether the tag is alive, and it has no value that means "the visitor said no".

The tag records the event; a cookie is what attaches it to a click

Split the mechanism in two and most of the confusion dissolves.

When someone clicks your ad, click information arrives in the landing page URL. Google's Tag Manager documentation describes what happens next: the conversion linker "automatically detects the ad click information in your landing page URLs, and stores this information in first-party cookies and browser local storage on your domain" (Google Tag Manager Help, checked 10 September 2026). The cookies are named _gcl_* — _gcl_aw and _gcl_gs among them — set on the top-most domain at root path, with the same data also kept in local storage under _gcl_ls.

Later, on the conversion page, the conversion tag fires and reads that stored click information so Google can associate the action with the click that produced it. Two independent things have to survive the journey: the event, and the identifier connecting it to the ad.

Modern setups don't always need a separate conversion linker tag — a container that loads a Google tag on every page gets the behaviour anyway, and Google Ads tags load a Google tag first. That's convenient, and it means the storage step is easy to forget exists. It's still the part that consent controls.

Denied is the obvious failure. Unresolved is the common one

ad_storage denied is the case people plan for. Google's documentation states it plainly: when ad_storage is denied, new cookies won't be set for advertising purposes, and third-party cookies previously set on google.com and doubleclick.net won't be used except for spam and fraud. Set ads_data_redaction to true on top of that and ad click identifiers in the outgoing network requests are redacted, with traffic routed through a cookieless domain such as pagead2.googlesyndication.com.

The failure that actually costs accounts money is different, and it comes from one sentence in the setup guide: "By default, no consent mode values are set."

A site with a CMP that never calls the consent API isn't sending denied. It's sending nothing. The banner renders, the visitor clicks Accept, and the tag platform never hears about it. Three variations on that theme are documented as known issues, and all three are ordering problems rather than configuration ones:

• The code runs out of order. Google's guidance is blunt: "If your consent code is called out of order, consent defaults won't work." The default call has to precede any command that sends measurement data.
• Consent is granted on a page transition. When a page loads with consent denied and reloads with it granted, Google's docs warn that tags "may lose key data points from the original page" and subsequent reports may be incomplete. The advice is to call update on the page where the choice is made, not after the navigation.
• The update fires as the page unloads. If the update command goes out while the browser is tearing the page down, the network request may be cancelled before it completes.

None of these produce an error anywhere you'd normally look. They produce a slightly smaller number.

There is a partial mitigation worth knowing about, and it has conditions. URL passthrough carries ad click information in URL parameters when ad_storage is denied, but only when the Google tag is consent-aware and present, the advertiser has enabled the feature, consent mode is implemented, the outgoing link stays on the same domain, and a GCLID or DCLID is in the URL. Five conditions. Sites break the fourth one routinely by sending checkout to a payment domain.

A correctly configured tag and an accurate conversion count are different claims

Modelling is what Google offers to close the gap, and its documentation is more candid about the limits than most summaries of it.

Eligibility is a hard gate. Consent mode modelling in Google Ads requires consent mode or IAB TCF v2.0 implemented correctly, plus "a daily ad click threshold of 700 ad clicks over a 7 day period, per country and domain grouping". Read the qualifiers: per country, per domain grouping. A UK advertiser running a single site at 400 clicks a week doesn't qualify, and no setting turns that on. The equivalent thresholds on the Analytics side are covered in Basic versus Advanced Consent Mode, and they are separate gates on separate products.

Google also states what the model cannot do: "Google is unable to observe whether an unconsented conversion previously had an ad interaction," and as a result "some conversions that in reality occurred may not be accounted for, as they are unattributable to ad-clicks without cookies." That is a vendor describing deliberate under-counting in its own product, and it's more useful than any recovery percentage you'll be quoted.

One number in that documentation deserves care, because it's the one people repeat. Google says consented users are "typically 2-5x more likely to convert than unconsented users", and that the variation is wide across consent rates, industries and conversion types. It's Google's own analysis, and no methodology, sample or independent replication is published alongside it. Treat it as the platform's stated expectation rather than a measured constant — and note which way it cuts, because if it's right, losing half your consent doesn't lose you half your conversions. Google's worked example has an advertiser at a 50% consent rate seeing a 19% drop in conversions.

What follows from that is the framing worth keeping: your reported conversion count is a function of your consent rate, and consent rate behaves like a conversion rate — measurable, improvable, and worth optimising deliberately rather than absorbing as weather.

The Ads status column has five values and none of them means consent

This is where diagnosis usually goes wrong, so it's worth naming the tool's actual scope. Google Ads gives conversion actions five overview statuses on the Conversions summary page:

• Active — everything is working as intended.
• Needs attention — there are items to address, but conversions haven't stopped recording.
• Misconfigured — conversions have stopped recording entirely, from a setup error or a broken tag.
• Awaiting conversions — nothing recorded in the last 7 days, typically because the action was created under 48 hours ago, campaigns are paused, or traffic is too low.
• Removed — manually deleted or archived.

Every one of those describes the health of the tag or the account. None describes consent. An account losing a third of its conversions to a denied ad_storage state shows Active, correctly, because the tag is installed and firing and Google can see it. The status column is answering a different question from the one you're asking.

So you have to separate the two failures by their shape instead:

The last row is the one that settles most arguments. If a fortnight of tag work has moved nothing, the problem was never in the tag.

Where to actually start, in order

1. Load a landing page in a clean browser and check for _gcl_aw. If a click identifier isn't being stored, nothing downstream can attribute anything. That single check separates most cases.
2. Look at what the consent API receives, not what the banner shows. A banner that renders is not a banner that signals. Confirm ad_storage, ad_user_data and ad_personalization are being set — to whatever the visitor actually chose.
3. Check the order of the code, once. Defaults before the tag, updates on the page where the choice happens, and not on unload.
4. Compare the drop against your accept rate. If reported conversions fell by roughly the share of people who decline, you have your answer without touching a tag.
5. Work out whether you qualify for modelling at all. Below 700 ad clicks over seven days for the relevant country and domain, the honest expectation from modelling is nothing.
6. Fix the trigger configuration before the CMP. In our experience the CMP is rarely the broken component, and replacing it is the expensive way to find that out.

Conversion tracking that under-reports isn't usually a tagging failure that someone missed. It's a measurement chain with a consent-shaped break in the middle, reported by an interface that was never built to show it. Finding where that chain breaks, and repairing it without pretending the old numbers were real, is what we do.

Sources

1. 1.Google Tag Manager Help — Conversion linker (first-party _gcl_* cookies, _gcl_ls local storage) · Checked 2026-09-10
2. 2.Google — Set up consent mode on websites (defaults, ordering, URL passthrough, ads_data_redaction) · Checked 2026-09-10
3. 3.Google Ads Help — About consent mode modeling (eligibility thresholds, consented vs unconsented conversion rates) · Checked 2026-09-10
4. 4.Google Ads Help — Troubleshooting conversion tracking status (the five overview statuses) · Checked 2026-09-10
5. 5.Google Ads Help — Set up your web conversions · Checked 2026-09-10
6. 6.Google — gtag.js consent reference (ad_storage, ad_user_data, ad_personalization) · Checked 2026-09-10