Pixel e Conversions API inviano lo stesso lead: Meta lo conta due volte?

Apri Gestione eventi e trovi lo stesso evento Lead ricevuto dal browser e dal server. Due righe, due origini: Meta sta contando due conversioni?

Non necessariamente. In una configurazione che usa Meta Pixel e Conversions API, inviare la stessa azione da entrambi i canali può essere intenzionale. Il browser offre un segnale immediato; il server aggiunge un percorso controllato dall’infrastruttura. Il punto è fare capire a Meta che quei due messaggi descrivono la stessa azione, non due lead distinti.

Due invii possono rappresentare una sola conversione

Meta tratta gli eventi browser e server come due modalità di trasporto verso lo stesso dataset. La documentazione consiglia di usare Conversions API come estensione del Pixel e, quando la stessa azione viene inviata da entrambe le fonti, di assegnare lo stesso identificativo ai due eventi. Fonte: Meta, relazione tra eventi server e browser.

Per la deduplicazione principale devono coincidere due elementi:

• il nome dell’evento: per esempio Lead nel Pixel e Lead come event_name nel server;
• l’identificativo dell’evento: eventID nel browser ed event_id nella richiesta Conversions API.

Quando nome e ID corrispondono, Meta può riconoscere le due copie e conservarne una ai fini del conteggio. Se l’evento browser ha ID lead-8472 e quello server genera autonomamente lead-1931, i valori sono entrambi “unici”, ma non collegano la stessa azione. È una coppia di gemelli senza cognome: il sistema non sa che devono stare insieme. Fonte: Meta, deduplicazione tra Pixel e Conversions API.

L’ID deve essere condiviso, non soltanto unico

L’errore più comune è generare un ID nel tag web e un altro nel tag server. La regola corretta è: un identificativo per ogni azione reale, poi lo stesso valore attraversa browser e server.

Con Google Tag Manager e Stape, l’ID può essere creato nel container web, allegato all’evento inviato al server e letto dal tag Meta Conversions API nel container server. Stape documenta questo flusso tramite una variabile Unique Event ID e il passaggio del valore con il metodo scelto per trasportare i dati al server GTM. Fonte: Stape, configurazione di Meta Conversions API.

Non userei un valore fisso come lead per tutte le richieste: azioni diverse finirebbero per sembrare copie. Non genererei neppure l’ID al caricamento della pagina se il modulo può essere inviato più tardi o più volte. L’identificativo va associato al momento preciso che rappresenta la conversione.

Deduplicare l’evento non significa deduplicare il contatto

Qui si nascondono tre problemi diversi:

• stessa azione, due canali: Pixel e server inviano una copia ciascuno; nome e ID devono coincidere;
• stessa azione inviata più volte: un doppio trigger o un nuovo tentativo tecnico dovrebbe conservare lo stesso ID;
• due azioni reali della stessa persona: due invii del modulo possono avere ID diversi e risultare entrambi eventi validi, anche se nel CRM appartengono allo stesso contatto.

Meta documenta che l’uso dello stesso event_id e event_name consente anche di rendere sicuro un nuovo tentativo di invio: le copie già ricevute vengono riconosciute come duplicati. Fonte: Meta, uso della Conversions API e reinvii.

La deduplicazione tecnica non decide però quanti lead unici esistano nel CRM. Se la stessa persona compila lunedì e venerdì, potrebbero essere due richieste ma un solo contatto. È il tema affrontato nell’articolo su come gestire due compilazioni della stessa persona.

Un esempio ipotetico

Esempio ipotetico, non riferito a un cliente: Anna invia un modulo preventivo. Il container web crea l’ID form-20261026-a8f4, lo passa sia al Pixel sia alla richiesta diretta al container server. Il tag Conversions API riutilizza quel valore e invia event_name: Lead.

Meta riceve una copia Browser e una Server con lo stesso nome e lo stesso ID: la coppia può essere deduplicata. Se Anna preme nuovamente “Invia” dopo aver corretto il telefono, bisogna decidere a monte che cosa rappresenta quell’azione. Se è un nuovo invio reale, avrà un nuovo ID; se è soltanto il ritentativo automatico della stessa richiesta, deve mantenere quello precedente.

Nel CRM conserverei inoltre un identificativo stabile del contatto e uno della singola richiesta. In questo modo il commerciale vede una persona con due interazioni, mentre Meta riceve segnali tecnici coerenti. Le due strutture rispondono a domande diverse.

Come verificare senza fidarti del solo totale

• Invia un modulo di prova una sola volta e annota l’ID generato.
• Controlla nel browser che il Pixel trasmetta quell’ID con il nome corretto.
• Apri l’anteprima server GTM e verifica che lo stesso valore arrivi al tag Conversions API.
• Controlla in Gestione eventi le origini Browser e Server e lo stato della deduplicazione.
• Ripeti il test con un secondo invio: l’ID deve cambiare tra le azioni, non tra i due canali della stessa azione.
• Verifica infine che il CRM abbia una sola richiesta per ogni azione e che mantenga il collegamento con il contatto.

Non confondere la deduplicazione con la qualità di corrispondenza. Dati come email, telefono, fbp o fbc possono aiutare Meta ad associare un evento, ma non sostituiscono automaticamente la coppia coerente di nome e ID usata nel flusso principale di deduplicazione. I parametri server sono descritti separatamente nella documentazione ufficiale. Fonte: Meta, parametri degli eventi server.

Il dominio personalizzato di Stape e il corretto endpoint server-side completano l’infrastruttura, ma non correggono ID discordanti. Allo stesso modo, Conversions API non elimina le scelte di consenso: il flusso deve rispettare la configurazione descritta nell’articolo su Consent Mode v2 e rifiuto dei cookie.

La domanda finale non è “vedo due eventi?”. È: “le due copie della stessa azione portano davvero lo stesso nome e lo stesso ID, mentre le azioni diverse ricevono ID diversi?”. Se la risposta è verificata dal browser fino al server e al CRM, due canali possono raccontare una sola conversione senza gonfiare il funnel.

Fonti ufficiali consultate il 26 ottobre 2026. L’esempio è ipotetico. Deduplicazione e tracking server-side non eliminano gli obblighi di consenso e non garantiscono risultati pubblicitari.