TagIntact
Module 3 · Lesson 3 of 4 · 8 min

A container someone else can maintain

Naming, constants, folders, versions, workspaces, and the export — the hygiene that decides whether a container gets fixed or abandoned.

Verified against Google Tag Manager Admin + Workspaces, September 2026 interface on 2026-09-27

Containers don't fail on day one. They fail in year three, when the person who built them is gone and the next person opens a list of 140 tags called GA4 Event, GA4 Event (2), Copy of Meta, and test. Nobody dares delete anything. Nobody knows what fires where. The container gets abandoned and rebuilt, badly, and the cycle restarts.

This lesson is the set of habits that prevents that. Every one of them is something the Container Auditor measures, so you can check a container you inherit in a minute.

Naming

Pick a pattern and never deviate. The one that reads best in the tag list:

<Platform> – <Type> – <What>
GA4 – Event – add_to_cart
GA4 – Google tag
Ads – Conversion – Purchase
Meta – Pixel – PageView
CE – purchase            (trigger: Custom Event)
Click – CTA primary      (trigger)
DL – ecommerce.value     (variable: Data Layer)
Const – GA4 ID           (variable: Constant)

Platform first so the list groups by vendor when sorted. Type second so you can tell a config from an event at a glance. The auditor reports what percentage of tags follow the dominant separator pattern and lists junk names (Untitled, Copy of, (2), test) — those are the first to rename.

Constants for every ID

Every measurement ID, conversion ID, pixel ID goes in a Constant variable and is referenced everywhere as {{Const – …}}. Reasons:

  • Migration or a new property: one edit.
  • Staging: swap the constant per environment instead of per tag.
  • Audit: "which tags send to which property" is answerable.

The auditor's hardcoded IDs finding is a literal G-/AW-/GTM- value typed into two or more tags. Ten minutes to fix; do it first on any inherited container.

Folders

Folders are purely organizational — they change nothing at runtime. Use them by platform (Google, Meta, Consent, Utilities) or by team ownership. A container with folders is one where a newcomer can hide 80% of the noise while they work on the 20%.

Versions and workspaces

Every Publish creates a version. Name it like a commit message: v27 – add begin_checkout, remove old UA tags. The version list becomes your changelog and your undo: Versions → (pick one) → Publish rolls back in seconds. A version called "Version 27" helps nobody at 11 p.m.

Workspaces let more than one person edit without stepping on each other; the free tier gives you three. Use them for anything that takes more than a sitting. Merge conflicts are shown on publish; resolve them like code.

Environments (Admin → Environments) give you separate Live / Staging snippets so a version can be tested on staging before it goes to production traffic. Underused, and the correct answer to "how do I test this without publishing."

Delete things

Paused tags still ship in the container script. Triggers nothing references still register listeners. Variables nothing references still get evaluated if they're Custom JavaScript. The auditor lists all three. Once a version has been live and healthy for a while, delete what it paused. Versions are your safety net.

Export it

Admin → Export Container. A JSON file with every tag, trigger, variable, and the container's settings. Three uses:

  1. Backup — before any large change.
  2. Audit — drop it into the Container Auditor for the graded report.
  3. Diff — two exports, before and after, tell you exactly what a colleague changed. (A diff tool is on the roadmap; until then, any JSON diff works.)

Export the live version to audit what visitors get; export the workspace to audit unpublished work. The auditor tells you which one it received.

A container that follows this lesson is one you can hand to a stranger with an export and a version list. That's the bar.

A container someone else can maintain — Tracking Foundations · TagIntact