Meta Conversions API einrichten

Die Meta Conversions API (CAPI) ist eine Server-zu-Server-Schnittstelle, die Conversion-Events direkt aus deinem Backend an Meta sendet, statt sich allein auf den browserbasierten Meta Pixel zu verlassen. Wo der Pixel vom Gerät des Nutzers feuert und von Adblockern, Safari Intelligent Tracking Prevention (ITP) und Consent-Ablehnung blockiert wird, sendet CAPI dieselben Events von deinem Server, wo diese Einschränkungen nicht greifen. Das Ergebnis sind vollständigere Conversion-Daten, die der Algorithmus von Meta zur Optimierung der Anzeigenauslieferung und Attribution nutzt.

Dieser Leitfaden erklärt, wie CAPI und Pixel zusammenarbeiten, warum die Deduplizierung über eine gemeinsame event_id das wichtigste Detail überhaupt ist, wie du die Event Match Quality (EMQ) steigerst, welche Abwägungen zwischen Server-Side GTM und einer direkten API-Integration bestehen, was bei Shopify nach dem Ende der Script Tags zu beachten ist und welche DSGVO-Aspekte in der EU gelten. Er ist herstellerneutral und auf dem Stand vom September 2026: Alle zentralen Aussagen sind mit der offiziellen Dokumentation von Meta und Shopify verlinkt.

Was die Meta Conversions API tatsächlich ist

Der Pixel ist ein JavaScript-Snippet, das im Browser des Besuchers läuft. Wenn jemand ein Produkt ansieht oder einen Kauf abschließt, sendet der Pixel ein Event (ViewContent, Purchase und so weiter) vom Client an Meta. Das ist von Natur aus fragil: Der Browser ist eine feindliche Umgebung für Tracking.

CAPI verlagert genau dieses Event auf den Server. Dein Backend, ein serverseitiger Tag-Container oder ein Gateway sendet eine strukturierte HTTP-Anfrage an den Graph-API-Endpunkt von Meta, mit Eventname, Zeitstempel, gehashten Kundendaten und Event-Parametern. Da die Anfrage aus deiner Infrastruktur stammt, ist sie nicht von Browser-Erweiterungen, Cookie-Limits oder Script-Blocking betroffen. Meta verarbeitet Server-Events nach eigener Aussage genauso wie Pixel-Events, siehe die Übersicht zur Conversions API.

CAPI ist kein Ersatz für den Pixel. Beide sind dafür ausgelegt, parallel zu laufen. Der Pixel erfasst weiterhin den reichhaltigen Echtzeit-Browserkontext (die _fbp- und _fbc-Cookies, den User Agent, die Click-ID aus der Anzeige). Das Server-Event ergänzt Zuverlässigkeit und kann First-Party-Identifier tragen, die der Browser nicht sauber preisgibt. Meta fügt die beiden Streams anschließend zusammen.

CAPI vs. Pixel: warum du beide parallel brauchst

Ein häufiger Fehler ist, CAPI als Entweder-oder-Entscheidung zu behandeln. Das ist es nicht. Die von Meta empfohlene Architektur heißt redundantes Event-Setup: Pixel plus CAPI für jedes wichtige Event, mit Deduplizierung, damit ein einzelner Kauf nur einmal gezählt wird.

Jede Schicht deckt die blinden Flecken der anderen ab:

Schicht	Stärke	Schwäche
Meta Pixel (Browser)	Reichhaltige Browser-Signale (`fbp`, `fbc`, Click-ID), Echtzeit	Blockiert durch Adblocker, ITP, Consent-Ablehnung, Netzwerkfehler
Conversions API (Server)	Übersteht Blocker und ITP, kann gehashte First-Party-Daten senden	Kein nativer Browserkontext, sofern nicht weitergeleitet, hängt an deiner Datenqualität

Wie viel ein dedupliziertes CAPI zurückholt, hängt von Traffic-Mix, Consent-Raten und der Sauberkeit der Implementierung ab. Zwei offizielle Zahlen geben die Größenordnung vor: Meta nennt in der Ankündigung vom April 2026 durchschnittlich 17,8 Prozent niedrigere Kosten pro Ergebnis für Werbetreibende, die CAPI zusätzlich zum Pixel nutzen. In den Best Practices empfiehlt Meta außerdem eine Event-Abdeckung von 75 Prozent als Zielwert für das Verhältnis von CAPI-Events zu Pixel-Events. Behandle beides als Orientierung, nicht als Garantie für deinen Shop.

Für das zugrunde liegende Signalverlust-Problem, das hier gelöst wird, deckt unser Server-Side-Tracking-Service die komplette Architektur vom Browser zum Server ab, nicht nur Meta.

Was sich 2026 geändert hat

Wer den Leitfaden mit einem Setup aus 2024 oder 2025 vergleicht, sollte vier Änderungen kennen:

Graph-API-Version. Die aktuelle Version ist v26.0 (veröffentlicht am 29. Juli 2026). v20.0 wurde am 24. September 2026 abgeschaltet, v21.0 läuft noch bis zum 21. Januar 2027. Prüfe die Version in deinem Endpunkt gegen das Graph-API-Changelog und plane Updates ein, bevor eine Version ausläuft.
Von Meta aktivierte Conversions API (Meta-enabled Conversions API). Seit dem 15. April 2026 bietet Meta eine rein webbasierte CAPI-Variante, die mit einem Klick im Events Manager aktiviert wird, kostenlos ist und die Events sowie Parameter des Pixels automatisch dedupliziert serverseitig spiegelt. Bestehende Pixel-Nutzer werden laut Meta 30 Tage vor einer automatischen Aktivierung informiert und können sie im Events Manager anpassen oder deaktivieren. Quelle: Ankündigung und Vergleich der Einrichtungsoptionen.
KI-gestützter Meta Pixel (AI-enhanced Meta Pixel). Aus derselben Ankündigung: Der Pixel erfasst zusätzlichen Geschäftskontext wie Produktnamen, Verfügbarkeit und Unternehmensdetails automatisch, ohne dass Entwickler diese Parameter manuell pflegen.
Klick-Attribution. Seit der Ankündigung vom 3. März 2026 zählen für Website- und In-Store-Conversions nur noch Link-Klicks als Click-through-Attribution. Andere Interaktionen wie Teilen, Speichern oder Likes wandern in die neue Engage-through-Attribution. Das ist eine Änderung der Berichte, nicht der Abrechnung. Wenn deine Conversion-Zahlen im Frühjahr 2026 gesunken sind, prüfe zuerst diesen Effekt, bevor du dein CAPI-Setup verdächtigst.

Die von Meta aktivierte Variante ist ein guter Start für kleine Shops ohne Entwickler. Sie schickt aber nur, was der Pixel ohnehin sieht. Mehr Identifier, Server-Trigger wie Bestell-Webhooks und eigene Consent-Logik brauchen weiterhin eine der Integrationen unten.

Pflichtparameter, Zeitfenster und Access Token

Bevor es um Qualität geht, muss die Anfrage überhaupt akzeptiert werden. Meta dokumentiert die Regeln in den Server-Event-Parametern und in Using the API:

Pflichtfelder pro Event: event_name, event_time, user_data und action_source. Für Website-Events kommen event_source_url und in user_data der client_user_agent hinzu. action_source muss der Wahrheit entsprechen, für Shop-Käufe also website.
event_time ist ein Unix-Zeitstempel in Sekunden und darf höchstens 7 Tage zurückliegen, sonst lehnt Meta die gesamte Anfrage ab. Meta empfiehlt, Events sofort zu senden, idealerweise innerhalb einer Stunde.
Batching: Bis zu 1.000 Events pro Anfrage im data-Array. Eine eigene Rate-Limitierung hat die Conversions API nicht, die Aufrufe zählen gegen das Limit der Marketing API.
Access Token: Erzeuge ihn im Events Manager unter Einstellungen im Bereich Conversions API über “Zugriffsschlüssel generieren” oder über einen Systemnutzer in den Business-Einstellungen, siehe Get started. Der Token gehört ausschließlich auf den Server, nie in Browser-Code oder Repositories. Seit v12.0 sind diese Tokens nicht mehr an die zum Erzeugungszeitpunkt aktuelle Graph-API-Version gebunden.
test_event_code ist ein optionales Top-Level-Feld neben data, dazu mehr im Abschnitt zum Testen.

Event Match Quality (EMQ): der Hebel für geringere Kosten pro Conversion

Event Match Quality (EMQ) ist der Wert von Meta auf einer Skala von 0 bis 10 dafür, wie gut die mitgesendeten Kundeninformationen ein Server-Event einem Meta-Konto zuordnen lassen. Laut Metas Hilfeseite berechnet sich der Wert aus der Qualität der gesendeten Kundenparameter und dem Anteil der Event-Instanzen, die tatsächlich einem Konto zugeordnet werden konnten. Drei Details, die oft übersehen werden:

Der Wert gibt es nur für Website-Events, die über die Conversions API mit action_source website gesendet wurden. Reine Pixel-Events haben keine EMQ.
Die Berechnung nutzt die Daten der letzten 48 Stunden. Wer Events nur sporadisch sendet, sieht einen unzuverlässigen Wert.
Meta nennt keine offiziellen Schwellen für “gut” oder “schlecht”. Konkrete Empfehlungen, welche Parameter fehlen, zeigt der Events Manager direkt am Event an.

Das ist keine Eitelkeitsmetrik. Zugeordnete Events sind die Basis dafür, dass Meta Conversions attribuieren und Anzeigen an Personen mit höherer Kaufwahrscheinlichkeit ausliefern kann. Je höher die Match Quality, desto mehr Signal bekommt die Optimierung.

Wie du die EMQ steigerst

Sende mehr Identifier, korrekt normalisiert und gehasht. Meta gewichtet die Parameter in user_data nach Priorität (Quelle: dieselbe Hilfeseite):

Priorität	Parameter
Hoch	E-Mail (`em`), Click-ID (`fbc`)
Mittel	Telefonnummer (`ph`), Land (`country`), Geburtsdatum (`db`), externe ID (`external_id`), Browser-ID (`fbp`), Facebook-Login-ID (`fb_login_id`)
Niedrig	Vorname (`fn`), Nachname (`ln`), Stadt (`ct`), PLZ (`zp`), Lead-ID (`lead_id`)

Die Regeln zur Normalisierung und zum Hashing stehen in den Customer Information Parameters. Die wichtigsten:

Hashen mit SHA-256 musst du em, ph, fn, ln, ct, st, zp, country, db und ge. Für external_id empfiehlt Meta das Hashing.
Nie hashen darfst du fbc, fbp, client_ip_address und client_user_agent.
E-Mail: Leerzeichen an den Rändern entfernen, alles in Kleinbuchstaben.
Telefon: Symbole, Buchstaben und führende Nullen entfernen, nur Ziffern. Die Ländervorwahl muss enthalten sein, auch wenn du nur ein Land bedienst.
Namen: Kleinbuchstaben ohne Satzzeichen. Stadt: Kleinbuchstaben ohne Satzzeichen, Sonderzeichen und Leerzeichen. PLZ: Kleinbuchstaben ohne Leerzeichen und Bindestrich. Land: ISO 3166-1 alpha-2 in Kleinbuchstaben, etwa de.
fbc hat das Format fb.1.{Zeitstempel in Millisekunden}.{fbclid}. Fehlt das Cookie, weil der Pixel blockiert war, kannst du den Wert serverseitig aus dem fbclid-URL-Parameter in genau diesem Format bilden.
Meta empfiehlt, client_ip_address und client_user_agent bei allen Events mitzusenden. Außerdem weist Meta darauf hin, dass sich fbp und fbc ändern können und regelmäßig aufgefrischt werden sollten (siehe Best Practices für Entwickler).

import crypto from "crypto";

function hash(value) {
  if (!value) return undefined;
  const normalized = String(value).trim().toLowerCase();
  return crypto.createHash("sha256").update(normalized).digest("hex");
}

const userData = {
  em: hash(customer.email),
  ph: hash(customer.phone?.replace(/\D/g, "").replace(/^0+/, "")),
  fn: hash(customer.firstName),
  ln: hash(customer.lastName),
  ct: hash(customer.city?.replace(/[^\p{L}]/gu, "")),
  zp: hash(customer.zip?.replace(/[\s-]/g, "")),
  country: hash(customer.countryCode),
  external_id: hash(String(customer.id)),
  fbc: cookies._fbc,
  fbp: cookies._fbp,
  client_ip_address: request.ip,
  client_user_agent: request.headers["user-agent"],
};

Die Funktion hash übernimmt Trimmen und Kleinschreibung. Die Telefonnummer wird vorher auf Ziffern reduziert und von führenden Nullen befreit, sie muss deshalb bereits mit Ländervorwahl vorliegen. Bei Stadt und PLZ entfernt der reguläre Ausdruck Leerzeichen und Bindestriche, wie Meta es verlangt. fbc, fbp, IP und User Agent gehen unverändert hinein.

Der größte EMQ-Gewinn für die meisten Shops ist, die _fbc- (Click-ID) und _fbp-Cookies (Browser-ID) vom Pixel an das Server-Event weiterzuleiten, plus eine gehashte E-Mail. Erfasse fbp und fbc clientseitig und übergib sie in deinen Server-Payload.

Deduplizierung: das Detail, das Setups kaputtmacht, wenn es falsch ist

Wenn du Pixel und CAPI gemeinsam betreibst, wird derselbe Kauf zweimal gemeldet: einmal vom Browser, einmal vom Server. Ohne Deduplizierung zählt Meta ihn doppelt, bläht Conversions auf und verfälscht die Optimierung. Deduplizierung ist Pflicht, nicht optional.

Die Regeln stehen in Metas Deduplizierungs-Dokumentation: Meta dedupliziert zwei Events, wenn sie denselben event_name und dieselbe event_id teilen und das zweite Event innerhalb von 48 Stunden nach dem ersten mit dieser event_id eingeht. Unterscheiden sich die Inhalte nicht wesentlich, behält Meta in der Regel das zuerst empfangene Event, egal ob es vom Browser oder vom Server kam. Die Kundendaten aus beiden werden zusammengeführt.

Als Alternative dedupliziert Meta auch über event_name plus fbp oder external_id. Diese Variante hat einen Haken: Ein Server-Event wird nur verworfen, wenn in den 48 Stunden davor ein passendes Browser-Event angekommen ist. Verlass dich deshalb auf die event_id.

Die Regel ist daher einfach und unerbittlich: Das Pixel-Event und das CAPI-Event für dieselbe Aktion müssen dieselbe event_id tragen.

Erzeuge die event_id einmal und nutze sie dann für beide. Ein zuverlässiges Muster ist, sie aus einem stabilen Transaktions-Identifier (der Bestell-ID) abzuleiten, sodass Browser und Server unabhängig denselben Wert berechnen. Im Browser heißt der Parameter eventID mit großem ID, auf dem Server event_id.

const eventId = "purchase_" + orderId;

fbq("track", "Purchase", {
  value: 49.90,
  currency: "EUR",
  content_ids: ["SKU-123"],
}, { eventID: eventId });

await fetch(
  `https://graph.facebook.com/v26.0/${PIXEL_ID}/events?access_token=${ACCESS_TOKEN}`,
  {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      data: [{
        event_name: "Purchase",
        event_time: Math.floor(Date.now() / 1000),
        event_id: "purchase_" + orderId,
        action_source: "website",
        event_source_url: orderUrl,
        user_data: userData,
        custom_data: {
          value: 49.90,
          currency: "EUR",
          content_ids: ["SKU-123"],
          order_id: String(orderId),
        },
      }],
    }),
  }
);

value und currency sind für Purchase Pflicht, currency als dreistelliger ISO-4217-Code, siehe Custom Data Parameters. order_id ist optional, hilft aber bei der Fehlersuche.

Drei Dinge, die hier falsch gemacht werden:

Abweichender event_name. Purchase im Pixel und purchase auf dem Server werden nicht dedupliziert. Groß-/Kleinschreibung und Schreibweise müssen identisch sein.
Eine zufällige event_id, die auf jeder Seite separat erzeugt wird. Sie wird nie übereinstimmen. Leite sie immer aus einer gemeinsamen, deterministischen Quelle ab.
Das Server-Event zu spät senden. 48 Stunden klingen großzügig, aber event_time darf höchstens 7 Tage zurückliegen und Meta optimiert mit frischen Events besser. Sende es zügig, idealerweise nahezu in Echtzeit bei der Bestellbestätigung oder über einen Bestell-Webhook.

Implementierungswege im Vergleich: direkte API vs. Server-Side GTM vs. Gateway

Es gibt nicht den einen richtigen Weg, CAPI-Events zu senden. Die richtige Wahl hängt von deinem Stack, deinem Team und davon ab, wie viel Kontrolle du über die Daten willst. Die fünf gängigen Wege:

Weg	Was es ist	Am besten für	Abwägung
Direkte API	Dein Backend ruft die Graph API von Meta selbst auf	Teams mit Backend-Zugriff und Entwicklern	Volle Kontrolle, volle Wartungslast
Server-Side GTM (sGTM)	Ein Server-Container empfängt Events und leitet sie über Metas Tag an Meta weiter	Marketing-Teams, die einen Server-Hub für alle Plattformen wollen	Braucht einen gehosteten Container; etwas Komplexität
Conversions API Gateway	Eine von Meta bereitgestellte Instanz in deinem eigenen AWS- oder GCP-Konto	Pixel-Nutzer ohne Entwickler und ohne Shop-Plattform	Cloud-Kosten, weniger Kontrolle über Identifier
Von Meta aktivierte CAPI	Ein Klick im Events Manager, Meta spiegelt die Pixel-Events serverseitig	Kleine Shops, schneller Start	Nur Web, nur was der Pixel sieht
Native Plattform-Integration	Der eingebaute CAPI-Connector von Shopify oder WooCommerce	Schneller Start, einfache Shops	Begrenzte Kontrolle über Deduplizierung und EMQ

Server-Side GTM ist die häufigste Wahl für Shops, die bereits GTM nutzen, weil ein Server-Container Meta, GA4, TikTok und weitere aus einem einzigen, einwilligungsbasierten Datenstrom speisen kann. Meta stellt dafür den Tag “Conversions API Tag” von facebookincubator in der Vorlagengalerie bereit; die Anleitung empfiehlt, Pixel-Tag und Server-Tag über dasselbe GA4-Event auszulösen, damit beide dieselbe event_id tragen. Unsere Server-Side-GTM-Arbeit liegt in dieser Schicht.

Direkte API gibt die sauberste Kontrolle und keinen Dritten im Datenpfad, was für die DSGVO und für Datenminimierung wichtig ist. Sie kostet Entwicklerzeit und laufende Wartung. Meta veranschlagt in seinem Vergleich 2 bis 4 Wochen für eine neue direkte Integration.

Conversions API Gateway ist laut Metas Hilfeseite eine codelose Self-Service-Option: Du provisionierst eine Instanz in deinem eigenen AWS- oder GCP-Konto, die Einrichtung dauert unter 30 Minuten, die event_id wird automatisch erzeugt und weitergegeben, die Cloud-Gebühren beginnen bei 30 US-Dollar pro Monat. Meta empfiehlt es Werbetreibenden, die bereits den Pixel nutzen, noch keine Web-Events per CAPI senden, mindestens 300 US-Dollar monatlich für web-optimierte Kampagnen ausgeben und nicht auf einer Shop-Plattform wie Shopify oder WooCommerce laufen. Technische Details stehen in der Gateway-Dokumentation.

Gateways und native Integrationen sind am schnellsten einsatzbereit, aber am schwersten auf hohe EMQ und zuverlässige Deduplizierung zu bringen, weil du weniger Kontrolle darüber hast, welche Identifier gesendet werden und wie die event_id erzeugt wird. Sie sind ein vernünftiger Ausgangspunkt, aber meist nicht der Endzustand für einen ernsthaften Werbetreibenden.

Shopify-Besonderheiten

Shopify hat mit der App “Facebook & Instagram” eine native Meta-Integration, die ab dem Basic-Tarif verfügbar ist. In den Einstellungen zur Datenfreigabe sendet die Stufe “Standard” nur über den Pixel, “Enhanced” und “Maximum” senden das Kauf-Event zusätzlich über die Conversions API und teilen laut Shopify-Hilfe Name, Standort, E-Mail und Telefonnummer der Kundschaft. Meta empfiehlt in der Anleitung zur Verknüpfung “Enhanced” oder “Maximum”. Das ist eine solide Basis, aber begrenzt: Du hast wenig Kontrolle darüber, welche Identifier gesendet werden und die Deduplizierung mit einem eventuell zusätzlich betriebenen eigenen Pixel kann inkonsistent sein.

Drei Fristen haben das Shopify-Tracking 2025 und 2026 umgebaut:

Checkout und Danke-Seite: checkout.liquid, das Feld “Additional Scripts” und Script Tags auf der Danke- und Bestellstatus-Seite endeten für Plus-Shops am 28. August 2025 und für alle anderen Shops am 26. August 2026. Quelle: Shopify-Hilfe zum Checkout-Upgrade und ScriptTag-Deprecation. Tracking auf diesen Seiten läuft seitdem ausschließlich über Web Pixels (App Pixels oder Custom Pixels).
Storefront-Script-Tags: Ab dem 1. Oktober 2026 können Apps keine Script Tags mehr anlegen oder ändern, ab dem 1. März 2027 injiziert Shopify sie gar nicht mehr. Quelle: Shopify-Changelog.
Geschützte Kundendaten: Seit dem 10. Dezember 2025 liefert Shopify an App Pixels ohne genehmigte Protected-Customer-Data-Scopes in checkout_completed für E-Mail, Name, Telefon und Adresse nur noch null. Custom Pixels, die du selbst im Admin anlegst, sind davon nicht betroffen. Quelle: Shopify-Changelog. Dieselbe Logik gilt für Webhooks: Ohne Freigabe werden geschützte Felder aus Bestell-Payloads entfernt, siehe Protected customer data. Prüfe also, ob deine Pixel-App und deine Webhook-App die Felder überhaupt bekommen, bevor du eine niedrige EMQ auf Meta schiebst.

Für ein hochwertiges Shopify-Setup:

Nutze einen Custom Pixel oder einen App Pixel mit genehmigten Scopes für das Browser-Event checkout_completed. Das Event feuert einmal pro Checkout, üblicherweise auf der Danke-Seite. Es liefert checkout.order.id als stabile Quelle für die event_id, siehe die Referenz zu checkout_completed.
Für das Server-Event ist der orders/paid-Webhook der zuverlässigste Trigger. Er feuert, sobald eine Bestellung bezahlt ist, trägt die vollständige Bestellung und ist nicht davon betroffen, dass der Kunde den Tab auf der Danke-Seite schließt.
Leite die event_id aus der Shopify-Bestell-ID ab, sowohl im Pixel als auch im Webhook-Handler, damit sie deduplizieren.
Erfasse _fbp und _fbc im Storefront und speichere sie mit der Bestellung (ein Cart-Attribut oder Note-Attribut funktioniert), damit der Webhook-Handler sie in user_data aufnehmen kann. IP-Adresse und User Agent liefert die Bestellung selbst über browser_ip und client_details.user_agent.

export async function handleOrderPaid(order) {
  const attribute = (name) =>
    order.note_attributes?.find((a) => a.name === name)?.value;

  await sendCapiEvent({
    event_name: "Purchase",
    event_time: Math.floor(new Date(order.processed_at).getTime() / 1000),
    event_id: "purchase_" + order.id,
    action_source: "website",
    event_source_url: order.order_status_url,
    user_data: {
      em: hash(order.email),
      ph: hash(order.phone?.replace(/\D/g, "").replace(/^0+/, "")),
      fn: hash(order.billing_address?.first_name),
      ln: hash(order.billing_address?.last_name),
      ct: hash(order.billing_address?.city?.replace(/[^\p{L}]/gu, "")),
      zp: hash(order.billing_address?.zip?.replace(/[\s-]/g, "")),
      country: hash(order.billing_address?.country_code),
      external_id: hash(String(order.customer?.id ?? order.id)),
      fbp: attribute("fbp"),
      fbc: attribute("fbc"),
      client_ip_address: order.browser_ip,
      client_user_agent: order.client_details?.user_agent,
    },
    custom_data: {
      value: Number(order.total_price),
      currency: order.currency,
      content_ids: order.line_items.map((i) => String(i.product_id)),
      order_id: String(order.id),
    },
  });
}

Der Handler liest fbp und fbc aus den Note-Attributen, die der Custom Pixel beim Checkout mitgegeben hat. event_time nimmt den Bezahlzeitpunkt der Bestellung, damit auch verzögert verarbeitete Webhooks innerhalb des 7-Tage-Fensters bleiben. event_source_url und client_user_agent sind für Website-Events Pflicht und kommen hier komplett aus der Bestellung.

WooCommerce folgt derselben Logik. Das Plugin Facebook for WooCommerce bringt CAPI nach Angabe des Herstellers ohne zusätzliche Einstellung mit und dedupliziert über eine gemeinsame Event-ID. Andere Plattformen: das Server-Event aus einem Order-Completed-Hook feuern, die event_id mit dem Pixel teilen und so viele gehashte Identifier weiterleiten, wie rechtlich zulässig ist.

Testen im Events Manager

Geh nicht davon aus, dass es funktioniert. Validiere es. Der Events Manager von Meta gibt dir die Werkzeuge dafür:

Tab Test-Events. Öffne den Events Manager, wähle unter Datenquellen deinen Datensatz, öffne den Tab Events testen und kopiere die Test-ID aus dem Bereich für Server-Events. Füge sie als test_event_code auf oberster Ebene deines Payloads hinzu und löse eine echte Aktion aus. Events erscheinen laut Metas Anleitung kurz nach dem Senden im Feed und bleiben dort 24 Stunden sichtbar. Der Payload Helper prüft die Struktur, bevor du sendest.
Deduplizierung bestätigen. Das Test-Events-Tool zeigt an, welche Events empfangen, dedupliziert oder verworfen wurden, siehe Metas Hilfeseite zur Deduplizierung. Siehst du zwei separat gezählte Events, stimmen deine event_id oder dein event_name nicht überein.
Den Event-Match-Quality-Wert prüfen. In der Datensatzübersicht weist jedes Server-Event seine EMQ aus, berechnet aus den letzten 48 Stunden. Nutze die Empfehlungen daneben, um zu sehen, welche Identifier fehlen und iteriere.
Den Tab Fehlerdiagnose beobachten. Meta meldet hier fehlende Parameter, Hashing-Probleme und verworfene Events, unterteilt in kritische Probleme und Warnungen. Ein Problem gilt 24 Stunden als aktiv und wandert nach drei Tagen ohne Reaktion in “Zuvor erkannt”, wo die Lösungsschritte verschwinden, siehe Fehlerdiagnose im Events Manager. Beseitige Probleme, solange sie aktiv sind.

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1790000000,
    "event_id": "purchase_1029",
    "action_source": "website",
    "event_source_url": "https://shop.example/checkout/thank-you",
    "user_data": {
      "em": "<sha256>",
      "client_ip_address": "203.0.113.10",
      "client_user_agent": "Mozilla/5.0",
      "fbp": "fb.1...",
      "fbc": "fb.1..."
    },
    "custom_data": { "value": 49.90, "currency": "EUR" }
  }],
  "test_event_code": "TEST12345"
}

Entferne den test_event_code, bevor du in Produktion gehst. Wichtig, weil es oft anders behauptet wird: Events mit test_event_code werden laut Meta nicht verworfen, sondern fließen in den Events Manager und werden für Targeting und Messung genutzt. Teste deshalb mit echten Testkäufen, die du auch sonst bereinigen würdest, nicht mit Fantasiedaten.

DSGVO-Aspekte für die EU

CAPI befreit dich nicht vom Datenschutzrecht. Personenbezogene Daten von deinem Server an Meta zu senden, ist weiterhin eine Verarbeitung personenbezogener Daten und erfordert in der EU eine Rechtsgrundlage und in nahezu allen Fällen Einwilligung. Dies ist eine technische Erläuterung, keine Rechtsberatung; kläre dein konkretes Setup mit deinem Datenschutzbeauftragten oder deiner Rechtsberatung.

Wichtige Punkte für ein DSGVO-konformes Setup:

Einwilligung ist weiterhin erforderlich. Serverseitig heißt nicht einwilligungsfrei. Metas Nutzungsbedingungen für Business-Tools zählen die Conversions API ausdrücklich zu den Business-Tools und verpflichten dich, dort, wo das Recht es verlangt, eine nachweisbare Einwilligung einzuholen, bevor du Daten übermittelst. Lehnt der Nutzer Marketing-Cookies ab, sendest du keine identifizierenden Daten an Meta. Koppele CAPI an deine Consent-Management-Plattform.
Consent im Browser und auf dem Server. Für den Pixel stellt Meta die Consent-API bereit: fbq('consent', 'revoke') vor init pausiert den Pixel, fbq('consent', 'grant') gibt ihn nach der Einwilligung frei. Diese Steuerung wirkt nur im Browser. Für CAPI musst du den Einwilligungsstatus selbst mit dem Event speichern (bei Shopify etwa als Cart-Attribut) und den Server-Aufruf daran binden. Google Consent Mode steuert Google-Tags, nicht Meta.
Personenbezogene Daten hashen. E-Mail, Telefon und Name werden SHA-256-gehasht gesendet. Hashing reduziert die Exposition, aber die Daten sind nach der DSGVO weiterhin personenbezogen, sodass es die Einwilligungspflicht nicht aufhebt.
Datenminimierung. Sende nur die Identifier, die du tatsächlich für das Matching brauchst. Leite keine Felder ohne Tracking-Zweck weiter.
Gemeinsame Verantwortlichkeit statt Auftragsverarbeitung. Für die Erhebung und Übermittlung der Event-Daten bist du mit Meta Ireland gemeinsam Verantwortlicher nach Artikel 26 DSGVO. Das regelt Metas Zusatz für Verantwortliche: Du bist für die Rechtsgrundlage deiner Verarbeitung und für die Information der Betroffenen zuständig, einschließlich des Hinweises, dass Meta Ireland gemeinsam Verantwortlicher ist und wo seine Datenschutzrichtlinie steht. Einen klassischen Auftragsverarbeitungsvertrag gibt es für diese Daten nicht.
Dokumentiere es. Halte die Rechtsgrundlage, den Einwilligungsfluss und den Datenfluss in deinem Verarbeitungsverzeichnis fest und benenne die Conversions API in der Datenschutzerklärung.

Der Vorteil einer sauberen, serverseitigen Architektur ist genau, dass sie dir einen einzigen, prüfbaren Punkt gibt, an dem Einwilligung durchgesetzt und Identifier kontrolliert werden, statt Tracking über Browser-Scripts verstreut zu haben. Für die Einwilligungs- und Rechtsgrundlagen-Schicht im Speziellen siehe unsere Tracking- und Consent-Arbeit.

Verlorenes Signal zurückholen: was zu erwarten ist

Ein dedupliziertes CAPI mit hoher EMQ ist der wirksamste Weg, die Conversion-Blindheit zu verkleinern, die iOS App Tracking Transparency, ITP und Adblocker geschaffen haben. Die belastbarste offizielle Zahl dazu stammt aus Metas Ankündigung vom April 2026: Werbetreibende, die CAPI zusätzlich zum Pixel nutzen, erzielten im Durchschnitt 17,8 Prozent niedrigere Kosten pro Ergebnis als Werbetreibende ohne CAPI. Eine gewisse Grund-Untererfassung bleibt erwartungsgemäß bestehen; CAPI verkleinert die Lücke, statt sie vollständig zu schließen.

Setze realistische Erwartungen: Du holst Signal zurück und verbesserst die Optimierung, du kaufst kein perfektes Tracking. Die Kombination aus vollständigeren Daten, einer Event-Abdeckung nahe der von Meta empfohlenen 75 Prozent und höherer Match Quality ist es, die die Kosten pro Aktion bewegt.

Implementierungs-Checkliste

Häufig gestellte Fragen

Was ist die Meta Conversions API und worin unterscheidet sie sich vom Pixel?

Der Pixel sendet Conversion-Events aus dem Browser des Besuchers; CAPI sendet dieselben Events von deinem Server. CAPI übersteht Adblocker, Safari ITP und consentgetriebenes Script-Blocking, die den Browser-Pixel stoppen. Beide sind dafür ausgelegt, zusammenzuarbeiten, nicht als Alternativen.

Brauche ich den Meta Pixel weiterhin, wenn ich CAPI einrichte?

Ja. Der Pixel erfasst den Echtzeit-Browserkontext (die _fbp- und _fbc-Cookies, Click-IDs), der das Matching verbessert. Das empfohlene Setup ist Pixel plus CAPI für jedes wichtige Event, dedupliziert über eine gemeinsame event_id.

Ist die Meta Conversions API DSGVO-konform?

CAPI kann DSGVO-konform betrieben werden, ist aber nicht automatisch konform. Personenbezogene Daten an Meta zu senden, erfordert weiterhin eine Rechtsgrundlage (in der Praxis Einwilligung), die Information der Betroffenen über die gemeinsame Verantwortlichkeit mit Meta Ireland und eine transparente Datenschutzerklärung. Dies ist eine technische Erläuterung, keine Rechtsberatung.

Was ist Event Match Quality und was ist ein guter Wert?

EMQ ist Metas Wert von 0 bis 10 dafür, wie gut die mitgesendeten Kundeninformationen ein Server-Event einem Meta-Konto zuordnen lassen, berechnet aus den Daten der letzten 48 Stunden. Meta veröffentlicht keine festen Schwellen, zeigt aber im Events Manager pro Event, welche Parameter fehlen. Du steigerst den Wert, indem du mehr genaue, korrekt gehashte Kunden-Identifier pro Event sendest, allen voran E-Mail und Click-ID.

Wie funktioniert die Deduplizierung zwischen Pixel und CAPI?

Meta dedupliziert Events, die denselben event_name und dieselbe event_id teilen und innerhalb von 48 Stunden nach dem ersten Event mit dieser ID eingehen. Bei gleichem Inhalt behält Meta in der Regel das zuerst empfangene Event. Sowohl das Pixel- als auch das Server-Event für dieselbe Aktion müssen eine identische event_id und einen identischen event_name senden.

Was ist der Unterschied zwischen Server-Side GTM, einem CAPI-Gateway und einer direkten API-Integration?

Direkte API bedeutet, dass dein Backend die Graph API von Meta selbst aufruft (meiste Kontrolle, meiste Wartung). Server-Side GTM leitet Events über einen Server-Container, der mehrere Plattformen speisen kann. Das Conversions API Gateway ist eine von Meta bereitgestellte Instanz in deinem eigenen Cloud-Konto (schnellste Einrichtung, wenigste Kontrolle). Alle drei können funktionieren; die Kontrolle über Identifier und event_id ist der Unterschied.

Wie richte ich die Conversions API für Shopify ein?

Nutze einen Web Pixel für das Browser-Event checkout_completed, löse das Server-Purchase-Event aus dem orders/paid-Webhook aus, leite die event_id auf beiden Seiten aus der Shopify-Bestell-ID ab und leite fbp/fbc plus gehashte Kundendaten weiter. Seit dem 26. August 2026 laufen auf der Danke-Seite auch in Nicht-Plus-Shops keine Script Tags mehr. Seit dem 10. Dezember 2025 brauchen App Pixels genehmigte Scopes, um Kundendaten zu sehen.

Wie lange dauert die Einrichtung der Meta Conversions API?

Eine fokussierte Implementierung für die Kern-Events kostet ein paar Stunden Arbeit; eine hohe EMQ zu erreichen und die Deduplizierung über alle Events und Sonderfälle zu validieren, dauert mit Iteration typischerweise länger. Meta selbst veranschlagt für eine neue direkte Integration 2 bis 4 Wochen, für die von Meta aktivierte Variante einen Klick.

CAPI richtig zu machen, dreht sich vor allem um die unglamourösen Details: eine deterministische event_id, identische Eventnamen, die richtigen gehashten Identifier, eine aktuelle API-Version und an einer Stelle durchgesetzte Einwilligung. Wenn du es lieber umgesetzt und validiert haben möchtest, siehe unseren Meta-Conversions-API-Service oder den umfassenderen Server-Side-Tracking-Service. Am besten startest du mit einem kostenlosen Erstgespräch: In einem kostenlosen Erstgespräch klären wir, was deinem aktuellen Setup fehlt und legen den schnellsten Weg zu einem sauberen, deduplizierten CAPI fest.

Meta Conversions API einrichten: CAPI, Deduplizierung und EMQ richtig gemacht