Google Tag Manager
GTM is meant to let marketing ship tracking without a developer. In practice most containers become a place where nobody dares change anything. We fix that.
What it is
Google Tag Manager is a container that sits on your website and decides which third-party scripts — analytics, ad pixels, chat widgets, heatmaps — run, and when.
The point is that adding or changing tracking becomes a configuration change rather than a code release. Your marketing team can add a new conversion pixel on a Tuesday afternoon without waiting for the next sprint.
It works on three pieces. Tags are the things that fire. Triggers decide when. Variables supply the details — the order value, the page type, the form name. Feed those from a well-designed data layer and the whole thing is stable. Feed them by scraping text off the page and it breaks the next time someone changes a button label.
Almost nobody sets out to build a mess. Containers decay because of how they're used: three agencies over six years, each with their own naming; a tag added for a campaign that ended in 2021 and never removed; custom HTML tags holding logic nobody documented; and publish rights handed to whoever asked.
The result is a container that technically works and that nobody can reason about. Page performance suffers, duplicate pixels inflate your conversion counts, and every change carries a risk that something unrelated stops firing.
How we help
Every tag, trigger and variable catalogued: what it does, who asked for it, whether it still fires, and whether anything still depends on it. Dead tags go. Duplicates get merged. Whatever survives gets renamed to a convention and documented. A mature container can lose a good share of its tags.
A written specification: the exact object shape, event names and parameters your site should push, for every interaction that matters. Your developers implement it from the spec; we QA it. After that, tracking changes stop depending on the site's HTML staying still.
Containers structured so a new person can find their way around: consistent naming, folders that mean something, lookup tables instead of forty near-identical tags, and triggers built on data layer events rather than fragile page scraping.
Publish rights limited to people who should have them, changes made in workspaces and reviewed before going live, a naming convention written down, version notes that say what changed and why, and a rollback plan for when something does go wrong.
Process
Every tag, trigger and variable documented, with its owner and whether it still does anything.
A data layer spec and naming convention agreed with you and your developers before anything is built.
Built in a workspace, tested in preview mode and on staging, then verified in production after publishing.
Documentation, a governance model, and a training session so your team can make changes confidently.
Questions
It's a structured object on the page describing what's happening — which product was viewed, what a form was for, what an order was worth. Tag Manager reads from it instead of guessing by scraping the page. Scraping works right up until someone changes a class name or a button label, at which point your tracking silently stops. If you've got more than a handful of tags, you need a data layer.
Yes — and in many containers, it is. Every tag is third-party JavaScript running in your users' browsers. The usual culprits are tags firing on all pages when they only need to fire on a few, duplicate vendor pixels nobody removed, and custom HTML doing work that belongs server-side. Clean-up alone can buy back a noticeable chunk of load time.
With guardrails, yes — that's rather the point of GTM. The guardrails are: publish rights for a small number of people, a documented naming convention, changes made in workspaces and reviewed before publishing, and a rollback plan. Open access without those is exactly how containers become unmaintainable.
Usually clean up — it's cheaper and less disruptive, and you keep your version history. We only recommend a rebuild when naming is so inconsistent or dependencies so tangled that untangling costs more than starting from a clear specification. We'll tell you which after the audit, not before.
Thirty minutes, free. We'll tell you whether it needs a tidy or a rebuild.