Strato 3: dare a Meta i segnali giusti sull’utente

Hai Pixel e CAPI attivi. La deduplicazione funziona. Gli eventi arrivano a Meta e vengono contati una volta sola.

Adesso devi affrontare un altro problema: Meta riceve quegli eventi, ma non sempre sa a chi attribuirli.

Come Meta usa gli eventi

Quando un evento di acquisto arriva a Meta, l’algoritmo prova a fare una cosa precisa: abbinare quell’evento a un utente nel suo database di circa tre miliardi di persone. Questo processo si chiama matching.

Se Meta riesce a fare il match, ovvero se riesce a capire che quella conversione appartiene a un utente specifico nel suo sistema, può usare quell’informazione per ottimizzare. Cerca persone simili a chi ha comprato. Affina il pubblico. Migliora l’attribuzione.

Se non riesce a fare il match, l’evento viene registrato ma l’algoritmo non sa cosa farsene, sa che una vendita è avvenuta, ma non sa chi era il cliente.

La qualità di questo abbinamento si misura con un punteggio visibile in Events Manager: l’Event Match Quality, o EMQ.

Cosa determina l’EMQ

Il matching si basa sui parametri di identità che includi in ogni evento. I principali sono:

Email (em). Il parametro più potente. Meta ha l’email di miliardi di utenti: se mandi l’email dell’acquirente, Meta riesce a fare il match nella grande maggioranza dei casi.

Numero di telefono (ph). Il secondo parametro per efficacia. Molto utile per gli utenti che non si registrano con email o che usano email temporanee.

Indirizzo IP (client_ip_address). Meno preciso dell’email ma molto facile da includere, perché è sempre disponibile nella richiesta HTTP che arriva al server.

User Agent (client_user_agent). Il browser e il dispositivo dell’utente. Combinato con l’IP, aiuta Meta a restringere ulteriormente il match.

Dati anagrafici (fn, ln, ct, st, zp, country). Nome, cognome, città, CAP, paese. Ogni parametro aggiuntivo aumenta la probabilità di un match corretto.

Più parametri invii, più alto è l’EMQ. Più alto è l’EMQ, più gli eventi che invii si trasformano in ottimizzazione reale per l’algoritmo.

Cosa succede con un EMQ basso

Un EMQ basso non significa che gli eventi non arrivano. Arrivano, ma Meta li vede come conversioni “anonime”, non abbinate a nessun profilo utente specifico.

Il risultato pratico: l’algoritmo non riesce a costruire un profilo affidabile di chi compra da te. I pubblici lookalike sono sfocati. Il targeting broad lavora su un segnale approssimativo. Le campagne trovano traffico, ma non necessariamente il traffico giusto.

Ho analizzato account con un EMQ tra 3 e 4 su 10, il che significa che Meta riusciva ad abbinare meno della metà degli eventi a un utente identificabile. In quei casi, CAPI era attivo e tecnicamente funzionante, ma il beneficio reale era limitato perché mancavano i parametri identità negli eventi.

Attivare CAPI senza curare l’EMQ è come costruire un’autostrada e poi mettere al volante qualcuno senza patente.

Come si implementa l’ottimizzazione dell’EMQ

Migliorare l’EMQ non è una questione di “aggiungere parametri a caso”. Serve un lavoro di configurazione preciso che richiede di mappare dove ogni dato utente è disponibile nel flusso e di collegarlo correttamente agli eventi.

Il punto di partenza: l’audit dei parametri attuali. Prima di aggiungere qualcosa, si verifica cosa c’è già. Events Manager mostra l’EMQ corrente per ogni evento, ma non mostra quali parametri mancano. Per vederlo, si analizza il payload degli eventi server-side, quello che effettivamente viaggia verso Meta, e si verifica campo per campo.

Dove si trovano i dati utente su WordPress. Su WooCommerce, l’email del cliente è sempre disponibile al momento della conferma ordine. Il numero di telefono è spesso raccolto ma non sempre passato. Nome e cognome idem. L’IP e l’user agent arrivano automaticamente dalla richiesta HTTP, ma devono essere inclusi esplicitamente nel payload CAPI, non è automatico. Ogni dato che viene raccolto durante il checkout e non viene incluso nell’evento è un punto EMQ perso.

La configurazione corretta lato server-side. In un’implementazione CAPI su WordPress, ogni evento deve essere costruito con l’insieme completo di parametri disponibili per quella transazione specifica: email, telefono, IP, user agent, e i dati anagrafici raccolti. Il plugin o il codice server-side deve leggerli dal profilo ordine e includerli nel payload.

EMQ e acquisti come ospite. Per chi permette acquisti senza registrazione, il set di dati è più limitato. In questo caso si lavora sui parametri sempre disponibili (IP, user agent) e si valuta se introdurre meccanismi di raccolta email nella pagina (es. email pre-compilata se l’utente è già loggato altrove). Non ci sono scorciatoie: l’EMQ riflette la qualità dei dati che il business ha effettivamente sul cliente.

Un EMQ sopra 7 è raggiungibile nella maggior parte degli e-commerce con una configurazione accurata. Sopra 8 richiede che l’email sia presente in quasi tutti gli eventi, il che significa lavorare anche sull’esperienza del checkout, non solo sul tracking.

La settimana prossima

Con i primi tre strati in ordine, il tuo sistema raccoglie segnali completi, li conta correttamente, e li abbina agli utenti giusti.

C’è ancora un’informazione che quasi nessuno manda a Meta, e che cambia radicalmente come l’algoritmo ottimizza: il valore economico reale di ogni conversione.

Adesso Meta sa quante persone hanno comprato. Non sa quanto ha speso ciascuna. E quella differenza determina se l’algoritmo va a cercare “qualcuno che compra” o “qualcuno che spende quanto ti serve per essere profittevole”.

È lo Strato 4 e cambia il modo in cui pensi all’ottimizzazione delle campagne.