Server-Side Tracking für Meta ohne Cookie-Banner

Was Server-Side Tracking ist

Klassisches Conversion-Tracking läuft im Browser: Auf der Danke-Seite lädt ein Skript, der Meta-Pixel, setzt Cookies und meldet den Kauf an Meta. Beim serverseitigen Tracking (bei Meta über die Conversions API, kurz CAPI) schickt dein System das Event selbst, von Server zu Server. Der Browser des Käufers ist daran nicht beteiligt.

Für Meta sind beide Wege gleichwertig. Ein Purchase-Event aus der Conversions API zählt in Kampagnen-Optimierung, Zielgruppen und Lookalikes genauso wie eines vom Pixel. Der Unterschied liegt darin, wer sendet, wann gesendet wird und welche Daten dabei mitgehen.

Der beste Zeitpunkt zum Senden ist der Moment, in dem die Zahlung bestätigt ist: der Webhook des Zahlungsanbieters. Ein Pixel meldet dagegen nur, dass jemand die Danke-Seite geladen hat. Ob die Zahlung durchging, weiß er nicht.

Warum der Browser-Pixel immer weniger sieht

Adblocker und der Tracking-Schutz in Browsern blockieren das Pixel-Skript ganz. Safari und iOS kürzen die Lebensdauer von Tracking-Cookies auf wenige Tage, sodass ein Kauf nach einer Woche nicht mehr zur Anzeige findet. Und wer den Cookie-Banner ablehnt, wird nicht getrackt; bei einem sauber gebauten Banner ist das ein großer Teil der Besucher.

Dazu kommt der Moment der Messung. Die Danke-Seite ist die letzte Seite, die der Käufer noch sehen muss. Schließt er den Tab, bevor das Skript geladen ist, fehlt der Kauf. Meta empfiehlt in seiner Dokumentation deshalb selbst, den Pixel mit der Conversions API zu ergänzen.

Wo § 25 TDDDG greift und wo nicht

Der Cookie-Banner kommt aus § 25 TDDDG, bis Mai 2024 TTDSG. Die Vorschrift verlangt eine Einwilligung, wenn Informationen auf dem Endgerät des Nutzers gespeichert oder von dort ausgelesen werden, es sei denn, das ist für den ausdrücklich gewünschten Dienst unbedingt erforderlich. Ein Tracking-Cookie ist der Standardfall: nicht erforderlich, also einwilligungspflichtig. Genau diese Einwilligung holt der Banner ein.

Serverseitiges Tracking speichert nichts auf dem Endgerät und liest nichts von dort aus. Die Klick-ID steht in der URL, mit der der Käufer im Checkout landet; sie zu lesen ist kein Zugriff auf das Endgerät. § 25 TDDDG greift also nicht, und für diesen Teil braucht es keinen Banner.

Das ist der halbe Weg. Die zweite Frage stellt die DSGVO: Sobald personenbezogene Daten an Meta gehen, brauchst du dafür eine Rechtsgrundlage nach Art. 6 DSGVO, ganz gleich, ob ein Cookie im Spiel war. Wie weit das trägt, hängt davon ab, welche Daten du sendest.

Wie die Zuordnung ohne Cookie funktioniert

Damit Meta einen Kauf einer Anzeige zuordnen kann, braucht es einen Anker. Beim Pixel ist das das Cookie _fbc, das der Pixel beim ersten Seitenaufruf aus dem URL-Parameter fbclid bildet. Beim serverseitigen Tracking übernimmt dein Server diese Aufgabe: Er liest fbclid beim Landen aus der URL, merkt sich die Klickzeit und baut daraus beim Senden den Parameter fbc im Format fb.1.<Klickzeit>.<fbclid>, mit der Klickzeit in Millisekunden.

Zwei Details entscheiden über die Qualität. In fbc gehört die Klickzeit, nicht der Zeitpunkt des Kaufs; Meta prüft das Format, und ein falscher Zeitstempel kostet die Zuordnung. Und die Klick-ID muss bis zur Zahlung überleben, ohne im Browser gespeichert zu werden. Sie hängt deshalb an der Bestellung, nicht am Gerät; Adblocker und Cookie-Laufzeiten spielen für sie keine Rolle.

Ohne Klick-ID gibt es keine Zuordnung. Ein organischer Kauf, bei dem niemand auf eine Anzeige geklickt hat, wird standardmäßig nicht gemeldet. Wer alle Käufe melden will, braucht einen zweiten Anker, in der Regel die gehashte E-Mail-Adresse.

Pixel und Server parallel, dedupliziert per Event-ID

Viele Shops fahren beides, den Pixel auf der eigenen Website und die Conversions API vom Server. Dann kommt derselbe Kauf zweimal bei Meta an. Meta zählt ihn nur dann einmal, wenn beide Events dieselbe event_id tragen; dann behält es eines und verwirft das andere.

Die Event-ID muss deshalb vor dem Senden feststehen und für beide Seiten erreichbar sein. Praktisch heißt das: Der Server erzeugt die ID aus der Bestellung und reicht sie an die Danke-Seite weiter, etwa als URL-Parameter, und der Pixel gibt sie als eventID mit. Rechnungskit hängt sie als Parameter rk_event_id an die Return-URL.

Was nach der DSGVO mitgehen darf

Die Conversions API nimmt eine ganze Reihe von Nutzerdaten an: E-Mail, Name, Telefon, IP-Adresse, User-Agent, je nach Feld gehasht oder im Klartext. Je mehr davon mitgeht, desto besser matcht Meta, und desto klarer brauchst du eine Rechtsgrundlage, in der Regel die Einwilligung des Käufers.

Der datensparsame Weg sendet nur, was für die Zuordnung zur Anzeige nötig ist: die Klick-ID, den Betrag, die Währung und die UTM-Parameter der Kampagne. Weder E-Mail noch Name noch IP-Adresse verlassen dein System. Meta kann den Kauf damit der Anzeige zuordnen, aber keine Zielgruppe aus deinen Käufern bauen. Für die Kampagnen-Optimierung reicht das.

Wer Käufer-Zielgruppen und Lookalikes will, sendet zusätzlich E-Mail und Name als SHA-256-Hashes. Meta verlangt dafür normalisierte Werte, kleingeschrieben und ohne Leerzeichen, sonst matcht der Hash nicht. Ob und wie du dafür eine Einwilligung einholst, entscheidest du als Werbetreibender mit deiner Datenschutz-Beratung. Ein Tracking-Werkzeug nimmt dir diese Entscheidung nicht ab.

So macht es Rechnungskit im Checkout

Im Rechnungskit-Checkout läuft kein Pixel und kein Drittskript. Die Meta-Ads-Integration meldet Käufe serverseitig aus dem Zahlungs-Webhook: bei jeder bestätigten Zahlung ein Purchase-Event mit Betrag und Währung, bei jedem Abo-Start ein Subscribe-Event mit dem Planbetrag der ersten vollen Periode. Die Klick-ID nimmt Rechnungskit beim Landen aus der URL und speichert sie serverseitig an der Bestellung, zusammen mit der Klickzeit. Sie landet in keinem Cookie und in keinem Browser-Speicher. Dasselbe gilt für die Klick-IDs von Google, Microsoft und TikTok (gclid, msclkid, ttclid); sie stehen im Checkout-Webhook und an der Return-URL für dein eigenes Tracking.

Standardmäßig gehen nur Klick-ID, Betrag, Währung und UTM-Parameter raus. Erweitertes Matching mit gehashter E-Mail und gehashtem Namen schaltest du in den Einstellungen ein und bestätigst dabei, dass du dafür eine Rechtsgrundlage hast. Jede Meldung steht im Protokoll auf der Integrations-Seite; ist Meta vorübergehend nicht erreichbar, wiederholt Rechnungskit die Meldung etwa eine Stunde lang in wachsenden Abständen. Wie du die Integration einrichtest, steht auf der Seite zur Meta-Ads-Integration.