Two problems with tracking in the browser
Classic tracking places third-party scripts in the visitor's browser. Two things make that less and less reliable. The first is that ad blockers, the browsers' tracking protection and stricter cookie rules remove a growing share of the data before it even arrives: you measure a subset and don't know how large. The second is legal and ethical: you aren't allowed to collect personal data before the visitor has actively consented. Both problems share the same root, that collection happens uncontrolled in the client.
Server-side tracking: move collection to your own server
With a server-side container, for example server-side Google Tag Manager, the events are sent first to an endpoint you control yourself, and from there on to the tools that should have them. You get first-party context, fewer scripts in the browser and control over exactly which data leaves the house and to whom. That makes for cleaner and more robust measurement.
There is also a concrete performance gain. Every third-party script in the browser, analytics, ad pixels, chat, heatmaps, costs download, main-thread time and network requests, and many at once drag the page's performance down. It shows directly in Core Web Vitals and the Lighthouse score, and in how fast the page feels. With collection on the server the browser instead sends a single request to your own endpoint, and the server distributes it onward to the tools. That way you don't have to drop tracking you actually want just to keep the page fast, you can keep it all without loading it onto the visitor's device.
But it is important to say what server-side is not: it is no shortcut around consent. If the visitor has said no, nothing should be collected, wherever the container stands.
Server-side solves where the data is collected. The consent order solves whether it may be collected. You need both.
Consent in the right order
This is the part most often built wrong. Tags must not fire before the consent status is known. The starting point should be that measurement and advertising cookies are off by default, and switched on only when the visitor chooses it. With Google Consent Mode the consent signal governs whether and how the tags run at all, and the order is decisive: the consent banner and the signal have to sit before the tags in the chain, otherwise a script collects data the moment the page loads, before the user has said anything. The right order is the difference between measurement that is both lawful and correct, and one that looks like it works but leaks.
How we build the stack
The order we start from is simple: consent first as a gate, then collection. The consent banner sets the signal, the signal governs the tags, and a server-side container handles what may actually be collected in a controlled way. The result is measurement that respects the visitor and is at the same time stable enough to trust. And just like with any other measurement, the measure is the business, not the activity: tracking is worth something only when it ties an event to a real deal.
If you want measurement that holds up to both cookie rules and reality, the conversion work and the measurement belong together from the very start.
