ssGTM für mehr Conversions & bessere Attribution: Mit serverseitigem Tagging ITP & Ad-Blocker umgehen

Browser wie Safari und Firefox machen Conversion-Tracking immer schwerer. Sie schränken die Laufzeit von Cookies ein, entfernen Tracking-Parameter und blockieren Tracking-Requests komplett. Dies führt zu weniger und zu ungenaueren Daten in GA4, Google Ads, bei Meta und anderen Tracking-Tools. Und dadurch zu höheren Kosten, da die Algorithmen der Tools weniger Daten zur Verfügung haben.

Beim Server-seitigem Tagging wird ein zusätzlicher (Server-seitiger) Google Tag Manager (ssGTM) installiert. Dieser bietet viele Möglichkeiten, um ITP (Intelligent Tracking Prevention) und ähnlichen Ansätzen entgegenzuwirken:

• Es werden Server-Cookies gesetzt, die nicht schon nach einem Tag automatisch vom Browser gelöscht werden.
• Statt „utm“-Parametern kann man seine eigenen URL-Parameter definieren, die nicht automatisch aus der URL entfernt werden.
• Man kann Dateien wie die GTM-Bibliothek und Tracking-Requests umbenennen, sodass sie nicht mehr blockiert werden.
• Man kann gelöschte Cookies wiederherstellen.

Julian Kleinknecht zeigt im Video alle diese Vorteile und die konkrete Umsetzung dazu.

Was ist serverseitiges Tracking?

Beim traditionellen Client-seitigen Tracking werden Daten vom Tag Manager direkt an die einzelnen Anbieter/Tools übermittelt.

Bei Server-seitigen Tracking wird ein zusätzlicher Tag Manager dazwischengeschaltet:

1. Statt Daten vom (Client-seitigen) Tag Manager direkt an z.B. Google oder Facebook zu schicken, werden die Daten an den Server-seitigen Tag Manager geschickt.
2. Im Server-seitigen Tag Manager werden die Daten angepasst und dann z.B. an Google oder Facebook weitergeschickt.

Wichtig: Der normale (Client-seitige) Container bleibt bestehen.

Herausforderungen durch ITP (Intelligent Tracking Prevention)

ITP ist Safaris Ansatz für mehr Datenschutz. Die wichtigsten Änderungen fürs Online-Marketing:

• Cookies sind nur noch maximal 7 Tage gültig.
• Sobald die Landingpage Tracking-Parameter (wie gclid oder fbclid) enthält, sind Cookies nur noch maximal 24 Stunden gültig
• Bestimmte URL-Tracking-Parameter werden entfernt

Das führt zu schlechterer Attribution und dadurch schlechterer Optimierung von Kampagnen bei Google Ads, Meta Ads, usw. Das gilt insbesondere für Websites mit signifikanten Werbeausgaben, mit vielen Apple-Besuchern und längeren Sales-Zyklen.

Vorteile des Server-seitiges Tagging im Überblick

Relevant fürs Tracking:

1. Bessere Attribution durch längere Cookie-Laufzeiten
2. Mehr gemessene Conversions durch Umgehen von AdBlockern
3. Bessere Attribution durch weniger entfernte URL-Parameter

Außerdem:

• Mehr Kontrolle, was gemessen wird
• Besserer Datenschutz (wegen Kontrolle, was an Tools geschickt wird
• Schnellere Ladezeiten (aber nur geringfügig)

So erzielt man längere Cookie-Laufzeiten

Vom eigenen Tagging-Server gesetzte Cookies sind nicht von ITP betroffen. Dies erkennt man anhand der Spalte “HttpOnly”, wenn man sich die Cookies einer Website in den Entwickler-Tools ansieht.

Hier wurde der GA4-Cookie “FPID” vom Tagging-Server gesetzt. Der normale GA4-Cookie “_ga” dagegen nur im Browser:

Wo Tagging-Server hosten?

Bevor man das Server-seitige Tagging aufsetzt, benötigt man einen entsprechenden Server. Es gibt drei Optionen, einen Tagging-Server aufzusetzen:

a) Selbst aufgesetzter Tagging-Server

Vorteile: Volle Kontrolle und geringe laufende Kosten

Nachteile:

• Technisch anspruchsvolles Setup
• Man benötigt einen Hoster, der ein Docker-Image (auf dem gleichen Server wie die Website) hosten kann
• Funktionen zur Umgehung von AdBlockern muss man selbst aufsetzen

b) Externen Anbieter wie Stape

Vorteile: Schnell aufgesetzt und technisch einfach. Viele zusätzliche Funktionen verfügbar

Nachteile:

• laufende Kosten (ab 20 EUR/Monat, kann aber schnell teurer werden)
• zusätzlicher Aufwand, Cookies wiederherzustellen

c) In der Google Cloud

Keine sinnvolle Option, da teurer als externe Anbieter und keine der zusätzlichen Funktionen (wie Cookies wiederherstellen) verfügbar sind.

Empfehlung: Bei vorhandenen technischen Wissen und passendem Hoster ist der selbst aufgesetzte Server ideal. Für alle anderen sind externe Anbieter wie Stape die bessere Wahl.

GA4, Google Ads und Meta Server-seitig aufsetzen

Für jedes der drei Tools ist die Implementierung etwas anders. Alle drei basieren jedoch auf den GA4-HTTP-Fragen aus dem Web-Container

GA4 einrichten

Im ersten Schritt aktiviert man im Client-Container die Option “An Servercontainer senden” und trägt die zuvor angelegte Subdomain des Tracking-Servers ein.

Im Server-Container einfach die fertige Vorlage für GA4 verwenden. Ab jetzt werden auch Server-Cookies verwendet.

Meta Ads

Bei GA4 leitet der Server-Container die Anfragen aus dem Browser einfach an GA4 weiter. Bei Meta ist dies anders. Es bleibt das normale Pixel bestehen und zusätzlich werden Daten per Server-GTM an die sogenannte Conversion API geschickt. Damit Conversions nicht doppelt gezählt werden, müssen sie de-dupliziert werden.

Im Client-Container muss man deshalb sowohl beim Meta-Pixel als auch bei GA4 eine Event-ID übergeben:

Im Server-Container werden die Conversions an Meta basierend auf den GA4-Events gesendet:

Google Ads

Bei Google Ads legt man für jede gewünschte Conversion eine weitere Conversion an (und stellt sie zuerst auf “sekundär”). Es gibt hier weder eine De-Duplizierung (wie bei Meta) noch werden Conversions einfach durchgereicht (wie bei GA4).

Wie bei Meta basiert die Conversion im Server-Container auf einem GA4-Event:

GTM und GA4 verschleiern, um AdBlocker zu umgehen

AdBlocker blockieren Tracking-Tools vor allem anhand der Domain (wie google-analytics.com) sowie des Dateinamen (wie gtm.js). Sowohl der Google Tag Manager (der normale Client-Container) als auch GA4 sind davon betroffen (siehe links).

Wenn man dagegen beide Tools vom eigenen Server lädt und die Dateinamen umbenennt, werden sie von AdBlockern nicht mehr erkannt. (siehe rechts)

In der Praxis sieht es dann so aus. Der erste Eintrag ist der Google Tag Manager (Client-Container), der zweite GA4.

Im selbst aufgesetzten Tagging-Server

Um die Tools vom eigenen Tagging-Server zu laden, fügt man im Server-Container einen neuen “Client” hinzu und trägt die ID des Client-Containers ein:

Dann tauscht man die Domain, von welcher der Google Tag Manager geladen wird:

Die Dateien umzubenennen, ist leider deutlich mehr Aufwand und abhängig vom verwendeten Server (also z.B. Apache oder nginx).

Bei externen Anbietern

Bei Stape gibt es ein “PowerUp” namens Custom Loader. Man trägt die ID des WebContainers ein und erhält (rechts) den JavaScript-Code, durch den man den bestehenden GTM-Code ersetzt.

https://static.conversionboosting.com/wp-content/uploads/2025/02/stape-powerup.png

Cookies wiederherstellen

Der grobe Ablauf:

1. Es wird ein Master-Cookie vom Server gesetzt (der daher nicht von ITP betroffen ist)
2. In der Datenbank des Server-GTM werden die Werte der Cookies (wie _ga) gespeichert
3. Gibt es den Master-Cookie, aber nicht _ga, wird dieser wiederhergestellt

In Stape kann man das PowerUp “Cookie Keeper” aktivieren:

Wichtig: Man muss sich darum kümmern, dass der Master-Cookie (hier “_sbp” gesetzt wird. Für Shopify, WordPress und weitere Systeme gibt es fertige Plugins, die das übernehmen.)

URL-Parameter umschreiben

Ab Safari 17 werden unter anderem diese URL-Parameter in Inkognito-Fenstern (Private Browsing) entfernt.

• fbclid
• gclid
• msclkid

Die Folge: Conversions können nicht mehr der jeweiligen Anzeigen zugeordnet werden. Aktuell verwenden jedoch nur wenige Personen das Private Browsing. In der Zukunft kann sich dies schnell ändern.

Das Gleiche trifft auch auf utm-Parameter (für das Kampagnen-Tracking in GA4 denkbar) zu.

Die Lösung: Statt Landingpages wie “domain.de?utm_campaign=xyz” in den Tools (wie Google Ads) zu hinterlegen, verwendet man “domain.de?cb_c=xyz”.

Die Variable “page_location with utm instead of cb params” sieht dann so aus. “cb_c” wird hier durch “utm_campaign” ersetzt:

Für wen lohnt sich Server-seitiges Tagging?

Vor allem Websites mit hohen Werbeausgaben profitieren von besserer Attribution und dadurch besserer Kampagnen-Optimierung.

Je mehr Apple-Besucher es gibt, und desto länger die Sales-Zyklen sind, desto wichtiger ist Server-seitiges Tagging.