The tracking audit: what Measurebase checks in your Tag Manager setup

NM Nick van Maaren

8 Oct 2026 · 9 min read

A tagging setup breaks quietly. Someone republishes the web container with the Google tag pointing straight at Google again, a conversion tag loses its event ID, a plugin pastes a second snippet onto every page, a DNS record changes at the registrar. Nothing errors, data just stops being right. The tracking audit reads your web and server container through the Tag Manager API, looks at what your site actually does with them, and tells you what is wrong, what could be better and what is in order. Every night, or whenever you press the button.

What it needs from you

On the domain's settings page, connect the Google user that can edit the domain's Tag Manager containers. Measurebase then lists the containers that user sees and suggests the web container whose domain matches and the server container whose tagging URL is this domain's host. Link both, and the first audit runs that night. The Run audit button on the domain's Tag Manager page runs one now, up to five times a day per domain.

Nothing is changed in Tag Manager by the audit itself. It reads the published version of each container and your domain's own request log, nothing more. Filling in the measurement setup on the settings page is optional, but worth it: once Measurebase knows which destinations this domain should measure, the audit also checks that each of them is really there.

What gets checked

Around forty checks, grouped by where the problem would live. Each finding names the container, the tag, trigger, variable or client it is about, and what to change.

Routing: does measurement flow through your domain?

Web container · the Google tag sends its hits to this domain's tagging host and nowhere else, it is live and has a firing trigger, no measurement ID is configured twice, GA4 event tags send to the property the Google tag configures, and ecommerce events fire on their data layer events rather than on every page.
Server container · the GA4 client that claims the hits exists, the "Google Tag Manager: Web Container" client allows your web container so the site can load it first-party, a live GA4 tag forwards the hits to Google Analytics, the client manages its cookies server-side and migrates the existing JavaScript client ID, default paths are accepted, and server-side Google Ads conversions have their Conversion Linker.
Backed by traffic · the audit also compares the containers with what your domain actually received: whether GA4 hits arrive at all when the Google tag is loaded, whether the web container is fetched through this domain instead of from googletagmanager.com, whether every Google tag ID the site loads is configured in the published container, and whether every GA4 event tag's event has shown up in the last weeks of hits.

Deduplication: browser and server copies that agree

A platform fed by both a browser pixel and a server-side Conversions API tag counts every conversion twice unless both carry the same event ID. The audit checks that every Meta, TikTok, Snapchat, Pinterest or ChatGPT pixel tag sends one, that your GA4 event tags carry an event_id for the server copies to deduplicate against, and that purchase events carry a transaction_id so GA4 can deduplicate purchases.

Consent: do your tags respect the choice?

Your domain's request log records the Consent Mode state of every GA4 hit, so the audit knows whether visitors actually send consent signals. When they do, it flags marketing tags that require no additional consent and would fire regardless of the choice. When a consent tag is in the container but hardly any hit carries a consent state, it says so. Tags that fire on Consent Initialization without being consent tags are called out too.

Container health

Paused tags and tags without a firing trigger, placeholder values such as G-XXXXXXX left in a field, tags blocked by an exception trigger that always matches, test tags that are live on every page, vendor pixels pasted as custom HTML next to a template tag, Universal Analytics leftovers, and test event codes left in Conversions API tags. On top of that, a tidy-up tip lists the templates, variables and triggers nothing in the container uses, with their names, so you can delete them in one pass.

Measurement setup alignment

With the measurement setup filled in, the audit checks that every destination you enabled has its tag in the live containers. It knows the difference between a GA4 property and the Google Ads configuration, treats server-side Google Ads conversions as complete without a browser conversion tag, and tells you to store a platform's API token first when a server tag cannot exist without it.

The site itself

Not everything lives in Tag Manager. From your domain's request log the audit sees whether your pages load the container with the enhanced tracking script rather than the standard snippet, whether that script loads the container you linked, whether a snippet is on the page twice, and whether page views are sent twice because a page runs twice. With the ad-block guard switched on, it checks that page views really arrive through the masked relay. And it looks outward: the DNS record for your tagging host points at Measurebase, and the host answers HTTPS with a valid certificate that is not about to expire.

Errors, warnings, tips and passed checks

Errors break measurement. The moment an audit finds one, the domain's audit alert opens: it is in the alert bell, on the Alerts page, in your email and in Slack if you connected it. The same set of errors tomorrow changes nothing; a different set refreshes the alert; a clean audit resolves it.
Warnings are probable issues: data that is likely counted twice, a tag that likely never fires, a setting that will cost you later.
Tips are optional improvements. An audit with only tips counts as clean.
Passed checks are everything the audit looked at and found in order. They are folded away under the findings, so a clean container does not read as a wall of green, but they are there when you want to see what was verified.

The Tag Manager page shows the counts per container and for the site, and every finding opens to the tag, trigger, variable or client it is about, as it was at the moment of the audit.

Proposed fixes

For many findings Measurebase can propose the change itself: a Google tag that gets its server_container_url, a GTM client that is created, a pixel tag that gets its Unique Event ID, a destination from your measurement setup built from the same templates as the GTM template builder. You tick the changes you want, review them, and apply. Measurebase writes them into a workspace named "Measurebase" in your container and audits that workspace right away, so you see the result before anything goes live.

Measurebase never publishes. You preview and publish in Tag Manager, as you always did, or abandon the workspace if you change your mind. Applied changes stay listed on the Tag Manager page with what happened to each operation.

History and workspace audits

Every audit is kept, with what changed in the containers since the one before: versions published, tags added, clients changed. Before you publish a workspace of your own, you can audit it instead of the published version to see whether the change holds up. Such an audit never replaces the latest one and never opens an alert.

Also from your AI assistant

The Measurebase MCP connector exposes the same audit to Claude, Cursor, ChatGPT and the other clients: read the latest audit, run a new one, list what Measurebase can fix and apply the operations you choose. The rules, the limits and the workspace are the same as in the dashboard.