The problem: consent breaks your conversion funnel

You're running Google Ads. A visitor clicks your ad, lands on your site, and sees a cookie banner. They click "Reject all." From Google's perspective, that visitor never existed. The click cost you money, but the conversion (if it happens) is invisible.

This isn't hypothetical. In the EEA, consent rates for analytics and marketing cookies typically land between 40% and 70%. That means 30% to 60% of your paid traffic generates zero conversion data. Your ROAS looks worse than it is, your Smart Bidding algorithms train on incomplete signals, and your attribution reports undercount every channel that touches a consenting visitor.

Google's response: Consent Mode v2 with conversion modeling. Instead of losing that data entirely, Google uses machine learning to estimate the conversions that likely happened among non-consenting visitors. But it only works if you've set it up correctly.

What Google actually requires in 2026

Since March 2024, Google has enforced the EU User Consent Policy for all advertisers serving ads in the EEA, UK, and Switzerland. In practice, this means:

Consent signals must reach Google before data collection. Your consent banner needs to fire gtag('consent', 'default', {...}) before any Google tag loads. If the consent signal arrives after the tag, Google treats it as if consent was never given.
Both ad_storage and ad_user_data must be granted. Consent Mode v2 added ad_user_data and ad_personalization as separate signals. Granting ad_storage alone isn't enough for full conversion attribution.
Google verifies the signal source. Google checks that consent signals come from a recognized CMP, not from a script that sets everything to "granted" by default. Using a real consent management platform isn't optional.

If you don't send these signals, Google won't stop showing your ads. But it will stop attributing conversions from EEA traffic, which tanks your reported ROAS and degrades Smart Bidding performance.

How Consent Mode v2 fills the gap

Consent Mode is a protocol between your consent banner and Google's tags. It works in two stages:

Stage 1: Default state (before consent)

When the page loads, your banner tells Google the default consent state. For EEA visitors, this is typically everything denied:

gtag('consent', 'default', {
  analytics_storage: 'denied',
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  wait_for_update: 500
});

Google's tags still load, but they send cookieless pings instead of setting tracking cookies. These pings carry enough context (timestamp, page URL, referrer) for Google to model conversions later.

Stage 2: Update after consent

When a visitor clicks "Accept," your banner fires the update:

gtag('consent', 'update', {
  analytics_storage: 'granted',
  ad_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted'
});

Google's tags then set cookies and begin full tracking for that visitor. For visitors who rejected, the cookieless pings from Stage 1 feed Google's conversion modeling algorithm.

Basic vs. Advanced implementation

The basic implementation only fires tags after consent is granted. No consent means no data at all. The advanced implementation loads Google tags before consent (in cookieless mode), giving Google the pings it needs for modeling. Advanced implementation recovers significantly more conversion data and is what Google recommends.

CookieBeam uses the advanced implementation by default. Tags load immediately in denied mode, and consent updates fire the moment the visitor makes a choice.

Enhanced Conversions and consent

Enhanced Conversions let you send hashed first-party data (email, phone, address) alongside conversion events so Google can match them to signed-in users. This improves attribution even when cookies are blocked.

The catch: sending hashed personal data still requires consent under GDPR. Your consent banner needs to collect explicit consent for ad_user_data before you can fire Enhanced Conversions for EEA visitors.

The workflow:

Visitor consents to marketing cookies (including ad_user_data)
Visitor completes a conversion (purchase, lead form)
Your conversion tag fires with the hashed email/phone attached
Google matches the hashed data to its user graph for better attribution

Without ad_user_data consent, Google ignores the Enhanced Conversion data even if you send it. The consent signal gates whether Google processes the personal data, not whether your tag fires.

Server-side tracking: the insurance policy

Client-side conversion tracking has three weaknesses that consent alone can't fix:

Ad blockers strip Google tags before they can fire, consent or not
Browser ITP/ETP limits cookie lifetimes to 7 days or less on Safari/Firefox
Page speed suffers when you load multiple tracking scripts in the browser

Server-side Google Tag Manager (sGTM) solves all three. Instead of running gtag.js in the browser, you run a GTM server container that receives events from your site and forwards them to Google's APIs. Ad blockers can't block a request to your own subdomain. Cookies set by the server aren't subject to ITP. And your page loads one lightweight script instead of a dozen vendor tags.

The consent model is the same: your banner sets Consent Mode signals, the server container reads them, and only forwards data to Google when consent was granted. The difference is reliability. A server-side setup captures conversions that client-side tracking misses entirely.

CookieBeam offers a managed sGTM add-on that provisions and maintains the server container for you, so you get the benefits without managing infrastructure.

Measuring the consent gap

Before you optimize anything, measure what you're losing. Here's how:

Compare GA4 reported conversions with actual conversions. If your CRM shows 100 leads this month but GA4 shows 65, the gap is your consent loss plus tracking loss.
Check your consent rate in CookieBeam's analytics. If 55% of EEA visitors consent to marketing cookies, you're losing direct tracking on 45% of that traffic.
Look at Google's modeled conversions. In Google Ads, go to Columns > Modify columns > Conversions and check "Conversions (by time)" which includes modeled conversions. Compare this with the un-modeled count.
Check the "Consent" column in GA4. GA4's reporting identity settings show you what percentage of your data is observed vs. modeled.

A well-implemented Consent Mode v2 setup typically recovers 50% to 70% of the conversions lost to non-consent through modeling. Combined with server-side tracking, you can get within 10% to 15% of full attribution.

Setting up consent for Google Ads with CookieBeam

CookieBeam handles Google Consent Mode v2 automatically. Here's what happens when you install it:

Default denied state fires before any Google tag. CookieBeam's script loads with wait_for_update: 500 and sets all consent types to denied for EEA visitors.
Google tags load in cookieless mode. GA4, Google Ads, and Floodlight tags fire their cookieless pings immediately, giving Google the data it needs for modeling.
Consent update fires on user choice. When the visitor clicks Accept (all or specific categories), CookieBeam fires the consent update with the exact signals Google expects: analytics_storage, ad_storage, ad_user_data, and ad_personalization.
Regional rules handle the complexity. EEA visitors get opt-in (everything denied by default). US visitors get opt-out (everything granted by default, with a "Do Not Sell" option for CCPA states). Other regions get the appropriate behavior. One banner, one script, correct behavior everywhere.

There's no manual gtag('consent', ...) code to write. CookieBeam injects the consent commands at the right time in the right order.

Common mistakes that break conversion tracking

These are the errors we see most often when auditing Google Ads accounts:

Consent default fires after Google tags. If gtag.js loads before the consent default, Google treats the first pageview as consented. That's a compliance violation and inflates your data. Make sure the consent banner script loads first.
Missing ad_user_data signal. Many older consent setups only send analytics_storage and ad_storage. Without ad_user_data, Enhanced Conversions and Customer Match won't work for EEA traffic.
Basic implementation instead of Advanced. Basic mode loads no Google tags until consent. That means zero cookieless pings, zero modeling data, and zero recovered conversions from non-consenting visitors.
Consent signals not reaching the server container. If you're running sGTM, the consent state needs to travel from the browser to the server. CookieBeam includes the consent state in every event sent to the server container.
Testing with consent granted. Developers often test with consent pre-granted (or from a non-EEA location). Test with a VPN set to Germany or France, clear all cookies, and verify the denied-then-updated flow works end to end.

What to do today

Verify Consent Mode v2 is active. Open Google Tag Assistant, visit your site from an EEA IP, and check that consent signals appear before any Google tag fires.
Check all four consent types. Make sure analytics_storage, ad_storage, ad_user_data, and ad_personalization are all present in the default and update commands.
Switch to Advanced implementation. If your current setup blocks Google tags until consent, switch to a CMP that supports Advanced mode (cookieless pings before consent).
Measure your consent gap. Compare CRM conversions with Google Ads reported conversions. If the gap is larger than 30%, your consent setup needs work.
Consider server-side tracking. If you're spending more than a few thousand per month on Google Ads, the conversion recovery from sGTM pays for itself quickly.