Google Tag Manager is often described as a way to add tracking code without a developer. That is true, and it is also how most containers end up with 140 tags, no naming convention and nobody willing to delete anything.
Used properly, GTM is the single place where all measurement is defined, documented and changed.
The three building blocks
Tags are the things that fire: a GA4 event, a Google Ads conversion, a Meta Pixel event.
Triggers decide when a tag fires: on a page view, a click, a form submission, an element becoming visible, or a custom event pushed into the data layer.
Variables are the values used by tags and triggers: the page URL, a click ID, a purchase value, a measurement ID.
The sentence to remember: a tag fires when a trigger tells it to, using values supplied by variables.
The data layer is the part that matters
The data layer is a JavaScript object your website uses to pass information to GTM. It is the difference between a container that works and one that breaks every time a developer renames a CSS class.
Scraping values out of the page with CSS selectors works right up until someone redesigns the page. A data layer push is explicit, versioned with your code, and does not care what the button looks like.
If you are scoping a new site build, a documented data layer is the single highest-value tracking requirement you can put in the specification.
Implementing GTM properly
- Create the container and install both snippets — the script in the head and the noscript iframe immediately after the opening body tag.
- Remove any hard-coded tracking that GTM will now handle. Leaving both in place is the classic cause of double-counted conversions.
- Set up a GA4 configuration tag firing on all pages, then event tags for each meaningful action.
- Use Preview mode to verify every tag before publishing. It shows exactly what fired, what did not, and why.
- Publish with a version description that says what changed and why.
Naming conventions save you later
Adopt a pattern on day one and never deviate:
- Tags:
GA4 - Event - Demo Request - Triggers:
Form - Demo Request - Success - Variables:
DL - form_name
Six months later, this is the difference between a ten-minute change and an afternoon of archaeology.
The mistakes we find most often
- Duplicate tracking — the same event firing from GTM and from a plugin or theme.
- Triggers built on fragile CSS selectors instead of data layer events.
- No documentation — nobody can say what half the tags do, so nobody removes them.
- Publishing without preview — and discovering the fault weeks later.
- Everything firing on all pages, which slows the site and pollutes the data.
- No consent handling, which is a compliance problem in most of the markets we work in.
When to consider server-side GTM
Server-side tagging moves tag execution from the browser to a server you control, which improves data quality against browser restrictions and reduces client-side load. It also costs money to run and takes real expertise to maintain, so it earns its place when signal loss is genuinely costing you performance, not by default.
Where to go from here
Most container problems are organisational rather than technical. A naming convention, a data layer and a preview habit prevent nearly all of them. If you want a second pair of eyes on your setup, our analytics and tracking team runs a free tracking audit that covers GA4, Google Tag Manager, conversion events, CRM integration and attribution.