Meta Event Match Quality: så höjer du din poäng

Event Match Quality (EMQ) är en poäng av 10 som Meta ger varje webbplatshändelse som du skickar via Conversions API. Den visar hur väl kundinformationen på händelsen kan matcha den mot ett Meta-konto. Du höjer den genom att skicka fler av de rätta identifierarna, formaterade och hashade så som Meta förväntar sig.

Den här guiden förklarar vad poängen mäter, vilka parametrar för kundinformation som väger tyngst, reglerna för hashning och normalisering, varför köp från orderdata bär fler identifierare än sidvisningar, vilken poäng du bör sikta på och var du kontrollerar den.

Vad mäter Event Match Quality?

Meta beräknar poängen utifrån två saker: kvaliteten på den kundinformation du skickar med en serverhändelse och andelen av dessa händelser som Meta matchar mot ett konto. En matchad händelse talar om för Meta vilken person som köpte. Meta kan då tillskriva köpet den annons som personen såg eller klickade på, och visa dina annonser för personer som är mer benägna att köpa.

Några fakta från Metas dokumentation påverkar hur du läser poängen:

• Den gäller per händelse. Purchase, AddToCart och PageView får var och en sin egen poäng, för både standardhändelser och anpassade händelser.
• Den gäller bara serverhändelser. Poängen finns för webbplatshändelser som skickas via Conversions API med action_source satt till website. Händelser som bara skickas av webbläsarpixeln har ingen poäng.
• Den använder de senaste 48 timmarna. Skicka händelser jämnt, annars blir poängen inaktuell.

Meta noterar också att bättre matchning kan öka de ytterligare konverteringar som det rapporterar för din Conversions API-uppsättning. Ett köp som Meta inte kan matcha är ett köp som dina annonser inte får kredit för.

Vilka parametrar för kundinformation höjer poängen?

Meta publicerar en prioritet för varje typ av kundinformation. Skicka varje parameter du har för en händelse, och börja med dem som har hög prioritet.

IP-adressen och user agent finns inte i Metas prioritetslista, men Metas utvecklardokumentation säger att det kan hjälpa matchningen att skicka client_ip_address och client_user_agent. User agent krävs ändå för webbplatshändelser. Båda måste vara köparens värden, inte din servers.

Hur hashar och normaliserar du kunddata?

Meta kräver att kontaktuppgifter hashas med SHA-256 innan du skickar dem. Hashning fungerar bara om varje system skriver samma värde på samma sätt, så Meta definierar en normalform för varje fält. Normalisera först, hasha sedan.

I koden är det ordningen på stegen som räknas:

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

Se upp för telefonnummer med inledande nolla. Ett nederländskt nummer som skrivs +31 (0)6 1234 5678 blir 310612345678 om du bara tar bort symbolerna. Rätt form är 31612345678. Platshållarvärden är en annan fälla: en e-postadress som noemail@example.com, som en butik fyller i för gästordrar, delas av många kunder och kan därför inte identifiera en enskild person. Utelämna fältet i stället.

Varför bär serverhändelser från orderdata fler identifierare?

En sidvisning sker innan besökaren har sagt något till dig. Webbläsaren känner till ett cookie-id, kanske ett klick-id, en IP-adress och en user agent. En betald order är annorlunda: köparen har skrivit in en e-postadress, ofta ett telefonnummer, ett namn och en adress.

Därför kan en Purchase-händelse som skickas från din server få högre poäng än PageView eller ViewContent. En köphändelse som bara kommer från tacksidan har webbläsaridentifierarna, men inte alltid e-postadressen och telefonnumret från ordern.

Inte varje parameter kan nå 100% av händelserna, och det är normalt. I exemplet nedan finns klick-id:t på 38% av köpen, eftersom bara de köpare som kom via ett klick på en Meta-annons har ett.

Vilket Event Match Quality-mål är realistiskt?

Metas utvecklardokumentation säger att Meta vanligtvis rekommenderar en poäng på 6.0 eller högre, där det är möjligt. Se det som målet för de händelser som bär kontaktuppgifter, framför allt Purchase. Ett Purchase som byggs från orderdata har e-postadressen, en av de två högprioriterade parametrarna, och de flesta av de mellanprioriterade, så det är den händelse där målet är mest realistiskt. Mät det i stället för att anta det: poängen beror också på dina kunder.

Förvänta dig inte samma poäng för varje händelse. PageView, ViewContent och AddToCart saknar ofta kontaktuppgifter, eftersom de flesta besökare är anonyma fram till kassan. En lägre poäng där är väntad, och det är ingen anledning att samla in e-postadresser tidigare än dina besökare vill lämna dem.

Jaga inte efter en 10:a heller. Poängen beror också på andelen händelser som Meta matchar, och en del av det ligger utanför din kontroll: vissa av dina köpare har inget Meta-konto eller använde en annan e-postadress där. Samtycke spelar också roll. I ROASaurus, med Respect visitor consent påslaget, har en besökare som tackar nej till marknadsföringscookies inget sparat klick-id eller besökar-id, så den betalda ordern skickas med hashad orderdata samt orderns IP-adress och user agent, men utan fbc och fbp. Fler nej-svar betyder färre identifierare per händelse. Vår hjälpsida om samtycke förklarar inställningen.

Den användbara frågan är inte om din poäng är hög, utan om den har förändrats. Jämför varje händelse med sin egen historik efter varje ändring i ditt tema, din kassa eller din tracking.

Hur kontrollerar du Event Match Quality i Events Manager?

1. Öppna ditt dataset

   Gå till Events Manager och välj namnet och id:t för din pixel eller ditt dataset.

2. Öppna händelsedetaljerna

   Hitta händelsen, till exempel Purchase, och klicka på View details.

3. Läs fliken Event matching

   Den visar poängen, andelen händelser som bär kundinformation och tips för att förbättra matchningen.

4. Kontrollera Diagnostics

   Fliken Diagnostics i Events Manager listar problem med dina händelser och rekommendationer om hur du åtgärdar dem.

5. Kontrollera igen efter två dagar

   Poängen bygger på de senaste 48 timmarna av händelser, så en åtgärd syns fullt ut först ungefär två dagar senare.

De andra flikarna på samma sida hjälper också. Event coverage jämför dina serverhändelser med dina pixelhändelser, Event deduplication visar andelen händelser som bär en dedupliceringsnyckel som händelse-id, och Data freshness visar hur snabbt dina serverhändelser kommer in. Om du fortfarande håller på att sätta upp serversidan, börja med vår guide till Meta Conversions API.

Varför är min Event Match Quality låg?

När en händelse får lägre poäng än du väntar dig är det här de vanliga orsakerna:

• Servern skickar sin egen IP-adress. Om händelserna går via din server eller en tag-server måste den vidarebefordra den IP-adress och user agent som den registrerade från köparen, inte sin egen.
• Fbclid tappas bort. Klick-id:t finns bara i landningssidans URL. Om inget sparar det där är det borta när köparen når kassan. Behåll det exakt som det kommer in, eftersom det är skiftlägeskänsligt.
• Kontaktuppgifter hashas utan normalisering, eller skickas ohashade.
• Webbläsaridentifierarna hashas. En hashad fbp eller fbc går inte att matcha.
• Köp kommer bara från webbläsaren. En händelse från tacksidan saknar ofta den e-postadress och det telefonnummer som ordern har. Om du skickar köpet från ordern löser du det.

Så skickar ROASaurus kundinformation

ROASaurus bygger Purchase-händelsen från ordern i din butik, så den bär orderns kontaktuppgifter. E-post, telefon, för- och efternamn, stad, delstat, postnummer och land normaliseras och hashas med SHA-256. Butikens kund-id och ROASaurus besökar-id skickas hashade som external_id. IP-adressen, user agent, sidans URL och fbp kopplas från köparens besök, och fbc byggs från den fbclid som skriptet i din webbshop sparar när besökaren landar.

En händelse utan fbc, fbp, e-post, telefon eller IP-adress hoppas över, eftersom Meta inte kan matcha den. På Metas integrationssida finns alla fält som skickas, och server-side tracking förklarar hur ordrar matchas mot annonsklicket. För att följa poängen läser sidan Tracking health varje Meta-pixels Event Match Quality varje dag och skickar ett larm när poängen för Purchase faller under ditt minimum, 6.0 som standard.

Källor

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

I ROASaurus

• Meta-integration
• Server-side tracking
• Hjälp: anslut Meta

Läs vidare