Skip to main content

Google Tag Manager and Integrated Consent Management

GTM integrates several native mechanisms to manage consent. Here's what they do and how they articulate with Axeptio.

Written by Alexandre Dias Da Silva

GTM includes several native mechanisms to manage consent: Consent Mode, Consent Settings (Built-In and Additional Consent Checks), and Consent Overview. These features can be useful if you don't use a CMP or if you manage consent manually, but they often cause confusion when using a CMP like Axeptio — you might think you need to configure them to be compliant. Here's what each one actually does, and how they work with Axeptio.

Consent Mode

Consent Mode is a proprietary Google mechanism. It allows Google tags (Google Ads, GA4, Floodlight
) to modify their behavior based on consent signals (ad_storage, analytics_storage, ad_user_data, ad_personalization, etc.): for example, sending anonymized data rather than not executing at all. Google designed it with universal ambition — the 7 available signal types (ad_storage, analytics_storage, ad_user_data, ad_personalization for Google services, and functionality_storage, personalization_storage, security_storage for third-party tags) are proof of that. In practice, however, few third-party services have made their templates consent-aware, and Consent Mode does not allow managing consent service by service.

Axeptio integrates with Consent Mode: it sets the default signals when the page loads and updates them based on user choices. For this integration to work, you must have properly configured Consent Mode by following the dedicated guide.

Consent Settings (Beta)

In each GTM tag, a Consent Settings (Beta) section is available. It displays two distinct blocks.

Built-In Consent Checks

Built-In Consent Checks indicate which Consent Mode signals the tag natively checks (for example ad_storage and analytics_storage for a Google Analytics tag). You cannot modify them — GTM determines them automatically based on the tag type, and they are only visible if the tag template actively accesses the consent state in its code.

These checks do not block tag firing. In advanced Consent Mode — that is, if the tag fires without being conditioned by an Axeptio trigger — they modify its behavior based on the state of signals: a Google Ads tag will send anonymized data rather than personal data if ad_storage is denied, for example. Since Axeptio manages these signals, the Built-In Checks work automatically without any configuration on your part.

Additional Consent Checks

This setting allows you to condition tag firing on the state of specific Consent Mode signals. It is particularly useful in configurations without a CMP, or with a CMP that manages only purpose categories without granularity at the service level.

It offers three options:

  • Not set — no additional checking (default behavior)

  • No additional consent required — the tag fires without additional consent condition

  • Require additional consent for tag to fire — the tag is blocked until the specified signals are granted

With Axeptio, leave this setting on "Not set". "No additional consent required" is also acceptable, but "Not set" is more accurate: you are not declaring that the tag does not require consent, you are simply letting Axeptio handle it.

This choice has a display effect in the Consent Overview: tags set to "Not set" appear in "Consent not configured", while those set to "No additional consent required" appear in "Consent configured". Both are correct with Axeptio — it's only a display matter, not a compliance issue. If the Consent Overview creates confusion in your team, note that it is possible to disable it in Admin > Container Settings, by unchecking "Enable consent overview".

Why not use "Require additional consent for tag to fire" with Axeptio?

There are two reasons. First, if you have already conditioned your tags according to our recommendations, this creates a double condition: GTM checks consent on its side, in parallel with what Axeptio has already communicated. A tag may then never fire, even if the user has given consent.

Second, this option asks you to link a tag to a Google Consent Mode signal, whereas Axeptio follows a different philosophy. Axeptio manages consent service by service: each service is accepted or refused individually. If you link a Meta pixel and a Pinterest pixel to the same ad_storage signal, you condition them to the same outcome — while a user may well have accepted one and refused the other. You lose the precision that Axeptio gives you, and the control you offer your visitors.

The Consent Initialization trigger

GTM offers a native trigger called Consent Initialization - All Pages. It fires before any other trigger in the container — it is the very first to execute on each page. Its role is to establish the default values of Consent Mode signals before other tags start to fire.

That is exactly what Axeptio does: it relies on this trigger to set the default signals as soon as the page loads, before everything else. If you load Axeptio via GTM, you must configure your Axeptio tag with the Consent Initialization - All Pages trigger — not "All Pages" or "Page View". Without this, other tags may fire before Axeptio has had time to set the default Consent Mode signals.

Axeptio triggers: the recommended approach

Managing consent with Axeptio is done through the events and variables that Axeptio sends to GTM, not through Consent Settings. This approach allows you to condition each tag to the consent of the corresponding service, with the granularity necessary to be compliant.

To configure your tags, start with Conditioning your GTM tags to consent: introduction.

Did this answer your question?