Consent Mode v2 for Malta and EU websites: what it changes in reporting

If you use GA4, Google Ads or other Google measurement tools on a website serving users in Malta or elsewhere in the EEA, Consent Mode v2 is likely to be part of your setup. The important thing to understand is what it actually does. Consent Mode does not collect consent for you. It does not decide whether a particular tag is lawful. And it does not restore every analytics event that disappears when somebody rejects tracking.

Its job is narrower: it tells Google what consent state applies, so supported Google tags can change their behaviour accordingly. That makes it somewhat useful, but it also means there are several separate pieces that all need to work properly.

The three parts people often mix together

A typical consent setup has three different jobs.

1. Ask for the visitor’s choice

The website or consent-management platform has to present the relevant choices and record what the visitor selected. Consent Mode does not provide the banner itself.

2. Make the tags follow that choice

Once the visitor has made a choice, that state needs to reach Google and any other services whose behaviour depends on it. For supported Google tags, Consent Mode is the mechanism that carries those signals. Third-party scripts still need their own consent controls.

3. Understand what is left in the reports

Once some visitors decline measurement, your reporting changes. Some data may be observed directly, some may be modelled, and some may simply not be available. That distinction matters when somebody later asks:

“How many people actually did this?”

A technically correct consent implementation can still produce reporting that needs careful interpretation.

What changed with Consent Mode v2

Consent Mode already had signals such as analytics_storage and ad_storage. Google later added two more:

• ad_user_data
• ad_personalization

ad_user_data communicates whether user data may be sent to Google for advertising purposes. ad_personalization communicates whether data may be used for personalised advertising. These signals became particularly important for businesses using Google advertising products with users in the EEA.

Google’s current guidance says advertisers sending EEA user data to Google must collect the relevant consent and communicate those choices if they want to retain applicable measurement, personalisation and remarketing functionality. For existing Consent Mode implementations, that is what the move to “v2” was mainly about. It did not fundamentally reinvent how consent works. It added more granular signals for Google’s advertising use cases.

Basic and advanced mode are quite different

This is probably the most important implementation decision.

Basic Consent Mode

In basic mode, Google tags are blocked until the visitor makes a choice. If the visitor does not consent, the tags do not send data to Google at all. Google describes this as the more restrictive implementation. Conversion modelling can still be available, but it relies on a more general model because there is less site-specific information available.

Advanced Consent Mode

In advanced mode, Google tags load immediately with consent set to denied by default. While consent remains denied, Google says those tags can send cookieless measurements containing limited information. If the visitor later grants consent, the tags can begin using the relevant storage and send fuller measurement data. Those cookieless signals can give Google more information for modelling. That can improve reporting compared with basic mode. It does not mean rejected visitors suddenly become normally tracked users.

Advanced mode does not mean “tracking without consent”

This is where marketing descriptions often get sloppy. Advanced Consent Mode can send limited cookieless requests while storage-related consent is denied. That does not mean:

“We can track everybody anyway.”

What is actually sent depends on the Google product, consent state and implementation. And whether a particular setup is appropriate under applicable law is a separate question from whether Google technically supports it. In the EU, the legal picture involves both ePrivacy rules and the GDPR.

Article 5(3) of the ePrivacy Directive governs storing information on, or accessing information from, the user’s device in most cases. Where personal data is then processed, GDPR requirements apply as well. The European Commission reiterated this distinction in its 2025 analysis of the framework.

Consent Mode does not replace that assessment. It implements a technical response to the consent state you provide.

What happens to GA4 data when users reject

If you use basic mode and analytics consent is denied, GA4 will not receive normal analytics data from that visitor. That means your directly observed GA4 dataset becomes smaller. In advanced mode, Google may receive cookieless measurements and use them as part of behavioural or conversion modelling where the relevant product requirements and thresholds are met. A report may therefore contain a mixture of:

• directly observed behaviour;
• modelled behaviour;
• data from users who consented;
• gaps where no reliable measurement is available.

I would not describe modelling as reconstructing what each unconsented visitor actually did. It is an estimate. Useful, potentially. Ground truth, no.

Why your numbers may change after implementation

If you introduce a proper consent setup and GA4 sessions suddenly drop, that does not automatically mean the implementation is broken. It may simply mean the previous implementation was collecting data that the new setup no longer collects under the same conditions. The useful questions are:

• Did tracking drop only for visitors who rejected consent?
• Are consented visitors still measured correctly?
• Are Google Ads conversions still arriving as expected?
• Did the change affect all pages or only certain templates?
• Does GA4 show modelling where expected?
• Do backend orders or leads still match the overall business trend?

That is much more useful than trying to force post-consent analytics totals back to the old number.

The implementation order matters

Consent setups can fail even when every individual component appears to be installed correctly. The order in which defaults, tags and consent updates are processed matters.

Google explicitly says consent defaults need to be set before the relevant tags fire. For Tag Manager implementations, it recommends using its Consent APIs or CMP templates rather than trying to configure consent through Custom HTML tags. A typical setup therefore looks roughly like this:

1. Set the initial consent state before normal tracking runs.
2. Load the consent-management interface.
3. Let the visitor make a choice.
4. Update the consent state immediately.
5. Let supported tags respond to that update.

If that ordering is wrong, you can end up with tags firing too early or with granted consent arriving too late for the page event that was supposed to use it. Those race conditions are surprisingly common.

Google Consent Mode only controls supported tags

Another important limitation: Consent Mode is not a universal consent switch for the entire website. Google tags understand the relevant Consent Mode states because they were built to. A random third-party chat widget, tracking script or Custom HTML tag does not automatically become consent-aware just because GTM contains Consent Mode.

Those integrations still need to be configured so they respect the relevant consent choice. That is why testing the banner visually is not enough. You have to check what actually loads and what requests leave the browser.

How I would test an implementation

I would test at least four states.

First visit, before making a choice

Check which tags load, which cookies exist and which network requests are already being sent.

Accept

Confirm that the relevant consent states change and that the expected analytics and advertising tags start working.

Reject

Check that anything that should remain blocked actually stays blocked. For advanced Consent Mode, verify what limited Google requests still occur and that no unexpected third-party tags are firing.

Change or withdraw consent

The implementation also needs to work after the initial banner interaction. A visitor who changes their preference should not remain stuck in the old consent state because the website only handled the first page load. Google’s Tag Assistant can show both default and updated states for analytics_storage, ad_storage, ad_user_data and ad_personalization, which makes it useful for debugging this flow.

Problems I regularly see in real implementations

Across consent and analytics work on more than 50 websites and client projects, I have seen both sides of the problem. Sometimes tags fire despite consent being denied. Sometimes the opposite happens: the visitor accepts, but the analytics or advertising tag still fails because the consent update and page event happen in the wrong order. Other common problems include:

• Consent Mode configured correctly for Google tags while third-party tags ignore it.
• Tags firing before the consent defaults are available.
• CMP settings and GTM settings contradicting each other.
• Different behaviour between the first page and subsequent pages.
• Consent working on the main site but breaking inside checkout or another domain.
• A technically working banner paired with reporting nobody understands afterwards.

My anonymous consent integration examples cover some of these cases in more detail.

What Consent Mode means for reporting

The main reporting consequence is simple: you should expect directly observed data to become less complete when visitors decline measurement. That does not make GA4 useless. It means GA4 should be treated as one measurement system rather than as an unquestionable record of the business. For ecommerce, lead generation and booking sites, I like to compare three layers:

GA4 / Ads
What did the measurement system observe or model?

Backend / CRM / ecommerce platform
How many leads, orders or bookings actually happened?

Consent data
What proportion of visitors could be measured under the chosen setup?

That makes it much easier to understand whether a reporting change reflects the business or merely the measurement system.

What I would document at handover

For a consent implementation, I would want the client to leave with a clear record of:

• which tags and vendors are in scope;
• what purpose each integration serves;
• the default consent states;
• what changes after acceptance or rejection;
• how non-Google tags are controlled;
• how changing or withdrawing consent behaves;
• which reporting gaps remain;
• and which legal or organisational decisions sit outside the technical implementation.

That documentation becomes especially useful six months later when somebody adds a new marketing tool and nobody remembers why the existing tags behave the way they do.

Do you need Consent Mode v2?

If your site uses Google measurement or advertising products and serves users in the EEA, you should review whether the relevant consent signals are being collected and communicated correctly. For advertisers, Google explicitly requires the relevant EEA consent signals for applicable measurement and advertising features. But implementing Consent Mode v2 should not be treated as a standalone checkbox. You still need:

• a consent mechanism appropriate to the site;
• correct tag behaviour;
• control over non-Google integrations;
• testing;
• and reporting that acknowledges the resulting measurement limits.

For GDPR integration work, I handle the technical side of that setup: consent signalling, GTM and analytics behaviour, third-party integrations, testing and documentation.