← All articles

GTM Trigger Types Explained — When to Use Each

April 1, 2026

Triggers are the "when" of Google Tag Manager. Every tag needs at least one trigger to fire, and picking the wrong trigger type is one of the most common reasons tags don't work as expected. A click trigger on a form submission, a page view trigger on a single-page app, or a visibility trigger with the wrong threshold — each leads to missing or incorrect data.

This guide explains every trigger type available in GTM, when to use each one, and the gotchas that trip up even experienced users.

What are GTM triggers and how do they work?

A trigger is a condition that tells GTM when to fire a tag. Under the hood, GTM listens for browser events (clicks, page loads, scroll, DOM mutations) and evaluates your trigger conditions against the event data. When all conditions match, the associated tags execute.

Key concepts:

• Trigger type determines which browser event GTM listens for (click, page view, scroll, etc.)
• Firing conditions narrow the trigger to specific elements, pages, or variable values
• Once per event / Once per page controls whether the trigger fires repeatedly or just once
• Triggers are OR'd on tags — if a tag has multiple triggers, it fires when any one of them matches (not all)

GTM evaluates triggers in the order events occur: Container Loaded → DOM Ready → Window Loaded → then user interactions (clicks, scrolls, form submissions). Understanding this sequence is critical for tags that depend on other tags or scripts being loaded first.

How do Click triggers work (All Elements vs Just Links)?

GTM has two click trigger types, and the difference matters more than you'd think.

Click — All Elements

Fires on any click anywhere on the page. The clicked element becomes available via built-in variables: Click Element, Click Classes, Click ID, Click Text, Click URL. Use this for:

• Buttons (<button>) and non-link elements
• Custom UI components (tabs, accordions, toggles)
• Images, icons, and interactive elements
• Any element that isn't a standard <a> link

Apply firing conditions to avoid matching every click on the page. The most common condition: Click Element matches CSS selector with a specific selector for your target element.

Click — Just Links

Fires only on <a> element clicks. This trigger type adds two features that All Elements doesn't have:

• Wait for Tags — delays the link navigation until the tag finishes executing. Critical for outbound link tracking where the page would navigate away before GA4 sends the request.
• Check Validation — only fires if the link click would actually navigate (respects event.preventDefault()). Prevents false positives from JavaScript-cancelled links.

When to choose which: Use Just Links for outbound link tracking, download tracking, and any <a> element where you need the Wait for Tags feature. Use All Elements for everything else — buttons, divs, images, custom components.

How do Form Submission triggers work?

The Form Submission trigger fires when an HTML <form> element is submitted. GTM intercepts the form's submit event and provides form-specific variables: Form Element, Form Classes, Form ID, Form URL, Form Target, and Form Text.

Wait for Tags: Like Just Links, this trigger has a "Wait for Tags" option that delays the form submission until tags finish executing. Enable this for standard HTML forms that redirect on submit — without it, the page navigates before your GA4 tag sends its request.

Check Validation: When enabled, the trigger only fires if the form passes browser-native validation (HTML5 required attributes, pattern matching). This prevents tracking invalid submission attempts.

The AJAX problem: Modern forms often use AJAX (fetch or XMLHttpRequest) instead of traditional HTML form submission. AJAX forms don't trigger the browser's submit event in a way GTM can intercept. For these forms, you need a different approach:

• Use a Custom Event trigger with a dataLayer push from the form's success callback
• Use a Custom HTML tag that listens for the form's JavaScript submit handler
• Track the "Thank You" page load instead of the form submission itself

GTM Event Helper detects whether a form uses standard HTML submission or AJAX. For AJAX forms, it generates the appropriate Custom Event trigger with a dataLayer push approach instead of the native Form Submission trigger.

How does the Element Visibility trigger work?

The Element Visibility trigger fires when a specific element becomes visible in the browser viewport. GTM uses the Intersection Observer API (or a polling fallback for older browsers) to detect when the element enters the visible area.

Configuration options:

• Selection Method: ID or CSS Selector. CSS Selector is more flexible and can target multiple elements.
• Minimum Percent Visible: What percentage of the element must be visible (1-100%). Default is 50%.
• When to fire: Once per page, Once per element, or Every time an element appears on screen.
• Observe DOM changes: Enable this if the element is added to the page dynamically (e.g., after an AJAX call or React render).

Common use cases:

• Product impression tracking (e-commerce view_item_list events)
• Ad impression counting (internal promotions)
• Lazy-loaded content engagement
• Section visibility for content engagement metrics
• Video player entering the viewport (trigger autoplay)

Performance note: Element Visibility triggers with "Observe DOM changes" enabled add a MutationObserver to the page, which can impact performance if the DOM changes frequently. Use this option only when the target element is dynamically added.

How does the Scroll Depth trigger work?

The Scroll Depth trigger fires when the user scrolls to a specified depth on the page. You can configure it by percentage (25%, 50%, 75%, 100%) or by pixel value (300px, 600px, etc.).

Percentages vs. pixels: Percentages adapt to page length — 50% on a short page might be 500px, while 50% on a long blog post could be 3000px. Pixels give you absolute positions. Use percentages for general engagement tracking; use pixels when you need to detect scroll to a specific section.

Available variables when the trigger fires:

• Scroll Depth Threshold — the threshold that was crossed (e.g., 25, 50, 75)
• Scroll Depth Units — "percent" or "pixels"
• Scroll Direction — "vertical" or "horizontal"

Typical setup: Create one Scroll Depth trigger with thresholds at 25%, 50%, 75%, and 100%. Attach a GA4 Event tag with event name scroll and pass {{Scroll Depth Threshold}} as a parameter. This gives you a complete scroll engagement picture in GA4.

Gotcha: GA4 has a built-in enhanced measurement scroll event that fires at 90% scroll depth. If you create your own scroll trigger, you might get duplicate scroll events. Either disable the enhanced measurement scroll event in GA4, or set your custom trigger thresholds to avoid 90%.

How do Page View triggers work (Page View, DOM Ready, Window Loaded)?

GTM provides three Page View trigger subtypes, each corresponding to a different stage of the page loading process:

Page View (Container Loaded)

Fires as soon as the GTM container loads — before the DOM is fully parsed. This is the earliest trigger available. Use it for:

• GA4 Configuration tags (should load as early as possible)
• Consent management platforms
• Any tag that needs to execute before the page renders

DOM Ready

Fires when the browser has finished parsing the HTML and building the DOM tree, but external resources (images, stylesheets, iframes) may still be loading. Equivalent to the DOMContentLoaded browser event. Use it for:

• Tags that need to access DOM elements (Custom HTML tags that query the DOM)
• Scripts that modify page content
• Tags that depend on the page structure being ready

Window Loaded

Fires when the entire page is fully loaded — all images, scripts, stylesheets, and iframes. Equivalent to the window.onload event. Use it for:

• Tags that depend on third-party scripts being loaded
• Performance measurement tags
• Low-priority tags that shouldn't compete for bandwidth during page load

Firing order: Page View → DOM Ready → Window Loaded. Tags attached to Page View triggers always fire before DOM Ready tags, which always fire before Window Loaded tags. Use this order to manage dependencies.

How do Custom Event triggers work?

Custom Event triggers listen for specific event names pushed to the dataLayer. When your code (or another tag) pushes an event to the dataLayer, any Custom Event trigger matching that event name fires.

// Push a custom event to the dataLayer
dataLayer.push({
  event: 'video_complete',
  video_title: 'Product Demo',
  video_duration: 120
});

The Custom Event trigger for this would have the event name set to video_complete. You can then access video_title and video_duration via Data Layer Variables.

When to use Custom Events:

• AJAX form submissions (push an event on success callback)
• Single-page application (SPA) virtual page views
• E-commerce dataLayer events (add_to_cart, purchase, etc.)
• Any interaction that doesn't correspond to a native browser event
• Communication between tags (Tag A pushes an event, Tag B fires on it)

Regex matching: The event name field supports regex. Setting it to ecom_.* would match ecom_add_to_cart, ecom_purchase, ecom_view_item, etc. This lets you use one trigger for a family of related events and differentiate them using a Data Layer Variable in your tag configuration.

How do Timer and History Change triggers work?

Timer Trigger

The Timer trigger fires at a specified interval (in milliseconds). Configure it with:

• Interval: Time between firings in milliseconds (e.g., 30000 for 30 seconds)
• Limit: Maximum number of times to fire (leave blank for unlimited)
• Conditions: Page URL or other conditions to restrict where the timer runs

Use cases: Time-on-page tracking (fire every 30 seconds to measure engagement), delayed tag firing (fire once after 10 seconds for users who stay on the page), and session heartbeat signals.

Warning: Timer triggers continue running even if the user switches tabs. The browser may throttle timers on inactive tabs, causing inconsistent intervals. Don't rely on timers for precise time measurement — use them for approximate engagement signals.

History Change Trigger

The History Change trigger fires when the browser's URL changes via the History API (pushState or replaceState) or the URL hash changes. This is essential for single-page applications (SPAs) built with React, Vue, Angular, or Next.js, where navigation happens without a full page reload.

Available variables:

• New History Fragment — the hash portion of the new URL
• New History State — the state object passed to pushState
• Old URL Fragment — the previous hash
• Old URL State — the previous state object

SPA page view tracking: Create a History Change trigger with no conditions. Attach a GA4 Event tag with event name page_view (or use the GA4 Configuration tag with "Send a page view event" enabled). This ensures every SPA navigation sends a page view to GA4.

Gotcha: Some SPAs push multiple history states per navigation (e.g., a redirect chain). This can cause duplicate page views. Add a condition to check that the {{Page URL}} actually changed between history events, or use a Custom JavaScript variable to debounce the trigger.

How do I choose the right trigger for my use case?

Here's a decision tree for the most common tracking scenarios:

Tracking button clicks: Click — All Elements with a CSS selector condition. Use Just Links only if the button is an <a> tag and you need Wait for Tags.

Tracking outbound links: Click — Just Links with "Wait for Tags" enabled. Filter by Click URL "does not contain" your domain.

Tracking form submissions: Form Submission trigger if the form uses standard HTML submission. Custom Event trigger with a dataLayer push if the form uses AJAX.

Tracking product impressions: Element Visibility trigger with a CSS selector matching product cards. Set minimum visibility to 50% and fire "Once per element."

Tracking scroll engagement: Scroll Depth trigger with percentage thresholds (25%, 50%, 75%, 100%).

Tracking SPA page views: History Change trigger with a GA4 page_view event. Consider adding conditions to prevent duplicate fires.

Tracking e-commerce events: Custom Event triggers matching your dataLayer event names (add_to_cart, begin_checkout, purchase).

Firing tags on page load: Page View for analytics and consent tags. DOM Ready for tags that need DOM access. Window Loaded for low-priority and performance tags.

How do trigger conditions and filters work?

Every trigger can be restricted with firing conditions. Conditions consist of a variable, an operator, and a value. Multiple conditions on the same trigger are AND'd — all must be true for the trigger to fire.

Common operators:

• equals / does not equal — exact match (case-sensitive)
• contains / does not contain — substring match
• starts with / ends with — prefix/suffix match
• matches RegEx — full regex support for complex patterns
• matches CSS selector — for Click Element, uses native element.matches()
• less than / greater than — numeric comparison

Variable scope: Conditions can use any GTM variable — built-in (Page URL, Click Classes, Referrer) or user-defined (Data Layer Variables, Custom JavaScript, Lookup Tables). Choose the most specific variable available. For example, use Page Path instead of Page URL when you don't want query parameters affecting the match.

Exception triggers: Every trigger has an "Add Exception" option. Exception triggers block the parent trigger from firing. Use exceptions to exclude specific pages or conditions without modifying the main trigger. For example: fire on all pages except /admin/*.

What are trigger groups and when should I use them?

A Trigger Group fires only when all the triggers within it have fired at least once during the page session. Unlike regular triggers (which are OR'd), triggers in a group are AND'd — every one must fire before the group trigger activates.

Example: You want to fire a survey tag only for users who have both scrolled past 75% and spent at least 30 seconds on the page. Create a Trigger Group containing:

1. A Scroll Depth trigger at 75%
2. A Timer trigger at 30000ms (limit: 1)

The tag attached to this Trigger Group fires only when both conditions have been met — regardless of which happens first.

Use cases:

• Engaged user qualification (scroll + time + page count)
• Multi-step conversion tracking (form start + form complete)
• Sequential interaction requirements (video watched + CTA visible)
• Conditional tag loading (consent granted + page loaded)

Limitation: Trigger Groups reset on each page load. They only track triggers within a single page session, not across pages. For cross-page conditions, use cookies, localStorage, or a Data Layer Variable that persists across page views.

What are the most common trigger mistakes?

These mistakes cause the most debugging headaches. Avoid them to save hours of troubleshooting:

1. Using Form Submission for AJAX forms. If the form doesn't cause a page navigation or full reload, the Form Submission trigger won't fire. Test by submitting the form — if the page doesn't refresh or navigate, you need a Custom Event trigger instead.

2. Forgetting to enable built-in variables. GTM doesn't activate click or form variables by default. If your trigger condition references Click ID but it's not enabled, the condition evaluates against undefined and never matches. Go to Variables → Configure and enable everything you reference.

3. All Pages trigger on SPAs. A Page View trigger set to "All Pages" fires once on the initial page load — it doesn't fire again when the SPA navigates to a new route. You need a History Change trigger (or a Custom Event from your router) for subsequent page views.

4. Click trigger matches child elements. When you click a button that contains a <span> or <svg>, the Click Element is the inner element, not the button. The "matches CSS selector" operator walks up the DOM, but "equals" and "contains" on Click Classes or Click ID don't. Always use CSS selector matching for click triggers.

5. Scroll trigger on short pages. If you set a 75% scroll threshold but the page content fits entirely in the viewport (no scrollbar), the trigger never fires because no scrolling occurs. Consider using Element Visibility instead for tracking whether users reach specific sections.

6. Timer trigger without a limit. A Timer trigger with no limit fires indefinitely every N milliseconds. If you intended a one-time delayed fire, set the limit to 1. Unlimited timers generate continuous events that inflate your GA4 event count and can hit session limits.

7. Case-sensitive event names. dataLayer.push({ event: 'Purchase' }) won't match a Custom Event trigger set to purchase. GTM's Custom Event matching is case-sensitive. Standardize on lowercase event names to avoid this.

8. Too many exception triggers. Exception triggers add complexity. If you have a trigger with five exceptions, consider inverting the logic — create a trigger that only fires on the pages you want, instead of firing everywhere and excluding specific pages.

External Resources

• Google: Trigger types in GTM
• Google: Trigger groups
• MDN: Intersection Observer API

Related Articles

• How to Track Button Clicks in GTM Without Writing Code
• How to Debug GTM Tags — Complete Troubleshooting Guide
• How to Track AJAX Form Submissions in GTM
• CSS Selector Best Practices for GTM Triggers
• GA4 Event Tracking Setup Without Code

← All articles · Home · Privacy Policy · Contact