Tracciamento conversioni errori: quando l’evento Purchase si spara due volte

Risposta diretta

Il double counting sugli eventi di conversione succede quando due workflow distinti conoscono lo stesso fatto — una vendita — e lo riferiscono entrambi a Meta. Nessuno dei due workflow è sbagliato preso da solo. Il sistema nel suo insieme mente. Il fix non è tecnico: è una regola di governance. Un evento di conversione ha un solo punto di emissione, e va deciso prima di costruire il secondo flusso, non dopo.

Il problema che non produce errori

I tracciamento conversioni errori più costosi non mandano alert. Arrivano silenziosi, con risposte HTTP 200 su ogni chiamata, con workflow che girano regolari e log puliti. Il doppio Purchase verso Meta è esattamente questo tipo di problema. Due workflow separati — chiamiamoli Contract Signed e Deal Won — sanno entrambi che una vendita è avvenuta. Hanno ragione entrambi: la firma del contratto è una conversione, il deal marcato come vinto è una conversione. Sono lo stesso fatto visto da due angolature diverse. Meta riceve due eventi. Ottimizza su due eventi. Le campagne lavorano su un universo gonfiato e tu non lo vedi finché qualcuno non apre il workflow per un motivo completamente diverso.

Perché la correttezza locale non basta

Quando costruisci un workflow nuovo, la domanda che ti fai è: «questo flusso sa della vendita?». Se la risposta è sì, aggiungi il nodo che spara il Purchase. Sembra logico. È il posto sbagliato dove guardare. La domanda giusta è un’altra: «chi sta già sparando questo evento?». La correttezza locale — ogni workflow fa esattamente quello che deve fare — non garantisce la correttezza del sistema nel suo insieme. Due emettitori su uno stesso dataset di conversione non si sommano in un risultato più preciso: si sommano in un numero falso che sembra vero.

Questa è la dinamica che rende il double counting così difficile da intercettare. Non c’è un nodo che fallisce. Non c’è un’eccezione nel log. C’è solo un contatore che sale il doppio di quello che dovrebbe, con la stessa cadenza, con la stessa regolarità. I report di Meta mostrano un ROAS che non corrisponde alla realtà, le campagne allocano budget su segmenti che ottimizzano su segnali gonfiati, e il sistema continua a girare in silenzio producendo danni che diventano visibili solo retrospettivamente — se diventano visibili.

La migrazione che non spegne il vecchio flusso

C’è una variante di questo errore ancora più comune: la migrazione incompleta. Costruisci un workflow nuovo per gestire l’evento Purchase, magari perché quello vecchio era fragile o perché cambia la fonte del dato. Il nuovo gira. Il vecchio non lo spegni subito perché «poi lo tolgo». Non lo togli. A quel punto hai due emettitori attivi, e ogni conversione genera due eventi.

La regola è semplice e non negoziabile: quando sposti un evento su un workflow nuovo, il vecchio si spegne nello stesso atto. Non in un secondo momento, non appena hai verificato che il nuovo funziona. Nello stesso atto. Il costo di dimenticarlo non è una riga sbagliata in un report — sono i dati di ottimizzazione pubblicitaria avvelenati per tutto il tempo che passa tra l’attivazione del nuovo e il momento in cui qualcuno se ne accorge.

Il caso del dataset ID sbagliato

C’è una variante aggiuntiva che amplifica il danno: oltre al vecchio workflow ancora acceso, l’evento viene sparato verso il dataset sbagliato. Due emettitori, dataset diversi, configurazione incrociata. Ogni booking finisce per generare eventi multipli su più dataset contemporaneamente. A quel punto non stai solo gonfiando un numero: stai inquinando più set di dati di addestramento con segnali incoerenti tra loro.

Sovra-conteggio e sotto-conteggio: due facce dello stesso difetto

Il double counting è la variante più visibile, ma la catena di misurazione sbaglia in entrambe le direzioni. Un numero gonfiato e un numero mancante hanno la stessa proprietà: sono plausibili. Nessuno dei due si presenta come un errore. Il webhook di un’unità di business che non esiste ancora manda zero eventi — e zero è un numero che sembra normale finché non lo confronti con i pagamenti effettivi. Un Purchase che arriva due volte genera un picco che non si distingue da una buona settimana di campagna.

Nei sistemi di tracciamento commissioni il meccanismo è identico: un tag mancante o doppio produce un calcolo sbagliato che nessun alert segnala, perché il sistema ha eseguito correttamente le istruzioni che gli hai dato. Il problema era a monte, nel momento in cui quelle istruzioni sono state scritte.

Come si struttura il fix

Il fix non è un nodo aggiuntivo. È un cambio di metodo su come si decide dove mettere i nodi.

Censimento dei punti di emissione

Prima di toccare qualsiasi cosa, mappa tutti i workflow attivi che emettono eventi verso Meta — o verso qualunque sistema di misurazione esterno. Non quello che ricordi, non quello che pensi sia attivo: tutti. Aprili uno a uno. Cerca il nodo che chiama l’API delle Conversions o che spara l’evento via pixel. Costruisci una lista con tre colonne: nome del workflow, evento emesso, dataset di destinazione. Se quella lista non esiste già, il tuo sistema ha una guardia mancante.

Punto di verità unico

Per ogni evento di conversione, identifica dove nasce la verità di quel fatto. Non dove è visibile — è visibile in più posti, per definizione — ma dove nasce. Se la vendita nasce dal pagamento confermato, il Purchase si spara dal webhook di pagamento. Se nasce dalla firma del contratto, si spara da lì. Scegli uno, documenta perché hai scelto quello, e togli tutti gli altri.

Quando hai casi diversi che devono generare lo stesso evento — per esempio una vendita diretta e una vendita da un canale specifico — la soluzione non è due emettitori ma un emettitore con un IF sul campo che distingue i casi. Un solo nodo, due rami, un evento. Questo è esattamente il movimento corretto: portare la logica dentro un workflow unico con un IF sulla BookingSource, invece di tenere due workflow separati che scrivono sullo stesso dataset.

La differenza tra parallelo legittimo e double counting

C’è una distinzione che vale la pena fissare. Due sistemi in parallelo sono un test se scrivono in registri separati che poi confronti: li affiancchi, vedi se i numeri tornano, e poi decidi quale tenere. Sono un doppio conteggio se scrivono nello stesso posto. Il criterio è il registro di destinazione, non la presenza di due flussi attivi contemporaneamente. Se stai migrando un sistema di affiliazione e tieni il vecchio acceso mentre il nuovo scala, stai facendo un test — ma solo se i due sistemi tengono libri mastri distinti. Se invece entrambi mandano eventi allo stesso dataset Facebook, hai un problema indipendentemente da quanto sia giustificata la transizione.

Scenario	Due workflow attivi	Registro di destinazione	Risultato
Migrazione con test	Sì	Separato per ciascuno	Confronto possibile, nessun gonfiamento
Double counting	Sì	Stesso dataset	Evento duplicato, ottimizzazione su dati falsi
IF su emettitore unico	No	Unico	Segnale pulito, casi distinti gestiti nel nodo
Vecchio non spento	Sì (per errore)	Stesso dataset	Identico al double counting, più difficile da trovare

Dove questo si rompe nei sistemi reali

Il naming incoerente tra sistemi è la causa che rende tutto più difficile da diagnosticare. Se un campo si chiama Program Sold in un sistema e contract template in un altro, e i valori possibili non coincidono — uno ha ACADEMY, l’altro ha Academy Pro — il filtro che dovresti usare per escludere i duplicati non funziona. Non perché sia scritto male: perché le parole sono diverse. Aggiungi una variante di prodotto e scopri che il codice è hardcoded su un valore che non esiste più. Retest completo, un giorno perso, e nel frattempo il problema continua a girare.

Questo è il motivo per cui il censimento dei punti di emissione deve includere anche i valori dei campi usati come filtro, non solo i nomi dei workflow. Se costruisci un sistema di automazione marketing su filtri hardcoded invece che su campi dinamici, ogni nuovo prodotto o variante rompe il routing in silenzio.

Per chi usa GoHighLevel come CRM centrale, il punto critico è il momento in cui un’automazione interna e un webhook esterno conoscono entrambi lo stesso stage change. Se non hai deciso esplicitamente quale dei due spara verso Meta, li hai lasciati decidere entrambi — e lo fanno.

Perché il silenzio è il sintomo

Ho gestito l’infrastruttura di un’academy americana che nei mesi buoni superava il milione di dollari al mese di cash collected. Il principio che ho portato da quella esperienza è uno: un’automazione senza guardie esegue sbagliato con la stessa sicurezza con cui esegue giusto. Non rallenta, non dubita, non ti chiama. Produce. E se produce dati di ottimizzazione pubblicitaria gonfiati del doppio, lo fa con la stessa regolarità con cui li produce corretti.

Il double counting sull’evento Purchase non è un bug di Make, n8n o GoHighLevel. È un difetto di progettazione del sistema nel suo insieme. Ogni tool ha fatto esattamente quello che gli hai chiesto. Il problema era a monte, nel momento in cui hai aggiunto il secondo emettitore senza chiederti se il primo stesse già lavorando. La mappa dei processi aziendali automatizzati dovrebbe includere, per ogni evento di conversione, una riga sola con il workflow sorgente. Se quella riga non esiste, il tuo sistema non è monitorato: è solo silenzioso. E il silenzio non è salute.

Domande frequenti

Come capisco se il mio evento Purchase si sta sparando due volte?

Vai nel Meta Events Manager e guarda il grafico degli eventi Purchase nel tempo. Confrontalo con il numero reale di transazioni nello stesso periodo. Se il rapporto è costantemente vicino a 2:1, hai un double counting. L’altro segnale è trovare due workflow distinti con un nodo che chiama le Conversions API sulla stessa action.

Posso usare la deduplication di Meta invece di correggere il flusso?

Meta offre un meccanismo di deduplication basato sull’event_id: se due eventi hanno lo stesso ID arrivano entrambi ma vengono contati una volta sola. Funziona solo se assegni lo stesso ID a entrambe le emissioni dello stesso fatto. Richiede comunque di sapere che hai due emettitori. Correggere il flusso è più pulito e non dipende dalla corretta propagazione di un campo.

Questo problema riguarda solo Meta o anche Google Ads?

Riguarda qualsiasi sistema che riceve eventi di conversione dall’esterno: Google Ads via Conversions API, TikTok Events API, sistemi CRM con lead scoring basato su webhook. La dinamica è identica: due emettitori che scrivono sullo stesso registro producono un numero falso che sembra vero.

Quanto spesso dovrei fare il censimento dei punti di emissione?

Ogni volta che aggiungi o modifichi un workflow che tocca una fase di vendita. Non a cadenza fissa: al momento della modifica. Se il tuo processo di deploy non include la domanda «chi sta già sparando questo evento?», il censimento arriverà sempre dopo il danno.