GTM Triggers: A Complete Guide to All 8 Types (with Examples).

Triggers are the "when" in Google Tag Manager. A tag does nothing on its own — it fires only when a trigger condition is met. Get triggers right and every conversion, scroll depth, and video play lands cleanly in your reports. Get them wrong and your most important events never fire, or they fire on every page load and inflate every metric you care about. Either way, the data is wrong and the decisions built on it are wrong.

This guide covers the 8 trigger types you will use in almost every GTM implementation, the filter conditions that make them precise, and the 5 mistakes that account for the majority of GTM tracking problems. By the end you will know which trigger to reach for in any situation and what to watch for before you publish.

What Is a GTM Trigger?

A trigger is a listener. It watches for a specific event in the browser — a page load, a click, a form submission, a custom push into the data layer — and when that event matches its conditions, it fires every tag assigned to it. Every tag in GTM requires at least one trigger. A tag with no trigger is dormant; it never fires regardless of what happens on the page.

The relationship is one trigger to many tags: one Page View trigger fires your GA4 configuration tag, your marketing pixels, and your heatmap tool simultaneously. You can also assign multiple triggers to a single tag — the tag fires if any of them match. And you can attach a blocking trigger to prevent a tag from firing even when its main trigger matches, which is how you exclude internal traffic without duplicating every tag setup.

The 8 Main GTM Trigger Types

Page View

The Page View trigger fires when a page loads. GTM gives you three variants, and the difference between them matters more than most people expect.

Page View fires as early as possible — before the DOM is fully built, before images have loaded. It is the right choice for tags that need to initialize early, like your GA4 configuration tag sending a page_view event. Firing early means the tag loads before the user has any chance to navigate away, reducing missed events on fast clicks.

DOM Ready fires once the HTML document has been fully parsed and the DOM tree is built, but before external resources like images and stylesheets have finished loading. Use this when your tag needs to read DOM elements — for example, pulling a product name from a heading tag.

Window Loaded fires last, after every resource on the page has finished loading. Use this for performance measurement tools, scroll depth initialization, or any tag that needs the complete page state. Firing too early with these tools produces unreliable results because parts of the page they need to measure are not yet present.

For most setups: use Page View for your GA4 tag, and Window Loaded for anything that requires the full page to be ready.

All Elements Click

The All Elements Click trigger fires on any click anywhere on the page — links, buttons, divs, images, or any other element. It is the broadest click trigger and the one you will configure with filters most often.

Common uses: outbound link tracking, phone number click tracking (Click URL contains "tel:"), CTA button tracking (Click Classes contains "cta-button"), and click tracking on interactive elements that are not <a> tags.

Always add a filter condition. An unfiltered All Elements Click trigger firing on every click on every page is almost never what you want — it bloats your event data and makes analysis impossible. Before adding this trigger, decide exactly which element you need to track and add a condition that narrows the scope to only that element.

Just Links Click

The Just Links trigger fires only on clicks on <a> anchor elements. It is more precise than All Elements Click for link tracking because it automatically surfaces the link-specific built-in variables: Click URL (the href attribute) and Click Text (the visible anchor text). These are available without any additional configuration.

Use Just Links for outbound link tracking, download tracking (filter on Click URL ending in .pdf or .zip), and email link tracking (Click URL contains "mailto:").

One important setting: Wait for Tags. When a user clicks a link that navigates immediately to a new page, the browser abandons the current page before tags have time to fire. Enabling "Wait for Tags" pauses navigation for up to 2 seconds while tags complete. Enable it whenever you are tracking outbound links or any link that leaves your domain, where losing the hit on navigation is a real risk.

Form Submission

The Form Submission trigger listens for the native submit event on HTML form elements. It fires when a user submits a form — contact forms, newsletter sign-ups, lead generation forms, checkout steps built with native HTML forms.

Two settings matter here. Wait for Tags applies the same way as with Just Links: if the form submits and immediately redirects the user to a thank-you page, the redirect can interrupt tag firing. Enable it for forms with immediate page redirects on submission.

Check Validation tells GTM to fire only if the form passes the browser's native validation. Enable it if your form has required fields — otherwise the trigger can fire on failed submission attempts where the user never actually converted.

One important limitation: the Form Submission trigger fires on the native submit event. Many modern form libraries (React Hook Form, Vue, Formik, custom AJAX submissions) do not use native form submission — they intercept the submit and send data via JavaScript. For those, the Form Submission trigger does nothing. You will need a Custom Event trigger wired to a dataLayer push from the form's success callback instead.

Timer

The Timer trigger fires repeatedly at a set interval after the page loads, measured in milliseconds. A 30,000ms interval fires once after 30 seconds; a 10,000ms interval fires every 10 seconds.

Use it for: time-on-page engagement tracking (fire once at 30 seconds = user is engaged), scroll engagement proxies, or video progress tracking for non-YouTube embeds. A single "user spent 30 seconds on this page" event per session is a practical proxy for reading engagement when scroll depth does not apply (single-screen pages, apps).

Two mistakes to avoid. First, setting the interval too short: a 100ms interval fires dozens of times per second and can generate hundreds of events per page view, which is almost certainly not what you want and will inflate your event counts. Second, forgetting to set a limit: GTM lets you specify a maximum number of times the trigger fires per page. If you are tracking a 30-second engagement milestone, set the limit to 1 so it fires once and stops.

Scroll Depth

The Scroll Depth trigger fires when the user scrolls to a specified percentage of the page height. You can set multiple thresholds in one trigger (25%, 50%, 75%, 90%) or set individual triggers per threshold if you need different tags at different depths.

Use it to measure content engagement. For blog posts and long-form articles, scroll depth is a direct proxy for how much of the content a user actually consumed. A user who scrolled to 90% on a 3,000-word post read the post. A user who bounced at 10% did not. Combine scroll depth events with page path in your GA4 reports to find content that loses readers early.

Vertical scroll depth is almost always what you need. The horizontal scroll option exists but has few practical applications; most pages do not scroll horizontally. Leave it off unless you have a specific horizontal scroll element you need to measure.

Note that GA4's Enhanced Measurement already includes a scroll event at 90% by default. If you are using GTM to add scroll depth tracking, either disable the Enhanced Measurement scroll event in GA4 or use different threshold values to avoid duplicate 90% events.

YouTube Video

The YouTube Video trigger fires on YouTube embed player events: Start, Progress (at percentage milestones: 10%, 25%, 50%, 75%), Pause, Seeking, and Complete. It works on embedded YouTube iframes with the standard embed URL format.

GA4's Enhanced Measurement includes automatic YouTube video tracking, but it fires at fixed milestones and gives you limited control over which events fire and what data they carry. The GTM trigger approach gives you full control: choose exactly which milestones to track, add custom parameters (video title, video duration, video URL), and attach the data to specific tags with specific event names.

For most setups, the YouTube Video trigger in GTM is more reliable than Enhanced Measurement's video tracking because you can test it in Preview mode and confirm exactly what fires. Use it whenever you need video engagement data beyond the default Enhanced Measurement output.

Custom Event

The Custom Event trigger is the foundation of advanced GTM. It fires when the data layer receives a push with a matching event name:

window.dataLayer = window.dataLayer || [];
dataLayer.push({
  event: 'checkout_step_complete',
  step: 2,
  step_name: 'shipping_info',
  order_value: 129.00
});

In GTM, you create a Custom Event trigger with the event name checkout_step_complete, and any tag assigned to that trigger fires when the data layer push occurs.

Use Custom Event triggers for anything the built-in triggers cannot detect natively: single-page app (SPA) page views, checkout funnel steps, user authentication events, AJAX form submissions, add-to-cart interactions, video player progress on non-YouTube players, and application-specific state changes. Pair them with data layer variables to read the payload from each push and pass it into your tags. If your website or app fires events that matter for your analytics, Custom Event triggers are how those events reach your tags.

The event name is case-sensitive. purchase and Purchase are two different events. This is one of the most common sources of broken Custom Event triggers — the name in the trigger does not exactly match the name in the dataLayer push.

Trigger Filters — Making Triggers Specific

What Trigger Filters Are

A trigger filter is a condition that restricts when a trigger fires. Without filters, most triggers fire on every matching event across the entire site. With filters, you narrow the scope to exactly the events you care about.

For example: an All Elements Click trigger with no filters fires on every click on every page. The same trigger with a filter "Click URL contains /checkout" fires only on clicks that navigate to your checkout flow. The trigger type defines the event category; the filter conditions define the specific event.

The Most Useful Filter Conditions

Contains — the variable value includes the specified string. Use for partial URL matching, partial class name matching, partial text matching. Page URL contains /blog/ fires on all blog pages without needing to enumerate each URL.

Equals — exact match. Use when you need to match one specific value and no partial matches are acceptable. More precise than Contains but requires the exact string.

Matches RegEx — the variable value matches the regular expression pattern. Use for flexible multi-pattern matching: Page URL matches RegEx /(checkout|cart|order)/ fires on any of three URL patterns in one condition. Useful when Contains would be too broad or you need alternation.

Does Not Contain — the inverse of Contains. Useful for exclusions: "fire on all pages except those containing /admin/."

When you add multiple filter conditions to one trigger, GTM evaluates them with AND logic by default — all conditions must be true for the trigger to fire. Use multiple conditions to narrow scope progressively: "Page URL contains /product/" AND "Click ID equals add-to-cart-btn".

Blocking Triggers

A blocking trigger prevents a tag from firing even when its assigned trigger conditions are met. In the tag's trigger configuration, you can add an exception trigger — when that exception trigger fires, the tag is suppressed.

The most practical use: internal traffic exclusion. Your GA4 tag fires on All Pages. You want to exclude your office IP. Create a trigger that fires on Page View when a first-party cookie or data layer variable identifies internal traffic, then add it as an exception to your GA4 tag. The tag fires everywhere — except when the exception trigger matches. No need to duplicate every tag setup.

Blocking triggers let you maintain clean default triggers (broad, reusable) while handling exceptions cleanly without creating dozens of narrowly-scoped trigger variants.

The 5 Most Common Trigger Mistakes

1. Firing on all pages instead of filtering to the right page type. The most common trigger mistake is creating a trigger that fires everywhere when it should fire only on specific pages. A purchase event tag firing on every page view, or a form submission tag with no URL filter running on every form on the site, pollutes your data immediately. Before saving any trigger, ask: "On which pages should this fire?" and add a Page URL filter if the answer is not "every page."

2. Form Submission with "Wait for Tags" disabled on forms that redirect. When a form submits and immediately redirects to a thank-you page, the browser abandons the current page before GTM tags have a chance to fire. The result is silent data loss — the submission happened, but no event landed in your analytics. Enable "Wait for Tags" on any Form Submission trigger where the form redirects on submit.

3. Using All Elements Click where Just Links would be more precise. Just Links is the correct choice for any click on an <a> tag. It gives you Click URL and Click Text automatically, without needing to enable additional built-in variables. All Elements Click is for non-anchor elements. Using the wrong one is not a critical bug, but Just Links makes link tracking setups cleaner and more explicit.

4. Custom Event trigger with the wrong event name. Event names in Custom Event triggers are case-sensitive. If your dataLayer push uses purchase (lowercase) and your trigger listens for Purchase (uppercase), the trigger never fires. The mismatch produces no error — the tag just silently doesn't fire. Any time a Custom Event trigger is not working, the first thing to check is whether the event name in the trigger exactly matches the event name in the dataLayer push, including capitalization.

5. Publishing without testing in Preview mode first. GTM's Preview mode shows you exactly which tags fired on each event, in what order, and with what variable values. It costs nothing and takes two minutes. Every trigger configuration — especially new ones on production — should be tested in Preview before publishing. A trigger that looks correct in the GTM interface may not behave correctly on the actual page, due to dynamic rendering, delayed DOM loading, or event listener conflicts. Preview mode catches these before they become production data problems. When you're satisfied, publish as a named container version so you have a clean rollback point if something goes wrong.

Frequently Asked Questions

What is a GTM trigger?

A GTM trigger is a rule that determines when a tag fires. It listens for a specific event in the browser — a page load, a click, a form submission, a data layer push — and fires any tags assigned to it when that event matches its conditions. Every tag requires at least one trigger to fire. Tags without triggers never run.

What is the difference between Page View and Window Loaded in GTM?

Page View fires as early as possible when a page starts loading, before the DOM is fully built. Window Loaded fires last, after every resource on the page (images, scripts, stylesheets) has finished loading. Use Page View for tags that should initialize early (like GA4). Use Window Loaded for tools that need the full page to be present before they run, such as performance measurement or scroll depth initialization.

How do I track button clicks in GTM?

Create an All Elements Click trigger set to fire on "Some Clicks," then add a filter condition to target your button specifically — for example, "Click ID equals submit-btn" or "Click Classes contains cta-button". Assign that trigger to your GA4 event tag. Test in Preview mode: click the button and confirm the tag fires, then click other elements on the page and confirm it does not fire. Publish once the scope is confirmed correct.

What is a Custom Event trigger in GTM?

A Custom Event trigger fires when your website pushes a named event into the data layer: dataLayer.push({ event: 'your_event_name' }). You set the event name in the trigger configuration; GTM fires the tag whenever it sees a push with that exact name. Custom Event triggers are how you connect application-level events — checkout steps, login events, AJAX form submissions, SPA page views — to your analytics tags.

How do scroll depth triggers work in GTM?

The Scroll Depth trigger fires when the user scrolls to a specified percentage of the total page height. You define thresholds (e.g., 25%, 50%, 75%, 90%) in the trigger configuration. Each threshold fires the trigger once per page load when the user first reaches that scroll position — scrolling back up and down again does not re-fire it. Use vertical scroll depth for content engagement measurement; avoid the horizontal option unless you have a specific horizontal scroll use case.

What does "Wait for Tags" do in GTM?

"Wait for Tags" pauses the browser's default action (following a link, submitting a form) for up to 2 seconds while all assigned tags finish firing. Without it, fast page navigations or form redirects can abandon the current page before tags have sent their data. Enable it on Just Links Click triggers when tracking outbound links, and on Form Submission triggers when the form redirects immediately after submission.

Why is my GTM trigger not firing?

Open GTM's Preview mode and reproduce the action that should trigger it. In the debug panel, look for the event in the event list on the left and click it — the right panel shows which tags fired and which did not. If your tag appears under "Tags Not Fired," click the tag name to see which trigger condition failed. Common causes: a filter condition is not matching (check exact values vs. what the variable actually holds), the event name does not match for a Custom Event trigger (case-sensitive), or the trigger type is wrong for how the element is built (e.g., using Form Submission on an AJAX form).

What is the difference between All Elements Click and Just Links in GTM?

All Elements Click fires on any click on any element on the page — links, buttons, images, divs, anything. Just Links fires only on clicks on <a> anchor elements and automatically populates Click URL and Click Text variables. Use Just Links for tracking link clicks (outbound links, downloads, email links) since it gives you the link destination automatically. Use All Elements Click for non-anchor interactive elements like <button> tags, custom components, or any clickable element that is not an anchor.