Webclat / Truth
Service

Website tracking audit: what actually fires, per device and consent state

The tag container says what should fire. The site decides what does. We run real sessions on real devices, decode every beacon, parse the container rule by rule, and hand you the difference.

What a tracking audit measures

Three things, in this order.

  • What is wired. The tag container parsed rule by rule: every tag, every trigger, every consent gate, every data element. This is what the container is built to carry. On one national retailer's live build, 279 of 280 rules carried no consent gate.
  • What fires. Real sessions walked from storefront to payment step, on a fresh profile, with the network recorded. Every request decoded: which tool, which event, which parameters, which consent string rode with it. This is what was observed firing. The two are different facts and we never swap them.
  • What the plan says. The tracking plan or the event taxonomy, compared with both. An event that is in the plan and not in the container is a gap. An event that fires and is not in the plan is a stranger in your data.

Conversion tracking audit: the checkout is where it breaks

Checkouts fail the audit more than any other page. On the retailer's site the checkout is a shell document with four child frames; the same-origin frame hosts the entire Adobe stack, while the shell holds only the tag manager and the consent events. A console reading in the top window sees no Adobe at all. Two of our own conclusions were wrong that evening for exactly that reason, and both were retracted once the frame scan ran.

Once the frames were read: analytics beacons on every checkout step, shipping, billing, pickup contact, pickup billing; a checkout progress event fired six times and begin checkout fired twice in one pass. A revenue model built on those events counts some steps more than once.

A second tag-management environment loaded on the sign-in pages, a different build of the same property. Which stage it was, production or otherwise, could not be read from the page. It is in the report as unread, not as guessed.

Per consent state, not just per page

A tracking audit that runs with every category on measures the best case. We run each state your notice allows.

With Targeting refused on the retailer's site, the gated conversion and remarketing tags stayed silent: zero Google conversion or remarketing calls, zero calls from the gated retargeting tag. The gates held. On the same page, under the same refusal, the analytics requests still went out marked as denied and reached Google as cookieless pings, seven of them on one page. The retail-media stack sent 30 calls and a Google cookie sync. Whether that is compliant depends on how the company classifies its own advertising. The audit reports what fired; the company decides what it means.

What you receive

DeliverableWhat it holds
Wiring tableEvery rule in the container with its trigger, its gate and its data elements.
Firing tableEvery request observed per page and per consent state, decoded.
Plan diffIn the plan and not wired, wired and not firing, firing and not in the plan.
Fix listEach gap with the change that closes it, ready for the container owner.

Counts are derived two ways and refuse to publish on mismatch. When the container changes, the counts are re-derived before they are quoted again; the retailer's audited build was superseded ten days after the extract.

Analytics QA that stays

The audit is a snapshot. Tracking QA is the habit. The firing table becomes the test set: run it after each container release, diff against the last run, and the release either passes or shows exactly which event moved. That is the re-audit tier on /answer-audit.

Platform-specific audits live on our platform sites: Google Analytics at ga.webclat.com, Google Tag Manager at gtm.webclat.com, Adobe Analytics and Launch at adb.webclat.com, Shopify pixels on shpf.webclat.com when it ships. This page is for the audit that spans them, because the AI reading your data does.

Related: cookie audit, Google Consent Mode v2, the data layer, cases.

Questions

Do you need access to our tag manager?

Read access to the container, yes. We parse the published container and compare it with what we observe. Without it, we can still measure what fires; we cannot say what was meant to.

Which devices do you test on?

Real desktop and mobile browsers, fresh profiles, no extensions. Emulators are a supplement, never the evidence.

How is this different from a Google Analytics audit?

A GA audit checks one tool's configuration. A website tracking audit checks every tool that fires from the site against the plan and against each other. The GA-specific work lives on ga.webclat.com.

What does analytics validation mean here?

Every number in the report is derived two ways, from the container and from the network, and published only when they agree. Where they disagree, the report says so.

Every wrong answer traced to the tracking, taxonomy or consent fault that caused it.

See the answer audit