Basic vs Advanced Consent Mode: The Complete Guide

Google’s Consent Mode comes in two variants with radically different technical implications. Misconfiguring the chosen mode means losing either data or GDPR compliance. This guide details the differences, pitfalls, and best practices, drawing notably on analyses by Simo Ahava.

Advanced Consent Mode: Apparent Simplicity

In Advanced Consent Mode, Google tags (GA4, Google Ads, Floodlight) fire immediately on page load but automatically adapt to the consent state. Without consent, they send cookieless pings that allow Google to model conversions. With consent, they work normally.

The advantage is simplicity of implementation. Tags fire normally, and Google’s SDK handles the adjustment. The downside: data (even anonymized) is sent before consent, which some data protection authorities consider problematic.

Basic Consent Mode: Full Control

In Basic Consent Mode, tags are completely blocked until the user has given consent. No data is sent, no pings, no network requests. This mode offers the strictest compliance but requires rigorous manual implementation in GTM.

The Four Signals to Master

Consent Mode relies on four signals that your CMP must manage:

• ad_storage: authorizes storage of advertising cookies (gclid, conversion linker)
• analytics_storage: authorizes storage of analytics cookies (GA4 client ID)
• ad_user_data: authorizes sending user data to advertising platforms
• ad_personalization: authorizes remarketing and lookalike audiences

The recommended pattern: set all signals to denied in the Consent Initialization trigger, then update via a dataLayer event when the user consents. For more details on implementation, see our practical Consent Mode v2 guide.

The Critical Additional Consent Checks Bug

Here is the most treacherous trap in GTM with Basic Consent Mode. You configure a tag with a “Once per page” trigger (like All Pages) and add Additional Consent Checks to that tag. The scenario: the user arrives, consent is denied, the trigger fires but the tag is blocked. The user accepts cookies. Consent changes to granted. But the “Once per page” trigger has already been consumed. The tag will never fire again on that page.

Result: zero data collected even after explicit consent. This bug is silent and can go unnoticed for weeks.

The Solution: Trigger Groups

The solution recommended by Simo Ahava is to use Trigger Groups rather than Additional Consent Checks. A Trigger Group waits until all conditions are met simultaneously before firing the tag. Create a group combining the Page View trigger and a trigger on the consent update event. The tag will only fire when both conditions are met.

This approach works in both Basic and Advanced Consent Mode and eliminates the consumed trigger problem. To go further on compliance, see our Consent Mode v2 FAQ.