Triggers

In web containers, triggers attached to a tag govern when the tag is fired or not fired. In mobile app containers, certain variable types have triggers associated with them that allow the mobile app to be configured conditionally based upon the runtime environment.

In web containers, a tag must have at least one trigger in order to fire. Triggers are evaluated during runtime and associated tags are fired (or not fired) when the trigger conditions are met. For example, a tag with a trigger based on a pageview event with the following filter will be fired on the example.com home page:

url equals example.com/index.html

A trigger is composed of one event and one or more filters (except for custom events which don’t require a filter). Each filter takes the form: [Variable] [Operator] [Value]

Variable Operator Value
Choose between url, referrer, etc. Choose between equals, contains, etc. You provide a value. Google Tag Manager compares the value you provide with the runtime value in the variable.

In our example, the variable “url” is evaluated during runtime. The variable “url” has been defined such that it contains the current page URL . Thus, during runtime, the current page URL is compared to the value you’ve provided, “example.com/index.html”, to determine whether the trigger condition has been met.

In web containers, you can enable built-in variables such as url, url hostname, or referrer. In addition, when setting up a click based trigger, Google Tag Manager also automatically populates the variables corresponding to the clicked element id, classes, etc. With these variables, you’re able to construct the triggers you’ll most commonly need. However, you can also define your own variables and use their values in your trigger filters. Read Variables to learn more.

You can provide multiple filters ([Variable] [Operator] [Value]) in a single trigger. The trigger is met if all of the conditions in the trigger are met.

Firing/Blocking Triggers for Tags

A tag will fire whenever any one of its triggers are met. For example, if a tag has two triggers, one for "all pages" and another for "only page ABC", the tag will fire on all pages.

A trigger that blocks a tag from firing always overrides a trigger. For example, if a tag has a trigger "all pages" and a blocking trigger "URL equals thankyou.html", the tag will never fire on the page "thankyou.html".

Enabling/Disabling Triggers for Variables

In mobile app containers, some variable types have triggers associated with them that allow the mobile app to be configured conditionally based upon the runtime environment. A variable is available whenever any one of its enabling triggers is met. For example, if a variable has two enabling triggers, "Always", and "platform equals Android", the variable is always available. A disabling trigger always overrides an enabling trigger.

Web Container Triggers

All tag firing in Google Tag Manager is event-driven. Anytime an event is registered by Google Tag Manager, triggers from the container are evaluated and tags are fired accordingly. No tag can be fired unless an event occurs.

An event can be a pageview, a click on a button, a form submission, or any custom event that you define. Google Tag Manager has 6 built-in event types plus a custom event option. The first step in setting up a trigger is selecting the event type associated with it. The built-in events include:

Pageview

This event corresponds to the rendering of a page in the user’s browserer. This event can be further configured via the trigger type drop-down to tell Google Tag Manager if the tag should be fired immediately when the browser starts parsing the page (Page View), after the browser has finished constructing the full page DOM (DOM ready), or after the page has fully been loaded, including embedded resources such as images and scripts (Window Loaded. Adjusting the timing of a pageview based trigger can be helpful if your tag is using DOM or Javascript variables to capture dynamic values. All pageview based tags that interact with the DOM to populate variables should use DOM Ready as the trigger type to ensure the variables are consistently set.

Click (link or DOM element)

To fire a tag when the user clicks on a link or an element of the page, select the click event type.

In the trigger filter, we recommend that you specify the url (or url pattern) of the page(s) where you expect the click to take place, in order to optimize Google Tag Manager’s performance.

When the user clicks on any element on pages matching the filter, Google Tag Manager will automatically populate the following variables:

  • Click Element: The HTML element that was clicked.
  • Click Classes: An array of the values found in the element's class attribute.
  • Click ID: The ID attribute of the clicked element.
  • Click Target: The target attribute of the clicked element.
  • Click URL: The HREF attribute of the clicked element, if any.
  • Click Text: The visible text inside the clicked element.

You can then include those variables in your click trigger filter. For instance, if you have a button with the following markup on the page www.example.com/cart.html

<button type="submit" id="cart-add" class="addToCart" >ADD TO CART</button>

The following trigger will fire a tag when the user clicks on that button:

Add new trigger form

You can further configure a click based trigger to specify if you want it to only listen for clicks on regular links (“Just Links” option) or for clicks on any HTML element on the page (“All Elements” option).

trigger type just links wait for tags

Since link clicks usually cause the browser to load a new page and interrupt any pending HTTP request, you have the option to add a small delay to allow tags fired by Google Tag Manager to execute properly before redirecting to the next page. Checking the “Wait For Tags” option will delay opening of links until all tags have fired or the specified timeout has elapsed, whichever comes first.

The “Check Validation” option allows you to only fire tags when opening the link is considered a valid action. If unselected, fire tags whenever a user tries to click the link. Read About the Check Validation Option, below, for more information.

Form Submission

To fire a tag when a form is submitted by the user, select Form as your trigger event.

In the trigger filter, we recommend that you specify the url (or url pattern) of the page(s) where you expect the form submission to take place, in order to optimize Google Tag Manager’s performance.

When a form submission trigger is executed, the following variables will be automatically populated:

  • Form Element: The form element that was clicked.
  • Form Classes: An array of the values found in the form's class attribute.
  • Form ID: The ID attribute of the form element.
  • Form Target: The target attribute of the form element.
  • Form URL: The HREF attribute of the form element, if any.
  • Form Text: The visible text inside the form.

The “Wait for Tags” option allows you to delay the form submission until all the tags that depend upon this trigger have fired or the specified timeout has elapsed, whichever comes first. If unselected, slow tags may not fire before the form submit causes the next page to load.

The “Check Validation” option allows you to only fire tags if the form will successfully submit. If unselected, fire tags whenever a user tries to submit the form.

History Change

Triggers based on the History Change event will fire a tag when the URL fragment (hash) changes or when a site is using the HTML5 pushstate APIs. This trigger is useful to fire tags tracking virtual pageview in an Ajax application, for instance.

When an history change event occurs, Google Tag Managers populates the following variables:

  • History old url fragment: What the URL fragment used to be.
  • History new url fragment: What the URL fragment is now.
  • History old state: The old history state object, controlled by the site's calls to pushState.
  • History new state: The new history state object, controlled by the site's calls to pushState.

Javascript Error

This type of trigger is used to fire tags when an uncaught Javascript exception occurs. When the trigger fires, the following variables will be populated:

  • Error message: A string containing the text of the JavaScript error message.
  • Error url: The URL: where the error was raised.
  • Error line number: The line number in the code where the error was raised.

Timer

Triggers based on this event allow you send events to Google Tag Manager at custom intervals to raise a Google Tag Manager event at a desired frequency. When using this trigger, Google Tag Manager starts a countdown timer that fires an event at the Interval (in milliseconds) you specify. An Interval of 5000 will fire an event every five seconds. The name of the event is whatever name you specify in Event Name. You can then use this event name to create a custom event trigger. For example, if you specify an Event Name of “timer5” in a timer based trigger, you should then create a custom event based trigger where the event condition is event equals timer5. Read Google Analytics Events for examples. Limit is the maximum number of times to fire the event. Leaving Limit blank causes the event to keep firing until the user leaves the page.

Custom Events

In addition to the built-in event types, you can programmatically raise any type of event by using the data layer. To send a custom event to Google Tag Manager, use the following syntax:

dataLayer.push({ ‘event’: ‘myCustomEventName’ });

Custom events are important to track any type of interaction that might take place on your website or application and could be used to trigger tags.

Once you have given a name to your event via the data layer, you can create a trigger to fire tags based off of that event by selecting custom event as the trigger event type, and entering the event name you set in the data layer as the event condition.

new custom trigger event equals mycustomeventname

Standard event and custom event alike are all pushed into the data layer queue. To view the sequence of events pushed to the data layer on a given page, open the Javascript console on your web browser and type “dataLayer”.

data layer screenshot from Google Chrome

Using RegEx and CSS Selector Operators

You can use regular expressions and CSS selectors as operators when setting up triggers. When setting a regular expression or CSS selector as the operator for a trigger, you can specify that the trigger matches or does not match the rule you are applying. For example, the regular expression applied to a URL or URL path variable:

/pro/

will match all pages with the string "pro" in the URL path, including "products", "promotions, "professionals", and "processes".

The CSS selector may be used to target specific HTML elements. For instance, this selector applied to a Click Element variable:

#promo .purchase

will match a click for any element with a class attribute value of "purchase" that is a descendant element of a parent with an ID attribute value of "promo".

Adding Filter to a trigger

After the selecting the event on which your trigger is based, you can further specify the conditions under which your trigger should fire tags depending on the values of Google Tag Manager variables. Each built-in event comes with one or more variables automatically populated by Google Tag Manager, such as the page url for a pageview or the clicked element id for a click event. You build filters for your trigger using variables associated with the type of event you selected, or any other custom variables you may have created.

With the exception of custom event based triggers, you must specify at least one filter when creating a trigger.

Lastly, you can provide a name for your trigger and set up additional configuration options that vary based on the chosen trigger type.

Triggers & Variables

If your tag uses variables, the values that will be passed to the tag are the values that those variables have at the time of the event that triggered the tag to fire.

Consider the following example of successive data layer updates:

Screenshot of chrome devtools showing objects in data layer

A tag with a trigger to fire on the event productView would fire twice. If it uses a variables mapped to the data layer variable productId, its value will first be ‘ABCD’ for the first tag fire, then ‘EFGH’ for the second tag fire. If it uses the data layer variable mapped to loggedInUser, the value will be ‘no’ for both tag fires, since the value is initially set to ‘no’ and not overwritten on the second tag fire.

A tag with a trigger to fire on the ‘addToCart’ event would fire with the value ‘XYZ’ for productId, and with the value ‘yes’ for loggedInUser since the loggedInUser variable was modified from its previous value of ‘no’ in a dataLayer update that preceded the addToCart event. Note that the data layer update that sets the loggedInUser variable to ‘yes’ can not be used to trigger tags to fire since no event is associated with this update.

Best Practices

Sometimes triggers, when configured improperly, can cause unexpected results. When setting up your triggers, please consider the following guidelines:

Test your triggers with Preview mode

It is important to test form and link triggers before publishing them to your site. These triggers can break if another JavaScript event interrupts the process. A common culprit is that another script returns false before the form or link trigger is reached, preventing those triggers from ever firing. Use Preview mode to see if your tags aren't firing or if form submissions aren't being sent properly.

Test in older web browsers

Older web browsers, especially Internet Explorer 8 and lower, can have issues with tags firing properly. These issues are far less common in modern web browsers. If your product requires support for older browsers, we highly recommend thorough testing using Preview mode before deployment.

Limit the scope of form and link triggers to tested pages

Testing every page on your site can be very time consuming, and you should be judicious in how you deploy form and link triggers. Use filters to ensure that your trigger will only fire when your specified conditions are met (such as Page Path equals /my/tested/form/page) to make sure these triggers are only applied to the pages that you have tested.

Was this article helpful?