A lot of people run their tracking through Google Tag Manager because it's convenient.
Most platforms make it easy. You paste the web container ID into a field and it's done.
But easy to set up and good at tracking are not the same thing.
What most people running ads don't realize is that Google Tag Manager is a bad way to track conversions, and you don't notice until you check your numbers.
You line up what you actually sold against what it reported, you put your ad spend next to the sales it's claiming, and the two don't match.
By then you've been spending against numbers that were never real.
Here's what's going on under the hood, one problem at a time.
It doesn't collect anything on its own
People think Google Tag Manager watches the site and collects conversions for them. It doesn't. It collects nothing on its own.
When someone buys, none of that reaches Google Tag Manager automatically.
You have to push it there yourself, through something called the data layer: the customer details, the purchase, the order value, and the click IDs that tell Meta and Google which ad the buyer came from.
If it's not in the data layer, Google Tag Manager never sees it.
Some platforms do push that data in for you. But that's still not the fix, because getting it into the data layer is only half the job.
You then have to map each piece into a variable, and only then can you plug those variables into the tags that send it all back to the ad platforms.
Capture it, map it, fire it. Miss a step, or wire one field wrong, and the tag still fires. It just fires with the data missing.
That's the trap. The tag goes green, no errors on screen, and underneath it the click ID is empty or the value is blank.
Nothing warns you. You find out when your marketing stops producing the results you expected.
Server-side GTM is broken, and here's why
So people hear the fix is to go server-side, somewhere the browser blockers can't reach. With Google Tag Manager, that's not what you get.
Its server-side is heavily dependent on the browser side. The browser fires first.
It initializes the tracking scripts, the Facebook pixel and the rest, and pushes the event out.
Only then can the data move to the server and fire the server-side event. No browser trigger, no server event.
So it isn't really server-side at all.
It's a server-side step bolted onto a browser-side trigger, and it only works if the browser half fires first.
That dependency is the crack everything falls through.
Which is exactly why it gets blocked
And the browser piece is the easiest thing in the world to block.
Ad blockers and privacy browsers already know what Google Tag Manager is.
They know advertisers use it for tracking, and they know the exact file it loads. So they block it, on default settings, straight out of the box.
Once the browser piece is blocked, the server side never gets its trigger, and the whole chain dies at the first link.
Roughly 25 to 40 percent of desktop users run some form of ad blocking, and depending on your niche you lose anywhere from 15 to 50 percent of your data.
That's not a rounding error. That's a chunk of your conversions your tracking will never record, server-side or not, because Google Tag Manager's server side is still chained to the browser.
And there's nowhere to actually see your numbers
Even if the tracking were perfect, there's a second problem. Google Tag Manager doesn't show you anything.
It's a plumbing tool. It moves data from your site to the ad platforms, and that's the whole job.
There's no dashboard inside it where you can see your overall marketing performance in one place.
You can connect Google Analytics to it. But that hits two walls.
Google Analytics loads in the browser too, so the same blockers take the same bite, and the numbers come back missing the same data.
And even when it survives, Google Analytics is notoriously complex to use, the kind of tool you have to study before it tells you anything useful.
So you're left with a setup that's hard to see into, on top of being hard to trust.
And none of this is easy to run
All of it takes real depth to build. You need to understand how servers work, how server-side tracking flows, and how each platform shapes its data, because every one is different.
Then there's the hosting, the domain, the variable mapping, the consent handling.
And it's never finished, because platforms change their fields and blocker lists change their targets, so what you built quietly breaks and needs fixing again and again.
Most people setting this up don't have that depth, and they were never supposed to. They run ads.
So they wire what they can, the screen looks fine, and the gaps stay invisible until the numbers stop making sense.
The hosting is cheap, so forget the money. The real price is the build time, the expertise it demands, and a setup that's fragile by design.
What real server-side actually looks like
Real server-side tracking, the kind that can't be blocked by ad blockers or Safari ITP, isn't dependent on the browser at all.
It runs in the backend, behind the scenes, where the blockers can't even look for it. That's why it isn't blockable.
That's the part Google Tag Manager misses. It can't fire a server event until it fires a browser event first.
