Conversions dropped after implementing Consent Mode v2: what is normal and what is a fault.

If conversions dropped after implementing Consent Mode v2, the orders probably did not. Tags now wait for a consent decision, visitors who decline are no longer measured directly, and a drop of roughly your decline rate is the expected cost until Google’s modelling fills part of it. A drop well beyond that, or one that hits visitors who accepted, is a wiring fault (F-201 ), and it is fixable without rolling consent back.

You can run this check yourself, no developer needed. Take backend orders and GA4 (or Google Ads) purchases for the two weeks before the banner went live and the two weeks after, and work out the percentage fall in recorded purchases against orders. Then set it against the decline rate in your consent platform’s dashboard. Example: 1,000 orders, 610 recorded purchases, a 39 per cent fall. Decline rate 25 per cent. That is 14 points beyond it, in the fault band below.

How much of a conversion drop after Consent Mode v2 is normal?

This is a working rule from the audits I have run, not a Google figure:

• Up to about five points beyond the decline rate is normal. A correct set-up waiting for modelling, or one below the modelling thresholds, looks like this.
• Five to ten points beyond it is worth a Tag Assistant check before you decide.
• More than ten points beyond it is usually F-201 . Either the site never tells Google “assume no” before tags load (no default), or the banner click never tells the tags the answer (no update).

The rule assumes visitors who decline would have converted at about the same rate as those who accept. They often do not, which is why it has a middle band. Two more tells point at a fault whatever the size: accepted visitors converting less than before, and, if your default is region-scoped to the UK and EEA, a drop in regions the banner does not cover.

The same rollout as numbers, assuming a 75 per cent accept rate:

STATE	ORDERS (BACKEND)	CONVERSIONS RECORDED	GAP
Before CMv2	~1,000	1,000	0%
After CMv2, wired correctly, before modelling	~1,000	~750	−25%
After CMv2, tags mis-gated	~1,000	610	−39%
After fix, modelling eligible	~1,000	960	−4%

The last row depends on clearing Google’s modelling thresholds (fix step 2). Below them, a correct set-up stays nearer the second row.

Tag Assistant confirms which case you are in: a missing default, or no update after the banner click, is the fault (Troubleshoot consent mode). The step-by-step check is filed under F-201 . Rule out F-204 at the same time: there the ad click id is stripped in a redirect before consent applies, so attribution breaks even for visitors who accepted.

When the drop is close to 100 per cent

A drop to almost nothing on UK and EEA traffic, overnight, is not a decline-rate story. Either tags are blocked for everyone, or the consent choices Google requires are not reaching it. Google requires advertisers to follow its EU user consent policy to use measurement with website tags, and the advertiser passes those choices to Google through Consent Mode, including ad_user_data and ad_personalization (Google Ads: updates to consent mode for EEA traffic). Open Tag Assistant first. If the default and update are both there, check the Google Ads diagnostics and notifications for the conversion action.

Why conversions drop after Consent Mode v2

On a typical UK or EEA set-up the default consent state is denied, so tags that used to fire for everyone now wait for a yes that, for a share of visitors, never comes. What a declined visitor sends depends on the mode. In basic mode Google tags do not load until the visitor accepts, so a decline sends Google nothing. In advanced mode tags load on the denied default and send cookieless pings, anonymous signals Google can model from (Google Ads: About consent mode).

Consent Mode v2 added two signals for EEA traffic to the original ad_storage and analytics_storage: ad_user_data (may the hit carry user data for advertising) and ad_personalization (may it feed remarketing) (Google Ads: updates to consent mode for EEA traffic). With denied defaults, each stays denied until the visitor grants it, so a visitor who accepts analytics only leaves the three advertising signals denied (Google: consent mode concepts).

A correct set-up loses roughly the 25 per cent who declined. A mis-wired one loses that, plus a slice of the accepters whose hits left on the denied default before the banner’s answer reached the tags. The usual causes are an update call that never fires, or a wait_for_update too short for the banner to answer (Set up consent mode).

That is how the worked example reaches 39 per cent overnight while selling as much as it did the day before. Collection breaks under F-201 . Recovery, once collection is fixed, is F-402 .

Since 15 June 2026, Google says GA4 uses “Consent Mode (within Google Ads)” as the single control for collecting Google Ads data from GA4, and the Google Signals setting only governs linking GA4 data to signed-in users (Google: updates to Google Analytics data controls). So the consent wiring, not the Signals toggle, decides what Google Ads receives from GA4.

The fix, in order

Steps 1 and 2 are tag manager work. Step 3 also needs the customer’s email available on the order confirmation page (in the data layer or a page variable), which on some platforms is a template change. Hand whoever owns your GTM container or consent platform the drop-versus-decline figure and the Tag Assistant result.

1. Wire the tags to the consent state. Set the default to denied before any tag loads, fire the update on the banner decision for all four signals, and use advanced mode where UK and EEA decline rates are material, for the reason above: declined visitors still send pings modelling can work from (Set up consent mode).
2. Know whether you are big enough for modelling.
   • Google Ads: 700 ad clicks over 7 days per country and domain grouping, roughly 100 a day, is the floor. Below it modelling does not start. Above it there is still a training period, then modelled conversions flow gradually into the Conversions column (Google Ads: consent mode modelling).
   • GA4 behavioural modelling: at least 1,000 denied-state events a day for 7 days, and 1,000 consented daily users on at least 7 of the previous 28 days. It starts only from the date the property became eligible, and only advanced mode sends the denied-state events it needs (GA4: behavioural modelling).
3. Turn on Enhanced Conversions for the consented portion. It sends hashed first-party data, such as the email address entered at checkout, when a visitor converts, so Google Ads can match the conversion to the ad (About enhanced conversions). It applies only to visitors who granted ad_user_data and does nothing for those who declined (Google: consent mode concepts). In my experience it is the last few points of recovery, and it is filed under F-402 .

How much of the drop can you recover

Not all of it, and nobody should promise it. Visitors who declined and could not be modelled are unmeasured, not lost. A recovered line a few points under the backend is the honest result. A recovered line that matches the backend exactly can mean tags are firing past the consent choice. Check in Tag Assistant that a rejected session leaves all four consent signals (ad_storage, analytics_storage, ad_user_data, ad_personalization) denied before you read it as success.

If conversions fell the week you shipped Consent Mode v2, set the drop against your decline rate first. If it matches, the orders are probably fine and modelling is the wait. If it does not, the wiring is the fault, and it is filed under F-201 .

Running server-side GTM? The server container needs its own check: Consent Mode v2 with server-side GTM.