- How triggers decide when a tag fires
- The five page view triggers, in firing order
- Consent Initialization is not a speed setting
- Initialization, Page View, DOM Ready and Window Loaded
- How trigger filters work
- Custom event triggers and the regex trap
- Setting up a trigger, step by step
- My take on Tag Manager triggers
- Frequently asked questions
A Google Tag Manager trigger listens to your page or app for an event, such as a form submission, a button click or a page view, and tells a tag when to fire. Every tag needs at least one trigger, and a tag with none never fires at all.
Here's the catch. If you set up a custom event trigger with regex matching and use .* as the event name, it matches every event Tag Manager sees, including the ones Tag Manager and the Google tag send automatically. Your tag fires on all of them, and if it's a conversion tag, you're counting things that were never conversions.
How triggers decide when a tag fires
Triggers are evaluated when code on the page or app runs. When the trigger's conditions are met, the tag fires or is blocked.
One default trips people up. A new trigger is set to fire on all events of its type. Create a click trigger and leave it untouched, and it fires on every click on every page. You narrow it with filters, which is the step most people skip.
You don't have to build triggers in a separate screen first. You can create a new trigger while you're setting up a tag, and the more actions menu on a trigger lets you copy it, delete it, view its changes or show notes.
The five page view triggers, in firing order
Google Tag Manager has five page view trigger types, and as of October 2026 they fire in this order of precedence:
| Trigger, in firing order | Fires when | Use it for |
|---|---|---|
| Consent Initialization | Before everything else | Tags that set or update consent state |
| Initialization | Before all other triggers except Consent Initialization | Tags that need to run before the rest |
| Page View | As the browser begins to load the page | Tags that only need a page impression |
| DOM Ready | Once the DOM has been built | Tags that read the DOM to fill in variables |
| Window Loaded | Once the page, images and scripts have fully loaded | Tags that need everything on the page loaded first |
Consent Initialization is not a speed setting
Consent Initialization fires first so that consent settings are honored before any other trigger runs. Google says to use it for tags that set or update the consent state, such as your consent management platform tag or your consent defaults. Every web container comes with a trigger called Consent Initialization - All Pages already in it.
Google is clear that it isn't meant for tags that you'd just like to fire early. It's tempting to move an analytics or ads tag there to get it in ahead of everything else, but that's not what it's for, and it defeats the point of having consent settled first.
Initialization, Page View, DOM Ready and Window Loaded
Initialization fires before every other trigger apart from Consent Initialization, and each web container also has an Initialization - All Pages trigger by default. After that, the choice comes down to what your tag needs from the page:
- Page View fires as the browser starts loading the page. Use it if all you need is to count the page impression.
- DOM Ready fires once the DOM is constructed. Use it for tags that read the page's elements to populate variables.
- Window Loaded fires when the page, including images and scripts, has fully loaded. Use it when your tag depends on those being there.
Picking the earliest trigger that has what your tag needs is the safe rule.
How trigger filters work
Filters are how you stop a trigger firing on everything. At the bottom of the trigger configuration page, find This trigger fires on and choose the Some option for that event type. Each filter has three parts:
| Part | What it does | Example |
|---|---|---|
| Variable | The value Tag Manager checks | Page URL |
| Operator | How it compares, such as equals, contains, less than or matches RegEx | contains |
| Value | What it compares against | /products/ |
Put together, that example is a page view trigger that only fires on URLs containing /products/. Google also recommends restricting click triggers to the pages where the click happens, for example by adding Click URL contains /path/to/promo, because it improves performance.
Custom event triggers and the regex trap
A custom event trigger is for interactions the standard triggers don't handle. Google says the most common use is form submissions, when the form's default submit event has been overridden and the built-in form trigger can't see it.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
It works with a push to the data layer. Google's example puts this on a button:
onclick="dataLayer.push({'event': 'button1-click'});"
Then a custom event trigger with the event name button1-click fires your tag whenever someone clicks that button. The same push can carry extra values, such as a conversion value, which you read through a data layer variable in your Google Ads conversion tag. My guide to Google Ads conversion tracking covers the conversion side.
You can tick use regex matching to match event names with a regular expression. That's where the trap from the top of this page lives: .* matches every detected event, including the automatic ones from Tag Manager and the Google tag. Google's advice is to use a narrower pattern, so match the event names you mean and nothing else.
Setting up a trigger, step by step
- Open the tag, go to Triggering, and choose an existing trigger or create a new one.
- Pick the event type, such as page view, click, form submission or custom event.
- Under This trigger fires on, choose the Some option and add a variable, an operator and a value.
- For a custom event, type the exact event name, and only tick use regex matching if the pattern is narrow.
My take on Tag Manager triggers
I'd treat every trigger as firing on everything until I've filtered it, because that's the default. Use Consent Initialization only for consent, pick the earliest page view trigger that has what your tag needs, and never put .* in a custom event. Skip the clever regex unless you need it; an exact event name is easier to read later. If you're still getting your head around containers and tags, start with what Google Tag Manager does first.
Tracking that fires on the wrong things is one of the quietest ways a marketing budget gets wasted. I run AI training and workshops for teams, and help businesses with AI enablement, AI automation and GEO, which is about getting your business seen and cited in AI answers. Most of that work is with SaaS marketing teams, telecom companies and small businesses. Here's how we can work together.
Frequently asked questions
What is a trigger in Google Tag Manager?
A trigger listens to your page or app for events, such as form submissions, button clicks or page views, and tells a tag when to fire. Every tag needs at least one trigger.
What order do Google Tag Manager page view triggers fire in?
Consent Initialization, then Initialization, Page View, DOM Ready and Window Loaded.
When should I use the Consent Initialization trigger?
Only for tags that set or update consent state, such as a consent management platform tag or consent defaults. It isn't for tags you'd just like to fire early.
What does .* do in a custom event trigger?
With regex matching on, .* matches every detected event, including those Tag Manager and the Google tag send automatically, so your tag fires on all of them.
What is the difference between DOM Ready and Window Loaded?
DOM Ready fires once the DOM is constructed. Window Loaded fires when the whole page, including images and scripts, has fully loaded.


