Server-Side Tracking

Wer im Browser misst, verlässt sich auf viele Dinge gleichzeitig: dass das Skript lädt, dass kein Blocker es abfängt, dass der Browser das Cookie behält und dass der Dienst die Anfrage annimmt. Fällt eines davon aus, fehlt das Ereignis. Wie viele fehlen, merkt man meist erst, wenn die Bestellungen im Analyse-Tool nicht mehr zu denen im Shop passen.

Beim Server-Side Tracking schickt der Browser seine Ereignisse an einen Server unter der eigenen Domain. Dort werden sie geprüft, gekürzt oder ergänzt und an die Systeme weitergegeben, die sie brauchen. Wir setzen das für Analyse und Business Intelligence ein. Werbeplattformen können ein Ziel sein, der Grund für solche Projekte sind sie bei uns nicht.

Wann sich ein eigener Server lohnt

Der Aufwand lohnt sich, wenn die Zahlen im Analyse-Tool spürbar von Shop oder CRM abweichen, wenn dasselbe Ereignis an mehrere Ziele gehen soll oder wenn personenbezogene Felder vor der Weitergabe entfernt werden müssen. Auch eine Seite, auf der ein Dutzend Dienste eigene Skripte laden, ist ein guter Kandidat.

Für eine kleine Website mit einem einzigen Analyse-Tool ist ein eigener Server dagegen meist zu viel. Dort bringt ein sauber aufgesetztes Browser-Tracking mit klarem Messkonzept mehr.

Eine Einwilligung ersetzt der Server nicht. Der Consent-Status wird mit jedem Ereignis übertragen und gilt auf dem Server genauso wie im Browser. Wie das technisch funktioniert, beschreiben wir unter Consent-Tracking.

Was Browser heute blockieren

Safari ist am strengsten. Die Intelligent Tracking Prevention blockiert Drittanbieter-Cookies vollständig und löscht Cookies, die per JavaScript gesetzt wurden, nach sieben Tagen ohne Besuch. Selbst Cookies, die ein Server setzt, begrenzt Safari auf sieben Tage, wenn es die Anfrage als verdeckten Drittanbieter-Zugriff einstuft, etwa weil die Subdomain auf fremde Infrastruktur zeigt. Genau das passiert, wenn ein Tracking-Server per CNAME bei einem externen Hoster eingebunden wird. Die Domain-Anbindung planen wir deshalb von Anfang an mit.

Firefox blockiert bekannte Tracker und trennt Cookies mit der Total Cookie Protection nach Websites. Chrome bleibt bei Drittanbieter-Cookies: Google hat den Plan aufgegeben, sie abzuschalten, und im Oktober 2025 mehrere Privacy-Sandbox-Technologien eingestellt. Werbeblocker greifen unabhängig vom Browser und erkennen vor allem bekannte Skripte und Adressen. Anfragen an die eigene Domain fangen sie seltener ab, aber nicht ausnahmslos.

Ein Server unter eigener Domain schließt also einen Teil der Lücken. Was Besuchende ablehnen oder bewusst blockieren, bleibt abgelehnt.

Wie ein Server-Container arbeitet

Am häufigsten setzen wir den Server-Container des Google Tag Managers ein. Der Web-Container auf der Website schickt seine Ereignisse nicht mehr an viele Dienste, sondern nur noch an den Tracking-Server. Dort nimmt ein Client die Anfrage an und macht daraus ein Ereignis mit Parametern. Transformationen legen fest, welche Parameter welche Tags überhaupt zu sehen bekommen, und die Tags senden das Ergebnis an die Ziele.

Andere Anbieter und Eigenentwicklungen funktionieren nach demselben Prinzip. Google bietet außerdem das Google tag gateway an, das Google-Tags über die eigene Domain ausliefert. Das ist schneller eingerichtet, filtert aber nichts und bedient nur Google-Dienste.

Was auf dem Server mit den Daten passiert

Der eigentliche Gewinn liegt darin, dass Daten bearbeitet werden, bevor sie das Unternehmen verlassen. Die IP-Adresse wird gekürzt. E-Mail-Adressen, die versehentlich in URLs oder Formularfeldern landen, werden entfernt. Jedes Ziel bekommt nur die Parameter, die es braucht, und Dienste ohne eigene Consent-Logik erhalten Ereignisse nur, wenn eine Einwilligung vorliegt.

Umgekehrt kann der Server Ereignisse ergänzen, etwa um die Produktkategorie oder den Deckungsbeitrag einer Bestellung. Das sind Werte, die der Browser nicht kennt und auch nicht kennen soll.

Dasselbe Ereignis geht dann an das Analyse-Tool und an das Data Warehouse. Dafür gibt es zwei Wege: ein Tag, das direkt in BigQuery schreibt, oder eine eigene Schnittstelle, von der eine Datenpipeline die Ereignisse weiterlädt. Der zweite Weg ist aufwendiger, hält das Warehouse aber unabhängig vom Tag Manager. Im Warehouse werden die Ereignisse mit Bestell- und Kundendaten verbunden, und Dashboards rechnen mit denselben Daten wie das Analyse-Tool.

Hosting und laufende Kosten

Wo der Server läuft, hängt vor allem davon ab, wer ihn später betreut. Wer ohnehin in der Google Cloud arbeitet, nimmt meist Cloud Run, das Google für den Server-Container dokumentiert. Google empfiehlt dort mindestens zwei Instanzen, damit ein Ausfall keine Daten kostet, und das bestimmt die Grundkosten. Ein spezialisierter Hoster nimmt den Betrieb ab, rechnet nach Anfragevolumen ab und ist dafür ein weiterer Dienstleister im Datenfluss. Eigene Container in der vorhandenen Cloud oder im Rechenzentrum geben die meiste Kontrolle über Standort und Netzwerk, setzen aber Erfahrung im Betrieb voraus.

Die Kosten wachsen mit dem Traffic und der Zahl der Instanzen. Eine Obergrenze für die Skalierung verhindert Überraschungen. Zum Betrieb gehört ein Monitoring, das neben Fehlern und Antwortzeiten auch die Zahl der Ereignisse mit dem Vortag vergleicht. Ein Server, der fehlerfrei läuft und trotzdem nur die Hälfte der Bestellungen weitergibt, fällt sonst erst im Monatsbericht auf.

Umstellen ohne Datenbruch

Wir stellen nicht in einem Schritt um. Das Browser-Tracking bleibt zunächst aktiv, der Server läuft zusätzlich, und wir vergleichen Seitenaufrufe, Bestellungen und Umsätze aus beiden Wegen. Die meisten Unterschiede lassen sich erklären: durch Blocker, fehlende Einwilligungen oder Ereignisse, die doppelt ankommen, weil sie im Browser und auf dem Server gezählt werden. Erst wenn das geklärt ist, schalten wir das alte Setup ab.

Am häufigsten scheitern solche Umstellungen daran, dass nur der Weg der Daten verlegt wird. Unklare Ereignisnamen und fehlende Definitionen ziehen dann einfach mit auf den Server um. Deshalb schauen wir zuerst auf das Messkonzept, auch wenn der Auftrag eigentlich nur „Server-Side Tracking einrichten“ lautet.