Meta Event Match Quality: zo verhoog je je score

Event Match Quality (EMQ) is een score op 10 die Meta geeft aan elk websiteevent dat je via de Conversions API verstuurt. Het laat zien hoe goed de klantinformatie bij dat event het kan koppelen aan een Meta-account. Je verhoogt de score door meer van de juiste identifiers te versturen, opgemaakt en gehasht zoals Meta het verwacht.

Deze gids legt uit wat de score meet, welke parameters met klantinformatie het zwaarst wegen, de regels voor hashing en normalisatie, waarom aankopen uit bestelgegevens meer identifiers bevatten dan paginaweergaven, welke score je kunt nastreven en waar je hem controleert.

Wat meet Event Match Quality?

Meta berekent de score uit twee dingen: de kwaliteit van de klantinformatie die je met een serverevent meestuurt, en het aandeel van die events dat Meta aan een account koppelt. Een gekoppeld event vertelt Meta welke persoon heeft gekocht. Meta kan de aankoop dan toeschrijven aan de advertentie die die persoon zag of aanklikte, en je advertenties tonen aan mensen die waarschijnlijker kopen.

Een paar feiten uit de documentatie van Meta bepalen hoe je de score leest:

• Hij geldt per event. Purchase, AddToCart en PageView krijgen elk hun eigen score, voor standaard- en custom events.
• Het geldt alleen voor serverevents. De score is beschikbaar voor websiteevents die via de Conversions API worden verstuurd met action_source op website. Events die alleen door de browserpixel worden verstuurd, hebben geen score.
• Het gebruikt de laatste 48 uur. Verstuur events gestaag, anders raakt de score verouderd.

Meta merkt ook op dat betere matching de extra conversies kan verhogen die het rapporteert voor je Conversions API-opzet. Een aankoop die Meta niet kan koppelen, is een aankoop waarvoor je advertenties geen eer krijgen.

Welke parameters met klantinformatie verhogen de score?

Meta publiceert een prioriteit voor elk type klantinformatie. Verstuur elke parameter die je voor een event hebt, en begin met die met hoge prioriteit.

Het IP-adres en de user agent staan niet in de prioriteitenlijst van Meta, maar de ontwikkelaarsdocumentatie van Meta zegt dat het meesturen van client_ip_address en client_user_agent de matching kan helpen. De user agent is voor websiteevents sowieso verplicht. Beide moeten de waarden van de shopper zijn, niet die van je server.

Hoe hash en normaliseer je klantgegevens?

Meta vereist dat contactgegevens met SHA-256 worden gehasht voordat je ze verstuurt. Hashing werkt alleen als elk systeem dezelfde waarde op dezelfde manier schrijft, dus Meta definieert voor elk veld een normaalvorm. Normaliseer eerst, hash daarna.

In code gaat het om de volgorde van de stappen:

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

Let op telefoonnummers met een extra nul na de landcode. Een Nederlands nummer dat als +31 (0)6 1234 5678 is geschreven, wordt 310612345678 als je alleen de symbolen verwijdert. De juiste vorm is 31612345678. Placeholderwaarden zijn een andere valkuil: een e-mailadres zoals noemail@example.com dat een webshop bij gastbestellingen invult, wordt door veel klanten gedeeld en kan dus niet één persoon identificeren. Laat het veld in dat geval weg.

Waarom bevatten serverevents uit bestelgegevens meer identifiers?

Een paginaweergave vindt plaats voordat de bezoeker iets over zichzelf heeft verteld. De browser kent een cookie-id, misschien een click-id, een IP-adres en een user agent. Een betaalde bestelling is anders: de shopper heeft een e-mailadres ingevuld, vaak een telefoonnummer, een naam en een adres.

Daarom kan een Purchase-event dat vanaf je server wordt verstuurd hoger scoren dan PageView of ViewContent. Een aankoopevent dat alleen van de bedankpagina komt, bevat de browser-id's, maar niet altijd het e-mailadres en telefoonnummer uit de bestelling.

Niet elke parameter kan bij 100% van de events aanwezig zijn, en dat is normaal. In het voorbeeld hieronder zit het click-id bij 38% van de aankopen, omdat alleen kopers die via een klik op een Meta-advertentie kwamen er een hebben.

Wat is een realistisch doel voor Event Match Quality?

Volgens de ontwikkelaarsdocumentatie van Meta wordt doorgaans een score van 6.0 of hoger aanbevolen, waar mogelijk. Beschouw dat als de doelstelling voor de events die contactgegevens bevatten, vooral Purchase. Een Purchase die uit bestelgegevens is opgebouwd, bevat het e-mailadres, een van de twee parameters met hoge prioriteit, en de meeste parameters met gemiddelde prioriteit. Daarom is dit het event waarbij de doelstelling het meest haalbaar is. Meet het liever dan dat je ervan uitgaat: de score hangt ook af van je klanten.

Verwacht niet op elk event dezelfde score. PageView, ViewContent en AddToCart hebben vaak geen contactgegevens, omdat de meeste bezoekers tot aan de checkout anoniem zijn. Een lagere score is daar normaal, en geen reden om e-mailadressen eerder te verzamelen dan je bezoekers ze willen geven.

Jaag ook niet op een 10. De score hangt ook af van het aandeel events dat Meta kan koppelen, en een deel daarvan heb je niet in de hand: sommige van je kopers hebben geen Meta-account of gebruikten daar een ander e-mailadres. Ook toestemming speelt mee. Als in ROASaurus Respect visitor consent aan staat, heeft een bezoeker die marketingcookies weigert geen opgeslagen click-id of bezoeker-id. De betaalde bestelling wordt dan verstuurd met gehashte bestelgegevens en het IP-adres en de user agent van de bestelling, maar zonder fbc en fbp. Meer weigeringen betekenen minder id's per event. Onze helppagina over toestemming legt de instelling uit.

De nuttige vraag is niet of je score hoog is, maar of die is veranderd. Vergelijk elk event met zijn eigen verloop na elke wijziging aan je thema, checkout of tracking.

Hoe controleer je Event Match Quality in Events Manager?

1. Open je dataset

   Ga naar Events Manager en selecteer de naam en het id van je pixel of dataset.

2. Open de eventdetails

   Zoek het event, bijvoorbeeld Purchase, en klik op View details.

3. Lees het tabblad Event matching

   Daar zie je de score, het aandeel events met klantgegevens en tips om de matching te verbeteren.

4. Controleer Diagnostics

   Het tabblad Diagnostics in Events Manager toont problemen met je events en aanbevelingen om ze op te lossen.

5. Controleer na twee dagen opnieuw

   De score gebruikt de events van de laatste 48 uur, dus een oplossing is pas na ongeveer twee dagen volledig zichtbaar.

De andere tabbladen op dezelfde pagina helpen ook. Event coverage vergelijkt je serverevents met je pixelevents, Event deduplication toont het aandeel events met een ontdubbelingssleutel zoals het event-id, en Data freshness laat zien hoe snel je serverevents binnenkomen. Als je de serverkant nog aan het inrichten bent, begin dan met onze gids over de Meta Conversions API.

Waarom is mijn Event Match Quality laag?

Als één event lager scoort dan je verwacht, zijn dit de gebruikelijke oorzaken:

• De server stuurt zijn eigen IP-adres mee. Als events via je server of een tagserver lopen, moet die het IP-adres en de user agent doorgeven die hij van de shopper heeft vastgelegd, niet zijn eigen.
• De fbclid gaat verloren. Het click-id staat alleen in de URL van de landingspagina. Slaat niets het daar op, dan is het er bij de checkout niet meer. Bewaar het precies zoals het binnenkomt, want het is hoofdlettergevoelig.
• Contactgegevens worden gehasht zonder te normaliseren, of ongehasht verstuurd.
• De browser-id's worden gehasht. Een gehashte fbp of fbc kan niet worden gekoppeld.
• Aankopen komen alleen uit de browser. Een event van de bedankpagina mist vaak het e-mailadres en telefoonnummer die de bestelling wel heeft. Als je de aankoop vanuit de bestelling verstuurt, is dat opgelost.

Hoe ROASaurus klantinformatie verstuurt

ROASaurus bouwt het Purchase-event op uit de bestelling in je webshop, dus het bevat de contactgegevens van de bestelling. E-mailadres, telefoonnummer, voor- en achternaam, plaats, staat, postcode en land worden genormaliseerd en gehasht met SHA-256. Het klant-id van de webshop en het bezoeker-id van ROASaurus gaan gehasht mee als external_id. Het IP-adres, de user agent, de pagina-URL en fbp worden gekoppeld vanuit het bezoek van de shopper, en fbc wordt opgebouwd uit de fbclid die het script in je webshop opslaat wanneer de bezoeker landt.

Een event zonder fbc, fbp, e-mailadres, telefoonnummer of IP-adres wordt overgeslagen, omdat Meta het niet kan koppelen. De Meta-integratiepagina toont elk veld dat wordt verstuurd, en server-side tracking legt uit hoe bestellingen aan de advertentieklik worden gekoppeld. Om de score te volgen, leest de pagina Tracking health elke dag de Event Match Quality van elke Meta-pixel en geeft een waarschuwing wanneer de Purchase-score onder je minimum zakt, standaard 6,0.

Bronnen

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-integratie
• Server-side tracking
• Help: Meta koppelen

Lees verder