GTMSpy vs GTM Refine: Container Recovery Is Only the First Step

The Short Version

GTMSpy and GTM Refine can both start with a public website or Google Tag Manager container ID and reconstruct information from the published container. That makes both tools useful when you do not have access to the original GTM account.

The important difference is what happens after the container has been read.

GTMSpy is primarily an inspection and recovery tool. Its current Direct Scan view lists the tags, triggers, and variables it can extract, and it offers an export download. That can be enough when all you need is a quick look at a public container.

GTM Refine is designed for a longer workflow: recover, reconstruct, explain, audit, and improve. It detects modern container elements that GTMSpy leaves out, including Trigger Groups and Custom Templates. It then uses AI to assign meaningful names and notes to reconstructed tags, triggers, and variables instead of leaving a recovered container full of repeated type labels such as Google Analytics: GA4 Event, Window Loaded, or Custom Template (ID: 8).

That distinction matters because a JSON file is not genuinely recovered just because it can be downloaded. It also needs to preserve the container's logic and be understandable enough for someone to review, import, and maintain.

What Both Tools Are Trying to Solve

Sometimes the GTM container is still live but the account behind it is not available.

The original agency may be gone. Ownership may sit with an employee who left years ago. A client may know that tracking works but have no idea which Google account owns the container. Or you may simply want to understand how a public implementation is structured before planning a migration.

In those situations, the published GTM JavaScript is the remaining source of truth. A recovery tool reads that public representation and attempts to turn it back into familiar GTM entities.

Both GTMSpy and GTM Refine can help with that starting point:

• enter a website URL or a public GTM-XXXXXXX container ID;
• inspect the container without access to its GTM account;
• reconstruct tags, triggers, and variables from the published output; and
• download a JSON representation of the result.

This is not the same as stealing private account data. The tools work from configuration already delivered to a visitor's browser. They cannot recover unpublished workspaces, version history, user permissions, or server-side secrets that were never present in the published client container.

GTMSpy vs GTM Refine

Capability	GTMSpy	GTM Refine
Primary workflow	Inspect a public container and download a reconstructed export.	Recover a container, improve its structure, audit its logic, and produce maintainable outputs.
Inputs	Website URL or public GTM container ID.	Website URL, public GTM container ID, or an original GTM JSON export.
Core entities	Shows reconstructed tags, triggers, and variables.	Reconstructs tags, triggers, variables, built-in dependencies, and their relationships.
Trigger Groups	Does not detect and reconstruct Trigger Groups as container elements.	Reconstructs Trigger Groups, their members, and their stateful firing logic.
Custom Templates	Does not detect and reconstruct Custom Template definitions. A tag may only appear as a generic custom-template type or ID.	Detects Custom Templates, resolves known gallery templates where possible, and reconnects template-based tags and variables.
Names and notes	Recovered entities largely retain generic type-based labels; AI is not used to assign meaningful names and notes to the reconstructed export.	Uses AI and container context to propose meaningful names and explanatory notes for reconstructed tags, triggers, and variables.
Audit	Useful for inspection, but the reconstructed list is not a complete GTM health audit.	Checks configuration and dependency issues, then produces findings and recommendations.
Visualisation	Hierarchical lists and entity detail views.	Interactive dependency graph connecting tags, triggers, variables, built-ins, folders, and Custom Templates.
Review and exports	Downloadable reconstructed export.	Refined JSON, original-vs-refined diff, Excel report, graph view, and graph export.

The fairest way to describe the difference is not “old tool versus new tool.” The current GTMSpy site has both a Direct Scan interface and a chat interface. The difference is that its recovered container remains close to a raw technical extraction, while GTM Refine turns the extraction into a structured GTM recovery and audit workflow.

The Missing Trigger Group Problem

A Trigger Group is not just another label in a trigger list. It has distinct runtime behaviour.

GTM remembers whether each member trigger has fired during the page lifecycle. The Trigger Group fires on the event that completes the set, after every member has fired at least once. The members do not need to fire simultaneously or on the same GTM event.

If a recovery tool does not detect Trigger Groups, it loses part of the container's dependency graph. A tag may appear to use an ordinary trigger, while the real published logic required several events to occur in sequence. Rebuilding that tag from the incomplete representation can change when it fires or prevent it from firing at all.

This is also why Trigger Groups need more than a generic recovered name. A name and note should identify the member triggers and explain the stateful AND behaviour. GTM Refine reconstructs that relationship, applies naming context, and audits Trigger Groups for problems such as direct or nested self-reference. I have written separately about how Trigger Groups can reference themselves.

GTMSpy does not detect and reconstruct Trigger Groups as their own elements, so this layer of firing logic is absent from its recovered view and export.

Why Custom Templates Cannot Be Treated as Generic Tags

Custom Templates are another important gap.

A tag based on a Custom Template is only an instance of that template. The template definition contains the fields, permissions, sandboxed JavaScript, and metadata that give the tag its behaviour. Recovering the tag parameters without recovering or identifying the definition is like recovering a function call without the function.

In GTMSpy, a template-based tag may be visible only as a generic label such as Custom Template (ID: 8). That tells you that something custom exists, but not what the template is, what its parameters mean, or what must be present for a valid import.

GTM Refine treats Custom Templates as first-class container elements. It attempts to identify known Community Template Gallery definitions, reconnects the tags and variables that use them, and preserves the template context in the reconstructed container. When an exact template cannot be resolved, the result can say so explicitly instead of silently pretending that a generic tag type is enough.

This matters for consent platforms, advertising integrations, analytics vendors, server-routing helpers, and many other modern GTM setups that rely on Custom Templates rather than Custom HTML.

Raw Type Labels Are Not Meaningful Names

Published GTM JavaScript does not preserve every human-friendly detail from the original workspace. A reconstructed container can therefore end up with rows like:

• Google Analytics: GA4 Event
• Google Analytics: GA4 Event
• Google Analytics: GA4 Event
• Window Loaded
• Window Loaded
• Custom Template (ID: 8)

Those labels describe types, not intent.

They do not tell you which GA4 event is being sent, which measurement ID is used, what business action the event represents, why a trigger has its conditions, or which template powers a custom tag. Duplicate generic names also make references hard to follow once the JSON is imported into GTM.

GTM Refine uses the reconstructed configuration and its dependency context to propose names that describe what each entity actually does. It can also add notes explaining parameters, firing conditions, dependencies, usage, and potential cleanup work. You can choose which tags, triggers, and variables should be renamed or receive notes before the process runs.

The result is still reviewable. The built-in diff shows the original and refined JSON side by side, so AI-generated changes are not a black box. You can inspect the proposed naming convention and notes before importing the file.

GTMSpy's chat may help answer questions about a scanned container, but that is not the same capability. It does not use AI to assign meaningful names and notes to the reconstructed container elements in the downloadable export.

Inspection Is Not the Same as an Audit

A list of tags, triggers, and variables answers “what is present?” An audit also asks “what is wrong, risky, redundant, or difficult to maintain?”

GTM Refine inspects the relationships and inner configuration of the recovered container. That makes it possible to surface issues that are easy to miss in a flat list, including:

• the same trigger used as both a firing and blocking trigger on one tag;
• Trigger Group reference cycles or groups with too few members;
• inconsistent or ambiguous names;
• unused or duplicate elements;
• dependencies hidden inside variables and parameter tables;
• GA4 and Google Tag configuration problems; and
• Custom Template issues, including identifiable outdated gallery versions.

The audit is paired with an interactive graph. Tags, triggers, variables, built-ins, folders, and Custom Templates become connected nodes rather than unrelated rows. That view is especially useful in an inherited container, where the hardest question is often not what an entity contains, but what else will be affected if you change it.

When GTMSpy May Be Enough

GTMSpy can still be useful when the job is deliberately narrow.

If you want a fast public scan, a readable list of common tags, triggers, and variables, or a rough export for a simple container, its Direct Scan view may give you what you need. It is also useful as an independent second view when you are comparing what two public-container parsers can see.

The limitation appears when the result needs to become a working asset rather than a quick inspection. Missing Trigger Groups and Custom Template definitions can make the recovered model incomplete. Generic names make the result difficult to navigate. A lack of AI-assigned notes leaves the next practitioner to reverse-engineer the reverse-engineered container all over again.

When to Use GTM Refine

Use GTM Refine when you need to do more than look:

• recover a lost public container for a real migration or handover;
• reconstruct Trigger Groups and Custom Templates;
• make a modern GA4 or Google Tag setup easier to understand;
• replace generic recovered labels with meaningful, consistent names;
• add notes that explain intent and dependencies;
• audit the reconstructed logic before it is trusted;
• review every proposed JSON change in a diff;
• explore dependencies visually; or
• hand an Excel report to someone who does not want to inspect raw JSON.

You can also upload an original GTM JSON export instead of scanning a public container. In that workflow, GTM Refine works from the complete export you already have and focuses on refinement, explanation, and audit rather than recovery.

Recovery Should Produce a Container You Can Maintain

Recovering a published GTM container is valuable, but successful parsing is only the beginning.

The real test is whether the result preserves the important logic, identifies the components that modern containers depend on, and gives the next person enough context to work safely. Trigger Groups, Custom Templates, names, notes, dependency graphs, and audit findings are not cosmetic extras. They determine whether the recovered JSON is a maintainable container or simply a technical snapshot.

If you only need to see the common entities in a public container, GTMSpy offers a quick inspection path. If you need to reconstruct, understand, audit, and improve that container, try GTM Refine. Enter the website URL or GTM ID, or upload an exported container JSON, and review the refined result before you import or change anything.