Simply Explained: Consent Mode

1. Understanding the consent mode flags

If you are reading this, you are probably using Google measurement and marketing products such as Google Analytics, Google Ads, and others.

So first things first, you need to know about the consent mode flags:

Storage flags

These flags indicate whether the user allows usage of browser or app storage (eg. cookies) for:

• analytics_storage: Analytics purposes
• ad_storage: Advertising purposes
• personalization_storage: Personalization purposes
• functionality_storage: Website or app functionality purposes
• security_storage: Website or app security purposes

Take note that the flag values can change how Google tags (eg. GA, Google Ads, Floodlight) behave. More details below.

Processing flags

These flags tell Google how to process the data at the back end:

• ad_user_data: Consent for sending user data related to advertising to Google
• ad_personalization: Consent for personalized advertising

Normally their values will correspond to the ad_storage and/or personalization_storage flags.

Take note that the flag values have NO impact to how Google tags behave.

There are other advanced flags (eg. to handle data redaction). For the full details, please refer to the official Consent mode reference.

Consent mode flags are passed to Google compliance services

When a Google tag is fired and “denied” or “granted” values are set for these flags, they are automatically sent to Google services for compliance purposes.

This applies only to Google tags (eg. GA, Google Ads, Floodlight).

2. Mapping your website consent choices to the consent mode flags

The consent mode flags are a Google thing. You need to map your website consent choices to the Google consent mode flags accordingly.

For example:

• Strictly necessary cookies → functionality_storage, security_storage
• Performance cookies → analytics_storage, personalization_storage
• Marketing cookies → ad_storage, ad_user_data, ad_personalization

Many Consent Management Platforms (CMP) do this automatically if you enable “Consent mode” integration.

If your CMP does not do this automatically or you are using your own custom consent banner system, you have to do the mapping manually.

For example, when the page loads, it’s highly recommended to set the default flag values. You can fire a Custom HTML tag in Google Tag Manager (GTM) at the Consent Initalization event like this:

<script>
gtag('consent', 'default', {
  'ad_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'analytics_storage': 'denied'
});
</script>

When the user confirms the consent choices, or when the user’s saved consents are retrieved automatically on subsequent pages, you can fire a Custom HTML tag in GTM like this:

<script>
gtag('consent', 'update', {
  'ad_storage': 'granted',
  'ad_user_data': 'granted',
  'ad_personalization': 'granted',
  'analytics_storage': 'granted'
});
</script>

For better security, we recommend using a GTM custom template tag instead (such as this by Simo Ahava) so that you don’t have to write any JavaScript codes that could present a security concern.

3. Google Tag Manager tag firing strategy

CMPs provide many ways for you to integrate with GTM. Typically they have:

(1) Data layer events such as:

• Generic action events like: Consent Status, Consent Updated
• Or specific consent flag events like: Analytics Consented, Marketing Consented

(2) Data layer variables or cookies indicating the allowed/denied states of the consent flags.

With this info, let’s look at a few ways you can control the tag firing.

(A) No consent mode

You can choose not to use the consent mode flags at all to control the firing of your tags. For this method, you solely rely on GTM triggers.

(1) You may set all the default consent mode flags to “granted”.
(2) For each tag, set up the triggers according to the (a) original firing event, AND (b) when consent is given.

For example:
GA event tag: Trigger = Page View event AND analytics_consent variable = “allowed”

Better yet, use GTM trigger group. The reason is that most websites do not reload the page when the user confirms the consent choices. Take this scenario as an example:

(1) Landing page, consents are not given so no tags are fired
(2) User consents, but the page doesn’t reload, tags are still not fired
(3) User navigates to the next page, consents are now given, tags fired

This results in issues such as:
- The next page is first page recorded, so it becomes the Landing page, incorrectly
- The campaign parameters on the first page is not recorded, so you lose the accurate traffic source data

Change to GTM trigger group instead. For example:

GA event tag: Trigger group =

• Page View event
• Consent Updated event AND analytics_consent variable = “allowed”

This will ensure that the tag is fired when the two conditions are met (the sequence of the events doesn’t matter).

To illustrate:

Notice how the firing control is on the GTM triggers side.

Notice how GTM triggers (green arrows) now allow firing of tags. Also take note that for Google tags, the consent mode flags are passed to Google services.

(B) Consent mode (Basic)

For this method, you can choose to use the consent mode flags to control the firing of your tags, much like GTM triggers.

This setting is in the tag’s Advanced Settings > Consent Settings section:

Note that the setting is IN the tag itself.

What this means is that it’s like a 2-stage check:

1. The GTM trigger fires the tag based on the original firing event
2. The tag then does further check to see if the required consent flag(s) are set to “granted”

For example:
GA event tag (requires analytics_storage to be granted): Trigger = Page View event

To illustrate:

Notice how the tags have additional (like a 2nd stage) consent mode flags check before they allow the firing.

Whether to use this method or not, I’m currently on the fence. The additional consent check seems to be too “deep” and “hidden” in layers. Also, remember that the consent mode flags are Google terminology. Altogether it can makes it hard for you to comprehend all the tags firing conditions.

(C) Consent mode (Advanced)

This method works for Google tags only. Basically, what it means is that you always allow Google tags to fire, but the tag behavior will change based on the consent mode flags.

To illustrate:

When consent is not given, the hits are still being sent, but without using any cookie info.

When consent is given, everything is as per normal.

One of the added benefits of this method is that the tags will automatically re-fire when consent mode flags are updated.

Summary

Currently, my personal preference is:

• Google tags: Use (C) Consent mode (Advanced) method, as everything is pretty much automatic when the consent mode default and update flags are set up correctly.
• Non-Google tags: Use (A) no consent mode method.

Sparkline aims to provide data accuracy, comprehension and consolidation, and most importantly, tangible insights for businesses. Get in touch if you’d like to find out more.