what a GTM audit is actually for
Google Tag Manager is a container, not a tracking system. Open most stores' containers and you find the actual problems sitting inside: a GA4 tag left over from an old agency next to the current one, a conversion tag that never got removed when an ad account changed, a consent setting nobody wired up when the cookie banner went in. GTM doesn't cause any of that, but it's where all of it lives, so it's the first place to look.
This is the checklist I actually run through, grouped the way the problems show up rather than by which tag happens to cause them: what's being counted wrong, where tracking can't see, what's left over from a previous setup, and whether conversions are accurate. Below it, there's a short section on where a GA4-specific audit overlaps with this and where it doesn't, and a few ways to check each item yourself before paying anyone to do it for you.
Written by Andrew Maury, who built the free scanner these checks come from and runs the paid audit when a store wants it checked against real order data too. More on who's behind ecomloop and the stores it's worked with. Checked against the scanner's live detection rules, last reviewed October 2026.
jump to: the checklist · GTM audit vs. GA4 audit · check it yourself · FAQ
the checklist, 14 points
what's being counted wrong
Duplication is the single most common thing a GTM audit turns up. It inflates whatever a platform reports and quietly steers automated bidding toward a conversion rate that was never real.
1. More than one GA4 property collecting the same traffic
Two measurement IDs (G-XXXXXXXXXX) both firing on the same pages, usually because a previous agency or app installed its own and the old one was never removed. The two properties will never agree with each other, and there's no way to tell from inside GA4 alone which number is the real one.
2. More than one GTM container running at once
Same story, one layer up: an old container that was never removed when a new one went in. Tags inside each container can trigger independently, so the same event gets a chance to fire twice.
3. A single tag firing a page view twice on one page
One ID, two beacons, same page load. Every visit gets counted more than once in that platform, which throws off traffic, conversion rate and cost per acquisition together. This one is usually a single tag that needs removing, not anything that needs rebuilding.
4. More than one Meta pixel, Google Ads conversion ID, or TikTok pixel active at once
Conversions get split between them, so no single pixel has the full picture and whichever platform you're running ads in is optimizing against part of your data instead of all of it.
where tracking can't see
These are gaps, not duplicates, and they're easy to miss because the tag looks installed and working right up until the part of the funnel that actually matters.
5. Tags that run on the storefront but go quiet at checkout
A pixel shows up fine on the homepage and product pages, then never fires a single event through checkout, the one place a purchase actually happens. Whatever platform that tag feeds has no data at all on the one event you actually need it to count.
6. Consent mode that isn't actually wired up
A cookie banner exists, but it's never connected to Google Consent Mode, so Google has no signal about what a visitor accepted or declined. GA4's DebugView shows the consent state attached to every hit, which is the fastest way to tell whether yours is doing anything.
7. A tag that's installed but never reports a specific event
The base script loads fine, but the trigger wired to a specific event (an add-to-cart, a page view on one page type) never fires. Usually a trigger built against the wrong page or the wrong element, so the tag sits there looking connected and reporting nothing for that step.
8. A tag that runs on desktop but goes silent on mobile, or the other way around
Hides in plain sight, because the blended number across both devices still looks fine. Split event counts by device in GA4 over the last 30 days and the gap shows up immediately if it's there.
leftovers from a previous setup
None of this corrupts your numbers. It just sits there costing you page speed for zero return.
9. A dead Universal Analytics tag still loading
UA stopped collecting data in July 2023. If it's still loading on your pages, it is pure page weight with nothing behind it, and it's a reliable sign nobody has touched your tracking since the GA4 migration.
10. An empty GTM container: loads, fires nothing
You're paying the page-speed cost of loading Tag Manager itself and getting no tags, no data, and nothing back for it. GTM's own Preview mode will show this directly: if nothing lights up when you load the page, the container is either empty or every trigger inside it is broken.
11. Placeholder IDs still live
A theme setting or a pasted snippet left at its sample value (G-XXXXXXXXXX, AW-0000000000) that nobody ever filled in. It can still send real traffic to an ID that doesn't exist, which means whatever it was supposed to measure has been measuring nothing the entire time.
whether conversions are accurate
These are the ones that actually move ad spend, because they feed straight into whatever a platform's automated bidding is optimizing toward.
12. A Google Ads conversion tag firing with a price attached on the wrong page
Every one of those is a conversion value reported where no sale happened, which overstates what Smart Bidding is told to chase.
13. A Meta pixel reporting a Purchase event where no purchase happened
Sometimes a leftover rule in Meta's own Event Setup Tool, created automatically during a Shopify-Meta connection, counting a Purchase every time a particular page loads rather than when an order actually completes. Merchants have reported finding exactly this, unprompted, on Shopify's own community forum.
14. Multiple pixels disagreeing about how the same product is identified
If GA4 and Meta (or two Meta pixels) use different IDs for the same SKU, the platforms can't reconcile what actually sold, and anything built on top of that, like server-side matching, degrades along with it.
what about a GA4 audit, specifically?
Most of what breaks in GA4 actually breaks in GTM, because GTM is usually what's loading the GA4 tag in the first place. If what brought you here was "GA4 audit" rather than "GTM audit," the overlap is points 1, 6, 7 and 8 above: the duplicate-property check, the consent check, the missing-event check, and the device-split check. Those are the GA4-specific version of the same problems.
The part that's genuinely GA4-only, and the part a storefront scan can't do from the outside: whether the events arriving in GA4 actually match what your reports assume, like purchase value lining up with what you actually sold. That comparison needs your real order records, not just what the tag reports about itself, which is the gap the paid audit closes.
how to check each of these yourself
- GTM Preview mode, run against your own store, shows exactly which tags fire and which triggers never match. The fastest way to catch an empty container or a trigger wired to the wrong page.
- GA4 DebugView, walking through your own site, shows events arriving in real time, including the consent state attached to each one.
- Meta Events Manager's Test Events tab shows what a pixel is actually receiving, including anything sent from your server that a browser-only check would never see.
- A device split in GA4 over the last 30 days (desktop vs. mobile event counts) catches a tag that only runs on one of them.
- Searching your theme settings and app embeds for the exact string of a suspicious-looking ID is usually how a placeholder value gets found.
That's the manual version, and it works. It also takes a few hours to do properly across every page type, and it still won't tell you whether what's reported lines up with what you actually sold.
the pattern this catches most often
It's rarely one dramatic break. The most common version: two GA4 properties running side by side on the same pages, one from the current setup and one an old agency or app never removed. Both collect the same traffic, neither one matches the other, and there's no way to tell from inside GA4 alone which number is real. The fix is almost always deleting the old property and checking nothing still depends on it, not rebuilding anything.
what the report actually looks like
Every finding the scanner reports carries a confidence label, not a made-up severity score: Confirmed for something watched happening in the network traffic or the page source itself, Likely for something that should be there and wasn't (which can sometimes mean server-side tracking that isn't visible from outside), and Worth checking for anything with more than one ordinary explanation. That's the actual format behind every item on this checklist, not a description of one.
run it instead of reading it
The free scanner runs the storefront half of this checklist against your actual store in about a minute, no login needed, and tells you which of the above apply to you, not which ones theoretically could. If you want the checkout and real-order-record half checked too, the part nothing can see from outside, that's the $1,750 Tracking & Profit Audit, a fixed 10-business-day turnaround.