Conversions API oder Pixel? Der Vergleich

Pixel und Conversions API im Vergleich

Der Meta Pixel ist ein Skript im Browser. Er erfasst Seitenaufrufe und Aktionen wie einen Kauf oder eine Formularsendung und schickt sie an Meta. Die Conversions API sendet Ereignisse stattdessen von deinem Server an Meta. Beide Wege liefern dieselbe Art von Ereignissen, nur der Weg dorthin ist ein anderer, und daraus ergeben sich fast alle Unterschiede.

Die Frage lautet deshalb selten Pixel oder API, sondern: Reicht mir der Pixel, oder lohnt sich der Server-Weg zusätzlich? Für die Antwort musst du wissen, was jeder Weg kann, wo er scheitert und wie viel Aufwand er macht.

Meta Pixel: einfach, aber angreifbar

Den Pixel baust du in den Tag Manager ein. Das geht in kurzer Zeit, du brauchst keinen eigenen Server, und die ersten Ereignisse siehst du im Events Manager bald nach dem Veröffentlichen. Für viele Websites ist das genau richtig.

Dafür ist der Pixel auf den Browser des Besuchers angewiesen. Werbeblocker, Datenschutz-Erweiterungen und Browser-Einstellungen können das Skript einschränken oder blockieren. Und ohne Einwilligung darf er ohnehin nicht feuern. Einen Teil der Ereignisse siehst du deshalb nie, und dieser Teil lässt sich nicht genau beziffern. Im Events Manager fehlt er einfach.

• Schnell eingerichtet, kein Server nötig.
• Für kleine Websites oft ausreichend.
• Verliert Ereignisse bei Blockern und Browser-Einschränkungen.

Passend dazu: Server-Side oder Client-Side Tagging?

Conversions API: robuster, mehr Aufwand

Die Conversions API schickt Ereignisse von Server zu Server. Werbeblocker im Browser erreichen diesen Weg nicht, deshalb kommen mehr Ereignisse bei Meta an. Das gilt besonders für wichtige Ereignisse wie Käufe, die ohnehin auf dem Server entstehen, etwa wenn die Bestellung im Shopsystem gespeichert wird.

Die Einrichtung ist aufwendiger. Entweder nutzt du eine Partner-Integration deines Shopsystems, den Conversions API Gateway von Meta oder einen Server-Container im Tag Manager. Jeder Weg hat andere Voraussetzungen und einen anderen Pflegeaufwand. Der Server-Container verlangt eigenes Hosting und läuft dauerhaft.

Wichtig: Der Server-Weg ersetzt keine Einwilligung. Auch über die Conversions API dürfen Ereignisse nur gesendet werden, wenn der Besucher zugestimmt hat. Das Thema ist rechtlich relevant; dieser Artikel ist keine Rechtsberatung, besprich Zweifelsfälle mit deinem Datenschutzbeauftragten.

Beides zusammen mit Deduplizierung

Meta empfiehlt, Pixel und Conversions API parallel zu betreiben. Was der Browser nicht liefert, kommt über den Server, und umgekehrt. So entsteht ein vollständigeres Bild als mit einem Weg allein.

Damit nichts doppelt zählt, braucht Meta eine Möglichkeit zu erkennen, dass beide Meldungen dasselbe Ereignis betreffen. Dafür senden beide Wege dieselbe Ereignis-ID und denselben Ereignisnamen mit. Meta führt die Meldungen zusammen und zählt das Ereignis einmal. Fehlt die ID oder stimmt sie nicht überein, zählt Meta den Kauf zweimal, und deine Auswertung ist verfälscht.

Ein Beispiel: Ein Kunde bestellt in einem kleinen Shop. Der Pixel meldet im Browser das Ereignis Purchase mit der Ereignis-ID 12345. Der Server meldet kurz danach ebenfalls Purchase mit derselben ID. Meta erkennt die Dopplung und behält eine Meldung. Hat der Kunde einen Werbeblocker, kommt nur die Meldung vom Server an, und der Kauf geht trotzdem nicht verloren.

Qualität des Event-Abgleichs

Im Events Manager zeigt dir die Qualität des Event-Abgleichs, wie gut sich Ereignisse Personen zuordnen lassen. Sie hängt von den Kundendaten ab, die du zusammen mit dem Ereignis mitsendest, zum Beispiel einer E-Mail-Adresse, die vor dem Senden gehasht wird. Je vollständiger und sauberer diese Angaben sind, desto besser kann Meta Ereignisse einem Konto zuordnen.

Die API hat hier einen strukturellen Vorteil: Auf dem Server liegen solche Daten oft ohnehin vor, etwa in der Bestellung. Aber auch hier gilt: Senden darfst du sie nur im Rahmen der Einwilligung und der Datenschutzerklärung. Im Events Manager prüfst du außerdem, ob die Ereignisse beider Wege ankommen und zusammengeführt werden.

So prüfst du dein Setup

Beginne mit dem Pixel allein und kontrolliere im Tag Manager mit der Vorschau, ob das Ereignis zur richtigen Zeit feuert und nur einmal. Im Events Manager siehst du die eingehenden Ereignisse. Meta bietet dort außerdem einen Test für Ereignisse, in dem du live sehen kannst, was ankommt.

Kommt die Conversions API dazu, prüfst du dasselbe: Kommen Ereignisse vom Server an, und tragen sie dieselbe Ereignis-ID wie die Pixel-Ereignisse? Teste außerdem ohne Einwilligung. Weder Pixel noch Server dürfen dann Ereignisse an Meta senden. Typische Fehler sind doppelte Käufe durch fehlende Deduplizierung, fehlende Ereignisse, weil der Server den Einwilligungsstatus nicht kennt, und Ereignisse mit abweichenden Namen auf beiden Wegen, die Meta deshalb nicht zusammenführt.

Was passt zu dir?

Für kleine Websites reicht oft der Pixel. Ein Handwerksbetrieb mit einem Kontaktformular und einer überschaubaren Anzeigenkampagne gewinnt durch die API meist wenig, und der Mehraufwand lohnt sich selten. Du kannst später nachrüsten, wenn die Kampagnen wachsen.

Für Shops mit viel Werbebudget ist die Kombination sinnvoll. Jedes verlorene Kaufereignis verschlechtert die Optimierung der Kampagnen, weil Meta weniger Beispiele für erfolgreiche Käufe sieht. Wenn du im Events Manager auffällig weniger Käufe siehst als in deinem Shopsystem, ist das ein guter Anlass, über die API nachzudenken. Vergleiche dafür die Zahlen über einen Zeitraum und prüfe vorher, ob der Pixel selbst sauber eingerichtet ist.

Den Pixel richtet Trackum für dich ein. Die Conversions API gehört zum Server-Side Tracking, das bei Trackum bald verfügbar ist.