A tidy container is not about aesthetics. It is about being able to change tracking safely, hand it to someone else, and find the cause when a number looks wrong. This guide gives the conventions I apply to every container, a release discipline, a clean-up routine, and notes on the 2026 interface changes.
Naming Convention
Prefix by type, then platform, then what it does. Everything sorts by type and reads as a sentence.
| Asset | Pattern | Examples |
|---|---|---|
| Tags | Platform - Type - Detail | GA4 - Event - generate_lead, GAds - Conversion - Purchase, Meta - Purchase, Listener - Gravity Forms, Google tag - G-XXXX |
| Triggers | Type - Detail | CE - form_submit_success, Click - tel link, PV - thank-you page, Vis - pricing section, Init - All Pages |
| Variables | Type - Detail | dlv - ecommerce.value, url - form param, cookie - gclid, cjs - items to content_ids, LT - form id to name, const - GAds Conversion ID, UPD - email and phone |
| Folders | Platform or purpose | GA4, Google Ads, Meta, Listeners, Consent, Utilities |
Rules: no spaces at the ends, no versions in names such as v2 or new, no personal names, and the event name in a tag name matches the actual event it sends.
Folders
Create a folder per platform and one for listeners and utilities. Move every asset into a folder when you create it. The unfiled list should be empty. Folders do nothing functionally, which is exactly why they are safe to use freely.
Workspaces and Versions
- Create a workspace named for the work:
Add Stripe purchase tracking. - Build and test in Preview inside that workspace.
- Submit as a version with a name and a description that says what changed and why:
Stripe purchase to GA4, GAds and Meta. Dedup by session ID. Tested in test mode. - Publish. The workspace is consumed.
- If something breaks, open Versions, find the previous one, and publish it. That is the rollback.
Every version description is your change log. Future you will read it before anything else.
Environments
For sites with a staging server, create a Staging environment and publish to it first. The site's staging GTM snippet includes the environment parameters. Production gets the version only after staging checks pass. Small sites can skip this and rely on Preview.
Reuse Over Duplication
- One Google tag, one Conversion Linker, one Meta base pixel. If you find two, one is wrong.
- Constants for IDs: measurement ID, conversion ID, pixel ID. Every tag references the constant.
- One User-Provided Data variable used by all Google Ads tags.
- One form success trigger and conditions per form, not a trigger per form.
- Lookup Tables for mapping instead of ten near-identical tags.
Blocking and Safety
- A
PV - admin pagestrigger used as an exception on every tag, so nothing fires in the CMS. - Consent requirements on every non-Google tag.
- No Custom HTML tag without a comment at the top saying what it does and who added it.
- Tag sequencing only where order genuinely matters, such as the Google tag before events, and even then prefer the Initialization trigger.
The Quarterly Clean-Up
- Open the latest version and review each tag's last fired date if your host shows it, or check Preview on the key pages.
- Pause tags for platforms the business no longer uses.
- Delete paused tags older than one quarter, their now-unused triggers, and variables with zero references. GTM shows references on each variable's page.
- Check for duplicates: two tags sending the same event to the same platform.
- Re-run the main conversion flows in Preview to confirm nothing depended on what you removed.
- Publish with a version note:
Quarterly clean-up. Removed TikTok tags, 4 unused variables.
The 2026 Interface and Optimisation
Google announced in August 2026 that the Google tag and Tag Manager are being unified, with the new layout rolling out through the year. Practical consequences:
- Settings tab. Container-wide configuration moves here. Your Google tag may appear as a Google Analytics or Google Ads destination with shared settings rather than as a tag in the list. The naming convention still applies to what remains in Tags.
- Advanced tab. Triggers, variables, templates and folders are tucked under a collapsible section. Nothing is removed.
- Optimisation wizard. A banner offers to convert existing Google tags into destinations. It shows a summary before publishing. Review it carefully: it decides which Google tag becomes the shared configuration and can affect the Conversion Linker. Run it in a workspace, test in Preview, then publish. Google states it makes no changes automatically.
- Visual tagging. A beta that lets you set up conversions by clicking page elements, initially for Google Ads purchases. Anything created this way should still be named and foldered like everything else.
- Permissions. Linking a destination can give existing Google tag users read access to the container. Review user management after optimisation.
Documentation Outside GTM
Keep a one-page tracking document per site: the dataLayer specification, the list of conversions with their IDs and which tags send them, and the consent setup. Store it with the business, not with the specialist. The GTM version notes handle the history; the document handles the current state.
Outcome
A container someone else can read in ten minutes, changes that ship through named versions with a rollback path, and a clean-up habit that stops the slow decay into forty tags nobody understands.