Meta Pixel + Conversion API: eventi deduplicati e Event Match Quality che sale

Il problema

Il sintomo classico: campagne Meta che costano sempre di più per lo stesso risultato, e in Events Manager una sfilza di warning che nessuno ha mai aperto. Quando guardo dentro, trovo quasi sempre la stessa combinazione:

• Solo Pixel browser, installato anni fa: tra ad-blocker, ITP di Safari e consensi negati, una parte degli eventi non parte proprio.
• CAPI configurato a metà (di solito da un plugin) senza deduplicazione: Meta riceve due purchase per ogni ordine, le metriche si gonfiano e l’algoritmo ottimizza su dati sporchi.
• Event Match Quality bassa: gli eventi arrivano, ma senza email, telefono, _fbp/_fbc Meta non riesce ad abbinarli a un utente — e un evento non abbinato non serve all’ottimizzazione.

L’EMQ non è un numero cosmetico: misura quanti dei tuoi eventi Meta riesce ad attribuire a una persona reale. Più segnale utilizzabile dai all’algoritmo, meglio lavora la delivery — ed è lì che si gioca il costo per risultato, prima ancora dei creative.

Come lavoro

1. Audit in Events Manager

Parto dai dati che Meta ti sta già mostrando: EMQ per ciascun evento, rapporto eventi browser vs server, stato della deduplicazione, parametri user_data effettivamente ricevuti, warning attivi. Ti dico subito cosa è rotto e cosa manca. Se il setup è già sano e il problema è altrove, te lo dico altrettanto chiaramente.

2. Scelta dell’architettura server

CAPI si implementa in tre modi: container sGTM (la mia scelta di default, perché lo stesso container serve anche GA4 e Google Ads), CAPI Gateway (rapido, ma copre solo Meta), o integrazione nativa della piattaforma. Un errore che vedo spesso: tenere attivi Gateway e sGTM insieme. Il Gateway inoltra automaticamente tutti gli eventi del Pixel; se anche sGTM li invia, Meta riceve copie che la deduplicazione non copre. Se ne sceglie uno solo.

3. Implementazione CAPI con deduplicazione

Ogni evento parte sia dal browser (Pixel) sia dal server (CAPI) con lo stesso event_id e lo stesso event_name: Meta li riconosce come uno solo e tiene la versione più ricca di dati. Genero l’event_id a monte, nel dataLayer, così browser e server leggono dalla stessa fonte — è il punto in cui i setup fai-da-te sbagliano più spesso.

4. Advanced Matching e user_data enrichment

È qui che l’EMQ sale davvero. Lato browser configuro l’Advanced Matching; lato server arricchisco ogni evento con i parametri che Meta usa per il match: email e telefono hashati SHA-256, cookie _fbp e _fbc, external_id, e dove disponibili nome, città e CAP (sempre hashati). IP e user agent viaggiano dal server senza dipendere dal browser. Tutto nel rispetto del consent: se l’utente rifiuta, i dati non partono.

5. QA in Test Events

Per ogni evento verifico in Test Events che arrivi da entrambi i canali, che risulti “Deduplicated” e che i parametri user_data siano presenti e formattati come Meta li vuole (lowercase, senza spazi, prefisso internazionale sul telefono prima dell’hash). QA documentato con screenshot, non “abbiamo controllato”.

6. Monitoraggio EMQ e handover

L’EMQ in Events Manager si aggiorna con qualche giorno di ritardo: dopo il go-live monitoro l’andamento per un paio di settimane, sistemo quello che emerge e faccio una sessione di handover con il tuo team o con l’agenzia che gestisce le campagne.

Cosa ricevi a fine progetto

• Pixel + Meta Conversion API in produzione, con deduplicazione verificata evento per evento.
• Advanced Matching attivo, con mappatura documentata dei parametri user_data per ogni evento.
• Documento di architettura: flusso eventi browser/server, generazione dell’event_id, gestione del consent.
• QA report da Test Events: screenshot e log per ogni evento (browser, server, dedup).
• Sessione di handover con il tuo team o con chi gestisce le campagne.
• 30 giorni di supporto post-release: se qualcosa non gira, intervengo subito.

Tempi e costi

• Durata: 2–3 settimane dall’accesso agli account al go-live.
• Prezzo: da 1.500€. Fa variare il prezzo: il numero di eventi da coprire oltre al funnel e-commerce standard, la piattaforma del sito (Shopify e WooCommerce sono più rapidi di un headless custom), la presenza o meno di un container sGTM già funzionante, l’enrichment lato server da CRM o database ordini.
• Costi ricorrenti (non inclusi): hosting sGTM o CAPI Gateway, da circa 20$/mese in base ai volumi.
• Pagamento: 50% all’avvio, 50% al go-live. Fattura italiana con P.IVA.