iOS-Tracking-Schutz und Adblocker fressen einen wachsenden Teil deiner Pixel-Events. Die Meta Conversions API schickt Events serverseitig, vorbei an diesen Filtern. Dieser Artikel zeigt den Aufbau über einen Cloudflare Worker: SHA256-Hashing der Identifier, Deduplizierung per event_id und der DSGVO-Rahmen.
Warum clientseitiges Tracking löchrig geworden ist
Das klassische Meta-Pixel lebt im Browser. Es lädt JavaScript, setzt Cookies und schickt Events direkt vom Gerät des Nutzers an Meta. Genau dieser Weg ist in den letzten Jahren brüchig geworden. Apples App Tracking Transparency und der Intelligent Tracking Prevention beschneiden, was der Browser an Meta funken darf. Adblocker und strenge Browser-Defaults blocken das Pixel ganz.
Das Ergebnis: ein wachsender Anteil echter Käufe und Leads taucht in deinem Werbekonto nie auf. Deine Kampagnen optimieren auf unvollständige Daten, dein ROAS sieht schlechter aus, als er ist, und das Algorithmus-Lernen leidet.
Die Conversions API dreht den Spieß um. Statt aus dem Browser schickst du das Event von deinem Server, beziehungsweise hier von einem Cloudflare Worker, direkt an Metas Graph-Endpoint. Adblocker und ITP greifen dort nicht, weil sie nur im Browser wirken.
Der Cloudflare Worker als Sammelstelle
Ein Cloudflare Worker ist eine kleine Funktion, die am Edge läuft, also nah am Nutzer, ohne dass du einen Server betreiben musst. Er nimmt einen Event-Request von deiner Seite entgegen, reichert ihn an, hasht die Identifier und leitet ihn an Meta weiter.
Der grobe Ablauf im Worker: Du empfängst per fetch-Handler einen POST von deiner Website mit den Eventdaten. Du liest das Access-Token und die Pixel-ID aus den Worker-Secrets, nie aus dem Frontend. Dann baust du den Payload für https://graph.facebook.com/v19.0/PIXEL_ID/events und schickst ihn per fetch an Meta.
Der entscheidende Vorteil: Das Access-Token bleibt serverseitig im Worker-Secret. Käme es ins Frontend, könnte es jeder aus dem Quelltext ziehen und in deinem Namen Events schicken. Der Worker ist die vertrauenswürdige Zwischenschicht, die das Geheimnis hält.
Identifier korrekt hashen mit SHA256
Meta erlaubt das Matching von Events zu Nutzern, verlangt dafür aber, dass personenbezogene Identifier gehasht ankommen. E-Mail, Telefonnummer, Vorname, Nachname und weitere Felder müssen als SHA256-Hash im Hex-Format übertragen werden, niemals im Klartext.
Vor dem Hashen ist Normalisierung Pflicht, sonst matcht der Hash nicht. Die Regeln:
- E-Mail: in Kleinbuchstaben, führende und folgende Leerzeichen entfernen.
- Telefonnummer: ins E.164-Format, also nur Ziffern mit Landesvorwahl, ohne Pluszeichen, Leerzeichen oder Klammern.
- Namen: Kleinbuchstaben, Leerzeichen trimmen.
Im Worker nutzt du die Web Crypto API: crypto.subtle.digest('SHA-256', new TextEncoder().encode(wert)) und wandelst das Ergebnis in einen Hex-String. Dieser Hex-String wandert dann ins Feld user_data des Payloads, etwa als em für die E-Mail. Die IP-Adresse und der User-Agent gehören unverhasht ins user_data, weil Meta sie für das Matching ungehasht erwartet.
Deduplizierung mit event_id
Wenn du Pixel und Conversions API parallel betreibst, was empfohlen ist, kommt jedes Event potenziell zweimal bei Meta an: einmal aus dem Browser, einmal vom Worker. Ohne Gegenmaßnahme würde ein Kauf doppelt zählen und deine Zahlen verfälschen.
Die Lösung ist eine gemeinsame event_id. Du erzeugst pro Event eine eindeutige ID, zum Beispiel eine UUID, und schickst exakt dieselbe ID über beide Wege. Im Pixel-Aufruf landet sie als eventID, im Worker-Payload als event_id auf Event-Ebene. Meta erkennt anhand der identischen ID, dass es sich um dasselbe Event handelt, und zählt es nur einmal.
Zusätzlich solltest du den event_name (etwa Purchase) und den event_time in beiden Wegen konsistent halten. Stimmen ID, Name und Zeit überein, ist die Deduplizierung zuverlässig. Das ist kein Nice-to-have, sondern die Voraussetzung dafür, dass das parallele Setup überhaupt korrekte Zahlen liefert.
DSGVO: was server-side nicht aushebelt
Server-side Tracking umgeht technische Filter, aber keine Rechtspflichten. Auch ein über den Worker gesendetes Event verarbeitet personenbezogene Daten, und dafür brauchst du eine Rechtsgrundlage. In aller Regel ist das eine Einwilligung, die der Nutzer aktiv und informiert gegeben hat, bevor das Event rausgeht.
Praktisch heißt das: Dein Consent-Management muss vor dem Worker greifen. Hat der Nutzer Marketing-Cookies abgelehnt, darf der Worker für ihn kein matchbares Event mit gehashten Identifiern schicken. Das Hashing selbst ist kein Freibrief, ein SHA256-Hash einer E-Mail gilt weiter als personenbezogen, weil er einer Person zugeordnet werden kann.
Sauber gelöst heißt: Consent prüfen, dann erst senden, und in deiner Datenschutzerklärung den Einsatz der Conversions API benennen. Eine ehrliche Integration baut den Consent-Check als harte Bedingung ein, nicht als nachträglichen Gedanken. Genau so plane und baue ich solche Setups bei adsbird, als Festpreis-Modul, der Code bleibt dein Eigentum. Konditionen unter Preise, Rückfragen an [email protected].
Vom ersten Event zum stabilen Betrieb
Ein erster erfolgreicher Test-Event ist schön, aber Betrieb heißt mehr. Du brauchst Fehlerbehandlung im Worker, falls Meta mit einem Fehler antwortet, sinnvolles Logging ohne Klartext-Identifier und einen Umgang mit Events, die wegen fehlendem Consent gar nicht erst gesendet werden.
Ebenso wichtig ist die Datenqualität. Meta zeigt im Events Manager einen Event-Match-Quality-Score. Je mehr saubere, korrekt gehashte Felder du mitschickst, desto besser matcht Meta und desto wertvoller werden die Events fürs Kampagnen-Lernen. Hier zahlt sich Sorgfalt beim Normalisieren direkt aus.
Wenn du server-side Tracking aufsetzen willst, das technisch korrekt hasht, sauber dedupliziert und den Consent ernst nimmt, baue ich dir genau diese API-Pipeline auf einem Cloudflare Worker. Eine Person plant, baut und übergibt, danach gehört dir der Code. Schreib an [email protected] oder schau unter Preise.