Common Google Tag Manager Mistakes That Can Break Conversion Tracking

Wrong triggers

The trigger is where most problems start. A conversion tag set to fire on all page views will count every page load as a conversion. A tag set to fire on any click will count every button press, including ones that lead nowhere. The trigger has to match the real event, not just something close to it.

For form tracking, the trigger should fire on a successful submission event from the data layer, not on a click of the submit button. Clicks fire whether or not the form validates, which is why click based tracking almost always overcounts.

Duplicate tags

When the same conversion is tracked by two tags, it gets counted twice. This often happens when a platform has its own built in integration and someone also adds the same tag through GTM. The fix is to pick one path and remove the other. Two paths do not mean more accurate data, they mean double counting.

Tags firing on page load incorrectly

Some tags are meant to fire on page load, like a pageview or a base pixel. Conversion tags are not. If a conversion tag fires on page load, every visit to a thank you page counts as a conversion, even if the visitor got there by refreshing or using the back button. Use a real event trigger instead.

Form tracking mistakes

• Firing on button click instead of submission success.
• Not accounting for multi step forms where each step looks like a submission.
• Firing on a thank you page load without checking it came from a real submit.
• Using a CSS selector that changes when the site updates.

The most reliable form trigger is a data layer event pushed by the site after the form validates. If your site cannot push that event, the next best option is a thank you page view combined with a referrer check, but even that can misfire on reloads.

Click tracking mistakes

Click triggers are useful for engagement but dangerous for conversions. A common error is tracking a link click as a conversion when the link just scrolls to a form or opens a modal. The click happened, but no lead did. Reserve click triggers for genuine actions, and use submission triggers for real leads.

Duplicate conversions

Duplicates can also come from the same tag firing twice on one event. This happens when a trigger overlaps, such as a form submit trigger and a page view trigger both matching the same thank you page. Review your trigger conditions and make sure only one can match at a time.

Incorrect variables

Variables hold the values your tags send. If a conversion value variable returns undefined, your value based bidding has nothing to work with. If a transaction ID variable is wrong, your deduplication fails and you count purchases twice. Test variables in preview mode with real data, not assumptions.

Preview mode

Preview mode lets you see exactly which tags fire and why, on your live site, without affecting other visitors. It is the single most important tool for finding GTM problems. If you are changing tags without using preview mode first, you are guessing.

1. 1.Open preview mode and load the page or submit the form you are testing.
2. 2.Check the Tags Fired tab to see what actually ran.
3. 3.Inspect any tag that did not fire to see which trigger condition failed.
4. 4.Confirm variables return the values you expect.

Tag Assistant and testing

Google Tag Assistant and similar debugging tools show you what data reaches each platform. Use them alongside preview mode. Preview mode tells you what GTM did. Tag Assistant tells you whether the destination received it correctly. You need both to confirm a tag works end to end.

Testing before publishing

Never publish a container change without testing it first. A broken tag published live can corrupt your conversion data for days before anyone notices. Preview, test a real form and call, confirm the data lands once in each platform, then publish.

Container version control

GTM keeps a version history of every publish. Use it. Name your versions clearly so you can roll back when something breaks. If a change goes wrong, reverting to the previous version is faster than debugging the new one under pressure.