How GTM works
Google Tag Manager sits between your website and every third party that wants a snippet on it — analytics, advertising pixels, chat widgets, heatmaps. A single piece of code, the container, is installed on every page. Everything after that is configured inside Tag Manager and pushed live from there, so adding a pixel stops being a developer job and a deployment wait.
Three parts do the work. A tag is the code that fires. A trigger is the condition that makes it fire: a page loading, a link being clicked, a named event arriving from the site. A variable is a reusable value the other two refer to, such as the page path or an order total. Edits sit in a draft workspace until you publish a version, and any published version can be restored, which makes the whole thing far less frightening than editing theme files.
Why GTM matters
It separates marketing changes from website releases. A campaign that needs a new pixel on Monday does not have to queue behind a development sprint, and a pixel that turns out to be unnecessary can be removed the same afternoon. For a small business whose site is maintained by whoever originally built it, that alone usually justifies the setup.
It also concentrates risk somewhere visible. When every third-party script loads through one container, you can see exactly what runs on the site, when it was added and by whom — which is the starting point for any honest conversation about page speed, privacy and consent.
Where GTM goes wrong
The commonest failure is not the tool’s fault. Firing a conversion tag when a thank-you page loads, and calling that measurement, produces numbers that break whenever the page is refreshed, bookmarked or replaced by an inline confirmation. Reliable measurement starts with the website telling the container what happened, not the container guessing from the URL.
Containers also silt up. An old campaign pixel, a test tag from a trial, two competing analytics setups — each one costs load time and widens your privacy exposure, and nobody removes what nobody has listed. Reading values by scraping the page has the same fragility: a designer renames a class, and tracking stops without a single error appearing.
Then there is access. Publishing rights let someone run arbitrary code on every page of the site, so those rights are a security decision, not an admin convenience.
How to act on it
Install the container once, on every page including checkout and confirmation screens, and check it is not duplicated by a plugin that also injects one. Then write down the actions worth measuring before creating a single tag — enquiries, calls, add to cart, quote requests — and build only those. The GA4 and GTM setup checklist covers the order I work in.
Use preview mode before every publish, and name each version with what changed and why, so a broken report can be traced to a decision rather than to a mystery. Give publish rights to few people, review the container once or twice a year, and delete anything nobody can justify. If tags were inherited from a previous agency and no one knows what they do, an audit of the existing Tag Manager setup is the cheaper first step.