Did your new cookie banner just kill your conversions?

Rhobin

July 31, 2026

7 min read

Almost always it killed the record of them rather than the conversions themselves, and one comparison proves which: hold the same dates against the client's CRM or shop backend, outside the tracking. If the backend is flat while the dashboards stepped down, the banner changed your measurement, and because the ad platforms now bid on the smaller number, a reporting problem becomes a real one within weeks.

The symptom

The consent platform went live on a Tuesday. By Thursday, conversions in Google Ads are down against last week, GA4 agrees on the direction but not the size, and the client has already seen it.

Nobody wants to say the banner did it, because the banner was the compliance job everyone signed off on. And on Thursday you do not know yet. Two very different events draw the same chart: either the client is getting fewer conversions, or the client is getting the same conversions and you stopped being told about them.

Why it happens

First, work out which number moved

One check settles it, from outside the tracking. Take the same range before and after the release and pull what the business runs on: orders in the shop backend, deals in the CRM, booked calls. If that line is flat while the dashboards stepped down, the sales are still happening and the record of them stopped. If both fell together, you have a performance question instead.

Then compare one level up. If sessions fell with conversions, tags are not running at all for part of the traffic. If sessions held and only conversions fell, tags are running and something is gating them or breaking the join between an ad click and the sale.

Why the date of the break is not the date in the chart

Both platforms move the date on you, in opposite directions. On the Campaigns page, Google Ads credits a conversion to the time of the ad query preceding the click rather than the moment the sale happened, while its attribution reports use time of conversion. So a break that started on Tuesday keeps eating into the weeks before it, and looks like it is spreading backwards.

GA4 pulls the other way. Analytics Help puts intraday processing at 2-6 hours and says processing can take 24-48 hours, during which reports may change, so the freshest two days always look worse than they turn out to be.

The mechanisms that actually do it

Every cause below is configuration, not law.

The tags are held back until someone answers. Google's consent mode documentation describes two versions. In the basic one, "you prevent Google tags from loading until a user interacts with a consent banner". In the advanced one, tags load when the page opens and, while consent is denied, "send measurements without cookies". Move to the basic pattern and anyone who ignores the dialog is a blank, with nothing sent that could be modelled later.
A storage denial is not one single loss. With analytics_storage denied, Google Analytics does not read or write first-party analytics cookies but still sends measurement, so events survive and the stitching between them does not. With ad_storage denied, no advertising cookies or device identifiers may be written or read.
The ad click identifier is stripped on purpose. Per Google's consent implementation guide, with ads_data_redaction on and ad_storage denied, "ad click identifiers sent in network requests by Google Ads and Floodlight tags will be redacted". The sale can still be recorded, and Google Ads cannot join it to the click that paid for it. This is the version where GA4 looks healthy and the ad account looks broken.
The defaults cover more traffic than the banner does. Google notes that a default without a region applies to visitors not covered by a region-specific one. Set denied defaults globally during a European project and they reach markets that were never in scope, which is how the drop turns up in a US account.
A tag is gated and doing what it was told. In Google Tag Manager, a tag with additional consent checks "will only fire if the status of all specified consent types are 'granted' when the tag is triggered", per Tag Manager Help. On a conversion tag, that is a correct and entirely silent stop.

Why the repair takes weeks to show

Modelling covers the refusals, and a banner change can quietly disqualify you from it. Analytics Help requires an advanced implementation, tags loaded before the dialog appears and in all cases rather than only on consent, plus at least 1,000 events per day with analytics_storage denied for 7 days and 1,000 daily users with consent granted for 7 of the previous 28 days, and reporting identity set to Blended before modelled data appears at all.

The line that matters to a dated drop is about coming back. Google says a property regaining eligibility gets modelled data only from the date it became eligible again, and that training may take more than 7 days of meeting the threshold. The weeks between the banner and the fix stay thin, permanently. Google Ads Help sets a separate gate of 700 ad clicks over a 7 day period per country and domain grouping, which is why small markets in the same account never get modelling. How much of what remains is estimated rather than observed is worth answering separately.

And then part of it becomes real

Smart Bidding trains on conversion data, and Google's Smart Bidding guidance asks for volume baselines before you judge performance, at least 30 conversions over a month or longer. Feed it a smaller number and it optimises towards the smaller number. Two or three weeks in, bidding has adapted, spend has moved towards whatever still appears to convert, and real lost revenue is mixed into what began as a reporting artefact.

What good looks like

Date it, split it, then change the configuration rather than the banner. Dating it means writing down when the change went live in the client's reporting time zone and reading the shape of the drop rather than its size. Splitting it means that one comparison against a source outside the tracking.

Then separate what the banner had to do from what it was set up to do. Consent before storage is not negotiable, Article 5(3) of the ePrivacy Directive requires it, so the dialog is not the thing to undo. Everything above is a setting: which implementation version, which regions the denied defaults reach, which tags carry extra consent requirements, whether the consent state reaches your server container. Those decisions were made in a hurry during a compliance project and can be made again properly, and that work is covered in Consent Mode v2 without throwing data away.

This is what Archon Consent exists for. Archon Labs takes the legal requirement as given, then sets the implementation up so a refusal removes what it has to remove and nothing more, and what remains still reaches the platforms that need it. Combined with server-side collection, that recovers 15-40% more conversions than a browser-only setup records. What it does not do is close the gap: roughly 95% of events is the realistic ceiling, and 15-30% of conversions went uncaptured before a banner was involved.

FAQ

Can we just roll the banner back?

No, and it would not be the fix if you could. Article 5(3) of the ePrivacy Directive requires consent before storage, so the dialog stays. What is open for change is the implementation version, the regional scope of the defaults, and which tags were given extra consent requirements.

Once the configuration is fixed, do the numbers come back?

Forward, largely. Backward, no. Google gives a property regaining modelling eligibility modelled data only from the date it became eligible again, so plan for a gap that stays in the record and tell the client before they meet it in a year-on-year comparison.

What do we tell the client this week?

That you have dated the change and held the reporting against the business numbers. "Measured conversions fell on the 14th, orders in your backend did not, here is what we are changing and what will not come back" keeps an account. Reporting the smaller number in silence, then a bigger one next month, does not.

Our accept rate looks normal and conversions still fell. What then?

Then it is technical rather than behavioural. Whether sessions moved with conversions separates blocked tags from gated ones. Whether one region moved alone points at defaults applied wider than the banner. Whether GA4 held while the ad platform fell is the signature of redacted ad click identifiers.

Is a stricter banner ever the right call?

Sometimes, and it should be a decision rather than a side effect. A client in a regulated sector, or with a legal team that wants the strictest defensible reading, may accept a thinner dataset on purpose, and that is legitimate. Discovering the trade six weeks later in a performance review, having never priced it, is not.

If conversions stepped down after a banner change and you need to know which half of that drop is real, a free tracking audit will tell you, with the dates.