Numbers you can quote in a meeting

What we find in almost every account we inherit

Events counted twice. A form plugin sends its own conversion event and someone has also added a manual one. Every lead is now two leads, and the cost per lead in the ad platform is half what it truly is.

Conversions that cannot fire. A conversion action created as an upload-only type, waiting forever for a file that no one will ever upload. It looks configured. It can never record anything.

Pageviews wearing a conversion's name. The most damaging one, because Smart Bidding will faithfully optimise toward it and the campaign will look like it is working the whole time.

Verified against real orders, not against the debugger

The tag debugger tells you an event fired. It does not tell you the value was right, that it fired once, or that it corresponds to an order that actually exists.

So verification is done against reality: place a real transaction, find it in the admin, find it in GA4, find it in the ad platform, and confirm the value matches in all three. It takes an hour and it is the only proof worth having.

For lead generation the same applies — submit the form, receive the email, and check exactly one conversion was recorded.

One documented container instead of a decade of tags

Most Tag Manager containers we open contain tags nobody remembers adding, several of which belong to agencies that stopped working with the client years ago and are still collecting data.

We inventory what is firing, decide what stays, and rebuild to a plan you can read. Where the existing container is salvageable we fix it; where it is a decade of undocumented accumulation we rebuild and explain why.

You get a one-page map: what fires, where, and what each number means. That document is what stops this happening again in two years.

The tag on your site may belong to somebody else's account

An account had spent ₹2,670 across thirty days and recorded zero conversions on all twenty-two of its conversion actions — including store visits and clicks-to-call, which need no website tag at all to work.

The tag rendering on the site was AW-11234019247. The account's own tracking id was 10848327728. A different account. Every event that site fired for months went somewhere nobody was reading.

The interface never warns about this, because everything genuinely is configured — the actions exist, they are enabled, several are primary. They were created in the right account. Only the tag points elsewhere, and a "tag not detected" warning never appears while a valid tag for *some* account is present on the page.

Two commands settle it in under a minute, and they are now the first thing we run on any account reporting no conversions: read the account's own tracking id, then read the id actually printed on the homepage, and compare them.

Your speed plugin can quietly switch your tracking off

A guest-optimisation setting on one common caching plugin applies a hardcoded preset to every logged-out visitor and ignores the exclusion list entirely. Your analytics tag is rewritten into an inert placeholder — still visible in the HTML, never executed.

What makes it slow to find is that the exclusions save correctly and do nothing. You add the tag to the do-not-defer list, the setting persists, and the behaviour does not change.

It gets worse in two directions. That plugin treats Google's own crawler as a guest, so Google's tag detector, Lighthouse and every speed-testing tool are served the crippled page — which surfaces in Google Ads as "no tag found" on a site where the tag is provably present, and reads like a detection delay. It is not. And a first-time buyer is a logged-out visitor too, so the purchase event on the thank-you page may never fire at all.

A firewall rule can do the same thing from the other side. We have seen one that blocked the <script> element itself rather than anything about the tag inside it — the same code passed once it was expressed without that element. So when a tag is missing, we check what the page actually executes, not what the page contains.

Reconciliation, stated in writing

GA4, Google Ads, Meta and your store will never agree exactly. Different attribution models, different windows, different definitions of a session. That is expected.

What is not expected is nobody knowing the size of the gap. We document where they diverge and by how much, so you can read any of them correctly rather than trusting whichever is most flattering.

Consent handling is part of this too, and it changes what gets collected far more than most people expect — often the real reason a dashboard suddenly reports less traffic.