GTM Triggers Explained: Every Trigger Type and When to Use Each One

| Incisive Ranking
GTM Triggers Explained: Every Trigger Type and When to Use Each One | Incisive Ranking

Inside every Google Tag Manager container, there are three building blocks: tags, triggers, and variables. Most people spend their time thinking about tags — what tracking code to fire, which platform to send data to. But it's triggers that actually control whether any of that happens. Get the trigger wrong and your perfectly built tag sits dormant, waiting for a condition that never comes. Or worse, it fires constantly on every page when it should only fire once at the moment of conversion.

Understanding GTM triggers properly — what each type does, what signals it listens for, and when it's the right tool — is one of the highest-leverage skills in analytics. This guide covers every trigger type available in GTM, how each one works, and the specific situations where you'd reach for one over another.

🏷️

Not sure if your GTM triggers are set up correctly? Incisive Ranking offers full GTM audits to identify missed events and misfiring tags before they cost you conversion data.

Get a Free GTM Audit

What Is a GTM Trigger?

A trigger is a condition that tells GTM when to fire a tag. Every tag in your container must have at least one trigger attached to it — without one, the tag simply never runs.

When a user interacts with your website, GTM monitors those interactions continuously in the background. Every click, page load, form submission, scroll, and custom event generates a signal. Triggers are the filters that determine which of those signals should cause a specific tag to execute.

There are three broad categories of triggers in GTM: Page View triggers (fire when a page loads), Click triggers (fire when something is clicked), and Other triggers (a catch-all for form submissions, scroll depth, timers, custom events, and more). Let's go through each in detail.

Page View Triggers

These fire at various stages of a page loading. The difference between them matters more than most people realise.

Page View

This fires as soon as the browser begins loading the page — before the DOM has fully constructed and before most elements have rendered. It's the earliest possible moment GTM can fire a tag.

Use it when: You need to load a script as early as possible — for example, a consent management platform, a chat widget initialisation script, or any tag that needs to run before content renders. Be cautious: because it fires so early, the DOM isn't ready yet, so any tag that needs to read page elements (button text, form fields, product IDs) may not find them.

DOM Ready

This fires when the HTML document has fully loaded and the DOM is constructed, but before images and stylesheets have finished loading. At this point, all page elements exist and can be queried.

Use it when: Your tag needs to read information from the page — product names, prices, categories — that live in the HTML. DOM Ready gives you a reliable moment when those elements are present but the page hasn't fully rendered, keeping things fast.

Window Loaded

This fires after everything on the page has finished loading: HTML, images, stylesheets, and all synchronous scripts. It's the last of the three page view triggers.

Use it when: Your tag depends on third-party scripts or dynamically loaded content that doesn't exist until the page is fully complete. For example, if you're reading a value that gets populated by a payment widget loaded after the main page, Window Loaded is the only trigger that guarantees that widget is present.

Quick rule of thumb: Default to DOM Ready for most page-level tags. Use Page View only for consent/privacy scripts that need to run first. Use Window Loaded when you're reading values that only appear after external scripts finish running.
💡

Getting the timing wrong on page view triggers is one of the most common causes of missing data in GA4. Our team can review your setup and make sure every tag fires at the right moment.

Talk to Our Team

Click Triggers

Click triggers fire when a user clicks on an element. GTM offers two variants that behave differently depending on what's being clicked.

All Elements

This trigger fires whenever any element on the page is clicked — links, buttons, images, divs, spans, anything. GTM captures attributes of the clicked element automatically: its ID, class, text content, and the URL it links to.

Use it when: You want to track clicks on non-link elements like buttons, cards, or custom UI components. Because it captures everything, you'll almost always want to add a condition to narrow it down — for example, "Click Classes contains cta-button" — so the tag only fires for the specific element you care about.

Just Links

This trigger fires specifically when an anchor tag (<a>) is clicked. The key advantage is that GTM can optionally wait for the tag to fire before following the link — preventing the scenario where a user navigates away before the tracking request completes.

Use it when: Tracking outbound link clicks, PDF downloads via direct links, or navigation between sections. The "Wait for Tags" option (under advanced settings) is particularly valuable here — it gives your tags a brief window to send their data before the browser follows the link.

⚠️ Watch out for the Click trigger on SPAs: In single-page applications, navigation often doesn't involve real link clicks — it happens through JavaScript routing. All Elements or Just Links triggers won't capture these navigations. You'll need a custom History Change trigger or a data layer event pushed by the application instead.

Form Triggers

Form Submission

GTM's built-in form submission trigger fires when a user submits an HTML form on your page. It works by listening for the native form submit event in the browser.

Use it when: Your website uses standard HTML forms that submit with a page reload or redirect — classic contact forms, newsletter sign-ups, or lead forms on simple websites.

When it won't work: The form submission trigger breaks down in three common situations: AJAX forms (where submission happens without a page reload), forms embedded in iframes, and single-page applications. In all three cases, the native submit event either doesn't fire or isn't accessible to GTM. The reliable alternative is a data layer push triggered by the developer when the form submission is confirmed server-side.

User Engagement Triggers

Scroll Depth

This trigger fires as users scroll down a page, at thresholds you define. You can set percentage-based thresholds (e.g., 25%, 50%, 75%, 100% of page height) or pixel-based thresholds (e.g., after 500px of scroll).

Use it when: Measuring content engagement on blog posts or long-form pages, identifying where users stop reading, or qualifying "engaged" users for remarketing audiences. A common setup: fire a GA4 event when a user scrolls to 75% — a reasonable proxy for actually reading the content.

YouTube Video

This trigger fires on interactions with YouTube videos embedded on your page using the standard iframe embed method. It can track starts, pauses, completions, and progress milestones (25%, 50%, 75%).

Use it when: You have product demos, explainer videos, or testimonials embedded on key pages and want to understand how video engagement correlates with conversion. One important requirement: YouTube's JavaScript API must be enabled on the video, which GTM handles automatically when this trigger is activated.

Element Visibility

This trigger fires when a specific element on the page becomes visible in the user's viewport — even if they never scroll to it. You identify the element by CSS selector or element ID.

Use it when: Tracking whether users actually see a specific section — a pricing table, a testimonial block, a product recommendation widget — rather than just whether the page loaded. It's subtly different from scroll depth and much more precise for tracking impression-level engagement with specific components.

Timer Trigger

The timer trigger fires at regular intervals while a user is on the page. You set the interval in milliseconds (e.g., 30000 for 30 seconds) and optionally a maximum limit on how many times it fires per page.

Use it when: Measuring time-on-page engagement, triggering exit-intent style prompts after a defined period, or sending a "session quality" event to GA4 after a user has been on the page for a meaningful amount of time. Use sparingly — timers add a small overhead and should always have a reasonable maximum fire count to avoid polluting your data.

Custom Event Trigger

This is arguably the most important and versatile trigger in GTM. It fires when a specific named event is pushed to the data layer using dataLayer.push({ 'event': 'your_event_name' }).

Use it when: Tracking anything that requires backend confirmation or happens inside an AJAX flow — purchase completions, successful form submissions, video play events from a custom player, add-to-cart on a dynamic page, or any interaction that JavaScript on the page can detect but GTM's native triggers can't.

Custom events are the backbone of robust ecommerce tracking. They give you precise control: the tag fires only when the developer explicitly says "this interaction happened and was confirmed", not when GTM guesses based on a click or URL pattern.

Naming convention matters: Agree on event names with your developer before implementation. Use snake_case consistently (e.g., form_submitted, purchase_complete, video_played). Inconsistent naming leads to duplicate triggers and messy GA4 event reports.

History Change Trigger

This trigger fires when the browser's URL changes without a full page reload — the pattern used by single-page applications (SPAs) built with frameworks like React, Vue, Angular, or Next.js.

Use it when: Your website is a SPA and you need GTM to treat each virtual page navigation as a new pageview. Without this trigger, your GA4 property will record one session event when the user first lands and nothing else as they navigate between "pages" — making your data almost useless for understanding user behaviour.

Quick Reference: All Trigger Types at a Glance

Trigger TypeWhen It FiresBest Used ForCommon Pitfall
Page ViewAs page begins loadingConsent scripts, early-load tagsDOM not ready — can't read page elements
DOM ReadyHTML parsed, DOM builtReading page data, GA4 page eventsExternal scripts not yet loaded
Window LoadedAll resources loadedTags needing dynamically loaded contentSlowest to fire — don't use unnecessarily
All Elements ClickAny element clickedButton tracking, card clicksToo broad without conditions
Just Links ClickAnchor tags clickedOutbound links, PDF downloadsDoesn't catch SPA navigation
Form SubmissionNative form submittedSimple HTML forms with page reloadFails on AJAX, iframes, SPAs
Scroll DepthUser scrolls to thresholdContent engagement on blogsFires again on back navigation
YouTube VideoYouTube embed interactionVideo start/complete trackingAPI must be enabled on embed
Element VisibilityElement enters viewportImpression tracking on sectionsFires on every page load if element is visible immediately
TimerAt set intervalsTime-on-page engagementNo max fires = data flood
Custom EventdataLayer.push with event keyPurchase events, AJAX forms, SPAsNeeds developer coordination
History ChangeURL changes without reloadSPA virtual pageviewsMay double-fire if SPA also reloads

Combining Triggers: Firing and Exception Filters

Most GTM tags use a single trigger — but many real-world setups require more precision. GTM allows you to attach multiple triggers to a single tag and define exception conditions that prevent it from firing even when the main trigger activates.

For example: you might set up a Scroll Depth trigger to fire at 75%, but add an exception filter that prevents it from firing on your blog category pages (where you don't care about scroll depth). Or you might add an All Elements click trigger but restrict it to elements with a specific CSS class. This combination of firing trigger plus exceptions is how you build precise, reliable tracking without creating a different tag for every scenario.

Wrapping Up: Triggers Are the Foundation of Reliable Tracking

Tags get the headlines, but triggers do the work. A great tag attached to the wrong trigger is wasted — it either fires too early, too late, on the wrong page, or not at all. And because misfiring triggers often fail silently, you might not notice the problem until weeks later when you're trying to reconcile your analytics data with your backend numbers.

The pattern that works in practice: use native GTM triggers for standard interactions (clicks, scrolls, page views), and use Custom Event triggers for anything that requires backend confirmation or happens inside a dynamic application flow. That combination covers the vast majority of tracking needs cleanly and reliably.

At Incisive Ranking, we audit GTM containers regularly and the most common issue we find is mismatched triggers — tags firing on conditions that don't accurately represent the underlying user action. If your tracking feels unreliable or your GA4 data doesn't match reality, a trigger audit is usually the fastest way to find out why.

Want to make sure every tag in your GTM container is firing at exactly the right moment? Get a free audit from Incisive Ranking.

Get My Free GTM Audit View Our Services

Follow Us:

About Us

We are experts in Tags and Tracking Services. With experience in eCommerce and Custom Conversion tracking, Server Side Tagging, and Data tracking to help you get the advantage of ACCURATE data for better decision making. With more than 6 years of experience, We have already delivered more than 500 projects.