In use, only inactive users, orphaned: reading GTM usage verdicts

Usage is not status

Every inventory row has two separate signals, and mixing them up is the most common way to misread a container.

• Status is about tags only: Active or Paused. It describes the tag's own setting.
• Usage applies to every tag, trigger and variable. It asks: does anything that can actually fire depend on this item?

The two don't move together. A paused tag that still has firing triggers reads In use, because its own wiring is intact; the Status column is what says Paused. A trigger used only by that paused tag reads Only inactive users, because the only thing relying on it can't fire right now.

The three verdicts

ODDVX works out usage per container by following references from everything that can fire. A tag can fire when it isn't paused and has at least one firing trigger, or when it is the setup or cleanup tag of a tag that can fire. From there:

How references travel through a container

References are followed everywhere a {{Variable}} can appear: tag fields, Custom HTML, trigger conditions, Lookup and RegEx Table inputs, and other variables. Chains are followed to the end. If a live tag uses a Lookup Table, and the Lookup Table reads a Data Layer Variable, both variables are in use.

Some things don't count:

• Notes don't count. A variable mentioned only in another item's notes is still orphaned.
• Trigger Groups count. A trigger that is only a member of a Trigger Group is in use if a tag that can fire uses the group.
• Setup and cleanup tags count. Tag sequencing keeps a tag alive while the tag it supports can fire.

Read 'Referenced by' before you decide

The Usage badge carries a reference count. Hover it to see who references the item, by type and name: up to ten names, with a count for the rest. That list is often enough to answer the question without opening GTM.

Read it with some care:

• A variable with many referrers is a shared dependency. Renaming or removing it affects all of them.
• One referrer that is a paused tag points to a seasonal or retired campaign. Ask about the campaign before you ask about the variable.
• A count of zero is the starting point for an orphan review, not the end of it.

What the verdict does not analyse

The analysis is deliberately narrow, so that its verdicts mean something. It covers tags, triggers and user-defined variables in web containers, as they stand in each container's Default Workspace. It doesn't cover:

• Server, AMP and app containers. Clients, transformations and zones there can reference variables in ways outside the analysis, so their rows show n/a rather than a guess.
• Built-in variables. They aren't listed as rows and are never orphan candidates.
• Work in other workspaces. A variable that looks orphaned may be about to be used by a change someone is preparing elsewhere.

Why an orphaned item still deserves a second look

Variables and triggers are tempting cleanup targets because they don't send data themselves. But an orphaned verdict only describes the container today. It doesn't tell you about the business around it. Before you propose removing anything, ask:

• Is it seasonal? A Black Friday trigger is orphaned eleven months a year.
• Is a release pending? A developer may have prepared the variable for a change in another workspace.
• Is it documentation? A constant that records an ID can be the only place that ID is written down.

Then choose a step that fits what you know:

• Known purpose and current use: retain it and document it.
• Known reference but uncertain purpose: ask the owner and test the relevant journey.
• No references, but someone has work pending: check with the person doing that work.
• No identified use after review: prepare a removal proposal with the scope and a retest plan, then follow Clean up orphans across brands in one batch.

“The name looked old” is not a reason on its own.

Confirm the connections in Tag Dependency Map

When an item has referrers you don't recognise, or you are about to change something many items depend on, open the same container in Tag Dependency Map. It shows the item with everything upstream and downstream of it, including dataLayer keys. Inventory & Cleanup tells you whether something is used; the map shows you how. See the Tag Dependency Map use case.

Keep going

• Inventory every tag, trigger and variable across your brands
• Clean up orphans across brands in one batch
• Use case: see what depends on a GTM item