Was serverseitiges Tracking behebt und was es unberührt lässt

Was ist serverseitiges Tracking?

Eine Website betreibt serverseitiges Tracking, wenn der Browser ein Event an einen Server sendet, den die Website kontrolliert, und dieser Server das Event an Analytics- und Werbeplattformen weiterleitet, statt dass der Browser das übernimmt. Verlagert wird die ausgehende Strecke: Payload, Kennungen und Zielliste liegen in einer Infrastruktur, die Sie prüfen und protokollieren können. Listen Sie die Events auf, die Ihr Backend selbst bestätigen kann, denn diese profitieren am meisten vom Umzug.

Die Alternative ist clientseitiges Tracking, bei dem ein Anbieter-Skript direkt mit dem Endpunkt des Anbieters spricht. Der Tausch lautet Kontrolle gegen Sichtbarkeit: Ihr Server sieht eine verifizierte Bestellung, aber clientseitige und serverseitige Analytics unterscheiden sich darin, ob jemand den Rage Click sieht, der Ihr Backend nie erreicht hat.

Warum haben Teams das Tracking auf den Server verlagert?

Browser haben die Lebensdauer der Kennungen verkürzt, von denen clientseitige Tags abhängen. WebKits Intelligent Tracking Prevention 2.1, veröffentlicht am 21. Februar 2019, legte fest, dass "all persistent client-side cookies, i.e. persistent cookies created through document.cookie, are capped to a seven day expiry". WebKit legte am 24. März 2020 nach und blockierte Third-Party-Cookies in Safari 13.1 und iOS 13.4 vollständig, mit der Aussage, dass "cookies for cross-site resources are now blocked by default across the board". Dieses 7-Tage-Cookie-Limit kappt jede Messung wiederkehrender Besucher und jede Attribution, die ihre ID per JavaScript speichert.

Chrome ging den umgekehrten Weg. Google gab am 22. April 2025 bekannt, es habe "made the decision to maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies". Third-Party-Cookies funktionieren im Standard-Chrome weiterhin, der Druck kommt also von Safari, Content-Blockern und Einwilligungsquoten, nicht von einem einzelnen Abschaltdatum.

Wie funktioniert ein Setup für serverseitiges Tracking?

Zwei Bausteine erledigen die Arbeit: ein Tagging-Server, der Events empfängt, und eine Ziel-API, die sie annimmt. Googles serverseitiger Tag Manager betreibt den Tagging-Server auf Google Cloud Run oder App Engine oder auf "a platform of your choice" und nutzt "the same tag, trigger, and variable model" wie der Web-Container. Ein Client im Server-Container übernimmt eine eingehende HTTP-Anfrage und macht daraus ein Event-Objekt, das die Tags des Containers weiterleiten.

Metas Conversions API ist ein solches Ziel, mit oder ohne Tag Manager. Meta beschreibt sie als Verbindung, die Marketingdaten "from an advertiser's server, website platform, mobile app, or CRM to Meta systems" überträgt, und erklärt, dass "server events are linked to a dataset ID and are processed like events sent using the Meta Pixel". Prüfen Sie zuerst Metas Parameterregeln, denn ein abgelehntes Feld wird zu einem stillschweigend verlorenen Match.

Stellt serverseitiges Tracking die Cookie-Laufzeiten in Safari wieder her?

Nicht, wenn der Tagging-Server hinter einem CNAME steht. WebKit kündigte am 12. November 2020 an, dass "ITP now caps the expiry of cookies set in so-called third-party CNAME-cloaked HTTP responses to 7 days", womit ein per CNAME eingebundener Anbieter-Endpunkt unter dieselben sieben Tage fällt wie ein JavaScript-Cookie. Ein Tagging-Server auf Ihrer eigenen Subdomain, der sein Cookie mit einem Set-Cookie-Header statt über document.cookie schreibt, liegt außerhalb der ITP-2.1-Grenze, und genau dieser Mechanismus steckt hinter den meisten Aussagen zum First-Party-Cookie-Tracking.

Browser-Regel	Quelle und Datum	Was ein Tagging-Server ändert
Sieben-Tage-Grenze für Cookies aus document.cookie	WebKit ITP 2.1, 21. Februar 2019	Der Server schreibt das Cookie mit Set-Cookie, also greift die Grenze nicht
Alle Third-Party-Cookies standardmäßig blockiert	WebKit, 24. März 2020	Nichts. Das Anbieter-Cookie ist so oder so weg
Sieben-Tage-Grenze für Cookies aus CNAME-getarnten Antworten	WebKit, 12. November 2020	Nichts, wenn ein CNAME auf einen Anbieter zeigt. Hosten Sie den Endpunkt stattdessen selbst
Wahl bei Third-Party-Cookies bleibt beim Nutzer	Google, 22. April 2025	Nichts. Chrome erlaubt sie standardmäßig weiterhin

Macht serverseitiges Tracking die Einwilligung überflüssig?

Nein. Nach Artikel 5 Absatz 3 der ePrivacy-Richtlinie ist "die Speicherung von Informationen oder der Zugriff auf Informationen, die bereits im Endgerät eines Teilnehmers oder Nutzers gespeichert sind" nur mit Einwilligung gestattet, mit Ausnahmen für die Durchführung einer Übertragung und für das, was "unbedingt erforderlich" ist, um den gewünschten Dienst bereitzustellen. Die Regel benennt den Lese- oder Schreibvorgang auf dem Gerät, nicht den Hostnamen, der ihn ausführt. Wenn Sie den Weiterleitungsschritt auf Ihren eigenen Server verlegen, bleibt der Lesevorgang also dort, wo er war: auf dem Gerät. Behalten Sie die Ebene für Tracking-Einwilligung bei und behandeln Sie den Tagging-Server als Änderung am Transportweg.

Die Frage nach der GDPR liegt obendrauf. Sobald ein Event Ihren Server erreicht, verarbeiten Sie personenbezogene Daten, und dafür brauchen Sie eine Rechtsgrundlage nach Artikel 6 und einen rechtmäßigen Weg für jede Übermittlung außerhalb der EU. Teams mit Consent Mode behalten nach dem Umzug dieselbe Verkabelung, weil der Einwilligungsstatus mit dem Event zu jedem Ziel reist.

Wie verhindern Sie Doppelzählungen, wenn Browser und Server beide feuern?

Senden Sie auf beiden Kopien dieselbe ID und lassen Sie die Plattform das Duplikat verwerfen. Metas Dokumentation zur Deduplizierung sagt, dass "a Meta Pixel's eventID must match the Conversion API's event_id" und "a Meta Pixel's event must match the Conversion API's event_name", und dass Events "are only deduplicated if they are received within 48 hours" nach dem ersten Event mit dieser ID.

reported conversions = browser events + server events - matched duplicates

Nehmen Sie einen Tag mit 1.000 abgeschlossenen Checkouts. Der Pixel erreicht Meta bei 700 davon, der Server sendet alle 1.000, und jedes Server-Event trägt die event_id, die sein Browser-Zwilling verwendet hat. Die gematchten Duplikate belaufen sich auf 700, also ergeben die gemeldeten Conversions 700 + 1.000 - 700 = 1.000, die echte Zahl. Fehlt event_id im Server-Payload, fallen die gematchten Duplikate auf 0, und Meta meldet 700 + 1.000 = 1.700 Käufe bei 1.000 Bestellungen, eine Überzählung um 70 Prozent, die jede Cost-per-Acquisition-Kennzahl erbt.

Ein Event, zwei Zählungen

Browser-Events (Pixel)700

Server-Events1.000

Abgeglichene Duplikate700

Gemeldete Conversions mit event_id1.000

Gemeldete Conversions ohne event_id1.700

Welche Events gehören auf den Server und welche bleiben im Browser?

Legen Sie Events, die Ihr Backend verifizieren kann, auf den Server und lassen Sie Verhaltenssignale im Browser.

Event	Wohin es gehört	Warum
Kauf, Erstattung, Abo-Änderung	Server	Der Zahlungsdienstleister bestätigt es, und der Browser kann vorher geschlossen werden
Registrierung, Trial-Start, Plan-Upgrade	Server	Ihre Datenbank ist der Beleg, also kann eine blockierte Anfrage ihn nicht löschen
Pageview und clientseitiger Routenwechsel	Browser	Der Server sieht nie eine Navigation, nach der er nicht gefragt wurde
Rage Click, Dead Click, Scrolltiefe	Browser	Diese existieren nur als Interaktionen im DOM
JavaScript-Fehler und kaputter Flow	Browser	Der Fehler ist der Grund, warum keine Anfrage den Server erreicht hat

Braucht Privacy-First-Analytics einen Tagging-Server?

Nein. Ein Tagging-Server repariert einen Cookie-basierten Stack: Er siedelt Kennungen um, die Browser immer weiter verkürzen, und leitet Aufrufe an Hostnamen um, die Filterlisten immer wieder aufführen. Analytics, die ohne diese Kennungen gebaut ist, hat nichts umzusiedeln. Flowsery ist cookiefrei und in der EU gehostet, liefert ein einziges Skript unter 10 KB und verzichtet auf Data Sampling, sodass Privacy-First-Analytics ohne vorgeschalteten Proxy läuft, zusammen mit Umsatzattribution aus Stripe, Paddle, Polar, Lemon Squeezy und Shopify.

Betreiben Sie einen Tagging-Server, wenn eine Werbeplattform Server-Events braucht, die sie von der Seite nicht bekommt. Die Messung Ihres eigenen Produkts ist eine separate Entscheidung.

Häufig gestellte Fragen

Ist serverseitiges Tracking dasselbe wie serverseitiges Rendering?

Nein. Serverseitiges Rendering baut HTML auf dem Server, bevor der Browser es darstellt, und serverseitiges Tracking leitet Analytics-Events von einem Server weiter, den Sie kontrollieren. Beide teilen sich den Ort und sonst nichts. Eine Website kann jede Seite auf dem Server rendern und ihre Events trotzdem direkt aus dem Browser senden.

Funktioniert serverseitiges Tracking ohne JavaScript auf der Seite?

Teilweise. Events, die Ihrem Backend gehören, etwa eine abgeschlossene Zahlung oder ein eingehender Stripe-Webhook, brauchen keinen Browser-Code. Events, die beschreiben, was jemand auf einer Seite getan hat, brauchen ein Skript, das sie beobachtet und an Ihren Endpunkt sendet.

Hebelt ein Tagging-Server Content-Blocker aus?

Er ändert, worauf der Blocker anspringt. Filterlisten führen bekannte Analytics- und Werbe-Hostnamen auf, und eine Anfrage an Ihre eigene Subdomain fehlt in diesen Listen. Blocker prüfen aber auch Anfragepfade und Skript-Dateinamen, also wird ein Anbieterpfad, den Sie unverändert auf Ihre Domain kopieren, trotzdem erkannt.

Welche Kundendaten kann ich über Metas Conversions API senden?

Meta akzeptiert Kontakt- und demografische Felder, darunter E-Mail, Telefon, Vorname, Nachname, Geburtsdatum, Geschlecht, Stadt, Bundesland und Postleitzahl, und verlangt dafür SHA256-Hashing. Meta erklärt, dass client_ip_address und client_user_agent "must never be hashed". Eine gehashte E-Mail identifiziert eine Person weiterhin für jeden, der denselben Hash besitzt, also brauchen Sie vor dem Senden eine Rechtsgrundlage.

Brauche ich den Meta Pixel noch, wenn ich die Conversions API nutze?

Metas Anleitung zur Deduplizierung geht davon aus, dass beide laufen, denn sie gleicht die eventID des Pixels mit der event_id der Conversions API ab. Wenn Sie die Browserseite weglassen, fallen die Browser-ID fbp und die Klick-ID fbc weg, die der Pixel setzt. Betreiben Sie beide und deduplizieren Sie.

Verringert serverseitiges Tracking das Seitengewicht?

Es spart Gewicht, wenn Sie mehrere Anbieter-Skripte durch einen Aufruf an Ihren eigenen Endpunkt ersetzen, und es fügt Gewicht hinzu, wenn Sie jedes Anbieter-Tag behalten und seine Events auf dem Server duplizieren. Google nennt "improve page performance" unter den Gründen für serverseitiges Tagging. Messen Sie die Seite vorher und nachher, statt anzunehmen, dass das Setup diesen Effekt geliefert hat.

Wo kann ich einen serverseitigen Tag Manager-Container betreiben?

Googles serverseitiger Tag Manager läuft auf Google Cloud Run, auf App Engine oder auf "einer Plattform Ihrer Wahl". Der Container übernimmt "dasselbe Tag-, Trigger- und Variablenmodell" wie der Web-Container, sodass bestehende Tag-Logik weiterverwendet werden kann. Die Wahl des Hostings ändert nichts daran, was intern passiert, denn ein Client übernimmt weiterhin die eingehende Anfrage und wandelt sie in ein Event-Objekt um.

Wird Chrome Cookies von Drittanbietern genauso einschränken wie Safari?

Nicht nach dem Zeitplan, den Safari vorgegeben hat. Google kündigte am 22. April 2025 an, den aktuellen Ansatz zur Cookie-Wahl von Drittanbietern in Chrome beizubehalten und keinen neuen eigenständigen Hinweis dafür einzuführen. Cookies von Drittanbietern funktionieren in Chrome standardmäßig weiterhin, sodass der Druck, Tracking auf den Server zu verlagern, von Safari, Content-Blockern und Consent-Raten ausgeht und nicht von Chrome.

Wie viel Zeit bleibt mir, das passende Server-Event für die Deduplizierung zu senden?

Meta dedupliziert Events nur, wenn sie innerhalb von 48 Stunden nach dem ersten Event mit dieser event_id eintreffen. Wird dieses Fenster verpasst, zählen sowohl die Browser- als auch die Server-Kopie derselben Conversion, dieselbe Überzählung, die eine fehlende event_id verursacht. Senden Sie Pixel- und Serveranfrage nah genug beieinander, damit beide innerhalb der 48-Stunden-Zuordnung liegen.

Brauche ich einen Tag Manager, um Metas Conversions API zu nutzen?

Ein Tag Manager ist nicht erforderlich. Meta beschreibt die Conversions API als Verbindung, die Marketingdaten "vom Server, der Website-Plattform, der mobilen App oder dem CRM eines Werbetreibenden zu Meta-Systemen" überträgt, und eine einzelne Integration kann sie direkt aufrufen. Server-Events, die auf diesem Weg gesendet werden, sind weiterhin "mit einer Dataset-ID verknüpft und werden wie über den Meta Pixel gesendete Events verarbeitet".