Deduplicazione degli eventi tra Facebook pixel e Conversions API

La deduplicazione degli eventi del Facebook pixel è il modo in cui Meta riconosce che un evento del Meta Pixel e un evento della Conversions API descrivono la stessa azione, e ne conta uno solo. Meta li abbina per nome e ID: quando l’eventID del pixel è uguale all’event_id del server e i nomi coincidono entro 48 ore, tiene la prima copia e scarta il resto.

Se la sbagli, ogni lead riportato da entrambi i canali viene contato due volte. I lead contati due volte abbassano il costo per lead che Meta ti mostra, quindi un setup rotto sembra una buona settimana. L’articolo del centro assistenza di Meta sulla deduplicazione avverte che numeri di conversione gonfiati artificialmente possono fuorviare le decisioni di ottimizzazione e di allocazione del budget.

Il motivo per cui serve la deduplicazione

Meta consiglia quella che chiama configurazione ridondante: la Conversions API insieme al Meta Pixel, con gli stessi eventi inviati da entrambi (la guida di Meta alla gestione degli eventi duplicati). Il pixel dipende dal browser, e lo stesso articolo del centro assistenza nota che i dati del browser possono essere bloccati o persi per le impostazioni del browser o per problemi di connessione. Il server manda quello che il browser perde. Meta fissa anche un obiettivo nel suo articolo sui dettagli degli eventi del server: la Conversions API dovrebbe coprire il 75% degli eventi del pixel.

La ridondanza crea il problema di cui parla questa guida. Se invii lo stesso evento da entrambe le parti devi dire a Meta quali copie vanno insieme. Se invii eventi diversi da ciascuna parte (per esempio PageView dal browser e Lead dal server) non c’è niente da deduplicare.

Per la lead gen la linea è chiara: invia il Lead dal server ogni volta, tieni il Lead del pixel come copia ridondante e dai a entrambi lo stesso ID. L’evento server è quello che controlli tu, ed è il senso stesso del tracking lato server. L’evento del browser è quello che può arrivare oppure no.

Come funziona la deduplicazione degli eventi del Facebook pixel

La regola: event_name ed event_id

Meta considera identici due eventi quando valgono entrambe le condizioni:

1. l’eventID del pixel corrisponde all’event_id della Conversions API;
2. il nome dell’evento del pixel corrisponde all’event_name della Conversions API.

Nel pixel, eventID va nel quarto argomento della chiamata fbq. Per un Lead senza valore né valuta:

fbq('track', 'Lead', {}, {eventID: 'lead_3f9c2a7e-1b4d-4c8e-9a51-0d6e2f7b8c14'});

La finestra di 48 ore e quale copia tiene Meta

Gli eventi vengono deduplicati solo se arrivano entro 48 ore dal primo evento che Meta ha ricevuto con quell’event_id. Dentro la finestra, Meta in genere preferisce l’evento ricevuto per primo quando i due non differiscono in modo significativo nel contenuto. Il suo riferimento sugli eventi server aggiunge che, quando un evento del browser e uno del server arrivano a meno di 5 minuti l’uno dall’altro, viene favorito quello del browser.

La stessa logica vale per le ripetizioni da una sola origine. Secondo la guida di Meta all’uso dell’API, quando lo stesso event_id con lo stesso event_name arriva più volte, Meta tiene solo la prima copia: per questo i nuovi tentativi sono sicuri.

Cosa significa nei casi più comuni (tempi di esempio):

Il metodo di riserva: fbp o external_id

Meta ha un secondo metodo. Se l’evento del browser e quello del server hanno lo stesso event_name più lo stesso fbp e/o external_id, Meta confronta l’evento server con un evento del browser inviato prima. La sua guida elenca i limiti:

• in genere funziona solo quando l’evento del browser viene inviato per primo e quello del server lo segue;
• gli eventi server non vengono scartati se nelle 48 ore precedenti non è arrivato un evento del browser, anche se un evento del browser identico arriva dopo quello del server;
• non deduplica all’interno di una sola origine: due eventi del browser identici, o due eventi server identici, vengono tenuti entrambi.

L’ultimo punto è l’opposto del metodo con event_id. Considera fbp ed external_id una rete di sicurezza ed event_id la chiave; è anche il metodo che Meta indica come consigliato.

Un evento Lead lato server con event_id

La metà del pixel è la chiamata fbq qui sopra. La metà del server è una POST a https://graph.facebook.com/<API_VERSION>/<PIXEL_ID>/events con lo stesso ID. Payload di esempio per un Lead da un form su landing page:

{
  "data": [
    {
      "event_name": "Lead",
      "event_time": 1793787302,
      "event_id": "lead_3f9c2a7e-1b4d-4c8e-9a51-0d6e2f7b8c14",
      "action_source": "website",
      "event_source_url": "https://offer.example.com/free-quote",
      "user_data": {
        "em": ["10928b45363b7d849e040470c3277657f8177ef5a953a092b4302f149757a02e"],
        "ph": ["75565655f639ba28fbb0a88254e0d01fad0a351049bde96a286e336219a33e5f"],
        "client_ip_address": "2001:0db8:85a3:0000:0000:8a2e:0370:7334",
        "client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148",
        "fbc": "fb.1.1793787151204.IwAR2F4-dbP0l7Mn1IawQQGCINEz7PYXQvwjNwB_qa2ofrHyiLjcbCRxTDMgk",
        "fbp": "fb.1.1793787151880.1684203391"
      }
    }
  ]
}

Cosa controllare:

• event_name è Lead, scritto esattamente come nel pixel.
• event_id è la stringa che il pixel ha inviato come eventID.
• event_time è in secondi Unix (qui il 4 novembre 2026, 10:15:02 UTC). Meta rifiuta l’intera richiesta se anche un solo evento ha più di 7 giorni.
• action_source è obbligatorio, ed event_source_url è obbligatorio per gli eventi del sito web.
• em e ph sono hash SHA-256 di email e telefono normalizzati, mentre fbc (che contiene l’fbclid), fbp, l’IP e lo user agent vanno in chiaro. La guida all’Event Match Quality spiega l’hash, e cookie _fbc e _fbp, spiegati spiega i due valori dei cookie.

DropCPL invia l’evento Lead a Meta dal server con un event_id per la deduplicazione, più fbc e fbp. Il tuo CPL è calcolato sui lead ricevuti dal tuo server, quindi un errore di deduplicazione dalla parte di Meta non gonfia mai il numero su cui decidi. Inizia gratis →

Da dove deve arrivare l’event_id

Un ID per lead, generato una volta, usato da entrambe le parti. Per un form su una landing page il flusso più semplice è:

1. Quando il visitatore invia il form, il browser genera l’ID. Va bene un UUID: Meta accetta qualsiasi stringa univoca.
2. Il pixel invia Lead con quell’ID come eventID.
3. Lo stesso ID arriva al tuo server dentro la POST del form, per esempio come campo nascosto.
4. Il tuo server invia il Lead tramite la Conversions API con quell’ID come event_id, e lo salva insieme al lead.

Se JavaScript non è partito, non è partito nemmeno il pixel, quindi il server può generare il proprio ID senza rischio di duplicati. Funziona anche il flusso inverso: il server crea il lead, restituisce il suo ID e la schermata di conferma lancia il pixel con quell’ID. Gli esempi di event_id che fa Meta sono numeri d’ordine e ID di transazione; per gli eventi che non ne hanno uno va bene un numero casuale, purché lo stesso numero venga inviato sia dal browser sia dal server.

Gli errori che rompono la deduplicazione degli eventi

La lista di risoluzione dei problemi di Meta, nello stesso articolo del centro assistenza, mette al primo posto la coerenza dell’event_id e chiede di verificare che event_name ed event_id siano formattati in modo identico in tutte le origini.

Come verificare la deduplicazione in Events Manager

1. Prova un invio reale. In Events Manager (Gestione eventi) apri il tuo dataset e la tab Testa gli eventi, copia il codice di test e invialo come test_event_code al livello principale della richiesta server. Invia il form sulla tua landing page e controlla che arrivino entrambi i Lead, del browser e del server, e che uno dei due sia deduplicato; il centro assistenza di Meta indica proprio questo strumento per vedere quali eventi vengono ricevuti, deduplicati o scartati. Poi togli il codice. Meta precisa che gli eventi inviati con test_event_code non vengono scartati: finiscono in Events Manager e sono usati per il targeting e la misurazione, quindi per Meta un lead di prova è un Lead vero.
2. Leggi la tab Deduplicazione degli eventi. Sotto Visualizza dettagli dell’evento, la tabella delle chiavi di deduplicazione mostra la quota di eventi del pixel e del server ricevuti con ciascuna chiave, e la sovrapposizione mostra la quota ricevuta da entrambe le origini. Se entrambe le origini riportano event_id e la sovrapposizione resta bassa, gli ID non sono le stesse stringhe.
3. Non leggere Eventi ricevuti come un allarme. Nella tab Panoramica dell’evento, Eventi ricevuti è la somma degli eventi del pixel e del server prima della deduplicazione, quindi è normale che sembri alto.
4. Confronta con i lead che hai ricevuto. I lead riportati da Meta e il tuo conteggio non coincidono mai esattamente, per i motivi spiegati in CPL reale vs CPL della piattaforma. Un conteggio di Meta vicino al doppio del tuo, però, indica per prima cosa la deduplicazione. È il controllo numero tre di CPL: cinque cose da tenere a mente.