Check · C03 · Tracking core

Tag manager detection: GTM, Zaraz, Launch, Tealium or Segment

The check looks for five tag management systems in the HTML. Finding none is a note, not an error; a container in first-party mode can trigger it.

What we check

In the HTML: the scan looks for the loader paths of five tag management systems: Google Tag Manager (gtm.js or a GTM-… container ID), Cloudflare Zaraz, Adobe Launch, Tealium iQ and Segment. A match means "ok" with the name. No match is a note, never critical, because hardcoded tags measure too. Starting the scan as "server-side / custom" replaces the note with a remark that the tag manager probably runs server-side.

What the scan cannot see: containers loading through an own subdomain and a renamed path without the container ID in the source. And it does not look inside the container. Whether there are tags in it at all, whether they are published and what they hang on is left to the deep scan and Tag Assistant.

Why it matters

A tag manager is where tracking changes happen without a deployment, and where consent gets bound to every single tag. Hardcoded pixels have neither. Since the VG Hannover ruling, however, even fetching gtm.js needs consent; the container therefore belongs behind the CMP itself, and its triggers have to know the decision. What data the container receives is governed by the dataLayer, see the primer What is a dataLayer.

Common causes

All pixels are hardcoded individually, grown historically across several agencies.
A tag manager exists but loads from a first-party subdomain and is not recognisable as one in the HTML, then the finding is a false positive.
The CMS plugin manages the tags, without versioning and without permission separation.
The container was installed for a test and never published, the snippet points to an empty workspace.

The fix

Set up a tag manager and move every pixel into it, then delete the snippets from the template. Inside the container: versions with descriptions, a consent trigger on every tag, a dataLayer schema that is documented, and if you load the container through your own domain, leave the container ID in the snippet so scans and audits can attribute it. Second container? Usually a relic. Ask whether it is needed.

Matching template

GA4 and Google Ads Consent Mapping

Documents which data flows from GA4 to Google Ads and which signal governs each flow.

Get the worksheet →

Check it yourself first

The Tracking Check tests this point along with all the others, in seconds.

Start the Tracking Check →

Asked often

We load GTM through our own domain. Why does the scan not detect it?

Because the HTML then contains neither googletagmanager.com nor a gtm.js path. The scan also looks for the container ID (GTM-XXXX); if you rewrite that too, you get a note although the container runs. The deep scan still sees the requests and files them under the tracking architecture finding.

We have no tag manager, the pixels are built in directly. Is that bad?

Not an error, but an effort problem. Every new pixel needs a deployment, nobody sees which tags fire on which page, and consent has to be wired into every snippet individually. From three tags on, a container pays off, if only for having the consent triggers in one place.

Detected means well configured?

No. The scan sees the snippet, not the container's contents. Whether the workspace is published, whether the tags hang on consent triggers and whether two containers serve the same property twice is shown by the findings consent activates measurement, reject respected and duplicate Google IDs in the deep scan.

The fix, delivered

Wired up in days, not sprints.

Findings from the Tracking Check go into a ranked sequence with effort estimates in the Audit Sprint, every module with an acceptance criterion.

To the service Request an Audit Sprint