{"id":154286,"date":"2025-03-24T19:42:12","date_gmt":"2025-03-24T19:42:12","guid":{"rendered":"https:\/\/peraltafinancing.com\/analytics\/trigger-guide-for-google-tag-manager\/"},"modified":"2025-03-24T19:42:12","modified_gmt":"2025-03-24T19:42:12","slug":"trigger-guide-for-google-tag-manager","status":"publish","type":"post","link":"https:\/\/fivemor.com\/?p=154286","title":{"rendered":"Trigger Guide For Google Tag Manager"},"content":{"rendered":"


\n<\/p>\n

\n
\n

Updated 27 March 2019<\/p>\n<\/blockquote>\n

In the new version<\/a> of Google Tag Manager<\/a>, one of the most visible and profound changes to the previous version is how tags are fired (and blocked). First of all, there\u2019s the obvious terminological distinction: we talk about triggers<\/strong> now, not rules<\/em>. Second, triggers have become an integral part of the tag creation workflow, and as such have far more significance in the user interface than before.<\/p>\n

\n

<\/p>\n

\"New<\/p>\n

<\/a><\/p>\n<\/div>\n

The following text is a standalone article. It\u2019s not an update to the guide I wrote for the previous GTM version: Google Tag Manager: Playing By The Rules<\/a>, and many of the concepts covered therein are still valid.<\/p>\n

Triggers introduce many new features and functionalities (a new way of doing auto-event tracking<\/a>, for example), which require special attention.<\/p>\n

Here are the contents of this guide:<\/p>\n

As always, feel free to add your thoughts in the comments after this post, if there\u2019s some aspect of triggers that wasn\u2019t adequately covered.<\/p>\n


\n X<\/span><\/p>\n

\n
\n The Simmer Newsletter<\/strong>\n <\/p>\n

\n Subscribe to the Simmer newsletter<\/a> to get the latest news and content from Simo Ahava into your email inbox!\n <\/p>\n

<\/span><\/p>\n

1. What\u2019s changed<\/h2>\n

There are three major changes, in my opinion, to how triggers compare with the rules of the previous GTM version.<\/p>\n

I) Triggers are integrated into the workflow<\/h3>\n

Sure, this is more a cosmetic thing, but it\u2019s significant. In the previous version of Google Tag Manager, the entry-level for beginners was quite high. This was partly due to the fact that it wasn\u2019t clear just what firing rules<\/em> and blocking rules<\/em> do. It got even more confusing once you started learning about stuff like implicit events and conditions, and it didn\u2019t help that the UI gave very little hints about what to do next.<\/p>\n

In the new UI, everything is about the workflow<\/em>. There\u2019s actually a question there now: What triggers this tag to fire?<\/strong> Nothing about firing rules or blocking rules, nothing about event conditions, and so forth. Just the simple, quite self-explanatory question. Of course, to understand what \u201cfire\u201d means, you will need to do some exploration, but the question sets the scene: a tag needs a trigger to fire.<\/p>\n

\n

<\/p>\n

\"Tag<\/p>\n

<\/a><\/p>\n<\/div>\n

So the biggest obvious change is in the UI. Triggers are an integral part of the workflow, and it\u2019s impossible to not notice them, as you may have with rules in the previous version.<\/p>\n

II) You don\u2019t need to explicitly state the \u2018event\u2019 condition<\/h3>\n

The second major change is how you input the event condition. If you\u2019ve read my previous posts about rules<\/a>, or if you\u2019ve paid attention to the developer guides, you\u2019ll know that every single tag needs an \u2018event\u2019 push to fire<\/strong>. With \u2018event\u2019 push I\u2019m of course referring to a dataLayer.push()<\/code> command that gives a value to the key labelled \u2018event\u2019.<\/p>\n

\n

<\/p>\n

\"Event<\/p>\n

<\/a><\/p>\n<\/div>\n

This time around, you don\u2019t need to explicitly state the required Event condition (i.e. the value that \u2018event\u2019 key needs to have for the tag to fire). Instead, you rely on the available trigger types<\/em> to set this condition up for you. In fact, the only time you have to explicitly state the name of the event is if you use a Custom Event type, and even then you don\u2019t have to worry about setting it up as a proper condition. You just give the event its name in the required field (you can also use RegEx matching if you want more flexibility):<\/p>\n

\n

<\/p>\n

\"Custom<\/p>\n

<\/a><\/p>\n<\/div>\n

The point is that since Event is such a super-important part of any tag or trigger, it\u2019s taken out of the normal condition-based setup for triggers and elevated to a grander status.<\/p>\n

III) Auto-event tracking has changed<\/h3>\n

I\u2019ve already written a guide<\/a> on this, and I\u2019ll cover some of the concepts in this article as well, but this is really significant. Auto-event tracking is no longer tag-based, as it was in the previous version. Instead, you specify the event (click, link click, form submit, error, history event, or timer) by choosing one of the respective trigger types. Once you create a trigger for an auto-event type, GTM automatically starts listening for these events on your site.<\/p>\n

\n

<\/p>\n

\"Click<\/p>\n

<\/a><\/p>\n<\/div>\n

This is incredibly convenient, since it reduces clutter in your tags, and it makes event tracking a very central part of any tagging setup (as it should be).<\/p>\n

These are, in my view, the biggest changes. As a GTM fanboy, my honest and utterly biased opinion is that the improvements are amazing. There\u2019s a learning curve, and I know that improvements are made to the UI constantly. But the way that triggers have been integrated into the tag workflow, without compromising any of the features carried over from rules, is a wonderful display of design skill.<\/p>\n

2. Technical overview<\/h2>\n

It\u2019s not like I\u2019ve reverse engineered the GTM container JavaScript library (well, not all of it), but there are some interesting things to consider when working with triggers.<\/p>\n

First of all, as I said above, triggers require a dataLayer.push()<\/code> or a pre-container-snippet declaration to fire a tag. If a push()<\/code> command doesn\u2019t have an \u2018event\u2019 key, it becomes merely a \u201cmessage\u201d that\u2019s added to the message bus. It does nothing for tags. You can see this in the debug mode. If there\u2019s an \u2018event\u2019 key in the message, the instance gets the name of the event (unless it\u2019s one of the three default GTM events, see below) or just \u201cMessage\u201d if there\u2019s no \u2018event\u2019 key in the command:<\/p>\n

\n

<\/p>\n

\"Data<\/p>\n

<\/a><\/p>\n<\/div>\n

So if there\u2019s an \u2018event\u2019 key in the push()<\/code>, a data layer helper object activates and goes through all the active triggers in your container. If any one of these matches the value of the \u2018event\u2019 key, and if all the other conditions in the trigger pass, the tag is injected into the site and its code is executed.<\/p>\n

Very little has changed, then. You will still need to push \u2018event\u2019 values to fire tags. The three default events are still gtm.js<\/strong> (pushed when the container snippet is first rendered in the page template), gtm.dom<\/strong> (pushed when the DOM has loaded), and gtm.load<\/strong> (pushed when the window has loaded):<\/p>\n

\n

<\/p>\n

\"GTM<\/p>\n

<\/a><\/p>\n<\/div>\n

One thing that has<\/em> changed is how multiple triggers of same type on the same page are handled.<\/p>\n

Since there\u2019s no longer a listener tag that you work with, it\u2019s more than possible that you can have many link click triggers, for example, activating tags on the same page. It doesn\u2019t mean that GTM always attaches a new event listener to the document<\/code> node, because that would be an exercise in redundancy. Rather, all the triggers that use the same auto-event, e.g. gtm.linkClick<\/code>, are evaluated when the event occurs.<\/p>\n

This is fine in most cases, but it\u2019s also possible that you have two Link Click triggers, where on one you have \u201cCheck Validation\u201d set to ON, and on the other it\u2019s OFF. This means that the first one only fires if the default action of the link click has not<\/em> been prevented by other scripts, and the latter fires regardless. Since there\u2019s just one listener controlling the firing of your tags, GTM leverages the gtm.triggers<\/code> key in the auto-event object to specify which trigger should fire upon the event:<\/p>\n

\n

<\/p>\n

\"The<\/p>\n

<\/a><\/p>\n<\/div>\n

The value of the key is containerID_triggerID<\/strong>. So in this particular example, I had two Link Click triggers firing on the page, and one of them had \u201cCheck Validation\u201d ON. I then clicked a link where I had prevented the default action of the click with event.preventDefault()<\/code>. Thus, the gtm.triggers<\/code> key tells our tags that only the trigger where \u201cCheck Validation\u201d was OFF (id 27) is allowed to fire.<\/p>\n

This makes for a very economical but still extremely robust setup for your auto-event triggers.<\/p>\n

3. Triggers in the workflow<\/h2>\n

There are two obvious paths to creating triggers: 1) through the tag workflow, and 2) via the Triggers menu.<\/p>\n

Both paths take you essentially through the same steps.<\/p>\n

In the tag workflow<\/strong>, you can enter the trigger selection screen in three different ways:<\/p>\n

    \n
  1. \n

    If the tag has no triggers, then clicking the big empty space with \u201cChoose a trigger to make this tag fire\u2026\u201d will open the trigger selector.<\/p>\n<\/li>\n

  2. \n

    If the tag already has triggers, then clicking the blue plus symbol lets you add new triggers to the tag.<\/p>\n<\/li>\n

  3. \n

    You can also click the ADD EXCEPTION<\/strong> link to add triggers that block the tag from firing.<\/p>\n<\/li>\n<\/ol>\n

    \n

    <\/p>\n

    \"Open<\/p>\n

    <\/a><\/p>\n<\/div>\n

    In the trigger selection screen, clicking the blue plus button in the top right corner takes you to trigger creation mode.<\/p>\n

    You can also enter trigger creation mode by browsing to Triggers<\/strong> and clicking the red NEW<\/strong> button in the UI.<\/p>\n

    Regardless of which path you take, this is what you\u2019ll see:<\/p>\n

    \n

    <\/p>\n

    \"Trigger<\/p>\n

    <\/a><\/p>\n<\/div>\n

    Read on for information how to create your new trigger.<\/p>\n

    4. New trigger creation<\/h2>\n

    When you start creating a new trigger, you should already have a good idea of which GTM event<\/strong> should fire your tag.<\/p>\n

    \n

    <\/p>\n

    \"Create<\/p>\n

    <\/a><\/p>\n<\/div>\n

    The trigger type<\/strong> is essentially a combination of the GTM event and the type of interaction (or event) you want GTM to start listening to.<\/p>\n

    Here are the trigger types currently available:<\/p>\n

    Page View<\/strong>:<\/p>\n