GTM Triggers: Every Trigger Type and When to Use It

GTM triggers are the conditions that tell Google Tag Manager when to run a tag. Get them right and your tracking fires exactly when it should. Get them wrong and you end up with tags firing on every page load when they should fire on a button click, or never firing at all because the condition is too restrictive.

This guide covers every trigger type available in GTM, explains what each one is designed to measure, and gives you practical guidance on choosing the right trigger for each tracking scenario.

⠀

Page View Triggers: Gtm Triggers

⠀

Page view triggers are the most commonly used trigger type. They fire when a page loads or, for single-page applications, when a virtual page change occurs.

Page View: Fires as soon as the browser starts rendering the page — before the DOM is complete. Use this for tags that need to run as early as possible, like consent management scripts or analytics initialization tags. Not suitable for tags that need to read DOM elements.

DOM Ready: Fires when the HTML document has been fully parsed but before images and external resources have loaded. This is the right trigger for most analytics tags, as the full page content is available but the tag does not wait for slow-loading resources.

Window Loaded: Fires after everything on the page has finished loading — all images, scripts, and resources. Use this for tags that depend on content loaded by other scripts, or when you need to measure fully-loaded page performance.

For single-page applications (React, Vue, Angular), add a History Change trigger alongside page view triggers. When URL changes happen without a full page reload, history change fires a virtual pageview so analytics platforms register the navigation.

⠀

Click Triggers ve Gtm Triggers

⠀

Click triggers fire when a user clicks an element on the page.

All Elements: Fires on any click anywhere on the page. Use sparingly — this is a broad trigger that fires frequently and requires careful filtering conditions to isolate the clicks you care about.

Just Links: Fires only when a link element (<a> tag) is clicked. It includes built-in options to wait for tags to fire before following the link (useful for tracking outbound clicks where the page might navigate away before the tag completes), and to check validation before the click is counted.

For both click trigger types, add filter conditions to limit firing to specific elements. Common conditions include:

• Click URL contains /checkout — fires when a link to the checkout is clicked

• Click Classes contains cta-button — fires on elements with a specific CSS class

• Click ID equals submit-form-btn — fires on a specific element ID

⠀

Avoid using "matches CSS selector" with complex selectors in click triggers — it can cause performance issues on pages with many elements.

⠀

⠀

⠀

Form Triggers

⠀

Form triggers fire on form interactions. GTM has two built-in form trigger types:

Form Submission: Fires when any form on the page is submitted. Add conditions to restrict it to specific forms (by form ID, class, or action URL). GTM's form trigger works by intercepting the form's submit event, which means it captures standard HTML form submissions but may miss custom JavaScript form handlers.

For forms built with JavaScript frameworks (contact forms from HubSpot, Typeform embeds, custom React forms), standard form submission triggers often do not work. In these cases, rely on the form provider's native analytics integration or use a custom event trigger tied to a data layer push fired by the JavaScript form completion handler.

Click trigger as form submit: Sometimes the most reliable approach for complex forms is to treat the submit button click as the trigger, rather than the form submission itself. This works well for forms that handle submission asynchronously and do not navigate to a new page.

⠀

Scroll Depth Triggers

⠀

Scroll depth triggers fire when a user scrolls to a specified percentage or pixel depth on the page. They are essential for measuring content engagement on long-form pages.

Percentage-based: Fire at specified scroll percentages (25%, 50%, 75%, 90%). The most common use is tracking 90% scroll depth as an engagement signal.

Pixel-based: Fire when the user scrolls to a specific number of pixels from the top. This is useful when you have a specific content element at a known position that you want to track visibility for.

Enable "Once per page" in the trigger settings to avoid multiple firings as users scroll up and down. If scroll depth fires every time the user passes a threshold, your data will overcounting engaged sessions.

⠀

Element Visibility Triggers

⠀

Element visibility triggers fire when a specific DOM element enters the viewport. Unlike scroll triggers (which measure distance scrolled), visibility triggers fire when the element is actually visible to the user.

Use visibility triggers to track:

• When a CTA button becomes visible

• When a specific product or pricing block comes into view

• When a testimonial section is seen

• When a video player element enters the viewport (before the user clicks play)

⠀

Configure the trigger with a CSS selector or element ID that uniquely identifies your element. Set a minimum percentage visible (typically 50%) to avoid triggering on elements that are barely on screen. Set "Once per page" to avoid repeated triggers on scroll.

⠀

Timer Triggers

⠀

Timer triggers fire at specified intervals after a page loads. They are useful for tracking engaged time on page.

Interval: Fire every N milliseconds (you specify the interval). A timer with a 30,000ms interval and a limit of 1 fires once, 30 seconds after page load — useful for tagging "engaged visitor" events.

Page timer: Set to fire every 30 seconds to measure engaged dwell time in increments. Combine with a scroll trigger condition to ensure the user is actually engaged (both scrolled and stayed) rather than just leaving a tab open.

⠀

⠀

⠀

Custom Event Triggers

⠀

Custom event triggers are the most powerful and reliable trigger type for complex implementations. They fire when a specific named event is pushed to the data layer.

dataLayer.push({ event: 'video_completed' });

⠀

A custom event trigger configured to fire on event equals video_completed will fire exactly when that push occurs and no other time. This precision makes custom event triggers the preferred approach for:

• E-commerce funnel events

• Complex form interactions

• JavaScript-driven application state changes

• Any interaction where GTM's built-in trigger types cannot reliably detect the event

⠀

Work with your development team to define a data layer event naming convention and push structure before building your GTM configuration. When the data layer is well-designed, custom event gtm triggers are the most maintainable and reliable tracking approach.

⠀

JavaScript Error Triggers

⠀

The JavaScript Error trigger fires when an uncaught JavaScript error occurs on the page. This is useful for debugging and monitoring — fire a GA4 event whenever an error occurs, including the error message and URL, so you can monitor front-end errors in your analytics data.

This trigger does not require any page modifications. It hooks into the browser's window.onerror handler automatically.

⠀

Choosing the Right GTM Trigger

⠀

A quick decision guide:

Tracking goal | Recommended trigger

• Tracking goal: All page loads | Recommended trigger: Page View or DOM Ready

• Tracking goal: SPA navigation | Recommended trigger: History Change

• Tracking goal: Button click | Recommended trigger: All Elements + Click ID/Class filter

• Tracking goal: Outbound link | Recommended trigger: Just Links + URL filter

• Tracking goal: Standard form submit | Recommended trigger: Form Submission

• Tracking goal: Custom JS form | Recommended trigger: Custom Event

• Tracking goal: Scroll engagement | Recommended trigger: Scroll Depth (90%)

• Tracking goal: Element in view | Recommended trigger: Element Visibility

• Tracking goal: Time on page | Recommended trigger: Timer (30s, 60s)

• Tracking goal: Custom interaction | Recommended trigger: Custom Event (data layer)

⠀

⠀

Frequently Asked Questions

⠀

Why is my GTM form trigger not firing on a HubSpot or Gravity Forms form?

Third-party form providers often handle submission through JavaScript rather than standard HTML form events. GTM's built-in form trigger may not capture these. Use the provider's native analytics integration, or ask your developer to add a data layer push on form success and create a custom event trigger in GTM.

Can I have multiple triggers on one tag?

Yes. A tag can have multiple triggers — it fires when any of them is activated. You can also add exception triggers that prevent the tag from firing even when a trigger condition is met. Exception triggers are useful for excluding internal traffic, specific pages, or test environments.

What is the difference between a DOM Ready trigger and a Window Loaded trigger?

DOM Ready fires when the HTML is parsed and the page structure is available, but before images and external scripts finish loading. Window Loaded fires after everything — including images and third-party scripts — has fully loaded. For most analytics tags, DOM Ready is sufficient and faster. Use Window Loaded when your tag depends on data provided by a late-loading third-party script.