Duplicate tags firing on the same event
Two tags doing the same job is the most common problem in an inherited container. Usually it's GA4 installed twice: once as a hard-coded gtag snippet from whoever built the site, and again as a Google tag in GTM added later by an agency that didn't check what already existed. Both fire on every page. Page views get counted twice. If the event tags were duplicated too, every form submission counts as two leads, and your conversion numbers look better than the business is doing.
Finding it is mechanical. Open the container, filter by tag type and look for two tags doing the same job, then view the page source for a second gtag snippet outside GTM. Any account you didn't build yourself deserves this five-minute check.
Triggers scoped too broadly
A trigger set to fire on All Pages when it should fire only on a thank-you page looks harmless until the numbers stop making sense. So does a click trigger with no limit on which links it applies to. Picture a phone click trigger that matches any link whose text contains "call". It also matches a blog link reading "call us anytime" and a button labeled "Request a callback", and every one of those clicks gets reported as a phone lead.
GTM checks a trigger's conditions against every matching interaction on the page, including the ones you never had in mind when you built it, such as a footer link, a sidebar button or a widget added months later by someone who never opened the container. Loose triggers record the wrong data and report it as real. Build each trigger against the specific element it's meant to catch (a phone trigger should match links whose URL starts with tel:), then test it in Preview mode on the page where it should fire and on one where it shouldn't.
Work With John
If your site isn't bringing in inquiries, that's fixable.
I work with US service businesses and B2B brands on SEO, websites and lead follow-up. On a free strategy call, I'll tell you what's holding your site back, without a sales pitch.
Get a Free AuditNo naming convention, so nobody can tell what anything does
Bad names don't break tracking directly. They're the reason every other mistake on this list survives for months. A container full of tags named "Tag 3", "GA4 event" and "New Tag Copy" tells you nothing about what fires where, so whoever is debugging has to click into every tag before they can start looking for the problem.
A workable convention is type, then what it tracks, then where: GA4 - Phone Click - Sitewide, Ads - Form Conversion - Contact Page. It costs nothing to set up. When someone asks why a number looks wrong, it's the difference between a ten-minute investigation and a two-hour one.
Publishing without testing in Preview mode first
Preview mode shows which tags fire on which triggers before a change goes live. Skip it, and a single mistyped trigger condition can sit in production for weeks. Say someone edits a form submission trigger, mistypes the CSS selector it watches and publishes. Visitors notice nothing. The trigger stops matching anything, and recorded leads fall to zero until someone asks why the lead count looks strange.
The habit takes about ninety seconds per publish. Open Preview, click through the interaction the change affects, confirm the tag fires and only then publish, and you'll catch most of the other mistakes on this list before they ever reach your reports.
Orphaned tags from vendors you no longer use
Every service business collects a few. There's the chat widget you replaced two years ago, a remarketing pixel for an ad platform you stopped paying for, and a script a past marketing hire installed and never removed. Some still load code that slows the page for no benefit, and depending on the vendor, a few may still be sending visitor data to a company your privacy policy no longer mentions.
A pass through the container twice a year, asking "do we still use this vendor?", catches most of them. Pause the tag first instead of deleting it, wait a couple of weeks to confirm nothing depended on it, then remove it.
Consent settings nobody revisited
Depending on where your traffic comes from, tags that fire before a visitor has made a consent choice can be a compliance problem as well as a data quality one. GTM's consent mode support lets you hold tags back based on a visitor's consent state, and its Consent Overview screen lists every tag's consent settings in one place.
A common pattern is consent configured once during setup and never touched again as new tags arrive on top. Don't assume. Open the Consent Overview and confirm each tag matches what your cookie banner tells visitors, paying most attention to anything added after the original consent setup, because those are the tags most likely to have been published without consent settings at all.
Variables that reference the wrong data layer key
This one is harder to spot than a duplicate tag. A variable points at a data layer key that the site no longer pushes. It usually happens after a redesign or a form tool switch, when the new form pushes a slightly different data layer structure and nobody updates the GTM variables built around the old one.
The symptom is specific. Preview shows the tag firing exactly when it should, so everything looks fine, while the parameters attached to the event (the page name, the form name, the service selected) arrive blank or as "undefined" in GA4's DebugView. Picture a business with four service pages whose form events count correctly for months, while the field meant to record which service a lead asked about sits empty the whole time. The fix takes ten minutes. Finding it takes much longer, because a tag that fires on time hides the fact that its payload is empty.
That's why Preview alone isn't enough. Preview confirms that a tag fired. DebugView shows the event and its parameters as GA4 received them, and checking both is the only way to catch this before it turns up as a blank column in a report months later.
How to run your own quick audit
You don't need an agency review to catch most of this. Open your container and do four things. Filter tags by type and look for duplicates. Click through your two or three most important triggers and confirm their scope is no broader than intended. Run Preview on your homepage and contact page and watch what fires. Then read the last five published versions to see what changed and when. Done honestly, that surfaces most of the mistakes above within twenty minutes.
If you're building a container from scratch rather than untangling an old one, a naming convention and folder structure from day one avoids most of this list, which I cover in Google Tag Manager for service businesses: how to set up the container the right way. If you're still deciding whether you need GTM at all or a simpler gtag snippet would do, make that call on purpose with GTM vs gtag: which tagging approach fits a service business site.
What a neglected container costs a service business
None of these mistakes looks like an emergency on its own. Stack them across a container nobody has audited in a year, though, and the dashboard misleads you in several directions at once, inflating one number while hiding another. For a service business deciding where to spend on ads or which service line to push, that's a costly way to be wrong.
Once the container is clean, its data is only useful if you connect it to search performance and to what happens after a lead comes in. How to read a Google Search Console report covers the search side. If that review turns up problems worth fixing properly, that's the work covered under SEO consulting, and the Analytics & Data section has the rest of what I've written on measurement.
