Rules are the cornerstone of Google Tag Manager. As with any critical element in a system, they are easy to get wrong. This tip is just a refresher on how GTM firing and blocking rules work.

X

The Simmer Newsletter

Subscribe to the Simmer newsletter to get the latest news and content from Simo Ahava into your email inbox!

Tip 3: Google Tag Manager rules in a nutshell

Rules in Google Tag Manager

So, let’s go through these points one-by-one.

Every tag requires a firing rule to work - this is a given. Without a firing rule, your tag will not be written in the document object, and it will never be executed.

Every firing rule requires an {{event}} condition - this is a bit more complex. Every time an ‘event’ variable is pushed with some value into dataLayer, every single rule on every single tag will be evaluated against this value. Thus, every tag needs some value lookup for {{event}} in their firing rules.

{{event}} equals gtm.js is the “default” event - if there’s no explicit {{event}} condition in your firing rule, GTM will evaluate the tag as having {{event}} equals gtm.js as its firing rule. This event occurs at the earliest possible moment when the GTM Container Snippet is written on the page.

A single rule can have many conditions - but every single condition must be matched for this rule to work as a trigger. You can introduce some OR-logic into conditions by using e.g. {{event}} matches RegEx ^gtm.(js|linkClick)$, but this is generally better to do with multiple firing rules rather than this crude manipulation of rule conditions.

A single tag can have many firing rules - this is very important! Every single firing rule that the tag has can and will fire the tag if the rule conditions are met. Thus, if you have a rule {{event}} equals gtm.dom (fire the tag after DOM has loaded) AND {{url path}} matches RegEx ^/thankyou$, this tag will fire once on every page, and twice on the /thankyou-page: first for {{event}} equals gtm.js and second for {{event}} equals gtm.dom! Note that the tag will still fire only once for a given event. So even if you manage to botch things by having three {{event}} equals gtm.js rules in a single tag, the tag will fire just once when the event occurs.

A blocking rule overrides any firing rule - if you have a blocking rule, it will override any firing rule you might have on the tag. For example, if the firing rule is {{url}} matches RegEx .* and the blocking rule is **{{url path}} matches RegEx ^/thankyou$**, the tag will fire on all pages except the /thankyou-page. The good thing about using blocking rules is that the same rule you block this tag can be used as a firing rule on some other page, e.g. the actual /thankyou-page for your Transaction Tag!

A tag is written and run only when the firing rules activate it - thus, the moment the firing rule activates the tag, the tag is added to the document object and any macros referred to in the tag are evaluated. This is important, since it means that by the time the tag fires, any macros it refers to have to be available. Many eCommerce setups have failed because the Transaction Tag fires before the eCommerce payload is in the dataLayer.

One thing about macros (this is an extra tip). When a tag fires, all macros referred to in the tag are resolved. This means that it’s extremely difficult to know, especially with large implementations, how many times any macro will be resolved upon any event, as you can refer to the same macro in as many tags as you wish. Thus, it is highly recommended that you do not use macros to set or push data.

So be careful! As the wise members of the GTM product team always remind us: macros should not have side effects. They should be for value retrieval only - not to set or push data.