Updated: July 22nd, 2021.
Note: Even though some screenshots are using the older version of GTM preview mode, that does not change the essence of this blog post and you should still find the answer.
You have configured a tag in Google Tag Manager, enable Preview and Debug mode, try to test it but it behaves not as you expect. Even though you think you did everything right, it just 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 out 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
#1. Incorrect trigger
The first thing you should check in order to find out why your tag did not fire in GTM is firing triggers. If you are in a situation where tag did not fire, do the following. 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. If an icon (next to the trigger name) is a green checkmark, that means that this trigger activated the tag (or at least was supposed to). You can also see green and red icons next to every condition of tags. If the condition was met, the icon will be green.
This helps you identify possible reasons why a tag fired (or didn’t). In order 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 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 any of three pages, /pricinc/page1/, /pricing/page2/, /pricing/page3/. If you’re just starting to learn how to use GTM, you might think that 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, therefore, most likely, such a trigger will never be activated because it is not possible for the URL of a website to contain all 3 options (page1, page2, page3).
In this case, you have two options:
Create 3 separate triggers for each page (not very optimal, especially, when your condition can grow to 10, 20 or more pages) 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 the regular trigger’s ALL conditions are met, the blocking trigger has a higher priority.
In order to find out whether the blocking trigger is the reason why your tag in Google Tag Manager did not fire, follow the same process as in the previous chapter. 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 that 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).
This happens because of the misunderstanding of how blocking triggers (a.k.a. Exceptions) work.
You see, blocking triggers work only against firing triggers that use the same events. Let me explain.
You have a tag that fires on an outbound 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 how 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. Link click trigger can be blocked with link click trigger, pageview trigger can be blocked with 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. You have a tag, it has only one trigger — All Pages.
But for some reason, you see that in the Summary, the tag was fired twice. Why?
This probably has happened because of another feature in GTM called Tag Sequencing. 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 you whether the tag was activated because of tag sequencing.
But you can still figure this out. To do that, go back to your GTM container’s interface and open the tag that fired twice. 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 a bit 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. WTF?
There are no blocking triggers that would have caused that 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 weird. 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 another 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 the trigger’s 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, a green checkmark is next to a 2nd 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 amount of 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. It will fire only in your live environment (where GTM container snippet does not contain the >m_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 only place where the tag will be fired is live environment (when GTM preview and debug mode is disabled and the GTM code snippet does not contain the >m_preview= parameter).
#8. gtm.blocklist and gtm.allowlist
Developers of your website can limit what kind of tags can you use in your Google Tag Manager container. That can be done 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 certain tag types are added to the gtm.allowList, only they will fire. If certain types are added to the gtm.blocklist, then all of the tag types will work fine except those that are in the gtm.blocklist.
Here is a quick way how to check if you are dealing with blocklist/allowlist in GTM. Open the Preview mode of your GTM container and then see if you have any messages on the left sidebar that push gtm.blocklist or gtm.allowList (older dataLayer setups might use gtm.blacklist and gtm.whitelist. They also work.).
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). Read the description and you will find out that it blocks Custom HTML tags 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 have to 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, then 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. This sounds like one of the Captain Obvious’ tips 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 actually 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 a bunch of reasons why your tag might not behave as you’d expect. Maybe it does not fire when you want it to. Or maybe it just keeps firing although you’d like it 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
Blocking trigger is being used
Tag sequencing is being used
Configuration in Tag firing options
Tag firing schedule is being used
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
I have a feeling that I forgot to include something but cannot remember what exactly. So if you notice that there is a missing reason why a tag in Google Tag Manager is not firing, please let me know.
The post 8 Reasons Why a Tag in Google Tag Manager is Not Firing (or Fires When it Shouldn’t) appeared first on Analytics Mania.
Read MoreAnalytics Mania
