Facebook Server-side Tracking: So richten Sie die Meta Conversions API ein
Richten Sie die Meta Conversions API neben dem Meta Pixel ein: Deduplizierung, User-Data-Parameter, Event Match Quality und die passende Server-Route.

Content-Marketerin
10 Min. Lesezeit
Facebook Server-side Tracking sendet Ihre Conversion-Events über die Meta Conversions API von einem Server, den Sie kontrollieren, an Meta. So verlassen Sie sich nicht nur auf das Meta Pixel im Browser Ihrer Besucher. Fast jedes Setup nutzt beides: Das Pixel meldet weiter aus dem Browser, Ihr Server sendet eine passende Kopie jedes Events, und eine gemeinsame Event-ID zeigt Meta, dass beide denselben Kauf beschreiben. So wird er nur einmal gezählt.
An dieser Kopplung scheitern die meisten Meta-Setups. Die Deduplizierung passiert nicht automatisch: Stimmen die Event-IDs nicht überein, zählt Meta jeden Kauf doppelt, und jeder Bericht und jede Gebotsentscheidung danach arbeitet mit der überhöhten Zahl.
Dieser Guide zeigt, wie Sie beide Quellen einrichten, wie die Deduplizierung funktioniert und woran sie scheitert, wie Ihr Event Match Quality Score berechnet wird und welche der drei serverseitigen Routen zu Meta zu Ihrem Setup passt.
Was ist Facebook Server-side Tracking?
Die Conversions API ist die Server-zu-Server-Verbindung von Meta für Conversion-Events. Nicht nur der Browser des Besuchers sendet ein Event an Meta, auch Ihr Server sendet eine Kopie, mit den bestätigten Bestelldaten. Eine gemeinsame Event-ID zeigt Meta, dass beide Kopien dieselbe Aktion beschreiben.
Die Conversions API (CAPI) ist seit 2020 allgemein verfügbar. Geändert hat sich, wie viel vom Browsersignal Meta noch erreicht und wie stark Ihre Optimierung inzwischen davon abhängt, dass die Kopie vom Server ankommt.
Warum Browser-Tracking überhaupt Conversions verliert, erklärt unser Beitrag darüber, warum Ihre Meta-, GA4- und Google-Ads-Conversions nicht übereinstimmen.
Die wichtigsten Vorteile
Ein höherer Event Match Quality Score
Die Conversions API ordnet eine Conversion nur dann einer Person zu, wenn identifizierende Parameter mit dem Event mitgesendet werden. Serverseitig nehmen Sie E-Mail-Adresse, Telefonnummer und Anschrift aus dem Bestelldatensatz, nicht aus dem, was der Browser gerade gespeichert hatte. Deshalb erzielt dasselbe Purchase-Event meist eine bessere Zuordnung, wenn es vom Server kommt.
Conversions außerhalb des Browsers
Telefonische Bestellungen, Verkäufe im Geschäft und Statuswechsel im CRM erreichen den Browser nie, das Pixel kann sie also nicht erfassen. Die Conversions API ist der einzige Weg, sie zu Meta zu bringen.
Kontrolle darüber, was Meta erhält
Events laufen durch einen Server-Container, den Sie kontrollieren. Sie entscheiden, welche Felder weitergeleitet, welche gehasht und welche zurückgehalten werden.
Besseres Targeting und bessere Optimierung von Anzeigen
Das Auslieferungssystem von Meta optimiert auf die Conversions, die es erhält. Erreicht ein Teil Ihrer Käufe Meta nie, lernt das System aus einer unvollständigen Stichprobe. Es bevorzugt dann die Zielgruppen, deren Conversions den Browser überstehen, nicht die, die am besten konvertieren. Serverseitige Events liefern Meta mehr Conversions mit mehr Kundendaten, sodass Retargeting- und Lookalike-Zielgruppen auf allen Ihren Käufern beruhen.
Server-side Tracking kann keine Interaktion wiederherstellen, die Ihre Website nie erfasst hat. Es verhindert aber, dass der Browser entscheidet, ob eine Conversion zählt. Lesen Sie, wie Server-side Tracking Smart Bidding und automatisierte Kampagnen verbessert.
Pixel, Conversions API oder beides?
Wer die Conversions API nutzt, schaltet das Pixel nicht ab, und Meta rät auch davon ab. Die beiden Quellen sehen unterschiedliche Dinge. Das Pixel erfasst den Browserkontext, etwa den Referrer, die Seiten-URL und das fbp-Cookie. Der Server erfasst, was der Browser nicht erhalten hat: den bestätigten Bestellwert, den Kundendatensatz dahinter und Conversions nach dem Ende der Sitzung.
| Das Meta Pixel sieht | Die Conversions API sieht |
|---|---|
| Den Referrer und die Seiten-URL | Den bestätigten Bestellwert |
| Das fbp-Cookie und die fbclid-Klick-ID | Den Kundendatensatz hinter der Bestellung |
| Was während der Sitzung passiert | Conversions nach dem Ende der Sitzung |
| Nur das, was der Browser durchlässt | Telefon-, Ladengeschäft- und CRM-Conversions |
Reine Server-Setups gibt es, meist wenn keine Website zum Taggen existiert. Ihnen fehlt aber der Browserkontext, der die Zuordnung verbessert. Für die meisten Werbetreibenden mit einer Website lautet die Antwort: beide Quellen senden dieselben Events, dedupliziert. Schritt 5 unten erklärt, wie.
Wählen Sie Ihre serverseitige Route
Es gibt drei Wege, serverseitige Events an Meta zu senden. Welcher passt, hängt davon ab, wie viele Plattformen Sie tracken und wie viel Kontrolle Sie brauchen.
| Route | Geeignet für | Gut zu wissen |
|---|---|---|
| Conversions API über server-side GTM | Websites, die auch Daten an GA4, Google Ads oder andere Plattformen senden | Volle Kontrolle über Felder und Einwilligung. Erfordert einen Server-Container. |
| Meta Conversions API Gateway | Reines Meta-Tracking mit minimalem Einrichtungsaufwand | Vollständig gehostet, in zwei Schritten eingerichtet. Nur für Meta. Gehostet auf Google Cloud an einem Standort Ihrer Wahl; Google Cloud unterliegt dem US Cloud Act. |
| Integrierte Plattform-Integration | Shops auf einer Plattform mit eigener Meta-Integration, etwa Shopify | Schnell aktiviert. Die geringste Kontrolle darüber, was gesendet wird. |
Mehr zum TAGGRS Meta CAPI Gateway.
Server-side Tracking und die DSGVO
Mit Server-side Tracking haben Sie einen zentralen Ort, an dem Sie Einwilligungsentscheidungen und Datenminimierung anwenden, bevor etwas Meta erreicht. Mit TAGGRS entscheiden Sie, welche Informationen erfasst und weitergeleitet werden, und Sie können sensible Felder wie IP-Adressen oder Client-IDs filtern oder anonymisieren, bevor sie die Server von TAGGRS verlassen.
Wenn Sie Daten auf der Infrastruktur von TAGGRS verarbeiten und Tracking-IDs aus dem Client heraushalten, sinkt das Risiko, dass Daten an Ziele gelangen, die Sie nicht gewählt haben. Beim server-side GTM-Hosting wählen Sie, wo Ihr Server Daten verarbeitet, auch an Standorten innerhalb der EU. Das Meta CAPI Gateway wird auf Google Cloud an einem Standort Ihrer Wahl gehostet. Google Cloud unterliegt dem US Cloud Act, sodass US-Behörden auf die Daten zugreifen können. Wenn Sie das verhindern möchten, richten Sie die Conversions API über server-side GTM ein.
Das unterstützt Grundsätze der DSGVO wie Datenminimierung und Zweckbindung. Eine Rechtsgrundlage für die Verarbeitung ersetzt es nicht. Ein Event, das ein Besucher abgelehnt hat, darf gar nicht gesendet werden, ob aus dem Browser oder von Ihrem Server. Und Ihre Consent-Management-Plattform (CMP) muss weiterhin die Einwilligungsstatus setzen, bevor ein Tag Werbedaten verarbeitet. Mehr dazu in Server-side Tracking und die DSGVO und auf unserer Sicherheitsseite.
Expertentipp. Wer auf eine Meta-Anzeige klickt, landet auf einer URL mit fbclid. Hat Safari die verweisende Domain als Cross-Site-Tracker eingestuft, kann jedes Cookie, das JavaScript auf dieser Landingpage schreibt, auf 24 Stunden statt der üblichen sieben Tage begrenzt werden. Der Klick und ein Kauf drei Tage später sind dann zwei unverbundene Events. Ein Cookie, das Ihr eigener Server über den Set-Cookie-Header setzt, unterliegt dieser Begrenzung nicht, solange der Server auf Ihrer eigenen Domain läuft (siehe Schritt 1).
Facebook Server-side Tracking einrichten
Unsere Dokumentation enthält Schritt-für-Schritt-Anleitungen für jeden Teil des Setups. Arbeiten Sie sie in dieser Reihenfolge durch.
1. Erstellen Sie einen Server-Container in Google Tag Manager
Im Server-Container kommen Ihre Events an, bevor sie an Meta weitergeleitet werden. Er läuft auf einer First-Party-Tagging-URL auf Ihrer eigenen Domain, etwa sending.example.com. Eine Subdomain nur auf einen externen Dienst zeigen zu lassen, reicht nicht, denn Safari vergleicht IP-Adressen, bevor es entscheidet, ob es die Lebensdauer eines Cookies verlängert.
2. Installieren Sie das Meta Pixel
Das Pixel bleibt bestehen. Es erfasst Browserkontext, den der Server nicht sieht, und liefert in einem dualen Setup jeweils eine Hälfte jedes deduplizierten Paars. Installieren Sie es über Ihren Web-Container, statt es fest in den Code einzubauen. So können Sie die Event-ID aus Schritt 5 an einer Stelle an beide Tags übergeben.
3. Installieren Sie die Meta Conversions API
Das Conversions-API-Tag liegt in Ihrem Server-Container und sendet Events über eine direkte Server-zu-Server-Verbindung an Meta. Konfigurieren Sie es mit derselben Dataset-ID wie Ihr Pixel. Browser- und Server-Events an zwei verschiedene Datasets zu senden, ist ein häufiger Anfängerfehler, und dann ist keine Deduplizierung möglich.
4. Senden Sie Ihre User-Data-Parameter
Die Conversions API ordnet eine Conversion nur dann einer Person zu, wenn identifizierende Parameter mit dem Event mitgesendet werden. E-Mail-Adresse, Telefonnummer, Name, Ort und Land werden mit SHA-256 gehasht, bevor sie Ihren Server verlassen. Klick-ID (fbc), Browser-ID (fbp), IP-Adresse und User Agent werden unverändert gesendet.
Der Browser fügt IP-Adresse und User Agent automatisch hinzu. Server-Events tun das nicht, deshalb müssen Sie diese Werte in Ihrem Server-Container zuordnen. Wie viele Parameter Sie senden, bestimmt den Event Match Quality Score, um den es weiter unten geht.

5. Richten Sie die Event-Deduplizierung ein
Wenn Pixel und Conversions API zusammen laufen, erhält Meta zwei Kopien jedes Kaufs. Die Deduplizierung verhindert, dass Meta sie als zwei Verkäufe zählt.
Meta gleicht zwei Werte ab: den Event-Namen und die Event-ID. Der Parameter heißt eventID im Browser-Pixel und event_id im Server-Event, und beide müssen denselben Wert haben. Erzeugen Sie die ID einmal aus Ihrer Bestell- oder Transaktions-ID und übergeben Sie sie an beide Tags. Eine ID, die jedes Tag für sich erzeugt, stimmt nie überein. Das ist der häufigste Grund, warum ein Setup anfängt, doppelt zu zählen.
Beachten Sie:
- Die Deduplizierung gilt nur innerhalb von 48 Stunden nach dem ersten Event mit einer bestimmten ID. Danach zählt die zweite Kopie als eigene Conversion.
- Kommen beide Kopien innerhalb von etwa fünf Minuten an, behält Meta das Browser-Event.
- Ist in den vorangegangenen 48 Stunden kein Browser-Event angekommen, behält Meta das Server-Event. Ein reines Server-Event geht durch die Deduplizierung also nie verloren.
- Wenn Sie keine Event-ID übergeben können, kann Meta auch über den Event-Namen in Kombination mit fbp und/oder
external_iddeduplizieren, sofern Browser und Server beide Werte einheitlich senden.
Prüfen Sie Ihren Event Match Quality Score
Event Match Quality (EMQ) misst, wie gut die Kundendaten, die Sie senden, zu Meta-Konten passen. Meta bewertet jeden Event-Typ einzeln auf einer Skala bis 10 und berechnet den Wert anhand aktueller Daten neu. Die Zahl ändert sich also, wenn sich Ihr Setup ändert.
Die Werte unterscheiden sich je nach Event, und das ist so gewollt. Purchase und AddPaymentInfo erzielen die höchsten Werte, weil E-Mail-Adresse, Telefonnummer und Anschrift beim Checkout vorliegen. PageView und ViewContent erzielen die niedrigsten, weil es so früh in der Customer Journey kaum identifizierende Daten gibt. Ein Wert um 6 bei den Events, auf die Sie optimieren, gilt allgemein als gut, und zwischen 8 und 10 ist nur noch wenig zu gewinnen. Es lohnt sich kaum, den Wert bei Top-of-Funnel-Events zu steigern, denn so früh sind die Parameter noch nicht verfügbar.
Der Score zeigt, wie vollständig und korrekt formatiert Ihre Parameter sind, nicht, ob die Daten stimmen. Gut formatierte, aber falsche Daten können trotzdem hoch bewertet werden. Nutzen Sie den Score deshalb zur Diagnose, nicht als Ziel.
Testen Sie Ihr Setup
Öffnen Sie den Events Manager, wählen Sie Ihr Dataset und gehen Sie zu Test Events. Lösen Sie auf Ihrer Website einen Kauf aus und prüfen Sie, was ankommt.
Ein korrekt dedupliziertes Event erscheint als ein Event aus zwei Quellen: Browser und Server. Sehen Sie zwei getrennte Einträge für denselben Kauf oder nur eine Quelle, stimmen Ihre Event-IDs nicht überein, und Sie sollten Schritt 5 prüfen. Tun Sie das, bevor Sie sich beim Bieten auf die Zahlen verlassen, denn eine überhöhte Conversion-Zahl fließt direkt in die Optimierung von Meta ein.
So hilft TAGGRS
TAGGRS hostet Ihren Server-Container, sodass Sie die Conversions API nutzen können, ohne selbst einen Server zu verwalten.
- Server-side GTM-Hosting auf Ihrer eigenen Subdomain, für First-Party-Requests und längere Cookie-Laufzeiten.
- Das Meta CAPI Gateway, wenn Sie nur Meta brauchen und das schnellste Setup möchten.
- Data Enricher ergänzt Events um nicht sensible Kontextdaten wie Ort, Region und Gerät, was die Event Match Quality erhöht.
- Cookie Recovery und Click ID Recovery halten fbc und fbp über lange Kaufentscheidungen hinweg verfügbar.
- Fertige Vorlagen und eine Copy-Paste-Option für GTM, die das Setup beschleunigen.
Häufig gestellte Fragen
Brauche ich sowohl das Meta Pixel als auch die Conversions API?
Ja. Das Pixel erfasst Browserkontext wie den Referrer und das fbp-Cookie, der Server sendet bestätigte Bestelldaten und Conversions, die außerhalb des Browsers stattfinden. Meta empfiehlt, beides zu nutzen, dedupliziert mit einer gemeinsamen Event-ID.
Warum zählt Meta meine Conversions doppelt?
Meist, weil die Event-IDs von Pixel und Conversions API nicht übereinstimmen. Erzeugen Sie eine Event-ID aus Ihrer Bestell-ID und übergeben Sie sie an beide Tags. Prüfen Sie außerdem, ob beide Events an dasselbe Dataset senden.
Was ist der Unterschied zwischen dem Meta CAPI Gateway und der Conversions API über server-side GTM?
Das Gateway ist eine einfache, vollständig gehostete Option nur für Meta. Es wird auf Google Cloud gehostet, das dem US CLOUD Act unterliegt. Server-side GTM unterstützt mehrere Plattformen und gibt mehr Kontrolle über die Daten und den Ort ihrer Verarbeitung, erfordert aber mehr Konfiguration. Lesen Sie mehr über das Meta CAPI Gateway.
Was ist ein guter Event Match Quality Score?
Ein Wert um 6 bei den Events, auf die Sie optimieren, etwa Purchase, gilt allgemein als gut. Top-of-Funnel-Events erzielen bewusst niedrigere Werte, weil so früh weniger Kundendaten vorliegen.
Ist Facebook Server-side Tracking DSGVO-konform?
Es unterstützt die DSGVO, weil Sie steuern und minimieren können, was Meta erreicht. Eine Rechtsgrundlage oder Einwilligung ersetzt es aber nicht. Events, die ein Besucher abgelehnt hat, dürfen weder aus dem Browser noch vom Server gesendet werden. Mehr dazu in unserem Leitfaden zu Server-side Tracking und der DSGVO.
Über die Autorin oder den Autor

Content-Marketerin
Gosia Poddębniak ist eine erfahrene Content-Marketerin und Autorin mit mehr als fünf Jahren Erfahrung in den Bereichen SaaS, Analytics und SEO. Bei TAGGRS entwickelt sie Marketingmaterialien für verschiedene Kanäle und betreut die Inhalte der Website, mit Themen wie Datenerfassung, Marketingoptimierung, Datenschutz, Tracking und Analytics.