Reading the container map

Every report flattens a container into lists and throws away the thing that makes it hard to reason about: what depends on what.

Why a graph

A GTM container is a dependency graph and always was. Triggers fire tags, tags read variables, variables feed other variables, tags reach hosts, and tags sequence other tags. Presented as separate lists, the structure disappears.

The map exists to answer one question — what causes data to reach this host? — which the privacy owner, the marketer and the developer all ask in different words.

The views

Destinations. Every host the container can reach, ranked by how many tags send there. Pick one and you get the exact chain: which trigger fires which tag which sends to that host, and the variables read along the way.

Blast radius. The same question inverted — variables ranked by how many tags and triggers read them. The top entry is the thing whose change would alter the most behaviour. GTM's own plumbing is listed separately, because a built-in Event variable topping the list is how GTM works, not a decision anyone made.

Tags. Each tag with its triggers, its template, and every destination it can reach.

Graph. All of it at once. Useful for seeing shape — clusters, isolated tags, a variable everything depends on. On a phone the list views open first, because a force-directed graph needs room and precise pointing to be worth anything.

What it is read from

Only the published container, exactly as delivered to every visitor's browser. That means no login is needed — and also that tag names are not available, because the runtime artifact does not carry them. Tags are identified by type and GTM's own numeric ID. The names live in the GTM API export, which the CLI can fetch once you authorise it.