A tag read consent state before a default was set. What to do about it?

Here’s a situation. You implemented Google Consent Mode in Google Tag Manager. When you enable the preview mode and check the Consent tab, there’s an error “A tag read consent state before a default was set”.

In this guide, I will explain why it happens and what to do about it.

What does this error mean?

The error is pretty self-explanatory. If some tags (that use consent settings or have built-in consent checks) fire before the default consent state has been set, this error occurs. If not handled properly, this can lead to inaccurate data collection.

In the next chapter, I’ll briefly explain what a default consent state means.

Consent Mode in a nutshell

When consent mode is implemented on a website, there are two types of commands available:

• Default
• Update

They inform tags about the current consent state, which can affect how they behave.

The default command is necessary to set the default state. For example, if a visitor lands on your site for the first time, the values in the default command should be denied, for example:

gtag('consent', 'default', {
    'ad_storage': 'denied',
    'analytics_storage': 'denied',
    'ad_user_data': 'denied',
    'ad_personalization': 'denied',
    'wait_for_update': 500
  });

If some Google Tag (e.g., GA4) fires after the default command sets analytics_storage to “denied”, it will not use/set cookies.

When a visitor gives consent, an update command should be called with the new values, e.g.:

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

If another GA4 tag fires after the “update” command sets analytics_storage to “granted”, then the tag will use cookies and will send data as usual.

But if a tag (that has built-in consent checks or uses additional consent settings) fires before the default command is set, it will also behave as usual. It means that if the visitor has not given consent (yet) and you have already fired tracking codes, they will track that visitor as usual.

So, if some tags fire without any consent data, then others fire after the consent default is set, things might get messed up in your analytics (or ad accounts).

That’s why you should not ignore the error “A tag read consent state before a default was set”. Verify if everything works fine.

However, spoiler alert: I will explain another situation where this error is not a big deal later in this article. But first, let’s focus on a situation where your Consent Mode setup is indeed incorrect.

What should you do about it?

You should check the order in which the tags fire on your site. Are there any tracking tags that fire before the default consent is set?

Enable the GTM preview mode and check where the “Consent Default” appears on the left sidebar of the Tag Assistant.

It should appear as soon as possible, ideally before the Initialization event (that’s when the Google Tag for Google Analytics 4 usually fires). If not, that might be a problem. Then what? Here are some tips.

Activate your CMP as soon as possible. If you have installed a Consent Management Platform (CMP) (with a consent mode integrated) via Google Tag Manager, ensure its tag fires on the Consent Initialization. That’s the earliest moment when the tags can fire in GTM, and as the event name implies (“Consent initialization”), it’s explicitly designed for tags that deal with the consent stuff.

As for all other non-consent-related tags, fire them later. For example, Google Tag (for GA4) should fire on Initialization (or even a bit later). Do not fire your tracking codes on Consent Initialization. Fire them later.

What if CMP is slow? If you are using a CMP that takes more time to load and the consent defaults are not set very quickly, consider moving the CMP out of Google Tag Manager and instead ask the developer to implement that CMP code directly in the source code of the website *above* Google Tag Manager container. That should improve the situation.

Or, alternatively, you could switch to another CMP. Not all of them are convenient to work with, so it’s ok to look for alternatives. From my experience, Cookiebot is ok, Cookiehub is fine, too. And there are many more options. You will have to investigate what fits your needs the best.

You can also disable the consent mode in CMP and implement it yourself. Many modern CMPs offer Consent Mode integration. And I believe that most of them allow you to disable that.

In that case, you could implement a custom setup yourself (where you or a developer) that sets the default consent state (e.g., it can always be “denied”), and then once the real consent state is known, the “update” command is used. I explain how to build a custom setup in my GTM course for beginners.

This error isn’t always a problem

Here’s the fun part. Sometimes, people verify everything in and out and don’t find anything wrong. Yet, the error “A tag read consent state before a default was set” still persists. Why?

When the error says “A tag read…”, it’s a bit misleading. It does not necessarily mean “a tag”. It means “Something in your container read the consent”. That “something” can also be a variable.

I have seen some GTM containers with custom variables reading the consent. This can be useful in some situations.

For example, there is a custom variable template called GTM Consent State (created by Ayudante) that reads the current consent mode state and then returns “true” or “false” if some consent category is “granted” or “denied”. In fact, I found more templates that also check the consent state (I am not sure if they check consent mode specifically or not, though).

When the GTM preview mode is enabled, all variables in your container are evaluated on every event that is visible on the left sidebar (except “Message”).

Here’s an example. If your default consent state is set immediately after the “Initialization” event (while your tracking tags fire later), you will still get the error that the consent state was read too early. Why? Because GTM preview mode will invoke the GTM Consent State variable sooner.

It will invoke it on Consent Initialization, Initialization, Container Loaded, etc. At every event, the variable’s code will be run and it will read the consent state. To Ayudante’s defense, I checked their template code and found that they don’t read the consent on the “Consent Initialization” event. But in all other events, the consent is read.

So, it’s possible that while your tag and consent mode setup is correct, some variable(s) will read the consent status before the default command is set. This does not have any negative effect on your configuration, and there’s nothing to worry about.

If you found Ayudante’s (or similar) variable in your container and you want to verify if it is causing the error, do this:

• Temporarily delete the variable from the container (don’t publish the changes)
• Enable GTM preview mode
• Check if the error is gone in the Preview Mode. If yes, then your consent mode setup is correct, and you just had a false positive. Feel free to ignore the error.

A tag read consent state before a default was set: Final Words

To sum up, you should not ignore this error at first. Verify that the default consent state is set before any tag (that uses the consent checks) fires. GTM preview mode is helpful for that.

But if you tested everything thoroughly and could not find any problem, then there is a chance of a false positive.

You may have a custom variable that reads the consent state. GTM preview mode evaluates/invokes variables on each data layer event, which means that a particular custom variable can read the consent before the default is set.