The GA4 tag debugger

Every analytics team has the same story. A release goes out on a Tuesday. On the following Monday someone notices conversions look low. By the time anyone traces it back to a renamed CSS class that broke a GTM click trigger, six days of purchase data are gone and cannot be recovered.

The tools most teams use — GA4 DebugView, GTM Preview, the network tab — are all manual and momentary. They tell you tracking works right now, in your browser, while you are looking. They cannot tell you it still works next Tuesday. Closing that gap is the whole point of this tool.

Inspect: what live capture actually shows

The Inspect tab captures the analytics traffic a page produces and decodes it as it arrives. For each hit you see the event name, every parameter (including the ep. and epn. custom parameters that are unreadable in raw form), the measurement ID it was sent to, the consent state carried in gcs, and the dataLayer push that triggered it.

You can capture in two ways. The browser extension hooks your own browser, so you debug the real site in your real session with your real consent choices. The in-app headless browser drives a clean Chromium instance from Tagfire, which is the right choice when you want a first-visit state with no cookies, or when you are debugging a site on a machine where you cannot install anything.

• Confirm an event fires at all, and only once — duplicate purchase hits are the most expensive bug in ecommerce tracking
• Read consent flags on a hit to see whether your CMP is actually gating measurement
• Catch parameters that arrive empty or as the literal string undefined
• See the order events fire in, which is how you find a purchase that beats its own begin_checkout
• Watch server-side hits alongside browser hits in a hybrid setup

Recordings: turning a manual check into a repeatable one

Debugging one journey by hand is fine. Debugging it again after every release is not — which is why nobody does it. A recording captures the steps of a flow once (the clicks, the form inputs, the navigation) and stores them so the same journey can be driven again on demand.

What makes a recording useful rather than just repeatable is its expectations. An expectation says which GA4 events must fire during that journey and, optionally, what has to be true about their parameters — a purchase with a value above zero, a currency of USD, a non-empty transaction_id. After any replay, captured hits are checked against those expectations and you get a pass or fail per assertion, not a wall of raw requests to read.

This is the step that converts tribal knowledge into something a team owns. The person who knows that the checkout only fires add_to_cart correctly when a size is selected first can encode that, once, and it stays true after they leave.

Monitors: the part that runs without you

A monitor groups several recordings for one site into a single scheduled check. It owns the schedule (hourly, daily, or weekly), the list of email recipients, and the visual-regression settings. On each run, Tagfire replays every recording server-side in headless Chromium, evaluates its expectations, captures a full-page screenshot, and pixel-diffs that screenshot against the accepted baseline.

A recording fails if an expectation fails, a step fails, or the visual diff exceeds the threshold you set. Any failure sends one digest email to all recipients, with the failing assertions and the screenshots attached. Every run is kept as history, so you can see exactly which run a regression appeared in.

The visual diff matters more than it first appears. Analytics assertions catch tags that stopped firing; they cannot catch a checkout button that moved behind a cookie banner, because the tag still fires when the test clicks the element directly. The screenshot comparison catches the class of breakage where tracking is technically fine and the page is not.

Keeping synthetic traffic out of your reports

Replays drive real tags, which means they generate real hits. Tagfire sends a distinctive User-Agent containing a TagfireMonitor token from the headless browser, so you can exclude monitor traffic with a GA4 internal-traffic filter or a GTM exception regardless of who owns the property. Where you control the property, you can additionally filter the service static outbound IPs. Set this up before your first scheduled run, not after.

Where this fits against DebugView and GTM Preview

They are complementary. GTM Preview is a build-time tool — it is where you develop a tag. This is a verification and monitoring tool — it is where you prove the tag still works months later, without anyone remembering to check.

What to monitor first

1. 01

   The purchase or lead journey

   The one flow whose data the business actually acts on. If you only ever create one monitor, make it this one, and assert on transaction_id, value, and currency.

2. 02

   Consent accept and consent reject

   Record the journey twice: once accepting the banner, once rejecting it. The reject path is the one nobody tests, and it is where compliance problems and data loss both hide.

3. 03

   The main form submission

   Form success events break constantly, because form markup changes constantly. Assert that the success event fires and that the page reaching it is the confirmation page, not a validation error.

4. 04

   A key landing page from paid traffic

   Assert on campaign parameters surviving the landing. This is how you catch a redirect that strips gclid or your UTMs — see the UTM builder for keeping those links consistent in the first place.