Was wird geprüft
Drei Signale, in dieser Reihenfolge: der stape-Fingerabdruck (SDK-URL, load.stp- und sst-Subdomains, der Custom-Loader mit base64-kodierter Container-ID), ein gtm.js?id= von einer anderen Domain als googletagmanager.com, und eine Subdomain Ihrer eigenen Domain, hinter der ein Google-Mess- oder Loader-Pfad steht: /gtm.js, /gtag/js, /g/collect, /mp/collect. Der Check ist ein Hinweis, nie ein Fehler. Ohne Server-Side-Setup ist nichts kaputt, es fehlt nur die nächste Ausbaustufe.
Was der Scan nicht sieht: das Innere des Server-Containers. Welche Tags dort konfiguriert sind und wohin sie weiterleiten, bleibt unsichtbar. Wohin die Pings im Browser tatsächlich laufen, zeigt der Tiefenscan als eigenen Befund (Tracking-Architektur), inklusive DNS-Zuordnung des Endpunkts zu stape oder einem anderen Anbieter.
Warum ist das wichtig
Server-Side Tagging verlagert die Tags vom Browser auf einen eigenen Server. Ad-Blocker und ITP finden dann keine Vendor-Domains mehr, an denen sie ansetzen, die Cookies laufen auf Ihrer Domain, und Sie entscheiden, welche Daten das Haus verlassen. Der Preis: ein Container, der betrieben werden will, und eine Migration, die oft auf halbem Weg stehen bleibt. Halb migriert ist der Normalfall. Was Server-Side Tracking leistet, was es kostet und wann es sich lohnt, steht im Leitfaden Server-Side Tracking.
Häufige Ursachen
- Es gibt schlicht kein Server-Side-Setup, alle Tags senden direkt vom Browser an die Vendor-Domains.
- Der Server-Container existiert, aber der Web-Container sendet weiter an die Standard-Endpoints statt an die First-Party-Subdomain.
- Das Setup läuft über eine Subdomain ohne erkennbaren Mess-Pfad im HTML, dann zeigt erst der Tiefenscan den Datenfluss.
- Ein sGTM-Projekt wurde gestartet und nie abgeschlossen, der Container läuft im Leerlauf mit.