Google Tag Manager: set it up once, properly.

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

• 01It's a tool used by marketing, not engineering — and marketing rarely has the same code-review culture.
• 02Pixels are easy to add and easy to forget. Adding a tag is one click; auditing tags is dozens.
• 03Vendors actively send 'just paste this into GTM' snippets to clients — bypassing every quality check.
• 04Naming conventions are not enforced. By month six there are tags called 'Pixel', 'New Pixel', 'Pixel v2', 'Test', and 'DON'T DELETE'.
• 05Nobody owns it. Marketing thinks engineering owns it; engineering thinks marketing does.

The setup we use

• 01One container per site. Never share containers across brands — the blast radius is too big.
• 02Use dataLayer events, not DOM scrapes. CSS selectors break the moment the design changes; dataLayer events survive redesigns.
• 03Variables for every value worth re-using — page type, user role, environment, product ID, transaction value.
• 04Triggers named for the business event they represent ("Lead form submitted"), not the technical one ("form#contact submit").
• 05A consent-mode gate on everything. Cookies fire after consent or they fail closed.
• 06Tag names follow a convention — Vendor / Purpose / Page or Scope. Future-you will be glad.
• 07Folders by vendor. Google Ads in one folder, Facebook in another, Hotjar in another. Keeps the workspace navigable.
• 08Versioning discipline — every published version has a description of what changed and why.
• 09Two environments minimum — workspace (work in progress) and live. Test in workspace, publish to live, never edit live directly.

Naming convention we apply

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.

• 01page_view — fires on every navigation, includes route metadata.
• 02lead_submit — any successful lead form completion, includes form ID and consent state.
• 03purchase — checkout completion, includes transaction value and items array.
• 04video_play / video_complete — for media tracking on content sites.
• 05cta_click — branded CTAs that we want to count regardless of where they live.
• 06search_perform — internal search, useful for understanding what users can't find.

Things we won't put in GTM anymore

• 01Anything performance-critical — third-party tags add weight; the critical stuff lives in the codebase.
• 02Anything load-bearing for the business — checkout pixels, payment confirmations. Those go server-side or directly in the codebase.
• 03Anything that needs to survive a marketing-team mistake — payment confirmation must not fail because someone misconfigured a trigger.
• 04Custom HTML tags doing complex logic. If the tag has 30 lines of JavaScript, it shouldn't be in GTM.
• 05Anything 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.

The annual audit we run

• 01List every active tag. For each, document: what does it do, who needs the data, when did we last verify it firing?
• 02Pause anything we can't justify. Delete in the next quarter if nobody complains.
• 03Check every trigger for firing scope creep — page-scoped triggers that have quietly expanded to all-pages.
• 04Verify consent-mode gating on every non-essential tag. Anything firing pre-consent is a compliance risk.
• 05Diff the container against six months ago. Anyone surprised by what's been added?
• 06Performance check: how much weight do GTM-loaded tags add to the page? If it's more than 100KB, prune.

Tools we use alongside GTM

• 01GTM Preview / Debug — fire your trigger, watch the tag fire (or fail to). The single most-skipped step.
• 02Google Tag Assistant — verifies tags in production after deploy. Catches the 'works on staging, broken on live' class of bug.
• 03Chrome DevTools Performance panel — actually measure the impact of your tags on page load.
• 04Server-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.