Server-seitiges Tracking: Warum Meta und Google nicht alle Käufe sehen

Warum Käufe in Meta und Google fehlen

Ein klassisches Pixel läuft im Browser. Es meldet einen Kauf nur, wenn das Skript auf der Bestellbestätigungsseite lädt, ein Cookie gesetzt werden darf und die Anfrage den Browser verlässt. An jeder dieser Stellen gehen Daten verloren. Vier Ursachen sind dabei besonders relevant.

Apple App Tracking Transparency

Seit iOS 14.5 müssen Apps Nutzer über das AppTrackingTransparency-Framework um Erlaubnis fragen, bevor sie sie app-übergreifend verfolgen oder die Werbe-ID des Geräts auslesen. Ohne Erlaubnis besteht die Werbe-ID nur aus Nullen. Apple setzt diese Regel laut Apple Developer News seit dem 26. April 2021 für alle Apps durch. Das betrifft vor allem Klicks aus der Facebook- und Instagram-App heraus, also genau dort, wo viele Shops ihre Kunden gewinnen.

Intelligent Tracking Prevention in Safari

Safari blockiert Third-Party-Cookies standardmäßig und ohne Ausnahme. Zusätzlich löscht die Intelligent Tracking Prevention (ITP) alle per JavaScript erstellten Cookies und anderen skriptbeschreibbaren Speicher nach sieben Tagen ohne Interaktion mit der Website. Erkennt Safari eine Link-Dekoration, etwa angehängte Klick-IDs, wird die Laufzeit solcher Cookies auf der Landingpage auf 24 Stunden begrenzt. So beschreibt es WebKit selbst. Wer am Montag auf eine Anzeige klickt und am nächsten Montag kauft, wird dann oft nicht mehr der Anzeige zugeordnet.

Adblocker

Browser-Adblocker unterdrücken häufig die Anfragen an bekannte Tracking-Domains. Shopify weist in seiner Hilfe zur Meta-Datenfreigabe ausdrücklich darauf hin, dass reines Pixel-Tracking durch Adblocker verhindert werden kann.

Abgelehnte Einwilligungen

Für Besucher im EWR dürfen Marketing-Cookies nur nach Einwilligung gesetzt werden. Wer im Banner ablehnt, erscheint im Pixel nicht. Diese Lücke ist rechtlich gewollt und lässt sich nicht technisch „reparieren“. Dazu weiter unten mehr.

Was serverseitiges Tracking leistet

Beim serverseitigen Tracking meldet nicht nur der Browser, sondern auch Ihr Server oder Ihr Shopsystem den Kauf direkt an die Werbeplattform. Die Bestellung liegt im Shop ohnehin vor, mit Bestellnummer, Wert und Kundendaten. Diese Information wird von Server zu Server übertragen und kann vom Browser des Kunden nicht blockiert werden.

Meta Conversions API

Meta empfiehlt in den Best Practices zur Conversions API, die API zusätzlich zum Pixel einzusetzen. Meta nennt das ein „redundantes Setup“: Pixel und Server senden dasselbe Ereignis, Meta führt beide zusammen. Wichtig ist, Ereignisse möglichst zeitnah zu senden, weil Meta darauf hinweist, dass Echtzeitdaten die Kampagnenergebnisse verbessern können.

Google Enhanced Conversions und serverseitiges Tagging

Google verfolgt zwei Ansätze. Erweiterte Conversions (Enhanced Conversions) ergänzen das bestehende Conversion-Tracking um selbst erhobene Kundendaten wie E-Mail-Adresse, Name, Adresse oder Telefonnummer. Diese werden vor dem Versand mit dem Einweg-Hash-Algorithmus SHA256 verschlüsselt. Google gleicht sie mit angemeldeten Google-Nutzern ab und kann so Conversions zuordnen, die ohne Cookie verloren gingen.

Das serverseitige Tagging im Google Tag Manager verlagert die Tag-Verarbeitung auf einen Server, den Sie selbst kontrollieren. Laut Google haben nur Sie Zugriff auf die Daten, bis Sie sie weiterleiten, und Sie bestimmen, welche Felder an welche Plattform gehen. Google empfiehlt ausdrücklich, den Server auf einer eigenen Subdomain (First-Party-Kontext) zu betreiben.

Deduplizierung und Event Match Quality

Wer Pixel und Server parallel betreibt, muss verhindern, dass ein Kauf doppelt gezählt wird. Sonst wirkt Ihr ROAS plötzlich besser, als er ist.

Deduplizierung über event_id

Meta beschreibt in der Dokumentation zur Deduplizierung zwei Wege. Empfohlen ist die Kombination aus event_name und event_id: Der Pixel sendet den Kauf mit einer eventID, der Server mit derselben event_id. Meta behält dann in der Regel das zuerst empfangene Ereignis. Dedupliziert wird nur, wenn beide Ereignisse innerhalb von 48 Stunden eintreffen. Als ID eignet sich die Bestell- oder Transaktionsnummer, weil sie im Browser und im Backend identisch vorliegt. Die Alternative über fbp oder external_id funktioniert nach Meta im Allgemeinen nur, wenn das Browser-Ereignis zuerst ankommt.

Event Match Quality

Ein Server-Ereignis nützt nur, wenn Meta es einem Konto zuordnen kann. Die Event Match Quality (EMQ) bewertet auf einer Skala bis 10, wie gut die mitgesendeten Kundeninformationen dafür geeignet sind. Nur zugeordnete Ereignisse fließen laut Meta in Attribution und Auslieferungsoptimierung ein. Zusätzliche Parameter wie E-Mail-Adresse, Telefonnummer, Name und IP-Adresse können die EMQ erhöhen, ebenso die Cookie-Werte fbp und fbc sowie eine external_id. Personenbezogene Kontaktdaten sollten Sie gehasht übertragen. Die EMQ wird aktuell nur für Web-Ereignisse ausgewiesen.

Consent Mode v2: was im EWR gilt

Google hat im November 2023 zwei zusätzliche Parameter eingeführt: ad_user_data (Einwilligung, Nutzerdaten zu Werbezwecken an Google zu senden) und ad_personalization (Einwilligung in personalisierte Werbung). Laut Google-Hilfe zum Consent Mode v2 müssen Werbetreibende, die Mess-, Personalisierungs- und Remarketing-Funktionen weiter nutzen wollen, die Einwilligung von Nutzern im EWR einholen und die Signale an Google übermitteln. Seit März 2024 wirkt sich Googles EU-Richtlinie zur Nutzereinwilligung auch auf Messfunktionen aus. Es handelt sich um eine Vorgabe von Google, nicht um ein Gesetz. Ohne korrekte Signale fallen aber Remarketing-Listen und Teile der Messung weg.

Google unterscheidet zwei Varianten. Beim Basic Consent Mode laden Google-Tags erst nach einer Interaktion mit dem Banner, ohne Einwilligung fließen keine Daten. Beim Advanced Consent Mode laden die Tags sofort und senden bei Ablehnung cookielose Pings. Daraus kann Google ein werbetreibendenspezifisches Modell für fehlende Conversions erstellen, sofern ein Mindest-Datenvolumen erreicht wird. So steht es in der Google-Ads-Hilfe zum Consent Mode.

DSGVO und TDDDG: was serverseitiges Tracking nicht ändert

Hinweis: Dieser Abschnitt gibt einen Überblick und ist keine Rechtsberatung. Klären Sie Ihr Setup mit Ihrem Datenschutzbeauftragten oder einer Kanzlei.

Serverseitiges Tracking ist kein Weg, Einwilligungen zu umgehen. § 25 Abs. 1 TDDDG erlaubt das Speichern von Informationen auf dem Endgerät oder den Zugriff darauf nur mit Einwilligung, sofern keine Ausnahme greift. Die Ausnahme nach Abs. 2 Nr. 2 gilt nur für Vorgänge, die für einen ausdrücklich gewünschten Dienst unbedingt erforderlich sind. Werbe-Cookies wie fbp gehören typischerweise nicht dazu. Zusätzlich braucht die Übermittlung personenbezogener Daten an Meta oder Google eine Rechtsgrundlage nach der DSGVO.

Praktisch heißt das: Der Server sollte Kaufereignisse nur mit Kundendaten anreichern, wenn eine entsprechende Einwilligung vorliegt, und den Einwilligungsstatus mitsenden. Shopify weist zudem darauf hin, dass Sie in Ihrer Datenschutzerklärung offenlegen sollten, welche Daten Sie an Meta weitergeben. Der Gewinn des serverseitigen Setups liegt bei den Nutzern, die eingewilligt haben, deren Daten aber durch ITP, Adblocker oder abgebrochene Skripte bisher verloren gingen.

Checkliste für Shopify-Shops

• Datenfreigabe in der Meta-App prüfen: In der Facebook-&-Instagram-App von Shopify nutzen die Stufen „Erweitert“ und „Maximum“ die Conversions API, „Standard“ nur den Pixel. Kontrollieren Sie, welche Stufe aktiv ist.
• Doppelte Pixel entfernen: Ein manuell eingebauter Pixel plus App-Integration erzeugt leicht Doppelzählungen ohne gemeinsame event_id.
• event_id im Events Manager prüfen: Der Kauf sollte von Browser und Server mit identischer ID ankommen, idealerweise der Bestellnummer.
• EMQ für „Purchase“ ansehen: Fehlen E-Mail oder Telefonnummer in den Server-Ereignissen, ist das der erste Hebel.
• Enhanced Conversions in Google Ads aktivieren und in der Diagnose prüfen, ob gehashte Kundendaten ankommen.
• Consent Mode v2 testen: Mit dem Tag Assistant prüfen, ob ad_user_data und ad_personalization vor und nach der Banner-Auswahl korrekt gesetzt werden.
• Banner und Shopify-Einstellungen abgleichen: Die Regionen, in denen Ihr Banner Einwilligungen abfragt, sollten zu den Datenschutzeinstellungen in Shopify passen.
• Bestellbestätigungsseite kontrollieren: Prüfen Sie nach jeder Änderung am Checkout mit einer Testbestellung, ob alle Kauf-Tags auslösen, ob sie über Apps oder Custom Pixels laufen und ob der Bestellwert korrekt übergeben wird.
• Abgleich mit dem Backend: Vergleichen Sie monatlich die Käufe laut Shopify mit den gemeldeten Conversions in Meta und Google. Größere Abweichungen nach unten deuten auf Messlücken, Abweichungen nach oben auf fehlende Deduplizierung.

Fazit

Serverseitiges Tracking schließt nicht jede Lücke. Nutzer, die ablehnen, bleiben unsichtbar, und das ist richtig so. Es sorgt aber dafür, dass Käufe von einwilligenden Kunden zuverlässig, dedupliziert und mit hoher Match-Qualität ankommen. Davon profitieren die Gebotsalgorithmen von Meta und Google direkt. Für die Umsetzung gibt es mehrere Wege, vom Shopify-Standard über einen eigenen Server-Container bis zu spezialisierter Software wie Tracyn. Transparenzhinweis: Tracyn ist ein Produkt der Atmos GmbH, deren Geschäftsführer Sascha Blum zugleich Gründer von Minotaurus ist.

Quellen

1. Apple Developer News: Upcoming AppTrackingTransparency requirements
2. WebKit: Tracking Prevention in WebKit
3. Meta for Developers: Conversions API Best Practices
4. Meta for Developers: Handling Duplicate Pixel and Conversions API Events
5. Google Ads-Hilfe: Erweiterte Conversions
6. Google for Developers: An introduction to server-side tagging
7. Tag Manager-Hilfe: Updates to consent mode for traffic in the EEA
8. Google Ads-Hilfe: Consent Mode
9. § 25 TDDDG (gesetze-im-internet.de)
10. Shopify Hilfe: Facebook-Datenfreigabe