8 Reasons Why a Tag in Google Tag Manager is Not Firing (or Fires When it Shouldn’t)

Updated: October 24th, 2022. 

You have configured a tag in Google Tag Manager, enabled Preview and Debug mode, try to test it, but it behaves not as you expected. Even though you think you did everything right, it does not fire. Or maybe it does fire, although it shouldn’t. Why is that happening?

In today’s blog post, we’ll dive into a bunch of reasons why a tag in Google Tag Manager is not firing (or maybe it fires when it should not).

Some of the reasons below are pretty straightforward because you can easily find the reasons just by looking at the preview and debug mode. However, in some cases, preview mode does not tell you a thing, which is more confusing.

So buckle up, and let’s start.

If you want to learn more about debugging with Google Tag Manager, you might also find this article useful.

 

 

Table of contents

• #1. Incorrect trigger
• #2. Blocking trigger is added
• #3. Misunderstood Functionality of Blocking Triggers
• #4. Tag Sequencing
• #5. Tag Firing Options
• #6. Tag Firing Schedule
• #7. Fire a tag only in published containers
• #8. gtm.blocklist
• Bonus tip #1 – properly refreshed the preview and debug mode
• Bonus tip #2 – tag is “Still running”
• Bonus tips #3 – Broken Data Layer
• Final words

 

Video tutorial

If you prefer video content here’s a tutorial from my Youtube channel.

 

#1. Incorrect trigger

The first thing to check why your tag did not fire in GTM is firing triggers. Here’s a simple process to follow when this happens:

• Choose an event in the Preview and Debug console’s event stream (left side) and click the tag that behaved unexpectedly.

• Scroll down to see all the linked triggers linked to that tag. Take a closer look at the icons next to conditions. Check if the icon next to the trigger name is a green checkmark.

If yes, this trigger activated the tag (or at least was supposed to). Whether the condition was met or not, every tag condition will be accompanied by a red cross or a green checkmark.

This helps you identify possible reasons why a tag fired (or didn’t). For a tag to fire, ALL conditions in a single trigger must be met. If a tag is linked to multiple triggers, AT LEAST ONE of the triggers must be activated.

A common mistake among beginners is not knowing the relationship between all the conditions in a single tag. Here’s an example.

You want to fire a tag on three pages, /pricing/page1/, /pricing/page2/, /pricing/page3/. If you’re fairly new to using Google Tag Manager, you might think the following trigger is a good choice.

However, it’s NOT. As GTM’s interface instructs, ALL conditions in the same trigger must be met. What would happen here is that this trigger will never be activated. Think about it, how can any website’s URL contain all three options? (page1, page2, page3).

In this case, you have two options:

• Create three separate triggers for each page (not very optimal, especially when your condition can grow to 10, 20, or more pages in the future) and assign all of them to a single tag.
• Use regular expressions in a single trigger, e.g. \/pricing\/page(1|2|3)\/

 

#2. Blocking trigger is added

Blocking triggers are negative conditions that define when a tag should NOT fire. Even if there are multiple trigger conditions and they are all met, the blocking trigger has a higher priority.

To find out whether the tag is not firing in Google Tag Manager, follow the same process as in the previous chapter.

First, choose the event in the preview console (left side) when your tag was supposed to fire, then click the tag and scroll down to see which triggers were activated.

Even if all the conditions of the firing trigger contain the green checkmark, scroll down to the section “Blocking Triggers”. If you see at least one trigger with all the green checkmarks, then that is the reason why your tag did not fire.

 

#3. Misunderstood Functionality of Blocking Triggers

On the other hand, maybe you are familiar with blocking triggers and expect they will block a certain tag from firing. However, for some reason, the tag still fired (even though you are 100% positive that all the conditions of the blocking trigger worked).

If this situation arises for you, you’ve misunderstood how blocking triggers (a.k.a. Exceptions) work.

You see, blocking triggers work only against firing triggers that use the same events. Confused? Let me explain with an example.

You have a tag that fires on the menu link click. Here are the trigger’s conditions:

 

But on some occasions, you want that to be blocked. If you decide to achieve this with the blocking trigger, the only way it can work is if the blocking trigger uses the same type of trigger, link click (a.k.a. Just Links).

No other trigger will block the link click trigger except the link click trigger.

If you try to block the link click trigger with the Pageview trigger, that will not work. And the same principle applies to all trigger types in GTM.

So the key takeaway here is that you fight fire with fire. A link click trigger can block another link click trigger, a pageview trigger can block another pageview trigger, etc. Learn more about trigger exceptions here.

#4. Tag Sequencing

Now let’s move to a reason that is not displayed in the GTM preview and debug mode (at least for now). Here’s a situation. Let’s say you have a tag with only one trigger — All Pages.

But for some reason, the Summary section in the Preview & Debug Mode shows the tag fired twice. Why?

There is a feature in GTM called Tag Sequencing, which could have caused this. In a nutshell, with tag sequencing, you can create a chain of tags, e.g. if one tag fires, then fire another tag.

Even if the tag’s main firing trigger’s conditions are not met at a certain point, tag sequencing will still fire a tag. And that’s probably why your tag was fired twice:

• First time on a Page view event (due to All Pages trigger)
• And the second time because of the Tag Sequencing.

Unfortunately, GTM’s preview and debug mode is not friendly here. It will not tell whether the tag was activated because of tag sequencing.

But you can still figure this out. To do that, first, head over to your GTM container’s interface and open the tag that fired twice. Then, scroll down to the Triggering section. If the tag is a part of the sequence, it will be displayed there.

Pro tip: if you want to be sure that the tag has fired only once per page, you can use the Tag Firing Option field. Set it to Once per page. To learn more about this option, read the next chapter.

 

#5. Tag Firing Options

Now, here’s the opposite situation. You see that the tag should have fired multiple times on the same page, but it did only once. You click the event in the preview and debug mode, choose the tag and see that all the firing conditions were met. But the tag did not fire. Why?

There are no blocking triggers that would have caused this either. So where’s the problem?

Another possible reason for this situation can be this – the tag is set to fire only Once per page.

To verify this hypothesis, go to the tag that you think is behaving weirdly. If it is set to fire once per page, you will immediately see that in the tag summary.

If you want to change the settings and fire the tag every time it should, then go to Advanced Settings of that tag and choose “Once per event” in the Tag Firing Options dropdown.

 

#6. Tag Firing Schedule

Tag Firing Schedule is a GTM feature that lets you set conditions when a certain tag should or should not fire. With it, you can set the start and end date of when the tag should be active. This is useful for time-sensitive campaigns.

If the campaign (and Tag Firing Schedule) has ended,  the tag will not fire even if Google Tag Manager records that the trigger conditions are met (the only exception with higher priority here is Tag Sequencing).

When Tag Firing Schedule is enabled, in Preview and Debug mode, you will see two blocking triggers:

The first one is for the start date of the firing schedule, and the other one is for the end. In the screenshot above, do you see a green checkmark against the second blocking trigger? This means that the custom firing schedule has ended, and the time-sensitive blocking trigger is activated.

If you expect the tag to fire and the Tag Firing Schedule feature should be disabled, open the tag in GTM’s interface > Advanced Options and disable it.

 

#7. Fire a tag only in published containers

This feature is useful if you have a very sensitive tag that should fire only in live containers (maybe every time it fires, it charges some money off your business account).

If this option is enabled, the tag will not fire in the preview and debug mode. Also, it will not fire in your testing environments. This feature will allow the tag only in your live environment (where the GTM container snippet does not contain the &gtm_preview= parameter).

How to check if the tag has this option enabled? Open it in the GTM interface > Advanced Options > see the checkbox “Only fire this tag in published containers.”.

As long as it is enabled, the live environment is the only place where the tag will fire (when GTM preview and debug mode is disabled and the GTM code snippet does not contain the &gtm_preview= parameter).

 

#8. gtm.blocklist and gtm.allowlist

Developers of your website can limit what kind of tags you can use in your Google Tag Manager container. They do this with a feature called blocklist.

Developers can push certain parameters to the data layer, and based on the configuration, GTM tags will behave accordingly. You can learn more here.

In a nutshell, if you add certain tag types to the gtm.allowlist, only they will fire. If the same is done in the gtm.blocklist, then all tag types except those in the gtm.blocklist will work fine.

Here is a quick way to check if you are dealing with blocklist/allowlist in GTM. First, open the Preview mode of your GTM container. Check if you have any messages on the left sidebar that push gtm.blocklist or gtm.allowlist.

If you see a message like this, then this might be the reason why certain tags don’t work. Then you will need to read this documentation and tell your developers what to add (or remove) to the blocklist/allowlist.

In the screenshot above, class html is blocked. According to the documentation, this will block all customScripts (because it is an alias). The description also mentions how all Custom HTML tags are blocked from firing.
.

And that is not all. If you are facing problems with tags that are using Custom Tag Templates, then read this warning at the end of the documentation:

If you have a blockList, you must ask a developer to add sandboxedScripts to the gtm.allowList array. For example:

dataLayer.push({'gtm.allowlist' : ['sandboxedScripts']});

If you already have something in the allowList, your developer should update the existing array.

 

Bonus tips

Here are some additional ideas for you to discover further why your tags in Google Tag Manager are not firing properly. I’ll start with the obvious one.

 

Make sure you have properly refreshed the preview and debug mode

I know. I don’t want to sound like Captain Obvious, but this happens more often than everyone would like. So I’ll just say it.

If you have made some changes to your tag/trigger/variable, make sure you refresh the Preview and Debug mode first (by clicking the Refresh link in the orange banner) and only then refresh the page you’re working on.

 

You see your tag being activated in the preview mode, but it remains as “Still running”

If you see a tag in the preview console like this, your tag will not properly fire.

One of the most common reasons for this is GA Settings Variable being inserted in the wrong field. Instead of adding it to the dedicated field, some GTM users insert it in the “GA Tracking ID” field. And that is NOT the same.

I’ve written a guide about it here If that does not help, you can also read this guide.

 

Broken Data Layer

If this happens, you won’t even see new events in the preview mode. Hence no tags will be fired (except on DOM Ready and Window Loaded).

This happens when this dataLayer code snippet is placed below the Google Tag Manager container in the source code.

<script>
dataLayer = [....];
</script>

It rewrites the existing dataLayer on a page and breaks the function that helps Google Tag Manager monitor changes in the dataLayer. I’ve written more about this topic here and here.

A solution to this?

• Ask a developer to move that dataLayer code snippet above GTM container
• Or use dataLayer.push instead

 

A Tag in Google Tag Manager is Not Firing? Quick Summary

In this guide, I have explained why your tag might not behave as you expected. Maybe it does not fire when you want it to. Or maybe it just keeps firing, although you’d like to do that only once.

In a nutshell, here are the possible reasons why a tag in Google Tag Manager is not firing (or fires unexpectedly):

• Trigger misconfiguration
• A blocking trigger is being used
• You’ve configured Tag sequencing in your tag
• Incorrect configuration in Tag firing options 
• You might have used Tag firing schedule if you’re running a time-sensitive campaign
• Firing a tag only in published containers option is enabled

Additionally, it’s a good practice to take a look at whether:

• You have properly refreshed the preview and debug mode
• You have inserted the GA settings variable in the correct field
• The Data Layer is not broken