Meta Conversion API: cos’è, a cosa serve e come evitare i doppioni

Perché usare il server se c’è già il pixel?

Perché il pixel dipende dal browser: problemi di rete o una pagina che non finisce di caricarsi possono fargli perdere l’evento. Meta consiglia di usare i due insieme e di mandare dal server gli stessi eventi, come acquisto e inizio del pagamento. Il server fa anche una cosa che il pixel non può fare: inviare eventi avvenuti fuori dal sito.

Aspetto	Pixel	Conversion API
Da dove parte	Dal browser del visitatore	Dal tuo server o da un contenitore server
Che cosa può fermarlo	Rete, pagina interrotta, blocchi del browser	Errori di configurazione o di autorizzazione
Dati del cliente	Quelli disponibili nella pagina	Quelli che scegli di inviare, compresi quelli dell’ordine
Eventi fuori dal sito	No	Sì

Il server non è una scorciatoia per aggirare il banner dei cookie. Il consenso resta una condizione anche qui: ne parliamo più sotto. Se devi ancora capire come funziona un contenitore server, trovi le basi in GTM server side, e il confronto per decidere in client side o server side.

Il portale di marginalità lavora sui dati di Google e non legge Meta Ads. Meta rientra nella consulenza sui tracciamenti, che configura e controlla gli invii, non in quello che il portale mostra.

Come funziona la deduplica con event_id?

Meta considera doppi due eventi se hanno lo stesso identificativo e lo stesso nome. Lato browser sono eventID ed event, lato server event_id ed event_name. Se la coppia arriva allo stesso pixel entro 48 ore dal primo evento, i successivi vengono scartati.

Ecco i due invii per lo stesso ordine di esempio. Il numero d’ordine, con un prefisso, è una buona fonte per l’identificativo perché è unico e lo conoscono sia la pagina sia il server.

// Nel browser: eventID è il quarto argomento
fbq("track", "Purchase", { value: 84.50, currency: "EUR" }, { eventID: "ordine-1042" });

// Dal server: stesso nome, stesso identificativo
{
  "event_name": "Purchase",
  "event_id": "ordine-1042",
  "event_time": 1790000000,
  "action_source": "website",
  "event_source_url": "https://www.negozio-esempio.it/conferma-ordine/",
  "user_data": {
    "em": ["HASH_SHA256_DELL_EMAIL"],
    "client_user_agent": "USER_AGENT_DEL_BROWSER",
    "fbp": "VALORE_DEL_COOKIE_FBP",
    "fbc": "VALORE_DEL_COOKIE_FBC"
  },
  "custom_data": { "value": 84.50, "currency": "EUR" }
}

Tre dettagli che fanno saltare tutto:

• Il nome deve coincidere esattamente. Purchase da una parte e purchase dall’altra sono due eventi diversi.
• Il tempo conta. Un invio dal server che parte oltre le 48 ore dal primo non viene deduplicato. E event_time non può essere più vecchio di 7 giorni.
• I contenuti devono essere uguali. Se browser e server non differiscono in modo significativo, di norma Meta tiene il primo arrivato: un valore con IVA da una parte e senza dall’altra rende il dato casuale.

Esiste un’alternativa basata su fbp o external_id, ma funziona soprattutto quando il browser arriva per primo e non toglie i doppioni generati da una fonte sola. La via consigliata resta quella con event_id. Le altre cause di doppioni, anche fuori da Meta, sono raccolte in conversioni doppie.

Che cos’è l’Event Match Quality e come si alza?

È un punteggio da 1 a 10 che dice quanto i dati di un evento dal server permettono di collegarlo a un account Meta. Conta perché solo gli eventi collegati possono servire per l’attribuzione e per ottimizzare la consegna degli annunci. Dove possibile, Meta suggerisce di puntare a 6,0 o più.

Il punteggio sale con dati più numerosi e migliori, sempre con il permesso di inviarli. Alcuni vanno trasformati in hash, altri devono arrivare così come sono: confonderli è un errore frequente.

Parametro	Che cos’è	Hash?
em, ph	Email e telefono, dopo la normalizzazione	Sì
fn, ln	Nome e cognome	Sì
external_id	Il tuo identificativo del cliente	Consigliato
client_ip_address	Indirizzo IP	No, mai
client_user_agent	Il browser usato: obbligatorio per gli eventi dal sito	No
fbp, fbc	Cookie del pixel e identificativo del clic	No

Per gli eventi del sito sono obbligatori anche action_source ed event_source_url. Gli esempi di Meta usano SHA-256, lo stesso algoritmo che trovi nelle conversioni avanzate di Google Ads, ma con regole di normalizzazione proprie: non riusare la stessa funzione senza controllarle.

Non inseguire il punteggio mandando tutto quello che hai. Meta raccomanda di inviare gli eventi il più vicino possibile al momento in cui accadono, e combinazioni troppo generiche di dati vengono scartate.

Che cosa cambia per il consenso?

Niente: spostare l’invio sul server cambia la strada del dato, non il permesso che serve per farlo partire. Se il visitatore rifiuta i cookie di marketing, il contenitore server deve saperlo e comportarsi di conseguenza. Meta stessa ricorda di avere il permesso adeguato prima di condividere i dati con terzi.

• Il banner deve passare la scelta anche all’evento diretto al server, non solo ai tag del browser.
• I dati del cliente vanno inviati solo nei casi decisi con il tuo legale.
• Il token di accesso è una credenziale: sta nel contenitore server, mai nel browser o in un file condiviso.

La parte tecnica si può provare con un test. La parte legale, cioè quali dati e su quale base, va decisa con chi segue la privacy dell’azienda. Il funzionamento del consenso lato Google, che spesso condivide lo stesso banner, è spiegato in Consent Mode v2.

Come controlli che pixel e server lavorino insieme?

Si controlla in Gestione eventi (Events Manager), in tre tappe: arrivo, prova e deduplica.

1. Arrivo. Apri il pixel dalla pagina Origini dei dati (Data Sources) e guarda la Panoramica (Overview): gli eventi dovrebbero comparire entro 20 minuti, e la colonna del sistema di connessione dice da quale canale arrivano.
2. Prova. Nella sezione Testa gli eventi (Test Events) ottieni un codice: mandalo come test_event_code per vedere l’evento nella finestra di prova, e toglilo prima di andare online.
3. Deduplica. Nei dettagli dell’evento (Event Details) apri la scheda dedicata, Event Deduplication nell’interfaccia in inglese, e leggi la percentuale di eventi deduplicati. Se è troppo bassa, compare un avviso.

Poi fai il controllo che i pannelli non possono fare per te: prendi un giorno di ordini e confrontalo con gli acquisti ricevuti da Meta.

Sintomo	Causa probabile	Dove guardare
Acquisti quasi doppi rispetto agli ordini	Manca event_id su una delle due parti	Scheda di deduplica
Copertura bassa della chiave di deduplica	Chiavi non univoche o presenti su un lato solo	Stessa scheda, uso della chiave
Valori diversi dal negozio	Regole diverse su IVA o spedizione	Il contenuto dei due invii
Punteggio basso	Dati del cliente pochi, o hash su ciò che non lo vuole	Event Match Quality nella panoramica

Su WooCommerce valore, identificativo e dati dell’ospite vanno letti dall’ordine: come farlo è in tracciamento WooCommerce con GTM. Se preferisci affidare il lavoro, la configurazione di pixel e server rientra nel tracciamento delle conversioni Google Ads e Meta, che si appoggia al contenitore server.

Il motivo per fare tutto questo è economico. Se Meta conta due volte, un budget può sembrare redditizio e non esserlo: la pubblicità va giudicata sul guadagno, non sul numero che la piattaforma riporta.

Domande frequenti

Fonti

• Meta for Developers: deduplicare gli eventi di pixel e server
• Meta for Developers: buone pratiche della Conversions API
• Meta for Developers: verificare la configurazione
• Meta for Developers: parametri delle informazioni sul cliente
• Meta for Developers: usare la Conversions API e Test Events