Meta Event Match Quality: So erhöhst du deinen Score

Die Event Match Quality (EMQ) ist ein Score von 10, den Meta jedem Website-Event gibt, das du über die Conversions API sendest. Sie zeigt, wie gut sich dieses Event anhand der enthaltenen Kundeninformationen einem Meta-Konto zuordnen lässt. Du erhöhst sie, indem du mehr der richtigen Kennungen sendest, so formatiert und gehasht, wie Meta es erwartet.

Dieser Leitfaden erklärt, was der Score misst, welche Parameter für Kundeninformationen am meisten zählen, die Regeln für Hashing und Normalisierung, warum Käufe aus Bestelldaten mehr Kennungen tragen als Seitenaufrufe, welchen Score du anstreben solltest und wo du ihn prüfst.

Was misst die Event Match Quality?

Meta berechnet den Score aus zwei Dingen: der Qualität der Kundeninformationen, die du mit einem Server-Event sendest, und dem Anteil dieser Events, die Meta einem Konto zuordnet. Ein zugeordnetes Event sagt Meta, welche Person gekauft hat. Meta kann den Kauf dann der Anzeige zuschreiben, die diese Person gesehen oder angeklickt hat, und deine Anzeigen Menschen zeigen, die mit höherer Wahrscheinlichkeit kaufen.

Einige Fakten aus der Dokumentation von Meta bestimmen, wie du den Score liest:

• Er gilt pro Event. Purchase, AddToCart und PageView bekommen jeweils ihren eigenen Score, bei Standard-Events und benutzerdefinierten Events gleichermaßen.
• Er betrifft nur Server-Events. Der Score ist für Website-Events verfügbar, die über die Conversions API gesendet werden und bei denen action_source auf website gesetzt ist. Events, die nur das Browser-Pixel sendet, haben keinen Score.
• Er nutzt die letzten 48 Stunden. Sende Events gleichmäßig, sonst veraltet der Score.

Meta weist außerdem darauf hin, dass eine bessere Zuordnung die zusätzlichen Conversions erhöhen kann, die es für dein Conversions-API-Setup meldet. Ein Kauf, den Meta nicht zuordnen kann, ist ein Kauf, für den deine Anzeigen keinen Credit bekommen.

Welche Parameter für Kundeninformationen erhöhen den Score?

Meta veröffentlicht für jede Art von Kundeninformation eine Priorität. Sende jeden Parameter, den du für ein Event hast, und beginne mit denen mit hoher Priorität.

Die IP-Adresse und der User-Agent stehen nicht in der Prioritätsliste von Meta, aber laut der Entwicklerdokumentation von Meta kann das Senden von client_ip_address und client_user_agent bei der Zuordnung helfen. Der User-Agent ist für Website-Events ohnehin erforderlich. Beide müssen die Werte des Käufers sein, nicht die deines Servers.

Wie hashst und normalisierst du Kundendaten?

Meta verlangt, dass Kontaktdaten mit SHA-256 gehasht werden, bevor du sie sendest. Hashing funktioniert nur, wenn jedes System denselben Wert auf dieselbe Weise schreibt, deshalb definiert Meta für jedes Feld eine Normalform. Erst normalisieren, dann hashen.

Im Code kommt es auf die Reihenfolge der Schritte an:

import { createHash } from 'node:crypto';
const sha256 = (s) => createHash('sha256').update(s).digest('hex');

// Normalize first, then hash.
const em = sha256(' Anna.Berg@Example.com '.trim().toLowerCase());
// hashes "anna.berg@example.com"

const ph = sha256('+1 (415) 555-0134'.replace(/\D/g, ''));
// hashes "14155550134"

const ct = sha256('San Francisco'.toLowerCase().replace(/[^a-z]/g, ''));
// hashes "sanfrancisco"

// Sent as they are, never hashed:
// fbp, fbc, client_ip_address, client_user_agent

Achte auf Telefonnummern mit Vorwahl-Null. Eine niederländische Nummer, die als +31 (0)6 1234 5678 geschrieben ist, wird zu 310612345678, wenn du nur die Sonderzeichen entfernst. Richtig ist 31612345678. Platzhalterwerte sind eine weitere Falle: Eine E-Mail-Adresse wie noemail@example.com, die ein Shop bei Gastbestellungen einträgt, teilen sich viele Kunden, daher identifiziert sie keine einzelne Person. Lass das Feld in diesem Fall lieber weg.

Warum tragen Server-Events aus Bestelldaten mehr Kennungen?

Ein Seitenaufruf findet statt, bevor der Besucher dir irgendetwas mitgeteilt hat. Der Browser kennt eine Cookie-ID, vielleicht eine Click-ID, eine IP-Adresse und einen User Agent. Bei einer bezahlten Bestellung ist das anders: Der Käufer hat eine E-Mail-Adresse, oft eine Telefonnummer, einen Namen und eine Adresse eingegeben.

Deshalb kann ein Purchase-Event, das von deinem Server gesendet wird, einen höheren Score erreichen als PageView oder ViewContent. Ein Purchase-Event, das nur von der Dankeseite kommt, enthält die Browser-Kennungen, aber nicht immer die E-Mail-Adresse und die Telefonnummer aus der Bestellung.

Nicht jeder Parameter kann bei 100% der Events ankommen, und das ist normal. Im Beispiel unten ist die Click-ID bei 38% der Käufe vorhanden, weil nur Käufer, die über einen Meta-Anzeigenklick kamen, eine haben.

Was ist ein realistisches Ziel für die Event Match Quality?

In der Entwicklerdokumentation von Meta steht, dass Meta nach Möglichkeit in der Regel einen Score von 6.0 oder höher empfiehlt. Betrachte das als Ziel für die Events, die Kontaktdaten enthalten, vor allem für Purchase. Ein aus Bestelldaten aufgebautes Purchase enthält die E-Mail-Adresse, einen der beiden Parameter mit hoher Priorität, und die meisten Parameter mit mittlerer Priorität. Deshalb ist es das Event, bei dem das Ziel am realistischsten ist. Miss es, statt es anzunehmen: Der Score hängt auch von deinen Kunden ab.

Erwarte nicht bei jedem Event denselben Score. PageView, ViewContent und AddToCart haben oft keine Kontaktdaten, weil die meisten Besucher bis zum Checkout anonym sind. Ein niedrigerer Score ist dort normal und kein Grund, E-Mail-Adressen früher zu erheben, als deine Besucher sie angeben möchten.

Jage auch nicht der 10 hinterher. Der Score hängt außerdem vom Anteil der Events ab, die Meta zuordnen kann, und das liegt teilweise außerhalb deiner Kontrolle: Manche deiner Käufer haben kein Meta-Konto oder haben dort eine andere E-Mail-Adresse verwendet. Auch die Einwilligung spielt eine Rolle. Ist in ROASaurus Respect visitor consent aktiviert, hat ein Besucher, der Marketing-Cookies ablehnt, keine gespeicherte Click-ID und keine Besucher-ID. Die bezahlte Bestellung wird dann mit gehashten Bestelldaten sowie der IP-Adresse und dem User Agent der Bestellung gesendet, aber ohne fbc und fbp. Je mehr Besucher ablehnen, desto weniger Kennungen hat jedes Event. Unsere Hilfeseite zur Einwilligung erklärt die Einstellung.

Die nützliche Frage ist nicht, ob dein Score hoch ist, sondern ob er sich verändert hat. Vergleiche jedes Event nach jeder Änderung an deinem Theme, deinem Checkout oder deinem Tracking mit seinem eigenen Verlauf.

Wie prüfst du die Event Match Quality im Events Manager?

1. Dataset öffnen

   Gehe zu Events Manager und wähle den Namen und die ID deines Pixels oder Datasets aus.

2. Eventdetails öffnen

   Suche das Event, zum Beispiel Purchase, und klicke auf View details.

3. Den Tab Event matching lesen

   Er zeigt den Score, den Anteil der Events mit Kundeninformationen und Tipps zur Verbesserung des Matchings.

4. Diagnostics prüfen

   Der Tab Diagnostics im Events Manager listet Probleme mit deinen Events auf und gibt Empfehlungen, wie du sie behebst.

5. Nach zwei Tagen erneut prüfen

   Der Score nutzt die Events der letzten 48 Stunden, deshalb zeigt sich eine Korrektur erst nach etwa zwei Tagen vollständig.

Auch die anderen Tabs auf derselben Seite helfen weiter. Event coverage vergleicht deine Server-Events mit deinen Pixel-Events, Event deduplication zeigt den Anteil der Events, die einen Deduplizierungsschlüssel wie die Event-ID tragen, und Data freshness zeigt, wie schnell deine Server-Events ankommen. Wenn du die Server-Seite noch einrichtest, beginne mit unserem Leitfaden zur Meta Conversions API.

Warum ist meine Event Match Quality niedrig?

Wenn ein Event einen niedrigeren Score hat, als du erwartest, sind das die üblichen Ursachen:

• Der Server sendet seine eigene IP-Adresse. Wenn Events über deinen Server oder einen Tag-Server laufen, muss er die IP-Adresse und den User Agent weiterleiten, die er vom Käufer erfasst hat, nicht seine eigenen.
• Die fbclid geht verloren. Die Click-ID steht nur in der URL der Landingpage. Wenn sie dort nicht gespeichert wird, ist sie beim Checkout weg. Behalte sie genau so, wie sie ankommt, denn Groß- und Kleinschreibung spielen eine Rolle.
• Kontaktdaten werden ohne Normalisierung gehasht oder ungehasht gesendet.
• Die Browser-Kennungen werden gehasht. Ein gehashtes fbp oder fbc kann nicht zugeordnet werden.
• Käufe kommen nur aus dem Browser. Einem Event von der Dankeseite fehlen oft die E-Mail-Adresse und die Telefonnummer, die in der Bestellung stehen. Wenn du den Kauf aus der Bestellung sendest, ist das behoben.

Wie ROASaurus Kundeninformationen sendet

ROASaurus baut das Purchase-Event aus der Bestellung in deinem Shop auf, deshalb enthält es die Kontaktdaten der Bestellung. E-Mail-Adresse, Telefonnummer, Vor- und Nachname, Stadt, Bundesland, PLZ und Land werden normalisiert und mit SHA-256 gehasht. Die Kunden-ID des Shops und die ROASaurus-Besucher-ID werden gehasht als external_id mitgeschickt. IP-Adresse, User Agent, Seiten-URL und fbp werden aus dem Besuch des Käufers ergänzt, und fbc wird aus der fbclid gebildet, die das Storefront-Skript speichert, wenn der Besucher auf der Seite landet.

Ein Event ohne fbc, fbp, E-Mail-Adresse, Telefonnummer oder IP-Adresse wird übersprungen, weil Meta es nicht zuordnen kann. Die Seite zur Meta-Integration listet jedes gesendete Feld auf, und Server-Side-Tracking erklärt, wie Bestellungen dem Anzeigenklick zugeordnet werden. Um den Wert zu verfolgen, liest die Seite Tracking health jeden Tag die Event Match Quality jedes Meta-Pixels aus und löst einen Alert aus, wenn der Purchase-Score unter dein Minimum fällt, standardmäßig 6,0.

Quellen

1. Meta Business Help Center: About Event Match Quality
2. Meta for Developers: Customer Information Parameters
3. Meta for Developers: Verifying Your Setup
4. Meta Business Help Center: View server event details in Meta Events Manager
5. Meta for Developers: Best Practices - Conversions API

In ROASaurus

• Meta-Integration
• Server-Side-Tracking
• Hilfe: Meta verbinden

Weiterlesen