GA4 Traffic Dropped After a Cookie Banner Change? Expected Consent Loss or Tracking Problem?

Start outside GA4.

Look for independent evidence of what happened around the date of the CMP or consent change.

Depending on the business, that might include:

• Google Search Console clicks;
• Shopify or ecommerce orders;
• CRM lead volumes;
• form-platform submissions;
• booking volumes;
• server or platform traffic data;
• other operational measures of website activity.

These systems do not measure the same thing as GA4, so their numbers should not be expected to match exactly.

They are useful because they can help establish whether the underlying business activity changed at the same time.

For example:

Search Console clicks remain broadly stable, but GA4 organic sessions fall sharply on the day a new CMP goes live.

That does not prove the CMP caused a tracking fault.

But it is a strong reason to investigate measurement before concluding that organic traffic actually disappeared.

Likewise, if GA4 conversions fall but the business continues to receive roughly the same number of orders or enquiries, the measurement change deserves attention.

A useful investigation starts with the deployment timeline.

Identify:

• when the new CMP or cookie banner went live;
• when Consent Mode was introduced or changed;
• whether GTM was republished;
• whether the Google tag implementation changed;
• whether the website launched or changed at the same time;
• whether regional banner behaviour changed;
• whether consent categories were remapped;
• whether tags that previously loaded freely became consent-controlled.

Then compare that timeline with the change in GA4 data.

A sudden measurement shift that begins on the same date as a CMP deployment is more actionable than a vague decline spread across several weeks.

Google supports two broad Consent Mode implementations: basic and advanced.

They do not produce the same measurement behaviour.

Basic Consent Mode

With Google's basic implementation, Google tags are blocked until the user interacts with the consent banner and grants the relevant consent.

Before consent is granted, no data is sent to Google through those tags.

This can create a substantial difference between actual site usage and the users visible in GA4.

Advanced Consent Mode

With advanced Consent Mode, Google tags load with consent defaults in place.

Where consent is denied, Google says consent state information and cookieless pings can still be sent. When consent is granted, the tags can use the permitted storage and send fuller measurement data.

The important point is not that one method is universally "better".

It is:

You cannot interpret a post-CMP drop properly unless you understand which measurement architecture is now being used.

Two websites with visually similar cookie banners can produce very different GA4 behaviour depending on how consent is implemented underneath them.

Suppose a website previously loaded analytics for nearly every visitor.

It then introduces a CMP that prevents analytics storage or tag loading for some users depending on their consent choice.

GA4 may now observe fewer users, sessions and events.

That does not necessarily indicate a broken implementation.

It may simply mean the measurement now reflects the consent architecture that has been introduced.

Google's own documentation notes that consent affects the data available to Analytics and that users who decline analytics cookies can create gaps in directly observed data.

This is why the right question is not:

"How do I get the old traffic number back?"

It is:

"Is the new behaviour consistent with the consent implementation we intended?"

Consent Mode introduces several points where configuration can go wrong.

Google's current troubleshooting guidance specifically highlights problems such as:

• consent defaults not being set;
• defaults being set too late;
• consent state failing to update after the user interacts with the banner;
• tags being blocked in ways that prevent the intended Consent Mode behaviour;
• regional settings leaving users in an unintended consent state.

So a data drop should not simply be dismissed as "that's consent".

It still needs to be tested.

When the page initially loads, the intended default consent state should already be available before relevant Google tags act on it.

Google recommends using Tag Assistant to inspect the earliest consent event and verify states including:

• analytics_storage;
• ad_storage;
• ad_user_data;
• ad_personalization.

The exact state you expect depends on the implementation and region.

The diagnostic question is:

Was a default state set when the tags needed it?

If tags read consent before a default exists, Google can flag that the state was set too late.

Interact with the banner as a real user.

Grant the relevant consent and inspect whether the consent state updates correctly.

Google's Tag Assistant verification process specifically recommends checking the latest consent event after banner interaction and confirming that the updated values reflect the user's choice.

If the visitor accepts analytics cookies but analytics_storage remains denied, measurement can continue to behave as if consent was never granted.

That would point towards an implementation or CMP integration issue rather than normal consent-related loss.

Do not only test the happy path.

Repeat the process with the relevant consent rejected.

Then inspect:

• the resulting consent state;
• which tags fire;
• which tags remain blocked;
• whether behaviour matches the intended basic or advanced implementation.

Google recommends checking fired and blocked tags directly in Tag Assistant after consent interaction.

The point is not to force tags to fire.

It is to verify that they behave consistently with the consent state they have been given.

One implementation problem worth checking is additional consent blocking layered on top of Google's built-in consent behaviour.

Google documents cases where tags using Consent Mode are also blocked by:

• consent-based trigger conditions;
• additional consent requirements in GTM;
• CMP settings;
• other tag-blocking mechanisms.

That can result in tags not behaving as intended even though Consent Mode itself is configured.

This does not mean additional controls are always wrong.

It means you need to understand the combined architecture.

If a Google tag is designed to respond to consent state but is also prevented from loading by another rule, the resulting measurement can differ substantially from what was expected.

This distinction matters enough to repeat.

In a basic implementation

Tags are prevented from loading until consent is granted.

If a user never grants consent, Google says no data is sent by those tags before consent.

A website moving from unrestricted measurement to this setup could therefore see a substantial reduction in observed GA4 traffic without anything being technically broken.

In an advanced implementation

Google tags load with consent defaults and adjust their behaviour according to the consent state.

Where storage is denied, cookieless measurement may still be sent.

This can support modelling where the property meets Google's requirements.

The important point is that the same consent rate does not necessarily produce the same GA4 reporting behaviour under both architectures.

GA4 can use behavioural modelling for eligible properties to estimate some activity from users who decline analytics cookies.

Google currently requires, among other conditions:

• Consent Mode across the relevant pages;
• an advanced implementation on the web;
• at least 1,000 events per day with analytics_storage='denied' for at least seven days;
• at least 1,000 daily users sending events with analytics_storage='granted' for at least seven of the previous 28 days.

Google also states that meeting those prerequisites does not guarantee eligibility because additional model-quality criteria apply.

This is especially relevant for smaller businesses.

You should not assume:

"Consent Mode will model back all of the users we can no longer observe."

It may not.

Even where behavioural modelling is available, modelled and directly observed data are not the same thing.

There is no universal rule such as:

"A 20% drop after a cookie banner is normal."

The effect depends on factors including:

• user consent rates;
• geography;
• banner design and behaviour;
• basic versus advanced Consent Mode;
• previous measurement implementation;
• browser mix;
• site audience;
• which tags depend on which consent states.

A 10% change can hide a serious implementation problem.

A much larger change can sometimes be explainable.

The better question is:

Does the behaviour match the architecture and user choices we intended?

Overall GA4 traffic can look plausible while key business outcomes are still affected.

Test important journeys individually, such as:

• contact forms;
• quote requests;
• bookings;
• ecommerce purchases;
• registrations.

For each journey, test the relevant consent states and verify:

1. what the user does;
2. what success looks like;
3. whether the underlying website event occurs;
4. whether the measurement tag behaves as intended;
5. whether GA4 receives the expected event where appropriate.

A conversion drop that is materially larger than the traffic drop can indicate that the issue sits in the conversion implementation rather than the base GA4 configuration.

Consent implementations are often region-aware.

Google's own troubleshooting guidance describes scenarios where users can receive a denied default consent state but never see a banner that allows them to update that state because the regional targeting of the banner and consent defaults do not align.

That can produce highly uneven measurement patterns.

If the change appears concentrated in particular countries or regions, inspect whether:

• the banner is displayed there;
• the same default consent settings apply;
• users can update those settings;
• the intended tag behaviour is consistent.

Do not assume one successful UK test proves that every regional implementation behaves the same way.