GTM Preview Mode Debugging
What Preview mode actually connects to
Entering GTM Preview mode (Tag Assistant) injects a debug session connector into your current workspace's unpublished draft and opens a side panel showing, for every page load and interaction, exactly which tags fired, which didn't, and under what trigger conditions. Crucially, Preview mode tests your current *workspace* state, not the live published container — this is what lets you safely validate unpublished changes against real browsing behavior before anyone else is exposed to them.
Reading the Tags panel: fired vs not fired is only the start
The Tags panel splits every tag into 'Tags Fired' and 'Tags Not Fired' for each event in the session timeline. A tag appearing under 'Not Fired' isn't automatically a bug — it might correctly not have met its trigger condition on that particular page. The useful diagnostic step is clicking into the tag and checking its trigger evaluation details, which show exactly which condition passed or failed and why, down to the specific variable value that didn't match what the trigger expected.
The Variables panel: where most 'why didn't this fire' answers live
Most debugging sessions end not in the Tags panel but in the Variables panel, which shows the resolved value of every GTM variable at each point in the event timeline. If a trigger condition checks {{Click Classes}} contains add-to-cart and the tag isn't firing, the Variables panel immediately shows what {{Click Classes}} actually resolved to for that specific click — frequently revealing the real class name has a typo, extra whitespace, or simply isn't the class actually present on the clicked element, which is invisible from source code alone but obvious once you see the resolved runtime value.
The Summary/event timeline on the left is a sequencing tool, not just a list
Window Loaded will never fire if its trigger is scoped to DOM Ready. Clicking through each timeline entry and checking what data layer state existed *at that specific point* is how timing-dependent bugs get diagnosed, rather than only looking at the final state after everything has loaded.Debugging server-side containers specifically
Server-side GTM containers have their own separate Preview mode, connecting to the server container rather than the client-side one, and showing a different set of concerns: which client (e.g. the GA4 client) matched the incoming request, how the event was transformed before being routed to server-side tags, and what the server-side tags actually sent onward to each destination platform's API. Debugging a server-side pipeline issue requires chaining both Preview sessions — confirming the client-side container sent the expected request to the server container, then confirming the server container processed and forwarded it correctly — since a bug can originate in either half independently.
Preview mode vs other debugging tools, by what each one actually shows
| Tool | Shows | Best for |
|---|---|---|
| GTM Preview mode | Tag firing status, trigger evaluation, variable resolution within GTM's logic | Diagnosing why a specific tag did or didn't fire, and why |
| Browser console (dataLayer) | Raw data layer pushes, in order, independent of GTM's reaction to them | Confirming the underlying data even exists before troubleshooting GTM |
| Network tab | The literal outbound request and parameters actually sent to a platform | Verifying what a platform actually received, ground truth beyond any UI abstraction |
| GA4 DebugView | Real-time events as GA4 itself received and parsed them | Confirming GA4's own interpretation matches what you intended to send |
What's Next?
Preview mode is the daily-driver tool for diagnosing GTM-specific issues, but a complete debugging workflow also reaches outside GTM entirely — into browser devtools, network inspection, and platform-specific debug views — for the full picture of what's actually happening across the stack.
I build these systems professionally.
Whether it's a RAG pipeline, analytics migration, or AI workflow — let's talk.