Google Tag Manager gives you two distinct ways to control when a trigger fires: trigger filters inside the trigger itself and additional conditions applied at the tag level via blocking triggers. Understanding when to use each is one of the most underrated GTM skills, and getting it wrong leads to tags firing on the wrong pages, data pollution, and debugging nightmares that take hours to untangle.

The Anatomy of a GTM Trigger

Every trigger in GTM has three parts: a trigger type (Page View, Click, Custom Event, etc.), a firing condition (All Pages, Some Pages, or a custom match), and an optional set of exceptions. The firing condition is what most people call a “trigger filter” — it is the condition that must be true for the trigger to activate. Exceptions work in reverse: if the exception condition is true, the trigger will not fire even if the main condition is met.

Trigger Filters: Conditions Inside the Trigger

A trigger filter is a condition you set within the trigger configuration itself. For a Page View trigger, you might add the condition “Page URL contains /checkout” to limit the trigger to checkout pages only. Trigger filters are evaluated using GTM variables. You can filter on any built-in variable or any custom variable you have created. The filter operators include contains, equals, matches CSS selector, matches regex, starts with, ends with, and their negations.

When to use trigger filters: use them when the condition is intrinsic to the purpose of the trigger. If you are creating a trigger called “Checkout Page View”, the filter “Page URL contains /checkout” belongs inside the trigger because it defines what kind of page view this trigger represents. Any tag that uses this trigger gets the filtering for free — the key benefit is reusability.

Tag-Level Trigger Combinations

When you assign multiple triggers to a single tag in GTM, the tag fires when ANY of those triggers activates (OR logic). If you want a tag to fire only when trigger A AND trigger B are both satisfied, you cannot do this by simply adding both triggers to the tag — you will get OR behavior instead.

To implement AND logic, you have two options. First, you can create a single trigger that includes all the conditions as filters within the trigger itself. Second, you can use a custom event pushed from a script that checks multiple conditions before pushing the event.

// Custom HTML tag to push a combined condition
(function() {
  var isLoggedIn = {{DL - user_logged_in}} === true;
  var isCheckout = window.location.pathname.indexOf('/checkout') !== -1;
  if (isLoggedIn && isCheckout) {
    dataLayer.push({ event: 'logged_in_checkout_view' });
  }
})();

Blocking Triggers: The Exception Mechanism

GTM’s blocking trigger feature lets you prevent a tag from firing by assigning an exception trigger. In the tag’s trigger configuration, you click the minus icon next to a trigger to convert it from an activating trigger to a blocking trigger. If the blocking trigger fires, the tag will not fire regardless of whether the activating trigger also fires.

Blocking triggers are useful for negative cases that are hard to express as negations within a trigger filter. For example, you might have an “All Pages” trigger for your GA4 tag, but you want to exclude your thank-you page. Rather than changing the All Pages trigger, you create a “Thank You Page” trigger and add it as a blocking trigger on just the GA4 tag.

When Trigger Filters Cause Problems

The most common mistake is building overly specific triggers that cannot be reused. A trigger called “Product Page Click – Add to Cart Button – Logged In User – Desktop” is so narrowly defined that it will never be used by any other tag. You end up with hundreds of nearly identical triggers that are impossible to audit and maintain.

The rule of thumb: put conditions in triggers that define the event type. Put conditions that are specific to a particular tag’s requirements as blocking triggers or by using a more specific custom event trigger. Your trigger library should contain generic, reusable triggers: All Page Views, Checkout Page Views, Click Any Link, Submit Any Form.

Regex in Trigger Filters

GTM’s “matches regex” operator uses RE2 syntax, not Perl-compatible regex. The most important difference is that RE2 does not support lookaheads or lookbehinds. For matching multiple URL patterns in a single trigger filter, use the pipe character as an OR operator: /product/|/category/|/brand/. GTM automatically anchors the match to check whether the variable contains the pattern, so you do not need ^ and $ anchors for most use cases.

Testing Trigger Conditions with Preview Mode

GTM’s Preview mode shows you every trigger that fires and every trigger that does not fire, along with the reason. When debugging a tag that is not firing, open Preview, navigate to the page where the tag should fire, and look in Not Triggered for your trigger. GTM will show you which condition in your trigger filter evaluated to false, telling you exactly which variable value caused the mismatch.

A pattern that saves significant debugging time: before adding a new trigger filter condition, check the actual value of the variable you plan to filter on using Preview mode’s Variable panel. It is extremely common to discover that the variable value includes query parameters, trailing slashes, or capitalization that your filter did not account for.

Building a Clean Trigger Architecture

A well-organized GTM container has trigger names that describe what happened, not what tag should fire. “Checkout Page View” is a good trigger name. “GA4 Checkout Tag Trigger” is a bad trigger name — it couples the trigger to a specific tag and cannot be reused. Review your trigger library quarterly. Any trigger used by only one tag and containing more than two filter conditions should be evaluated for whether those conditions should be expressed differently.