Fehler und Probleme im GTM Server-Side Tagging finden

Checkliste & Audit Server-Side Tagging

Server-seitiges Tagging hat viele Vorteile wie längere Cookie-Laufzeiten, Umgehung von AdBlockern und mehr Kontrolle, welche Daten an Google, Meta, usw. übermittelt werden.

Das Thema ist aber kompliziert. Wer bisher nur mit dem (normalen) Client-GTM gearbeitet hat, muss die Herangehensweise grundlegend ändern. Es gibt viele Stolperfallen und die Dokumentation der Anbieter ist häufig nicht ideal.

Letzte Aktualisierung
21.10.2025

Drucken & PDF speichern
Als PDF speichern & drucken

Julian Kleinknecht
Julian Kleinknecht

Über den Autor

Julian Kleinknecht ist Geschäftsführer bei ConversionBoosting und unterstützt Unternehmen seit mehr als 14 Jahren bei Webanalyse und Tracking. Er teilt Erkenntnisse hier, auf LinkedIn und auf YouTube.

Mein Versprechen: Wir haben schon über 100 Audits des Server Side Taggings durchgeführt. Alle Empfehlungen kommen aus der echten Praxis.

Hoster des Tagging-Servers und verwendete Subdomain

1) Wird ein sinnvoller Hosting-Anbieter verwendet?

Sinnvolle Optionen sind Spezialanbieter wie Stape, TAGGR oder owntag. Auch wenn der GTM-Server selbst per Docker-Image gehostet wird (kompliziert), ist dies eine gute Option.

Nicht sinnvoll ist dagegen Google Cloud als Hoster. Diese Option ist nicht nur teurer als Spezialanbietern, sondern man profitiert auch nicht von den Vorteilen wie verlängerten Cookie-Laufzeiten.

Mehr zur Frage, welche Option die richtige ist, haben wir in unserem Beitrag dazu zusammengestellt.

2) Kommt eine eigenen Subdomain zum Einsatz?

Damit Cookies von der eigenen Domain gesetzt werden, muss der Tagging-Server auf einer Subdomain der eigenen Domain laufen.

Bei Stape darf man also zum Beispiel nicht die vorgefertigte Subdomain verwenden, sondern muss eine eigene anlegen:

3) Wurde eine unauffällige Subdomain für den GTM-Server gewählt?

Subdomains, die Worte wie “tracking”, „sst“, „gtm“ o.ä. enthalten, riskieren von AdBlockern geblockt zu werden. Eine unauffällige Domian wie “a.domain.de” ist sinnvoller.

Web-Container und Spezialfunktionen

Der normale Web-Container wird beim Server-Side Tagging nicht ersetzt, sondern der Server-Container zusätzlich verwendet.

1) Wird der Web-Container von der eigenen Subdomain-Domain geladen (statt von googletagmanager.com)? („Custom Loader“)

Bestehende Events werden an den Tagging-Server geschickt (zum Beispiel GA4-Events). Der GTM-Tagging-Server kann aber auch dazu verwendet werden, den Web-Container vom eigenen Server zu laden. Dies hat mehrere Vorteile:

  • Es wird kein Consent für den Web-Container benötigt. (Insbesondere wichtig nach dem Urteil des Verwaltungsgerichts Hannover, dass für den Web-Container eine Zustimmung notwendig ist.)
  • Nur so funktionieren Erweiterungen (wie das Umbenennen der Dateinamen, um AdBlocker zu umgehen).

Einfach im Quelltext prüfen, ob die GTM-Datei vom Tracking-Server geladen wird:

Wer die Dateinamen des Web-GTM oder der Requests an GA4 umbenennt (siehe unten), der schaut in den Entwickler-Tools nach, ob dort der GTM von der eigenen Subdomain geladen wird. Beispiel von Stape:

2) Wird der Client-GTM nur einmal ausgeführt?

Integriert man den Web-GTM zum Beispiel über eine Shopify-App oder eine WordPress-Erweiterung, darf der Web-GTM nicht auch noch im Theme oder an anderer Stelle vorhanden sein.

Sonst wird der Web-GTM doppelt ausgeführt und Events doppelt gemessen.

3) Werden von ITP gelöschte Cookies wiederhergestellt („CookieKeeper“)

Wenn die IP-Adressen des Tagging-Servers und des Website-Servers nicht in der vorderen Hälfte identisch sind, löscht ITP Cookies innerhalb von 7 Tagen. Genau dies ist der Fall, wenn man den Tagging-Server bei Spezialanbietern wie Stape oder TAGGRS hostet.

Die Spezialhoster bieten deshalb die Option, von ITP gelöschte Cookies wiederherzustellen. Dafür wird ein Master-Cookie als Key verwendet und die Werte der Cookies von Google Ads, Meta, usw. in eine Datenbank gespeichert. Werden diese Cookies nun gelöscht, können sie mit den Werten aus der Datenbank wiederhergestellt werden.

Wird der GTM-Server selbst per Docker-Image gehostet, ist diese Funktion nicht notwendig. Denn dann werden diese Cookie erst gar nicht gelöscht.

4) Wird für das Wiederherstellen der Cookies („CookieKeeper“) ein passender Master-Cookie verwendet?

Um gelöschte Cookies wieder herzustellen, benötigt man einen eigenen Cookie, der als Key in der Datenbank gespeichert wird. Dieser Cookie muss diese Anforderungen erfüllen:

  • Er muss für jeden Nutzer eindeutig sein.
  • Er muss vom Server gesetzt werden (also nicht im Client-GTM).
  • Er muss auch vom Client ausgelesen werden können, also nicht auf „httpOnly“ gesetzt sein.

Für viele Shopsysteme (wie Shopify und Magento) und CMS (wie WordPress und Wix) gibt es passende Plugins, die diesen Master-Cookie automatisch bereitstellen.

Bei Shopify heißt der Cookie zum Beispiel „_shopify_y“.

5) Wurde die Anti-AdBlock-Erweiterung aktiviert?

Spezialhoster bieten die Möglichkeit, dass Dateien wie “gtm .js” oder “/collect” umbenannt werden, damit sie nicht von AdBlockern blockiert werden.

Bei Stape aktiviert man sie hier:

Google Analytics 4 (GA4)

GA4 dient häufig als „Transportmittel“ für andere Dienste wie Google Ads oder Meta Ads. Es ist umso wichtiger, dass es korrekt integriert ist.

1) Werden GA4-Daten tatsächlich an den Tagging-Server gesendet?

Nur wenn die Daten auch an den eigenen Tagging-Server (und nicht direkt an google-analytics.com), werden auch tatsächlich Server-Cookies gesetzt. Nur dann profitiert man von den Vorteilen des Server-Side Tagging.

In diesem Beispiel werden die Daten fälschlicherweise direkt an google-analytics.com gesendet:

Am besten trägt man die Server-URL in eine “Google Tag: Configuration Settings”-Variable ein:

Diese Settings-Variable hinterlegt man dann im Google-Tag von GA4:

2) Werden ALLE Events an den Tagging-Server gesendet?

Werden manche Events direkt an den GA4-Server gesendet (statt über den GTM-Server), kann dies zu Problemen führen. Es werden zum Beispiel Sessions ohne Informationen zur Traffic-Quelle generiert („unassigned“).

Deshalb: Bei allen GA4-Events die Server-URL per “Google Tag Event Settings” Variable oder als Event Parameter übergeben:

3) Ist im Server-GTM ein GA4-Tag eingerichtet?

Wenn man die server_container_url hinterlegt hat, werden die Daten an den Tagging-Server gesendet. Man diese dann auch GA4 weitergeleitet werden, muss dort ein GA4-Tag angelegt sein:

Im Tag keine weiteren Einstellungen vornehmen und als Trigger diesen verwenden:

Am besten prüft man im GA4-debugView noch, ob Daten auch wirklich in GA4 ankommen.

4) Wird nur *eine* GA4-Property verwendet, um Daten an die verschiedenen Endpunkte zu senden?

Häufig sieht man, dass eine neue GA4-Property angelegt wurde, um Events an die Facebook CAPI zu senden. Dies ist nicht notwendig. Entweder man verwendet ein “neutrales” Tag wie das Data Tag von Stape oder hängt die zusätzlichen Informationen (wie die eindeutige Event-ID oder die Parameter beim Kauf) an die bestehenden GA4-Events an.

5) Werden in GA4 die Parameter für andere Anbieter entfernt? (im Server-GTM)

Verwendet man die GA4-Events, um Conversions für andere Anbieter (wie Meta) zu messen, muss man die von Meta erwarteten Parameter übergeben (siehe Punkt 4 bei „Web-Container“). Diese Parameter werden in GA4 jedoch nicht benötigt.

Hierfür erstellt man am einfachsten eine Transformation, welche unerwünschte Parameter entfernt:

Für Website in mehreren Ländern oder Sprachen: Werden Rollup-Propertys im Server-GTM erstellt?

Unternehmen mit Website in verschiedenen Ländern haben häufig verschiedene GA4-Property je Land. Zusätzlich ist es sinnvoll, eine Rollup-Property zu pflegen. Dort laufen die Daten aus allen Ländern zusammen. So können zum Beispiel Vergleiche über Länder hinweg durchgeführt werden.

Für eine Rollup-Property sollte man kein zusätzliches GA4-Tag im Web-GTM integrieren. Stattdessen kann man den zusammengefassten Data Stream im Server-GTM generieren.

Meta Ads

1) Funktioniert die Deduplizierung der Events?

Im Facebook Events Manager aber auch in Pinterest kann man prüfen, ob die Deduplizierung korrekt funktioniert:

2) Werden auch bei den Server-Events alle relevanten Parameter übergeben?

Um zum Beispiel das Retargeting bei Meta zu erlauben, müssen bei unter anderem beim “In den Warenkorb legen” und beim Kauf die gekauften Produkte übergeben werden. Diese Werte müssen mit denen im Web-Container übereinstimmen:

3) Wird im Web-Container eine Event-ID mitgeschickt?

Anbieter wie Facebook und Pinterest lassen einen Conversions im Browser und im Server messen. Damit Conversions nicht doppelt gemessen werden, müssen sie dedupliziert werden. Dafür benötigt es eine Event-ID, die sowohl in der Browser- als auch Server-Conversion vorhanden ist.

Im GTM gibt es eine Template-Vorlage “Unique Event ID”, die eine solche ID erstellen kann. Diese muss bei allen Browser-Events übergeben werden:

Das Gleiche gilt für alle Events, die im Server verwendet werden. Also beispielsweise alle GA4 Events oder Events aus “neutralen Tags”, wie das DataTag von Stape:

2) Werden alle Parameter (wie gekaufte Produkte) im richtigen Format für die verschiedenen Anbieter gesendet?

Jeder der Anbieter wie GA4, Facebook, Pinterest und Affiliate-Tools benötigt Parameter in einem unterschiedlichen Format. Deshalb sollte man diese im Tag, das an den Server gesendet wird, mitsenden.

In der Template-Galerie findet man eine Variable namens “Universal Conversions Variable”. Diese bringt die Parameter für die jeweiligen Anbieter in das gewünschte Format.

X) Stimmen Trigger für die Conversions der verschiedenen Anbieter?

Damit die Deduplizierung (siehe oben) funktioniert, müssen die Tags im Web-Container und Server-Container zum gleichen Zeitpunkt ausgespielt werden. Funktioniert dies nicht, werden Conversions doppelt gezählt.

3) Stimmen Variablen für die Conversions der verschiedenen Anbieter?

Jeder Anbieter erwartet andere Variablen. Bei der Facebook CAPI müssen sie zum Beispiel so aussehen:

Google Ads

1) Wurden zusätzlichen Server-Conversions (zuerst) als “sekundär” markiert?

Anders als bei Meta oder Pinterest gibt es bei Google Ads keine Deduplizierung. Deshalb legt man alle Server-Conversions neu an und lässt diese parallel zu den bestehenden Web-Conversions laufen. Nach einiger Zeit kann man dann einschätzen, ob die Server-Conversions tatsächlich mehr Conversions erfassen.

Wichtig: Die zusätzlichen Server-Conversions sollten anfangs als sekundär markiert sein. Sonst werden alle Conversions doppelt gemessen.

Alerts + Monitoring

1) Wurden Alerts aktiviert?

Spezialanbieter bieten die Möglichkeit, Benachrichtigungen zu versenden, wenn zum Beispiel für 8 Stunden keine Transaktion gemessen wurde. Dies deutet darauf hin, dass etwas beim Tracking kaputt gegangen ist.

Viele kennen diese Funktion gar nicht und nutzen sie entsprechend auch nicht.

Consent

1) Wird auch im Server-GTM der Consent beachtet?

Obwohl man es von außen nicht sieht, dürfen auch Conversions im Server-Container nur ausgespielt werden, wenn der Consent vorhanden ist.

Angenommen man verwendet GA4 (Consent-Typ Statistik) für das Google Ads Tracking (Consent-Typ Marketing) im Server-Container. Dann darf man Conversion nur an Google Ads schicken, wenn auch der Consent für Marketing vorhanden ist. Denn in (nur wenigen Fällen) gibt es Besucher, die zwar Statistik zustimmen, aber nicht Marketing.

Hierfür übergibt man in GA4 den Wert des Consent-Cookies und liest in im Server-Container aus:

Oder man spielt auch GA4 nur aus, wenn Consent zu Statistik und Marketing vorhanden ist.

Julian Kleinknecht
Julian Kleinknecht

Mein Versprechen:Wir haben schon viele für viele Projekte ein Audit des Server Side Taggings gemacht. Ich schreibe hier nur über Themen, zu denen wir schon viel Erfahrung gesammelt haben.

Über den Autor

Julian Kleinknecht ist Geschäftsführer bei ConversionBoosting und unterstützt Unternehmen seit mehr als 14 Jahren bei Webanalyse und Tracking. Er teilt Erkenntnisse hier, auf LinkedIn und auf YouTube.

Du hast Fragen?

Schreib hier eine Nachricht oder kontaktiere mich bei LinkedIn

ConversionBoosting