Google Tag Manager

Google Tag Manager is not a tracking tool by itself. It is a small piece of code you put on your site once, and after that it acts as a control panel for every other tracking script you want to run: Google Analytics, a Google Ads conversion pixel, a chat widget, a heatmap tool. Instead of a developer editing the site’s code every time marketing wants to add or change a script, someone logs into Tag Manager, sets up the new tag through its interface, and publishes it. The site itself never changes.

That convenience is also its cost. Every tag inside the container is another script the browser has to load, and every one of them is a potential target for a privacy extension or an ad blockers list that is specifically watching for Google’s own container script. On sites where I know exactly what needs to be measured and nothing more, I sometimes skip Tag Manager entirely and load Google Analytics directly through the hosting layer instead, which is the approach behind what some clients hear described as loading analytics in place of a tag manager.

Why it matters to you

The honest answer is that Tag Manager matters most when more than one person or team needs to touch your tracking setup over time. If you run ads yourself, work with an outside marketing agency, or expect to add new tools as the business grows, having everything centralised in one container saves you from a string of small code changes, each one a small risk to the site.

If your tracking needs are simple and mostly set once, straight to analytics, straight to a conversion feed, the extra container can be more machinery than the job requires.

How I use it

When a client’s setup calls for it, I install Tag Manager once, configure the tags it needs to carry, usually Google Analytics and a conversion event or two, and hand over an account in the client’s own name. From then on, adding a new tag is a form to fill in, not a deployment. I still review anything added later, because a badly configured tag can silently double-fire an event or slow a page down, and neither of those show up unless someone is watching for them.

When the job does not call for that flexibility, I go the other way and wire analytics directly, which keeps the page lighter and the measurement steadier against browsers actively trying to block Google’s tooling. The decision is not ideological. It depends on who needs to touch the tracking after launch, and how much that flexibility is worth against the extra script weight.

What it looks like in practice

If your site uses Tag Manager, you will see it as one line in the page’s source and a login where you can view and add tags without calling anyone. If it does not, your analytics is wired more directly, and adding a new tracking tool later means a short conversation rather than a self-serve change. Either way, the goal is the same: numbers that hold up, delivered in whichever way costs the least in speed and risk.