Meta Event Match Quality: come alzare il tuo punteggio

Event Match Quality (EMQ) è un punteggio su 10 che Meta assegna a ogni evento del sito che invii tramite la Conversions API. Mostra quanto bene le informazioni sul cliente contenute in quell’evento permettono di associarlo a un account Meta. Lo alzi inviando più identificatori giusti, formattati e con hash nel modo che Meta si aspetta.

Questa guida spiega cosa misura il punteggio, quali parametri delle informazioni sui clienti contano di più, le regole di hash e normalizzazione, perché gli acquisti dai dati degli ordini portano più identificatori delle visualizzazioni di pagina, a quale punteggio puntare e dove controllarlo.

Che cosa misura Event Match Quality?

Meta calcola il punteggio da due elementi: la qualità delle informazioni sul cliente che invii con un evento server, e la quota di quegli eventi che Meta associa a un account. Un evento associato dice a Meta quale persona ha comprato. Meta può allora attribuire l’acquisto all’annuncio che quella persona ha visto o cliccato, e mostrare i tuoi annunci a persone con più probabilità di comprare.

Alcuni fatti dalla documentazione di Meta influenzano il modo in cui leggi il punteggio:

• È per evento. Purchase, AddToCart e PageView hanno ciascuno il proprio punteggio, sia per gli eventi standard sia per quelli personalizzati.
• Riguarda solo gli eventi server. Il punteggio è disponibile per gli eventi del sito inviati tramite la Conversions API con action_source impostato su website. Gli eventi inviati solo dal pixel del browser non hanno un punteggio.
• Usa le ultime 48 ore. Invia gli eventi con continuità, altrimenti il punteggio diventa obsoleto.

Meta osserva anche che un’associazione migliore può aumentare le conversioni aggiuntive che riporta per la tua configurazione della Conversions API. Un acquisto che Meta non riesce ad associare è un acquisto per cui i tuoi annunci non ricevono merito.

Quali parametri delle informazioni sui clienti alzano il punteggio?

Meta pubblica una priorità per ogni tipo di informazione sul cliente. Invia ogni parametro che hai per un evento, e parti da quelli ad alta priorità.

L’indirizzo IP e lo user agent non sono nell’elenco delle priorità di Meta, ma la documentazione per sviluppatori di Meta dice che inviare client_ip_address e client_user_agent può aiutare l’associazione. Lo user agent è comunque obbligatorio per gli eventi del sito. Entrambi devono essere i valori dell’acquirente, non quelli del tuo server.

Come si fa l’hash e la normalizzazione dei dati dei clienti?

Meta richiede che le informazioni di contatto siano sottoposte ad hash con SHA-256 prima dell’invio. L’hash funziona solo se ogni sistema scrive lo stesso valore nello stesso modo, quindi Meta definisce una forma normale per ogni campo. Prima normalizza, poi fai l’hash.

Nel codice conta l’ordine dei passaggi:

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

Fai attenzione ai numeri di telefono con lo zero del prefisso nazionale. Un numero olandese scritto come +31 (0)6 1234 5678 diventa 310612345678 se rimuovi solo i simboli. La forma corretta è 31612345678. Anche i valori segnaposto sono una trappola: un’email come noemail@example.com, che un negozio inserisce per gli ordini come ospite, è condivisa da molti clienti, quindi non può identificare una sola persona. Meglio omettere del tutto il campo.

Perché gli eventi server creati dai dati degli ordini portano più identificatori?

Una visualizzazione di pagina avviene prima che il visitatore ti abbia detto qualcosa. Il browser conosce un id del cookie, forse un click id, un indirizzo IP e uno user agent. Un ordine pagato è diverso: l’acquirente ha inserito un indirizzo email, spesso un numero di telefono, un nome e un indirizzo.

Per questo un evento Purchase inviato dal tuo server può ottenere un punteggio più alto di PageView o ViewContent. Un evento di acquisto che arriva solo dalla pagina di ringraziamento ha gli identificatori del browser, ma non sempre l’email e il telefono dell’ordine.

Non tutti i parametri possono raggiungere il 100% degli eventi, ed è normale. Nell’esempio qui sotto il click id è presente nel 38% degli acquisti, perché ce l’hanno solo gli acquirenti arrivati da un clic su un annuncio Meta.

Qual è un obiettivo realistico per Event Match Quality?

La documentazione per sviluppatori di Meta dice che in genere consiglia un punteggio di 6.0 o superiore, dove possibile. Consideralo l’obiettivo per gli eventi che portano dati di contatto, soprattutto Purchase. Un Purchase costruito dai dati dell’ordine porta l’email, uno dei due parametri ad alta priorità, e la maggior parte di quelli a media priorità, quindi è l’evento per cui l’obiettivo è più realistico. Misuralo invece di darlo per scontato: il punteggio dipende anche dai tuoi clienti.

Non aspettarti lo stesso punteggio su ogni evento. PageView, ViewContent e AddToCart spesso non hanno dati di contatto, perché la maggior parte dei visitatori è anonima fino al checkout. Lì un punteggio più basso è previsto, e non è un motivo per raccogliere gli indirizzi email prima di quando i tuoi visitatori vogliono darli.

Non inseguire nemmeno un 10. Il punteggio dipende anche dalla quota di eventi che Meta riesce ad associare, e una parte di questa non dipende da te: alcuni tuoi acquirenti non hanno un account Meta, o lì hanno usato un indirizzo email diverso. Conta anche il consenso. In ROASaurus, con Respect visitor consent attivo, un visitatore che rifiuta i cookie di marketing non ha un click id né un visitor id memorizzati, quindi l’ordine pagato parte con i dati dell’ordine sottoposti ad hash e con l’indirizzo IP e lo user agent dell’ordine, ma senza fbc e fbp. Più rifiuti significano meno identificatori per evento. La nostra pagina di aiuto sul consenso spiega l’impostazione.

La domanda utile non è se il tuo punteggio sia alto, ma se sia cambiato. Confronta ogni evento con il proprio storico dopo ogni modifica al tema, al checkout o al tracciamento.

Come controlli Event Match Quality in Events Manager?

1. Apri il tuo dataset

   Vai su Events Manager e seleziona il nome e l’id del tuo pixel o dataset.

2. Apri i dettagli dell’evento

   Trova l’evento, per esempio Purchase, e clicca su View details.

3. Leggi la scheda Event matching

   Mostra il punteggio, la quota di eventi che portano informazioni sul cliente e i consigli per migliorare l’associazione.

4. Controlla Diagnostics

   La scheda Diagnostics in Events Manager elenca i problemi dei tuoi eventi e i consigli per risolverli.

5. Ricontrolla dopo due giorni

   Il punteggio usa gli eventi delle ultime 48 ore, quindi una correzione si vede per intero circa due giorni dopo.

Anche le altre schede della stessa pagina sono utili. Event coverage confronta i tuoi eventi server con quelli del pixel, Event deduplication mostra la quota di eventi che portano una chiave di deduplicazione come l’event id, e Data freshness mostra con che rapidità arrivano i tuoi eventi server. Se stai ancora configurando il lato server, parti dalla nostra guida alla Meta Conversions API.

Perché il mio Event Match Quality è basso?

Quando un evento ottiene un punteggio più basso del previsto, di solito le cause sono queste:

• Il server invia il proprio indirizzo IP. Se gli eventi passano dal tuo server o da un tag server, questo deve inoltrare l’indirizzo IP e lo user agent che ha rilevato dall’acquirente, non i propri.
• L’fbclid va perso. Il click id si trova solo nell’URL della pagina di atterraggio. Se niente lo salva lì, al checkout non c’è più. Conservalo esattamente com’è arrivato, perché distingue tra maiuscole e minuscole.
• I dati di contatto vengono sottoposti ad hash senza normalizzazione, oppure inviati senza hash.
• Gli identificatori del browser vengono sottoposti ad hash. Un fbp o un fbc con hash non può essere associato.
• Gli acquisti arrivano solo dal browser. Un evento della pagina di ringraziamento spesso non ha l’email e il telefono che ha l’ordine. Inviare l’acquisto dall’ordine risolve il problema.

Come ROASaurus invia le informazioni sui clienti

ROASaurus costruisce l’evento Purchase a partire dall’ordine nel tuo negozio, quindi porta con sé i dati di contatto dell’ordine. Email, telefono, nome e cognome, città, stato, CAP e paese vengono normalizzati e sottoposti ad hash con SHA-256. Il customer id del negozio e il visitor id di ROASaurus vengono inviati con hash come external_id. L’indirizzo IP, lo user agent, l’URL della pagina e fbp vengono collegati dalla visita dell’acquirente, e fbc viene costruito dall’fbclid che lo script del negozio salva quando il visitatore arriva.

Un evento senza fbc, fbp, email, telefono o indirizzo IP viene saltato, perché Meta non riesce ad associarlo. La pagina dell’integrazione Meta elenca ogni campo inviato, e il tracciamento server-side spiega come gli ordini vengono associati al clic sull’annuncio. Per seguire il punteggio, la pagina Tracking health legge ogni giorno l’Event Match Quality di ciascun pixel Meta e genera un avviso quando il punteggio di Purchase scende sotto il tuo minimo, 6.0 per impostazione predefinita.

Fonti

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

• Integrazione Meta
• Tracciamento server-side
• Assistenza: collega Meta

Continua a leggere