How Google Tag Manager Triggers Silently Ruin Your Data
Last quarter I audited a B2B lead-gen site spending about EUR 12,000 a month on Google Ads. The marketing manager was convinced GA4 was under-counting form submissions. She was right — GA4 recorded 94 submissions in April while the CRM showed 162. A 42 percent gap.
The pixel was fine. The data layer was fine. The problem was three misconfigured triggers in Google Tag Manager. One fired on every page instead of the thank-you page. Another never fired at all because the trigger condition referenced a variable that returned undefined. The third doubled up with a duplicate trigger nobody remembered creating.
None of these threw an error. GTM does not warn you when a trigger is technically valid but logically wrong. It just fires — or doesn't — and your data drifts further from reality every day.
After fixing hundreds of containers, I keep seeing the same five Google Tag Manager trigger misconfigurations. If you manage any container with more than a handful of tags, at least one of these is probably live in yours right now.
1. Page View Trigger Firing on Every Page Instead of a Specific URL
This is the most common mistake I find, and it is the easiest to make. You create a tag — say a Google Ads conversion tag — and attach the default "All Pages" trigger. The tag fires on every single page load, not just the confirmation page where the conversion actually happens.
The result: inflated conversion counts, broken ROAS, and automated bidding optimising toward garbage data.
How to fix it. Create a trigger of type Page View with a condition like Page Path contains /thank-you or Page URL matches RegEx ^https://example\.com/confirmation. Test it in Preview mode, submit at least two test conversions, and verify the tag fires exactly once per real conversion.
If you are tracking purchases on Shopify and this sounds familiar, I wrote a detailed walkthrough in Google Tag Manager Shopify: Tracking That Fires.
2. Using the Wrong Trigger Type for the Event
Google Tag Manager offers over a dozen trigger types: Page View, DOM Ready, Window Loaded, Click, Form Submission, Custom Event, and more. Picking the wrong one is surprisingly easy.
A classic example: you attach a tag to a Page View trigger, but the data layer variable the tag needs is only pushed after the DOM is ready. The tag fires before the variable exists, so it sends undefined or an empty string to GA4. Your event lands in the reports with no useful parameters.
| Scenario | Wrong trigger | Right trigger |
|---|---|---|
| Tag needs data layer values pushed by your app | Page View | DOM Ready or Custom Event |
| Tracking a button click that navigates away | Click — All Elements | Click — Just Links (with "Wait for Tags") |
| Tracking a SPA virtual pageview | Page View | Custom Event (fired by your router via dataLayer.push) |
| Measuring how far users scroll | Page View | Scroll Depth |
If you are not sure which variables are available at which trigger timing, open GTM Preview, navigate to the page, and click through the event timeline on the left. Each event shows which variables are populated at that moment. This is the single best debugging habit you can build.
For a deeper look at how the data layer interacts with triggers and variables, see What Is a Data Layer and Why Tracking Breaks Without One.
3. Overlapping Triggers That Double-Fire Tags
When you assign google tag manager multiple triggers to a single tag, the tag fires if any of those triggers activate. GTM uses OR logic, not AND. That means if two triggers both evaluate to true on the same user action, the tag fires twice.
I see this constantly with event tags. Someone sets up a Custom Event trigger for form_submit, then adds a Form Submission trigger to the same tag "just to be safe." On a standard HTML form, both triggers fire on the same submission. The tag fires twice. GA4 records two events. Your conversion count doubles overnight and nobody notices until the monthly report looks suspiciously good.
How to diagnose it. Open GTM Preview, perform the action, and count how many times the tag appears in the "Tags Fired" panel. If it appears more than once per action, you have an overlap.
How to fix it. Pick one trigger per user action. Remove the redundant one. If you genuinely need AND logic — fire only when trigger A and trigger B conditions are both true — combine all conditions into a single trigger rather than stacking multiple triggers on one tag.
This matters even more when the tag in question sends conversion data to ad platforms. A double-fired Google Ads conversion tag will inflate your reported conversions by 2x, and Smart Bidding will chase the phantom signal.
4. Trigger Filters That Reference Undefined Variables
Triggers in Google Tag Manager rely on variables to evaluate their conditions. If a variable returns undefined — because the data layer push hasn't happened yet, or the variable name has a typo, or Consent Mode blocked the script that populates it — the trigger condition silently fails.
Here is what makes this dangerous: a failed condition means the trigger does not fire. The tag never executes. There is no error in Preview mode — the tag simply does not appear in the "Tags Fired" list, and unless you are specifically looking for it, you will not notice.
Common causes:
- Typo in the variable name.
dlv - formTypevsdlv - form_type. GTM is case-sensitive. - Race condition. The trigger evaluates before the script that pushes the variable to the data layer has run. This is especially common on single-page applications.
- Consent Mode blocking the script. If your Consent Mode v2 implementation gates a script that populates a data layer variable, any trigger depending on that variable will not fire for users who have not consented. That is technically correct behaviour, but if you did not account for it, your numbers will look inexplicably low.
How to fix it. In Preview mode, click the event where the trigger should fire. Switch to the "Variables" tab. Find your variable. If it shows undefined, trace backward: is the push happening? Is the variable name spelled correctly? Is consent blocking the push?
Understanding how google tag manager tags triggers variables interact is the difference between a container that works and one that looks like it works.
5. Not Accounting for Single-Page App Navigation
Traditional page view triggers rely on the browser loading a new page. In a single-page application built with React, Next.js, Vue, or similar frameworks, navigation happens without a full page load. The URL changes, the content changes, but GTM's built-in Page View trigger does not fire again.
This means your pageview tags, your scroll-depth triggers, your page-specific conversion triggers — none of them re-fire on SPA route changes unless you explicitly handle it.
The fix has two parts:
- Push a custom event on every route change. Your developers add a
dataLayer.push({ event: 'virtual_pageview', page_path: '/new-path' })call inside the router's navigation hook. - Create a Custom Event trigger in GTM that listens for
virtual_pageviewand attach your pageview and analytics tags to it.
Google documents this pattern in their single-page application guidance. If you skip it, every route change after the initial page load goes unrecorded — and in a heavily SPA-driven journey, that can mean most of your pageviews never reach GA4.
If your analytics already look suspicious — pageviews per session near 1.0, unusually high bounce rates, conversion paths that seem to start and end on the same page — an SPA navigation gap is a likely cause. I cover the broader audit process in Google Analytics Audit Checklist for GA4.
How to Audit Your Triggers Systematically
You do not need to guess which of these Google Tag Manager trigger issues exist in your container. Here is my process:
- Export the container JSON. In GTM, go to Admin → Export Container. Open the JSON file and search for every trigger object. List them in a spreadsheet.
- Map each trigger to its tags. Note which tags each trigger is attached to. Flag any tag with more than one trigger — those are your double-fire candidates.
- Check every trigger condition variable. For each filter condition, confirm the variable exists and is populated at the time the trigger evaluates. Use Preview mode to verify.
- Test every conversion path. Walk through each conversion flow in Preview mode. Confirm the right tags fire exactly once per action, with the right parameters.
- Review SPA behaviour. If your site is an SPA or a hybrid, navigate between pages in Preview mode and confirm pageview events fire on each navigation.
This is exactly the process I follow during a tracking audit. It takes a few hours for a simple container and a full day for a complex one with 50+ tags. Either way, the ROI is immediate — you stop making decisions on broken data.
The Real Cost of Broken Triggers
Misconfigured Google Tag Manager triggers do not just mean inaccurate reports. It means your ad platforms receive wrong conversion signals. Google Ads Smart Bidding and Meta's Advantage+ both rely on accurate conversion data to optimise. Feed them double-counted conversions or missing conversions and they will misallocate your budget with mechanical efficiency.
I wrote about the downstream effects of this mismatch in GA4 vs Google Ads Conversions: Why They Don't Match. In most cases, the root cause traces back to the container — and more often than not, to the triggers.
Google Tag Manager triggers are deceptively simple. The UI makes it easy to create them, hard to break them in obvious ways, and almost impossible to notice when they are silently wrong. That is why they deserve more scrutiny than any other part of your container.
FAQ
What are triggers in Google Tag Manager?
Triggers are rules that tell GTM when to fire a specific tag. Each trigger listens for an event such as a page view, a click, or a custom data layer push and evaluates conditions you define. When the conditions are met, the associated tag executes.
Can I assign multiple triggers to a single tag in GTM?
Yes, but GTM uses OR logic. The tag will fire when any one of the assigned triggers activates. If two triggers both activate on the same user action, the tag fires twice, which can double-count conversions. Combine conditions into one trigger instead of stacking multiple triggers.
Why does my GTM tag not fire even though the trigger looks correct?
The most common cause is a trigger condition that references a variable returning undefined. This happens due to typos in the variable name, race conditions where the variable is not yet populated, or consent settings blocking the script that sets the variable. Check the Variables tab in Preview mode to confirm.
How do I test if my triggers are working correctly?
Use GTM Preview mode. Click Preview in your workspace, navigate your site, and watch the event timeline. Each event shows which tags fired and which did not, along with the state of every variable. This lets you verify that triggers activate at the right moment with the right data.
Do GTM triggers work differently on single-page applications?
Yes. Standard page view triggers only fire on full page loads. In a single-page application, route changes happen without a page load, so those triggers never re-fire. You need to push a custom event from your router on each navigation and create a Custom Event trigger to handle it.
Not sure your triggers are firing correctly — or at all? Book a tracking audit and I will map every misconfiguration in your container, with a prioritised fix list you can hand straight to your developer.