Server-Side Tracking: die Vorteile im Überblick

Was Server-Side Tracking wirklich ändert

Ohne serverseitiges Tagging lädt jedes Tool sein eigenes Skript im Browser des Besuchers und schickt die Daten direkt an den Anbieter. Der Browser entscheidet dabei, was durchgeht: Adblocker, Intelligent Tracking Prevention und Cookie-Laufzeiten greifen genau an dieser Stelle.

Mit serverseitigem Tagging geht nur noch ein Treffer an einen Endpunkt auf Ihrer eigenen Domain. Von dort verteilt ein zweiter Container die Daten an die Zielsysteme. Sie bestimmen, welches Feld welchen Anbieter erreicht, und Sie setzen die Cookies selbst.

Zwei Container Serverseitiges Tagging ersetzt Ihren Web-Container nicht. Sie betreiben danach zwei: den bekannten im Browser und einen zweiten auf dem Server, der die Verteilung übernimmt.

Die Vorteile im Überblick

Die folgende Gegenüberstellung zeigt, was sich durch die Umstellung ändert. Die Spalte rechts beschreibt den Zustand nach der Umstellung, nicht ein Versprechen: Jeder Punkt hängt davon ab, dass der Aufbau sauber gemacht wird.

Bereich Ohne Server-Side Mit Server-Side

Cookie-Laufzeit Safari kürzt per Skript gesetzte Cookies auf sieben Tage Cookie kommt vom Server, die Verkürzung greift nicht

Blockierung Listen blockieren bekannte Skript-Adressen im Browser Anfrage geht an Ihre eigene Domain, nicht an einen Anbieter

Ladezeit Jedes Tool lädt ein eigenes Skript im Browser Ein Treffer geht raus, die Verteilung passiert auf dem Server

Datenhoheit Der Anbieter erhält alles, was im Browser verfügbar ist Sie entscheiden je Ziel, welches Feld überhaupt weitergeht

IP-Adresse Geht mit jedem Treffer an den Anbieter Kann vor der Weitergabe gekürzt oder entfernt werden

Kosten Keine eigenen Serverkosten Laufender Betrieb, je nach Volumen ab etwa 20 Euro im Monat

Schritt 1 bis 6: der Aufbau

Subdomain oder Subfolder entscheiden Der Endpunkt muss aus Sicht des Browsers zur eigenen Website gehören. Eine Subdomain wie sgtm.ihre-domain.de reicht dafür in den meisten Fällen. Ein Subfolder über einen Reverse Proxy ist technisch aufwändiger, wird aber von Safari als eindeutig gleiche Herkunft behandelt.

Server-Container anlegen Im Google Tag Manager einen neuen Container vom Typ Server erstellen. Sie erhalten einen Container-Konfigurationsschlüssel, den die spätere Umgebung braucht.

Tagging-Server bereitstellen Google schlägt Cloud Run vor, es geht aber jeder Host, der das Container-Image ausführen kann. Planen Sie mindestens zwei Instanzen ein, sonst gehen bei Lastspitzen Treffer verloren.

Eigene Domain auf den Server legen Die gewählte Subdomain per DNS auf den Tagging-Server zeigen lassen und ein Zertifikat einrichten. Erst wenn der Endpunkt über https erreichbar ist, gilt er als erste Partei.

Client und Tag im Server-Container Im Server-Container den GA4-Client aktivieren. Er nimmt die eingehenden Treffer entgegen. Dahinter kommt ein GA4-Tag, das die Daten an Ihre Property weitergibt. Weitere Ziele kommen später als eigene Tags dazu.

Gegenprobe in beiden Vorschaumodi Web-Container und Server-Container haben getrennte Vorschaumodi. Prüfen Sie beide gleichzeitig: Im Web sehen Sie, dass der Treffer an Ihren Endpunkt geht, im Server, dass der Client ihn annimmt und das Tag auslöst.

Die Umstellung im Web-Container

Der Web-Container bleibt bestehen, er schickt seine Treffer nur woanders hin. Dafür bekommt das GA4-Konfigurationstag ein zusätzliches Feld. Solange dieses Feld fehlt, geht alles weiterhin direkt an Google, unabhängig davon, ob der Server-Container läuft.

// Web-Container, GA4-Konfigurationstag // unter "Zu setzende Felder" eintragen: server_container_url = https://sgtm.ihre-domain.de // Server-Container, GA4-Client: // Standardpfade aktivieren, damit /g/collect // angenommen und an das GA4-Tag weitergegeben wird. // Danach beide Vorschaumodi parallel pruefen.

Stellen Sie zuerst eine einzelne Property um, nicht den gesamten Container. So bleibt eine unveränderte Vergleichsbasis erhalten, solange Sie messen, ob die Umstellung tatsächlich mehr Treffer liefert.

Rechnen Sie mit einer Abweichung nach oben. Mehr erfasste Sitzungen bedeuten nicht, dass vorher falsch gemessen wurde, sondern dass vorher etwas fehlte. Halten Sie den Umstellungstag im Reporting fest, sonst wirkt der Sprung später wie ein Datenfehler.

Was Server-Side nicht löst

Serverseitiges Tagging ist keine Umgehung der Einwilligung. Ob ein Treffer gesendet werden darf, entscheidet sich vor dem Versand im Browser, nicht auf dem Server. Wer ohne Einwilligung serverseitig misst, verlagert nur den Ort des Verstoßes. Ebenso verschwindet Adblocking nicht vollständig: Wird bereits der Web-Container blockiert, entsteht gar kein Treffer, den der Server verarbeiten könnte. Und der Betrieb kostet Geld und Aufmerksamkeit, weil ein ausgefallener Tagging-Server unbemerkt Daten verliert.

Häufige Fragen

Brauche ich trotzdem ein Consent-Banner?

Ja. Die Einwilligung bezieht sich auf die Verarbeitung und auf das Speichern von Informationen im Endgerät, nicht auf den technischen Weg der Übertragung. Serverseitiges Tagging ändert daran nichts.

Subdomain oder Subfolder?

Die Subdomain ist deutlich schneller eingerichtet und reicht meist aus. Der Subfolder über einen Reverse Proxy gilt als gleiche Herkunft und ist damit robuster gegen künftige Browser-Beschränkungen, erfordert aber Zugriff auf die Serverkonfiguration.

Wie viel mehr Daten sind realistisch?

Das hängt vom Anteil der Safari- und Adblocker-Nutzer ab und schwankt je nach Zielgruppe stark. Messen Sie es selbst, indem Sie eine Property umstellen und eine unverändert lassen. Pauschale Prozentangaben aus Anbieter-Material sind wenig wert.

Lohnt sich das für kleine Websites?

Meist nicht. Betrieb, Überwachung und Fehlersuche kosten dauerhaft Zeit. Unterhalb weniger tausend Sitzungen im Monat steht der Aufwand selten im Verhältnis zum gewonnenen Datenanteil.