--- title: "Google Tag Manager: set it up once, properly." date: 2023-07-25 url: https://remiam.co.uk/notes/google-tag-manager-set-it-up-properly tags: [GTM, Analytics, Marketing Tech] read_time_minutes: 10 description: "A Google Tag Manager setup that holds up — variables, triggers, consent gating, naming conventions, audits, and the discipline that stops your container becoming a graveyard." --- # Google Tag Manager: set it up once, properly. *Published 2023-07-25 · 10 min read · by Liam (Remiam)* Most GTM containers we inherit are a graveyard of duplicate pixels, broken triggers, and tags that fire on the wrong pages. Here is the discipline that prevents that — the setup we apply, the conventions we enforce, the audits we run, and what we now refuse to put in GTM at all. Google Tag Manager is one of those tools that gets installed once, then becomes a junk drawer. Every freelancer who's ever touched the marketing site has added a tag. Nobody's ever removed one. By year three the container has 60 tags, 40 of them firing twice, 10 of them firing on production by accident. The site is slower, the data is noisier, and nobody trusts the conversion numbers. We've untangled enough of these to know the cause is never the tool. It's the lack of conventions. Here's the playbook we apply to every project, and the audits we run on inherited containers. ## Why GTM gets messy in the first place - It's a tool used by marketing, not engineering — and marketing rarely has the same code-review culture. - Pixels are easy to add and easy to forget. Adding a tag is one click; auditing tags is dozens. - Vendors actively send 'just paste this into GTM' snippets to clients — bypassing every quality check. - Naming conventions are not enforced. By month six there are tags called 'Pixel', 'New Pixel', 'Pixel v2', 'Test', and 'DON'T DELETE'. - Nobody owns it. Marketing thinks engineering owns it; engineering thinks marketing does. ## The setup we use - One container per site. Never share containers across brands — the blast radius is too big. - Use dataLayer events, not DOM scrapes. CSS selectors break the moment the design changes; dataLayer events survive redesigns. - Variables for every value worth re-using — page type, user role, environment, product ID, transaction value. - Triggers named for the business event they represent ("Lead form submitted"), not the technical one ("form#contact submit"). - A consent-mode gate on everything. Cookies fire after consent or they fail closed. - Tag names follow a convention — Vendor / Purpose / Page or Scope. Future-you will be glad. - Folders by vendor. Google Ads in one folder, Facebook in another, Hotjar in another. Keeps the workspace navigable. - Versioning discipline — every published version has a description of what changed and why. - Two environments minimum — workspace (work in progress) and live. Test in workspace, publish to live, never edit live directly. ## Naming convention we apply | Asset type | Naming pattern | Example | | --- | --- | --- | | Tag | | | | GA4 | Pageview | All Pages | | Tag | | | | Meta | Lead Submit | Contact Page | | Trigger | – | Click – Header CTA | | Trigger | – | Form Submit – Newsletter Modal | | Variable | – | DLV – User Role | | Variable | – – | JS – GA4 – Currency Override | *Naming convention for GTM tags, triggers, and variables.* ## The dataLayer events we standardise on Marketing tools that depend on click handlers on specific elements are brittle. The first redesign breaks them. We push every meaningful business event into the dataLayer instead, with a stable event name and a payload we control. Then GTM listens for those event names. - page_view — fires on every navigation, includes route metadata. - lead_submit — any successful lead form completion, includes form ID and consent state. - purchase — checkout completion, includes transaction value and items array. - video_play / video_complete — for media tracking on content sites. - cta_click — branded CTAs that we want to count regardless of where they live. - search_perform — internal search, useful for understanding what users can't find. ## Things we won't put in GTM anymore - Anything performance-critical — third-party tags add weight; the critical stuff lives in the codebase. - Anything load-bearing for the business — checkout pixels, payment confirmations. Those go server-side or directly in the codebase. - Anything that needs to survive a marketing-team mistake — payment confirmation must not fail because someone misconfigured a trigger. - Custom HTML tags doing complex logic. If the tag has 30 lines of JavaScript, it shouldn't be in GTM. - Anything that touches PII directly. Tags should receive hashed identifiers, not raw email addresses. > GTM is a great tool when it's disciplined. The discipline is the whole product. The tool is free; the convention is the value. > — Internal marketing-tech playbook ## The annual audit we run - List every active tag. For each, document: what does it do, who needs the data, when did we last verify it firing? - Pause anything we can't justify. Delete in the next quarter if nobody complains. - Check every trigger for firing scope creep — page-scoped triggers that have quietly expanded to all-pages. - Verify consent-mode gating on every non-essential tag. Anything firing pre-consent is a compliance risk. - Diff the container against six months ago. Anyone surprised by what's been added? - Performance check: how much weight do GTM-loaded tags add to the page? If it's more than 100KB, prune. ## Tools we use alongside GTM - GTM Preview / Debug — fire your trigger, watch the tag fire (or fail to). The single most-skipped step. - Google Tag Assistant — verifies tags in production after deploy. Catches the 'works on staging, broken on live' class of bug. - Chrome DevTools Performance panel — actually measure the impact of your tags on page load. - Server-side GTM — for clients with the volume to justify it, moves tag execution server-side, dramatically improves performance and gives back control over data sharing. A well-maintained GTM container is invisible and useful. A neglected one is a mess that erodes site performance and data quality every month. The difference is the discipline you apply on day one — and the audit you run on the anniversary. ## References 1. [Google Tag Manager — official site](https://tagmanager.google.com/) 2. [Google Consent Mode v2 — documentation](https://support.google.com/tagmanager/answer/13802165) 3. [Simo Ahava — gold-standard GTM blog](https://www.simoahava.com/) 4. [Server-side GTM overview](https://developers.google.com/tag-platform/tag-manager/server-side)