Run GTM across every container from one screen

Every container, one screen

Google Tag Manager is organised one container at a time. That is fine for one website. It becomes the bottleneck when you look after a portfolio: several brands, several markets, staging containers beside live ones, containers set up by different people in different years, and a client who wants to know whether consent is handled the same way on every site.

The GTM Ultimate Stack is the set of ODDVX modules for that work:

• Reads run across every container of the brands you choose at once: the full inventory with what uses what, conformance to your standards, and the dependencies behind any tag, trigger or variable.
• Writes (rename, pause, delete, create and copy) always show a dry run first, are staged into a GTM workspace in each container, and are never published by ODDVX.

This guide explains how the three modules fit together, what each one reads and writes, and how a GTM change stays reviewable from start to publish. Each section links to the module's own guide, or to a shorter guide for the job in front of you.

The one-by-one problem in GTM's interface

Answering a simple portfolio question in GTM means opening a container, clicking through its tags, triggers and variables, noting what you see and doing it again. Does every GA4 tag declare analytics consent? Is there a trigger nothing uses any more? Does each container still have exactly one GA4 configuration tag? What stops working if this variable is deleted? A dozen brands means a dozen passes, and the difference you are looking for is easy to miss on the eleventh.

ODDVX puts the containers side by side. You pick the brands, run the module once, and the container that doesn't match stands out in one table.

How the GTM Ultimate Stack works

The modules group into four jobs, plus one rule that applies to all of them:

• See what is in your containers: every tag, trigger and variable, and what still uses each one.
• Check them against your standards with Standardization Audit: consent, GA4 configuration, naming and tag hygiene.
• Trace what depends on what with Tag Dependency Map, before you rename, pause or delete anything.
• Change them everywhere: clean up orphans, roll out a naming convention, create or copy across brands.
• Every change waits for you. A dry run shows it per container, Apply stages it in a workspace, and you publish in GTM.

Brands, GTM accounts and containers

ODDVX works with the brands you have set up in the app. Each brand points at a GTM account, and an account holds one or more containers: live sites, staging containers, old microsites.

Each module reads that scope slightly differently:

• Inventory & Cleanup extracts every container in the accounts of the brands you pick. Narrow the table with the Container filter afterwards.
• Standardization Audit checks the brands you pick. When one GTM account holds several brands, set each brand's container in the app and the audit checks only that brand's container; otherwise it checks every container in the account.
• Tag Dependency Map loads one GTM account at a time and maps every container in it.
• Copy reaches further than any extract: its targets include every web container your Google account can see.

If a container you expect is missing, check first that your Google account has access to it in GTM.

What each module reads and writes

Two modules only read; one can also change your containers. Knowing which is which tells you what to expect from a run:

The three modules

Inventory & Cleanup

Extract every tag, trigger and variable from the brands you pick in one pass, read a usage verdict on each row, and stage renames, pauses, deletes, new items and copies across as many containers as the change needs. It is the stack's only writing module, and the one with a full guide series: start with the complete Inventory & Cleanup guide.

Standardization Audit

A read-only check of every container against your standards. A standard says which items it applies to and what they must satisfy, and it can read settings, not just names. About 18 standards are built in, in four groups:

• Consent & privacy: a Consent Initialization trigger exists; GA4 tags declare analytics consent; ads and Floodlight tags declare ad consent.
• GA4 configuration: exactly one GA4 configuration tag, no hardcoded Measurement IDs, no Universal Analytics tags, snake_case event parameter keys.
• Naming & hygiene: no placeholder names or stray whitespace, and naming patterns for GA4 event tags, dataLayer triggers, Custom HTML tags and lookup tables.
• Tag hygiene & structure: no document.write in Custom HTML, no orphaned tags, firing options set on purpose, open workspaces within GTM's limit, required built-in variables enabled.

Switch each standard on or off, delete the ones you don't use, and add your own: a name pattern, a word a name must not contain, the consent types a tag must declare, a count. Each standard carries a severity. Results come back per container and name every item that doesn't conform. The audit never changes anything: stage the fix in Inventory & Cleanup, or make it in GTM. Read the complete Standardization Audit guide.

Tag Dependency Map

Load one GTM account and search for any tag, trigger, variable or dataLayer event. The map shows what leads to it and what it leads to: the triggers that fire or block a tag, the variables a tag or trigger reads, variables that read other variables, and the dataLayer event a Custom Event trigger listens for. Built-in variables such as Page URL appear too, because a reference to one is still a dependency.

Use it before you rename, pause or delete something, to see what else would be affected. It only reads, and there is nothing to schedule: it is a viewer you open when you need it. Read the complete Tag Dependency Map guide.

GTM changes are staged, not published

This is the biggest difference from the GA4 Ultimate Stack. GA4 has no workspace, so a confirmed GA4 change is live. GTM has workspaces and a publish step, and ODDVX keeps both between your change and your live site:

• Stage the change in the inventory table.
• Run the dry run. It writes nothing, not even a workspace, and shows what will happen in each container, including anything skipped and why.
• Apply sends exactly that batch into a workspace per container, under one name you choose.
• Publish in GTM, container by container, after your own checks. ODDVX never publishes.

Until you publish, a change can still be discarded by deleting its workspace in GTM; after publishing, GTM's version history is your rollback. See Read the Review & apply preview and Workspaces, publishing and recovery.

Free and Premium for GTM work

Every GTM module is available on Free, one GTM account per run. Within that account, Inventory & Cleanup extracts every container and creates and copies between them, Standardization Audit runs every built-in standard and keeps one custom standard, and Tag Dependency Map maps the whole account.

Premium removes the scope limit, so you can select brands in several GTM accounts in one run and create and copy across accounts. It also keeps any number of custom standards, and adds export, email delivery and scheduled reports and audits. Compare the plans.

What the GTM stack does not do

• Publish. You publish in GTM, container by container.
• Edit an existing item's configuration. You can rename, pause, activate, delete, create or copy. For other edits, use GTM itself.
• Fix what an audit finds. Standardization Audit and Tag Dependency Map only read. Stage the fix in Inventory & Cleanup, or make it in GTM.
• Analyse usage for server, AMP or app containers. Those rows show n/a, because clients and transformations there are outside the analysis.
• Schedule a change. Only reads run on a schedule.
• Delete workspaces. Remove a workspace you no longer need in GTM.

Choose your workflow

Each guide covers one job:

Keep going

• The GA4 Ultimate Stack complete guide
• Set up Google access for ODDVX
• GTM in ODDVX