The tracking errors your debugger can't see

If you work with GA4 or Google Tag Manager long enough, you’ll eventually inherit a setup you didn’t build. 

It was implemented years ago, the original owner has left, and several people have added ‘just one small change’ since. Yet somehow, you’re the person expected to explain why the numbers don’t look right. Sound familiar?

That’s a big part of my job as Analytics Integration Manager at IDHL, auditing GA4 and GTM configurations for new and existing clients, often without the benefit of a handover or anyone left to explain the original thinking. At MeasureFest & BrightonSEO, I shared one of those investigations: an ecommerce account with growing Unassigned traffic and a client who had stopped trusting the data.

The debugging tools said everything was fine, but the reports said otherwise. It was experience that reinforced something we don’t discuss enough in analytics: your tags firing isn’t the same as your data being right.

But the debugger said everything was working?

I started with the checks most of us would run: GTM Preview, DevTools, Tag Assistant, Omnibug and Analytics Debugger.

But every tag was present, all the triggers looked functional, Consent mode was active and the sequencing appeared correct. Nothing that overtly looked out of place, so much so that if you’d handed me the setup as new-build QA, I’d probably have signed it off. But the reporting problem still remained. 

That’s because these tools answer one question very well: did the tag fire?

However, what you’re not being told is whether the right thing happened, in the right order, at the right time for that particular user journey. A session ID might reset halfway through a session, a script could load outside the container, or a consent platform might respond slightly too late. Essentially, the individual components appear to work fine, while their interactions produce the wrong outcome. 

The solution you already have

The breakthrough didn’t come from a fancy, expensive new tool. It came from two files that were already available: a HAR file and GTM container export. For anyone unfamiliar with the former, a HAR (HTTP Archive) is simply the Network tab saved to disk. Every request the browser makes, in order, complete with timestamps.

Used together, they answer two different questions:

• The container export tells you what was configured
• The HAR tells you what actually happened

This distinction really matters. A container export can tell you exactly how tags and consent settings are configured. On the other hand, the HAR shows whether the browser behaved the way you expected. The interesting discoveries usually live somewhere in the gap between the two.

A quick word on AI

Before you upload anything into AI tools, remember that these files often include more than you expect and need to be properly considered. For example, HAR and container exports files can include cookies, headers, IDs, endpoints and anything hardcoded into Custom HTML. 

So, if you take away anything from this blog, let it be this: always sanitise the files and use test data and an AI environment approved by your organisation.

For this investigation, I used two sanitised HARs, one each for a first-time and returning visitors, and compared container exports from either side of the date reporting changed. The narrow prompt I then supplied looked something like this:

“List every measurement and consent request in order, identify its consent state and highlight the differences between the captures.”

The first theory was wrong

The AI generated theory was actually quite plausible, since analysis suggested consent was being resolved too slowly. On a first-time visit, Google's 500ms waiting period expired before the CMP had finished determining consent status. The page view was sent with denied consent, creating the possibility that attribution data was being lost. Everything was lining up.

Until I tested it. 

After capturing the same journey as a returning visitor whose consent choice had already been stored, the theory fell apart. All it took was a ten-minute browser check. The first GA4 request showed consent was already granted, a recognised client ID and an existing session history. But a weak theory disproved quickly is more valuable than a plausible one you spend a week casting. 

Finding the real culprit

The answer appeared when I compared historic GTM container versions. In this case, one consent setting on the GA4 configuration tag had been updated, allowing tags to send cookieless pings when consent was denied, and its release date matched the shift in reporting.

The real cause was advanced Consent Mode working as configured and that’s not a bug, so a debugger couldn’t see it. So, yes, the tags were firing, but that doesn’t mean the data was correct before further investigation. 

Make it your first check

The next time your reports don’t add up, don’t settle for the ‘tags are firing’ answer. If you would like a fresh pair of eyes on your GA4 or GTM setup, get in touch with IDHL team and we can help you build confidence in your data.