La stessa persona compila due volte: hai due lead o una conversione duplicata?

Una persona compila il modulo lunedì. Mercoledì lo ricompila, magari da un altro annuncio. Il CRM crea due righe e le piattaforme registrano due conversioni. Hai ottenuto due lead, una persona interessata due volte oppure un duplicato tecnico?

La risposta non si trova scegliendo una casella in Google Ads. Prima bisogna separare quattro oggetti: evento, invio, contatto e opportunità commerciale. Se li chiami tutti “lead”, il report sembra preciso solo perché ha molte cifre.

Un evento non è necessariamente una nuova persona

Ogni invio valido del modulo è un evento. Può rappresentare una nuova persona, ma anche un contatto già noto che chiede un servizio diverso, corregge i dati o ripete la richiesta perché non ha ricevuto risposta.

Nel CRM terrei quindi un identificativo stabile per il contatto e un identificativo separato per ogni richiesta. Non fonderei automaticamente due persone solo perché condividono telefono o indirizzo email: un recapito aziendale può essere usato da più colleghi, mentre una stessa persona può utilizzare recapiti diversi. La deduplicazione automatica deve produrre casi da verificare quando l’identità non è certa, non cancellare storia commerciale.

La struttura minima è:

• persona o azienda: chi stiamo seguendo;
• richiesta: quale bisogno è stato espresso e quando;
• opportunità: quale trattativa nasce, se nasce;
• esito: qualificata, persa, venduta o altro stato definito.

In questo modo puoi conservare due invii senza trasformarli automaticamente in due potenziali clienti.

Duplicato tecnico e richiesta ripetuta non sono la stessa cosa

Un duplicato tecnico si verifica, per esempio, quando lo stesso evento viene inviato dal browser e dal server oppure quando una pagina di conferma viene ricaricata. Una richiesta ripetuta avviene invece quando la persona compie davvero una seconda azione.

La differenza è decisiva. Nel primo caso vuoi che la piattaforma conti una sola occorrenza. Nel secondo devi conservare entrambi gli invii, poi decidere come interpretarli commercialmente.

Google Ads documenta l’uso di un ID transazione dinamico e univoco per evitare che la stessa conversione venga conteggiata due volte. Se lo stesso evento arriva anche dal backend, l’identificativo deve rimanere coerente tra tag e invio server-to-server. Google precisa inoltre che l’ID non deve contenere dati capaci di identificare il cliente. Fonte: Google Ads, ID transazione e deduplicazione.

Anche LinkedIn prevede una logica di deduplicazione quando la stessa conversione viene trasmessa sia con Insight Tag sia tramite Conversions API: browser e server devono condividere lo stesso eventId. Fonte: LinkedIn Marketing API, deduplicazione.

Il principio operativo vale anche in un’implementazione server-side con Stape: il server non riconosce magicamente che due chiamate descrivono la stessa azione. Serve generare l’identificativo nel punto corretto, conservarlo e riutilizzarlo per le copie dello stesso evento. Due invii volontari distinti, invece, dovrebbero avere identificativi distinti.

“Una” conversione in Google Ads non deduplica il CRM

Google Ads consente di conteggiare ogni conversione oppure una sola conversione per interazione con l’annuncio. La documentazione propone “Ogni” per le vendite e “Una” quando interessa un lead unico per clic. Fonte: Google Ads, opzioni di conteggio.

Questa impostazione cambia il report della specifica azione di conversione; non stabilisce se due record del CRM appartengano alla stessa persona e non unifica richieste provenienti da interazioni diverse. Allo stesso modo, un ID evento elimina la doppia trasmissione dello stesso fatto, non decide se una nuova compilazione abbia valore commerciale.

Per questo non userei una sola regola per tutto. Un acquisto ripetuto può generare nuovo valore. Tre invii identici in pochi secondi possono indicare un problema del modulo. Due richieste distanziate su servizi diversi possono diventare due opportunità reali.

Un esempio: due moduli, una persona, due significati

Esempio ipotetico, non riferito a un cliente: Marta invia una richiesta per un impianto fotovoltaico. Il browser e il server trasmettono lo stesso evento con il medesimo identificativo: la piattaforma deve deduplicarlo. Dopo due settimane Marta compila un secondo modulo per una colonnina di ricarica: è un nuovo invio reale, anche se il CRM riconosce la stessa persona.

Il CRM dovrebbe conservare entrambe le richieste sotto il contatto di Marta. Il commerciale potrà aprire una seconda opportunità oppure collegarla alla prima, secondo il processo aziendale. Alle piattaforme non invierei due volte la prima richiesta; valuterei invece quali eventi della seconda rappresentano davvero un nuovo segnale utile.

La regola pratica da mettere per iscritto

Costruirei una tabella decisionale con almeno questi casi:

• stesso ID evento ricevuto da browser e server: una sola conversione;
• stesso modulo inviato due volte a pochi secondi: conserva il log, verifica e non creare automaticamente due opportunità;
• stessa persona, bisogno diverso: un contatto con richieste separate;
• stessa richiesta riaperta dopo settimane: nuova attività, ma non necessariamente un nuovo lead acquisito;
• due vendite reali: due transazioni, ciascuna con il proprio identificativo.

Nel CRM vanno conservati origine, identificativi e stati; nel registro degli invii annoterei piattaforma, evento, ID e risposta ricevuta. Prima di usare questi dati per le offerte automatiche, eseguirei un test completo dal modulo al ritorno della vendita.

Il numero giusto dipende dalla domanda

Per valutare il carico commerciale possono interessare tutti gli invii validi. Per misurare l’acquisizione possono servire persone o aziende nuove. Per leggere la pipeline contano opportunità e vendite. Sono indicatori diversi, non versioni concorrenti della stessa verità.

La deduplicazione corretta non deve rendere il numero più basso: deve fare in modo che ogni riga rappresenti ciò che dichiara. Solo allora campagne, CRM e vendite possono scambiarsi segnali senza moltiplicare i clienti per errore.

Fonti ufficiali consultate il 21 ottobre 2026. L’esempio è ipotetico. Le configurazioni tecniche vanno verificate sul singolo account e non garantiscono risultati pubblicitari.