Consent Mode: Why Most of Your Conversions Are Missing from GA4

You open GA4, look at conversions, and the number lands at roughly a quarter of what the store reports. You blame attribution and move on.

Usually it is not attribution. It is that the signal from most of the people who bought from you never reached GA4 at all.

I will show you two settings in Google Tag Manager that look almost identical, one of which switches measurement off. Plus one trap that raises no error anywhere, which is why nobody goes looking for it.

How many people never give you consent

I have been measuring reactions to the cookie banner on my own site for a long time, and the numbers are stubbornly stable.

Around 15 % of visitors accept. About 10 % decline. And 72 % of people ignore the banner entirely, clicking nothing and carrying on reading. I tried a bottom bar and a centered card in the middle of the screen. The difference between them stayed within the margin of error, so placement is not the lever.

For an online store the ratio will differ, because a buyer is more motivated than a blog reader. The order of magnitude holds: most of your traffic arrives without consent.

And that is the heart of the problem. Consent Mode exists precisely so that something survives from that majority even when you may not store an identifier. Configure it wrong and nothing does.

Two settings that look alike

Every tag in Google Tag Manager has a Consent Settings section. It holds two things, and the difference between them decides whether you measure.

Built-in consent checks mean the tag knows how to react to denied consent on its own. It stores no cookie, but sends a cookieless ping, an anonymous signal carrying no identifier. Google learns that a visit happened, it just does not know whose. This is Consent Mode in its advanced form.

Google announced Consent Mode v2 in the fall of 2023 and has required it in the European Economic Area since early March 2024, from anyone who wants to keep targeting and measuring in Google Ads. The update added two signals next to analytics_storage and ad_storage: ad_user_data and ad_personalization. Without them no EEA user enters your remarketing audiences, and ad measurement and personalization get limited as well. You set them the same way as the first two, so a blocked tag sends none of the four.

Additional consent required means something else entirely. It is a hard condition: until the visitor consents, the tag does not fire at all. Not even a ping goes out.

When a tag carries both, the second overrides the first. The built-in checks are then worthless, because the tag never gets a turn.

The word "additional" in the name suggests a supplement. It is not. It is a switch.

How to spot a tag that is blocking measurement

When I went through this on my own container, 41 tags out of 48 had analytics_storage set as additional consent required. The Google tag among them, the one carrying both GA4 and Google Ads conversions.

The result: of the 85 % of visits that gave no consent, nothing went anywhere. Not even a ping. GA4 saw only 15 % of reality and Google Ads optimized against conversions that were only a fraction of the real number.

There are two ways to check. In the interface you open a tag, expand Advanced Settings and see whether Additional consent required is filled in. That is fine for a container with ten tags.

On a larger container it is faster to pull the published version straight from Google's server:

https://www.googletagmanager.com/gtm.js?id=GTM-XXXXXXX

That file contains the tag array including consent settings, and you read them all at once. On a container with sixty tags it is the difference between an hour and five minutes.

One exception where the gate should stay: tools that record sessions, Microsoft Clarity being the typical case. They have no cookieless mode, so blocking on denial is doing real work and must not be removed.

The trap that raises no error

This is the most expensive mistake I have caused myself, and it cost me three months of data.

Consent Mode is set in two steps. First the default state before the banner loads, then an update the moment the visitor clicks. That update has to go through the gtag() function, because it pushes its own arguments object into the dataLayer.

Write it by hand as a plain object and it looks almost the same:

// Looks right. Google discards it.
dataLayer.push({'0': 'consent', '1': 'update', '2': {...}});

// This one works.
gtag('consent', 'update', {...});

The difference is that the arguments object has a length property, which a plain object does not. Google's consent system uses it to recognize a call, and without it discards the message silently. No console error, no warning in Tag Assistant, nothing.

For me that meant no data reached GA4 from any React page between 29 May and 18 August 2026. Static pages kept measuring, because on them gtm.js arrives before the default consent, so the ping gets through. It looked like a container problem, not a code one.

I found it by isolating a single variable on local test pages against the production container. When measurement mysteriously works in some places and not others, look for a difference in load order, not in settings.

Why conversion modeling never starts

Google promises to model the missing conversions back from cookieless pings. There is a catch that is rarely mentioned.

Modelling needs roughly a thousand daily events with denied consent, sustained for seven days. A site that never reaches that bar never gets modeling, however perfectly Consent Mode is configured.

For an online store with normal traffic this is not an issue. For a corporate site with a few hundred visits a day, do not count on it, and accept that part of the data in GA4 is simply missing.

You can still watch traffic volume another way. I built my own counter that measures every visit with no cookie, no localStorage and no identifier of any kind, so it needs no consent. It cannot and never will return unique visitors or sessions, because that would require an identifier. For volume and traffic source it is enough, and conversion attribution stays in GA4.

What to do this week

The order matters, because each step only makes sense once the previous one holds.

1. Go through the tags in the container and remove additional consent required from the Google tag, GA4 and Google Ads conversions. Leave the built-in checks on.
2. Verify the consent update. In the browser console look at google_tag_data.ics.entries, which shows the state as Google sees it, not as you believe you sent it.
3. Check the gcs parameter on outgoing requests. After G1 comes one digit for ad_storage and then one for analytics_storage. G111 means consent to everything, G100 means denial, and G110 and G101 are the mixed states. If nothing goes out on denial, the gate is still there.
4. Only then look at the banner. Design and placement come last, because even after improving the accept rate, most people will still not consent.

If Tag Assistant reports a timeout and refuses to start, check the cross-origin-opener-policy header. Set to same-origin it severs the channel Tag Assistant uses to talk to the page. At that point you are debugging infrastructure, not the container.

Summary

1. Most visitors never give cookie consent. On my site 72 % ignore the banner entirely, and moving it does not help.
2. In Google Tag Manager, tell built-in consent checks apart from additional consent required. The first sends an anonymous ping on denial, the second switches the tag off.
3. When a tag has both, the switch wins. For me that was 41 tags out of 48, and GA4 saw only 15 % of reality.
4. Send the consent update through gtag(). A hand-written plain object pushed into the dataLayer is discarded silently, with no console error.
5. Conversion modeling needs roughly a thousand daily denied events over seven days. Smaller sites never get it.
6. Order of work: tags first, then verification in the console, and the banner design last.

Broken measurement is the most common finding I start with on accounts I take over. Before optimizing anything I sort out the conversion actions and consent, because a campaign built on bad data cannot be tuned. What Google Ads management covers is on its own page.