Server-Side Tracking Cookies? Gibt's nicht, das misst doch cookielos – so verkaufen es viele Anbieter.
Die Realität: Serverseitiges Tracking schafft Cookies nicht ab, es verlagert nur, wer sie schreibt. Und genau daran hängt, ob deine Attribution 400 Tage hält oder nach einer Woche bei null steht.
Nutzt Server-Side Tracking Cookies? Ja – und zwar diese
Sobald du einen Server-Container einsetzt, legt der GA4-Client von sich aus Cookies an. Zwei sind relevant:
- FPID – der First-Party Identifier. Kommt per Set-Cookie aus der HTTP-Antwort deines Servers, ist HttpOnly und damit für JavaScript unsichtbar. Er ersetzt die Rolle, die sonst _ga spielt.
- FPLC – ein Hash des FPID für Cross-Domain-Tracking. Der ist bewusst nicht HttpOnly, weil ihn JavaScript beim Domainwechsel lesen muss, und lebt nur rund 20 Stunden.
- _ga bleibt meistens trotzdem – in fast jedem Setup läuft der Browser-Tag weiter mit. Wer glaubt, er hätte den Client-Cookie losgeworden, hat ihn nur nicht mehr im Blick.
Heißt: Dein Consent-Banner muss diese Cookies weiterhin aufführen. Ein Setup, das serverseitig misst und im Cookie-Verzeichnis nur _ga stehen hat, ist schlicht falsch dokumentiert.
Der einzige echte Unterschied: wer den Cookie schreibt
Clientseitig schreibt JavaScript den Cookie über document.cookie. Serverseitig schreibt ihn dein Server über den Set-Cookie-Header. Klingt nach einer Formalie, ist aber der ganze Hebel:
Safaris Intelligent Tracking Prevention kappt per JavaScript gesetzte Cookies auf 7 Tage. Cookies aus dem HTTP-Header behalten ihre gesetzte Laufzeit – maximal 400 Tage, denn seit Chrome 104 deckelt Chrome jede Cookie-Laufzeit auf 400 Tage. Die „2 Jahre", die dir Anbieter versprechen, gibt es seit August 2022 nicht mehr.
Aus 7 Tagen werden 400. Das ist der Gewinn. Nicht Unsichtbarkeit, nicht Cookiefreiheit – Haltbarkeit. Warum das für die Datenqualität so viel ausmacht, habe ich im Überblick zu serverseitigem Tracking aufgeschlüsselt.
Die 7-Tage-Falle: Warum Safari deine Server-Side Tracking Cookies trotzdem kappt
Jetzt der Teil, den kaum ein Anbieter auf seiner Landingpage stehen hat. Apple hat zwei Regeln nachgeschoben, die den Vorteil kassieren:
- CNAME-Cloaking-Regel (seit 2020): Zeigt deine Tracking-Subdomain per CNAME auf einen Host, der aus Safaris Sicht ein Drittanbieter ist, werden auch die per HTTP-Header gesetzten Cookies auf 7 Tage gekappt. Genau der Trick, mit dem „First-Party" gebaut wird, fliegt auf.
- IP-Abgleich (seit Safari 16.4, April 2023): Antwortet der Server, der den Cookie setzt, aus einem anderen IP-Bereich als die besuchte Website, gilt dasselbe Limit – egal was in deinem Set-Cookie steht. In Apples Release Notes stand davon nichts, im WebKit-Quellcode schon.
Übersetzt in dein Setup: Deine Website liegt bei Hoster A, dein Server-Container läuft bei einem Managed-Anbieter oder in der Google Cloud – also Hoster B. Verschiedene IP-Bereiche. Willkommen zurück bei 7 Tagen.
| Wie der Cookie gesetzt wird | Laufzeit in Safari | Für JS & Extensions lesbar |
|---|---|---|
| JavaScript (document.cookie) | 7 Tage | ja |
| Server, hinter Third-Party-CNAME | 7 Tage | nein (HttpOnly) |
| Server, fremder IP-Bereich | 7 Tage | nein (HttpOnly) |
| Server, gleicher IP-Bereich wie die Website | bis 400 Tage | nein (HttpOnly) |
Nur die letzte Zeile ist das, wofür du bezahlst. Drei von vier Setups, die ich in Audits sehe, stehen in einer der oberen drei Zeilen – und niemand hat es gemerkt, weil das Tracking ja „funktioniert". Es funktioniert auch. Nur eben mit einer Woche Gedächtnis.
Was dich das kostet, wenn du nichts tust
Ein Cookie mit 7 Tagen Lebensdauer heißt: Jeder Safari-Nutzer, der nach acht Tagen wiederkommt, ist ein neuer Nutzer. Deine Kaufentscheidungsdauer wird künstlich gestaucht, dein Anteil an Direktzugriffen steigt, und jede Conversion mit längerem Vorlauf verliert ihre Quelle.
Bei Betrachtungszeiträumen über 7 Tage sitzt du also auf systematisch falschen Zahlen – und Smart Bidding lernt genau daraus. Verzerrte Daten führen zu falschen Entscheidungen und versenktem Budget, nicht zu ein bisschen Rauschen im Report.
Server-Side Tracking Cookies und die Einwilligung: nichts geschenkt
Ein zweiter hartnäckiger Irrtum: Weil der Server den Cookie setzt, brauche man keine Zustimmung mehr. Falsch.
§ 25 TDDDG knüpft die Einwilligungspflicht daran, dass Informationen auf der Endeinrichtung gespeichert oder von dort ausgelesen werden – nicht daran, wer das tut. Ein HttpOnly-Cookie vom Server liegt genauso auf dem Gerät wie einer aus JavaScript. Die Vorschrift greift sogar unabhängig davon, ob überhaupt ein Personenbezug besteht.
Wirklich cookielos bist du nur in einem Fall: wenn die Zustimmung fehlt und der Consent Mode auf Ablehnung schaltet (gcs=G100). Dann laufen cookielose Pings – weniger Daten, dafür sauber. Wie du das im Server-Container richtig verdrahtest, steht im Beitrag zu DSGVO-konformem Conversion-Tracking mit Consent Mode v2.
Was du jetzt prüfst – in 15 Minuten
- DNS-Eintrag deiner Tracking-Subdomain: CNAME auf einen fremden Host? Dann bist du in der 7-Tage-Klasse. A-Record auf eigene Infrastruktur ist die saubere Variante.
- IP-Bereich vergleichen: Löse Website-Domain und Tracking-Subdomain auf. Liegen die ersten beiden Blöcke auseinander, kappt Safari.
- Cookie-Laufzeit live messen: Entwicklertools, Reiter Anwendung, FPID ansehen. Steht dort ein Ablaufdatum in sieben Tagen statt in 400, hast du deine Antwort.
- Consent-Verzeichnis abgleichen: Stehen FPID und FPLC drin? Wenn nicht, nachtragen.
- Hosting-Entscheidung nachrechnen: Reverse Proxy über die eigene Infrastruktur statt separatem Host – im Vergleich der Server-Side-Tracking-Tools stehen die Anbieter samt Preisen.
Fazit: Cookielos ist ein Verkaufsargument, keine Technik
Server-Side Tracking Cookies sind real, sie sind gut – und sie sind fragiler, als der Verkaufsprospekt zugibt. Der Unterschied zwischen einem Setup mit 7 Tagen und einem mit 400 Tagen ist kein Tag im Container, sondern eine Zeile im DNS.
Prüf das, bevor du das nächste Quartal auf diesen Zahlen planst.
Häufige Fragen zu Server-Side Tracking Cookies
Nutzt Server-Side Tracking Cookies oder ist es cookielos?
Es nutzt Cookies. Der Server-Container setzt den FPID-Cookie per HTTP-Header und zusätzlich FPLC für Cross-Domain-Tracking. Cookielos läuft die Messung nur, wenn die Einwilligung fehlt und der Consent Mode auf cookielose Pings umschaltet.
Wie lange leben serverseitig gesetzte Cookies?
Maximal 400 Tage, denn seit Chrome 104 deckeln die Browser jede Cookie-Laufzeit auf diesen Wert. In Safari sind es trotzdem nur 7 Tage, wenn die Tracking-Subdomain per CNAME auf einen Drittanbieter zeigt oder der Server aus einem anderen IP-Bereich antwortet.
Was ist der FPID-Cookie?
FPID steht für First-Party Identifier. Dein Server schreibt ihn per Set-Cookie-Header, er ist HttpOnly und damit für JavaScript und Browser-Erweiterungen nicht lesbar. Er übernimmt die Rolle, die im clientseitigen Setup der _ga-Cookie hat.
Braucht Server-Side Tracking eine Einwilligung?
Ja. § 25 TDDDG stellt auf das Speichern von Informationen auf der Endeinrichtung ab, nicht darauf, wer den Cookie setzt. Ein serverseitig gesetzter Cookie liegt genauso auf dem Gerät des Nutzers und ist damit einwilligungspflichtig.
Wie erkenne ich, ob Safari meine Cookies kappt?
Öffne die Entwicklertools im Reiter Anwendung und sieh dir das Ablaufdatum des FPID-Cookies an. Steht dort ein Datum in sieben Tagen statt in gut 400 Tagen, greift eine der ITP-Regeln. Prüfe dann den DNS-Eintrag deiner Tracking-Subdomain.
Willst du wissen, wie lange deine Cookies wirklich leben?
Setup prüfen lassen