Fehler und Probleme im GTM Server-Side Tagging finden
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.
Ü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.
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.
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:


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.
Der normale Web-Container wird beim Server-Side Tagging nicht ersetzt, sondern der Server-Container zusätzlich verwendet.
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:
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:


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.
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.
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:
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“.
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:


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.
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:


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:


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.
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.
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:


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.
Im Facebook Events Manager aber auch in Pinterest kann man prüfen, ob die Deduplizierung korrekt funktioniert:


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:


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:


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.


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.
Jeder Anbieter erwartet andere Variablen. Bei der Facebook CAPI müssen sie zum Beispiel so aussehen:


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.


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.
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.
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