TL;DR

Google Tag Manager has five page view trigger types that always run in the same order: Consent Initialization, Initialization, Page View, DOM Ready and Window Loaded.
Conditions inside one trigger must all be true (AND); two firing triggers on one tag fire it when either matches (OR).
Google's own help warns that a .* regex in a Custom Event trigger matches every dataLayer event, including ones Tag Manager and the Google tag create automatically.
A trigger exception only blocks firing triggers on the same event, so a Page View exception cannot stop a tag fired by a Click trigger.

Google Tag Manager triggers are the rules that decide when a tag fires: each trigger listens for an event on the page, such as a page load, a click, a form submission or a custom dataLayer push, and checks optional conditions before it lets the tag run. Every tag needs at least one trigger, so if your Google Ads conversions or GA4 events are missing or doubled, the trigger setup is usually the first place to look.

This guide walks through how Google Tag Manager triggers work, the difference between the page view trigger types, how click and form triggers behave, how custom event triggers read the dataLayer, how trigger exceptions block tags, and how to prove a trigger works in Preview mode before you publish.

What Google Tag Manager triggers actually do

Tag Manager runs on an event model. As a page loads and as people interact with it, Tag Manager receives a stream of events. Some are built in, such as the page view event (internally called gtm.js), DOM ready (gtm.dom) and window loaded (gtm.load). Others come from clicks, form submissions, scrolling, or from your own code pushing an object with an event key into the dataLayer.

Every time an event arrives, Tag Manager evaluates the triggers attached to your tags. A trigger has two parts:

The event type it listens for, for example Page View, Click, Form Submission or Custom Event.
Optional filters, each made of a variable, an operator and a value, for example "Page Path contains /checkout/".

A new trigger fires on all events of its type by default. To narrow it, you switch "This trigger fires on" from "All" to "Some" and add conditions. Within one trigger, every condition must be true at the same time. If you attach two firing triggers to one tag, the tag fires when either of them matches. That AND-inside, OR-across logic explains a lot of surprising behaviour: if you want "checkout page OR thank-you page", you need two triggers (or one regex condition), not two conditions in the same trigger.

Available operators include equals, contains, starts with, ends with, matches RegEx, CSS selector matching for click targets, and numeric comparisons such as less than. Most of them also have a negated version, such as does not contain.

Page View vs DOM Ready vs Window Loaded

The page view family has five trigger types, and they fire in a fixed order on each page load. Choosing the right one is about timing: fire too early and the data your tag needs is not on the page yet; fire too late and you may lose the hit when someone leaves quickly.

The table below summarises the five page view trigger types in the order Tag Manager runs them, based on Google's Tag Manager documentation.

Page View vs DOM Ready vs Window Loaded
Trigger type	When it fires	Typical use
Consent Initialization	Before every other trigger	Consent management platform tags and consent defaults
Initialization	Before all triggers except Consent Initialization	Tags that must run early, such as the Google tag setup
Page View	As soon as the browser starts loading the page	Tags that only need page impression data
DOM Ready	After the HTML document is built and can be parsed	Tags whose variables read content from the page
Window Loaded	After the page and its images and scripts have fully loaded	Low-priority tags, or tags that depend on other scripts

A practical rule of thumb: use Page View for tags that only need the URL and referrer, use DOM Ready when a variable reads something from the HTML (a product price in an element, a form ID, a heading), and keep Window Loaded for things that genuinely depend on every other script having finished. Pushing everything to Window Loaded "to be safe" delays tags on slow pages and can lose data from visitors who bounce before heavy images finish loading.

Each web container ships with built-in "All Pages" versions of Consent Initialization and Initialization. If your site uses a consent banner, the banner's tag belongs on Consent Initialization so consent state is set before any measurement tag evaluates it.

Click triggers and form triggers

All Elements vs Just Links

The click trigger comes in two flavours. All Elements listens for clicks on anything: buttons, images, divs, icons. Just Links listens only for clicks on HTML a elements. Just Links adds two options that All Elements does not have:

Wait for Tags holds the link navigation until tags have fired or a timeout you set has passed, which helps when a click leads straight to another page.
Check Validation fires tags only when the click is a valid action. Left unticked, the trigger fires whenever a link is clicked, even if other code cancelled the navigation.

Click triggers rely on built-in click variables such as Click URL, Click Text, Click Classes and Click ID. These are not all switched on in a new container. Go to Variables, choose Configure under Built-In Variables, and enable the click variables you plan to filter on. A trigger that filters on a disabled variable will never match.

Google also recommends limiting click triggers to the pages where the clicks happen, for example with a "Page Path contains /promo/" condition, instead of listening on every page.

Form submission triggers

The form submission trigger listens for the browser's standard submit event. It offers the same Wait for Tags and Check Validation options as link clicks. The catch is that many modern forms never fire a standard submit event: they send data with JavaScript and show a "thank you" message without reloading. On those forms the trigger stays silent, or fires on the attempt rather than the successful submission.

When that happens, you have two dependable options: fire your conversion tag on a thank-you page with a page view trigger, or ask a developer to push a dataLayer event after the form has actually been accepted, then catch it with a custom event trigger. The second option is more precise because it only counts submissions the server accepted.

Custom event triggers and the dataLayer

The custom event trigger is how Tag Manager hears about things your own code knows that the page itself does not show. A developer pushes an object into the dataLayer, for example dataLayer.push({'event': 'lead_submit', 'form_name': 'contact'}). In Tag Manager you create a Custom Event trigger with the event name lead_submit. When the push happens, the trigger matches and the tag fires. The extra keys, like form_name, can be read with Data Layer Variables and passed into GA4 parameters or a Google Ads conversion value.

Three rules keep custom event triggers reliable:

Match the name exactly. The trigger compares against the value of the event key. Treat names as exact strings and keep one naming style (for example lower case with underscores) across the site so nobody guesses.
Push after the fact, not before. A lead event should be pushed when the form is accepted, a purchase event when the order is confirmed. Pushing on button press counts failed attempts as conversions.
Push the data before or with the event. Variables are read at the moment the event is processed, so a value pushed later will not be available to that tag.

Regex and wildcard event names

The custom event trigger has a "Use regex matching" option, which lets one trigger catch several event names, for example ^(lead_submit|quote_request)$. This is useful, but keep the pattern tight. A catch-all pattern such as .* matches every event in the dataLayer, including the events Tag Manager and the Google tag emit on their own. Any new event that appears later, whether from a new plugin, a developer change or a platform update, will also match it. The result is tags firing many times per page, inflated GA4 event counts and duplicate conversions. Anchor the pattern with ^ and $ and list the names you mean.

Trigger exceptions (blocking triggers)

A trigger exception, also called a blocking trigger, stops a tag from firing even when a firing trigger matches. The classic example is a tag set to fire on all pages with an exception for the thank-you page, so it never fires on that one URL. When a firing trigger and an exception both match the same event, the exception wins.

The detail that trips people up: an exception only blocks firing triggers that run on the same event. A Page View exception cannot block a tag that fires from a Click trigger, because the click happens on a different event. To block a click-fired tag on certain pages, build the exception as a click trigger with a Page Path condition. If an exception seems to be ignored, check that its trigger type matches the firing trigger's type.

Other trigger types worth knowing

History Change fires when the URL changes without a full page load. Single-page apps and some booking engines need it, because a standard page view trigger fires only once.
Element Visibility fires when a chosen element enters the viewport, for example a pricing table or an embedded form.
Scroll Depth fires at the vertical or horizontal percentages or pixel depths you set.
Timer fires at an interval in milliseconds, with an optional limit on how many times.
YouTube Video fires on start, pause, progress and completion of embedded YouTube videos.
JavaScript Error fires on uncaught errors, which can be sent to GA4 for debugging.
Trigger Group fires once all of the triggers inside the group have fired at least once, for example "scrolled 50% and stayed 30 seconds".

Separately, each tag has a firing option under Advanced Settings: once per event, once per page, or unlimited. A conversion tag that should count once per page load can be set to once per page as a safety net, though it is better to fix the trigger that fires it twice.

Testing triggers in Preview and Debug mode

Never publish a trigger you have not watched fire. Click Preview in the workspace, enter your site URL, and Tag Assistant opens your site in a connected tab. Then:

Perform the action: load the page, click the button, submit the form.
In Tag Assistant, select the event in the left-hand timeline (Container Loaded, DOM Ready, Window Loaded, Click, your custom event name).
Check the Tags tab. Your tag should sit under "Tags Fired" for that event and nowhere else. If it sits under "Tags Not Fired", open it to see which trigger condition failed.
Open the Variables tab for the same event to see the actual value of Click URL, Page Path or your Data Layer Variable at that moment. Most failed conditions come from a value that is different from what you typed.
Repeat on mobile width and on a second page to confirm the trigger does not fire where it should not.

When the tag fires on exactly the events you expect, publish with a clear version name that says what changed. Version history lets you roll back if the next release breaks something.

What this means for Thai marketers

Thai sites raise a few trigger issues of their own. Thai-language URLs are percent-encoded in the browser, so the Page Path variable returns the encoded form, not the Thai characters you see in the address bar. A condition like "Page Path contains" with Thai text will not match. Use the encoded string, match on an ASCII part of the URL, or use a regex built from the encoded value.

LINE is often the main conversion channel. Clicks on line.me links can be tracked with a Just Links click trigger and a "Click URL contains line.me" condition, sent to GA4 as an event and imported into Google Ads. Thailand's PDPA also makes consent handling part of every container: the consent banner tag belongs on Consent Initialization, and measurement tags should respect the consent state it sets. If your GA4 setup needs a clean rebuild with consistent triggers, start with our GA4 migration and tracking service.

Common trigger mistakes and what they cost

Two triggers on one conversion tag that both match the same action (for example a click trigger and a form trigger on one submit). Each match fires the tag, so conversions double and Smart Bidding learns from inflated numbers in your Google Ads account.
Conversion tags on button clicks instead of confirmed success. Failed or invalid submissions get counted.
"All Pages" triggers on tags that should run on a few pages. Extra hits, slower pages, and remarketing audiences that include everyone. Clean audiences matter if you run remarketing campaigns.
Filters on built-in variables that were never enabled. The trigger never matches and nobody notices until the report is empty.
Catch-all regex custom events. Tags fire on every dataLayer event, including new ones added later.

Google Tag Manager triggers FAQ

How many triggers can one tag have?

A tag can have several firing triggers and several exceptions, and it fires when any one firing trigger matches unless an exception on the same event blocks it. Keep the count low and give each trigger a descriptive name so the next person can read the setup.

Should I use Page View or DOM Ready for GA4?

Use the Initialization or Page View trigger for the Google tag itself, and DOM Ready only for tags whose variables read content from the page. The Google tag needs to load early so that later event tags can use its configuration.

Why does my form submission trigger not fire?

Most often the form sends data with JavaScript and never fires the browser's standard submit event. Use a thank-you page trigger or a dataLayer push with a custom event trigger instead, and confirm it in Preview mode.

Is it safe to use .* in a custom event trigger?

No, a .* pattern matches every dataLayer event, including those Tag Manager and the Google tag create automatically and any new event added later. Use a narrow, anchored pattern that lists the exact event names you want.

Do trigger exceptions work across trigger types?

No, an exception only blocks firing triggers that run on the same event. To block a click-fired tag on certain pages, the exception must also be a click trigger with a page condition.

Getting Google Tag Manager triggers right

Google Tag Manager triggers look simple, yet they decide whether every number in GA4 and Google Ads can be trusted. Pick the page view type by timing, prefer confirmed-success events over button clicks, keep regex patterns narrow, build exceptions on the same event type, and test every change in Preview before publishing. If your forms or landing pages make tracking awkward, a rebuild with tracking planned in from the start, as in our landing page design work, saves a lot of trigger workarounds later. When you want a second pair of eyes on your tracking, talk to Relevant Audience.

Google Tag Manager Triggers: How Each Type Works and When to Use It