Meta Conversions API: Maximierung der Event Match Quality (EMQ) und Deduplizierung

Was EMQ tatsächlich misst

Das Meta Pixel sendet Ereignisse aus dem Browser, die Conversions API (CAPI) aus dem Server. Melden beide Wege denselben Kauf, ordnet das Matching Daten einem möglichen Meta-Konto zu. Die Deduplizierung erkennt dagegen das doppelt gemeldete Ereignis. Beide Aufgaben sind voneinander zu unterscheiden.

Event Match Quality (EMQ) bewertet die übermittelten Kundeninformationen bei Web-Ereignissen auf einer Skala bis 10. Der Wert beschreibt die mögliche Eignung für den Abgleich. EMQ 8 bedeutet keine Trefferquote von 80 Prozent. Ein hoher Wert belegt weder korrekte Attribution noch zusätzliche Verkäufe oder datenschutzkonforme Verarbeitung.

Jedes Feld vor dem Hashing passend aufbereiten

SHA-256 erzeugt einen Fingerabdruck fester Länge aus einer Eingabe. Schon ein zusätzliches Leerzeichen verändert den Hash. Deshalb gelten bei Meta feldbezogene Regeln:

• em: äußere Leerzeichen entfernen und die E-Mail-Adresse in Kleinbuchstaben umwandeln. Auffällige Steuerzeichen oder unsichtbare Formatzeichen erfordern eine Prüfung statt einer stillen Veränderung der Adresse.
• ph: zuerst die internationale Rufnummer mit gesichertem Ländercode bestimmen, anschließend Formatierung entfernen. Das bloße Löschen aller Nicht-Ziffern ergänzt keinen Ländercode und behandelt nationale Vorwahl-Nullen nicht automatisch korrekt.
• Namen und Adressfelder: die jeweilige Parametervorgabe beachten. Akzente pauschal zu entfernen ist falsch; Metas Namensbeispiel erhält den Akzent in valéry.

E-Mail-Adressen, Telefonnummern und die entsprechend gekennzeichneten Namens- und Adressfelder erfordern SHA-256. Client-IP, User-Agent, fbp und fbc werden ungehasht übertragen. Für external_id empfiehlt Meta Hashing; eine allgemeine technische Hash-Pflicht besteht für diesen Parameter nicht. Verknüpfbare Kundeninformationen werden durch Hashing nicht anonym.

Ein bewusst begrenztes Node.js-Beispiel

Das folgende ES-Modul hasht eine E-Mail-Adresse oder eine bereits geprüfte internationale Telefonnummer. Die E-Mail-Prüfung ist eine einfache Plausibilitätskontrolle, keine vollständige Adressvalidierung. Telefonnummern müssen vorher anhand des bekannten Landes aufbereitet und geprüft werden. Der reguläre Ausdruck prüft lediglich das akzeptierte Format. Nationale oder noch formatierte Nummern werden abgelehnt statt geraten; eine zur Rufnummer gehörende Null nach dem Ländercode bleibt erhalten.

import { createHash } from 'node:crypto';
const sha256 = value => createHash('sha256').update(value, 'utf8').digest('hex');
export function hashEmail(raw) {
  if (typeof raw !== 'string') return null;
  const email = raw.trim().toLowerCase();
  if (/[\p{Cc}\p{Cf}]/u.test(email) || !/^[^\s@]+@[^\s@]+\.[^\s@]+$/u.test(email)) return null;
  return sha256(email);
}
export function hashCanonicalPhone(e164) {
  if (typeof e164 !== 'string' || !/^\+[1-9][0-9]{6,14}$/.test(e164)) return null;
  return sha256(e164.slice(1));
}

Ungültige Eingaben ergeben null und müssen im Payload entfallen. SDKs oder Tag-Vorlagen können Normalisierung und Hashing bereits übernehmen. Doppeltes Hashing erzeugt eine falsche Kennung; entscheidend ist deshalb der Eingabevertrag der verwendeten Integration.

Ein Ereignis mit einer gemeinsamen Kennung

Das empfohlene Verfahren benötigt denselben Ereignisnamen und dieselbe Ereigniskennung für dieselbe Pixel-ID. Im Browser heißt der Parameter eventID, bei CAPI event_id. Bei einem Kauf lautet der Ereignisname auf beiden Wegen Purchase. Meta dokumentiert ein Empfangsfenster von 48 Stunden ab dem ersten Ereignis mit dieser Kennung.

Die Kennung kann im Backend oder Browser entstehen. Eine einmal erzeugte, stabile Kaufereignis-Kennung wird an beide Wege übergeben. Wiederholungsversuche desselben Ereignisses behalten die Kennung; ein weiterer Kauf erhält eine neue Kennung. Eine gemeinsame Kennung für sämtliche Käufe würde unterschiedliche Ereignisse zusammenfallen lassen.

Zeitnahe Übermittlung verringert Probleme durch Warteschlangen, garantiert aber keine sofortige Aktualisierung der Berichte. Der Server-Payload bleibt nicht automatisch vollständig erhalten. Meta beschreibt mehrere Strategien und bevorzugt bei inhaltlich nicht wesentlich verschiedenen Ereignissen im Allgemeinen den zuerst empfangenen Datensatz.

Cookies, Kundenkennungen und Einwilligung

_fbp und _fbc sind First-Party-Cookies. Vorhandene Werte können die Parameter fbp und fbc befüllen. Eine abgeleitete fbc setzt eine tatsächlich beobachtete fbclid voraus. Groß- und Kleinschreibung der Klickkennung bleiben unverändert; erfundene Kennungen verbessern die Messung nicht.

Eine external_id ist eine vom Werbetreibenden vergebene Kundenkennung. Nach einem Abgleich anhand weiterer Kundeninformationen kann Meta eine Verbindung zu einem Konto speichern und bei späteren Ereignissen wiederverwenden. Diese Verbindungen laufen regelmäßig ab. Konsistente Kennungen können die Zuordnung unterstützen, garantieren aber keine geräteübergreifende Attribution nach mehreren Wochen und verlängern kein Attributionsfenster.

Bei einer einwilligungsbasierten Werbeintegration benötigen Browser- und Serverweg die passende Einwilligungsprüfung. Google Consent Mode sperrt ein Meta-Server-Tag nicht automatisch: Das CMP-Signal muss ausdrücklich zugeordnet und durchgesetzt werden. Ein Widerruf muss auch noch wartende Übermittlungen stoppen, soweit die Verarbeitung dadurch nicht mehr erlaubt ist. Hashing und Servertransport ersetzen diese Steuerung nicht.

Prüfung vor der Auswertung

Ein kontrollierter Testkauf muss Browser- und Serverereignis mit identischem Namen und identischer Kennung sowie das erwartete Deduplizierungsergebnis zeigen. Weitere Prüfungen betreffen fehlende Einwilligung, Widerruf, Wiederholungen, Verzögerungen und fehlende Kennungen. EMQ-Verläufe ergänzen Ereigniszahlen und Verarbeitungsfehler; ein einzelner Wert ist kein Qualitätssiegel.

Den Integrationsweg beschreibt Meta Conversions API über Server-Side GTM.