I Asserted the Pixel Fired. It Hadn't.

The HTML said the tag was installed. The network said it never fired. I had been trusting the HTML.

A tag present in the page is a claim. A GA4 beacon on the wire, an actual request to google-analytics.com/g/collect, is evidence. For a long time I treated the first one as if it were the second, and so did most of the tracking audits I had ever seen.

The proof that lied

The inherited way to prove tracking worked was to look at the page source. Is the snippet there? Is the container present? If yes, mark it green and move on.

That check kept passing. And the analytics beacon still never left the browser.

Present is not the same as firing. A tag can sit in the HTML, wired through a tag manager, fully “installed” by every static test, and still send nothing when the page actually loads. The proof I was relying on could not tell the difference between a tag that works and a tag that is merely there.

Assert the beacon, not the tag

So the check moved down a layer, from the source to the wire.

The new step watches the browser’s real network traffic and passes or fails on whether the beacon actually fired. It matches the request URL and the expected parameters against the real analytics endpoints: google-analytics.com/g/collect for GA4, bat.bing.com for Bing UET, facebook.com/tr for Meta. If the request goes out, it passes. If it does not, it fails.

It is deliberately read-only, for now. One headless page load, a fixed window to watch, no form submits, no injected test leads, no clicking the consent banner. It only observes.

That step is one rung in a larger eight-link funnel check that walks the whole path: the landing page and its form, the record landing in the CRM, dedup and identity, the GA4 event, the Meta signal, the Ads signal, the conversion definition, and audience readiness. Each rung is a live read, checked on its own terms, not an inference from configuration. The read-only beacon assertion covers the pixel rungs. The CRM and dedup rungs are separate reads against the CRM itself, not something a headless page load with no form submit could ever prove. It is a set of honest per-rung checks, not a claim that one lead walked all eight untouched.

And the beacon rung says less than it looks. An outbound request means the tag fired, that something left the browser. It does not mean the destination received it, recorded it, or counted a conversion. Emission is one rung. Receipt is another. A fired GA4 event is eligible at best, never a business outcome. The CRM stays the source of truth for whether a real thing happened.

The first run, and the sting

I pointed the brand-new assertion at two live sites as its first real test. It came back red on both. That was the assertion doing its job, not a false alarm to wave away.

One was a site I own. A GA4 assertion, a ten-second window, and no matching beacon across 28 captured requests. The GA4 container snippets were right there in the page source, exactly where the old check would have found them and passed.

The other was a real-estate client’s site. Same GA4 assertion, no beacon across 142 captured requests, on a page known to run a GA4 property through a tag manager.

The HTML said installed. The network showed no beacon in the window. Only the network was telling the truth.

A checker that can’t fail

The likely reason on both was ordinary: consent gating. On a site that holds its tags until someone accepts, or runs consent mode in its strict form, the GA4 tag waits, and a read-only check does not click the banner, so no beacon leaves in the window.

I say likely because a missing beacon only tells you it was missing. It does not tell you why. Delayed loading, a broken trigger, an ad blocker, or my own matcher being too narrow could all look identical from the outside. So the red is a flag to chase, not a verdict that tracking is broken.

That uncertainty is not the point. The point is that the tool said “no beacon observed” instead of quietly passing because a tag was present in the source. It could come back red, so it did.

A checker that cannot fail is not checking anything. If the old page-source test had never once come back red, that was not confidence. It was a test that had nothing to say.

What it taught

Verify runtime behavior. Do not infer it from configuration. A tag in the source is a claim about what should happen. A beacon on the wire is a record of what did.

Consent gating, where it turns out to be the cause, is a real and quiet reason analytics undercounts, and you only ever see it if you watch the actual request go out.

I had been certifying tracking off the page source, which is another way of saying I had been trusting the claim instead of the evidence. The day the check could finally come back red was the day it started telling me the truth.