Come prevenire conversioni duplicate nelle campagne Adgora

Conversioni duplicate nelle campagne Adgora dopo un postback: confronto tra le soluzioni

Una conversione può comparire due volte anche se un visitatore ha completato l’azione una sola volta. Il record aggiuntivo può dipendere da un postback ripetuto, da un endpoint di ricezione che accetta più volte lo stesso evento oppure da un sistema di report che conteggia un evento in due punti diversi. Per capire come evitare conversioni duplicate in Adgora, prima di modificare le impostazioni della campagna ricostruisci l’intero percorso e individua dove compare per la prima volta il secondo record.

Questo confronto esamina tre metodi per prevenire i duplicati: deduplicazione tramite ID evento, controlli basati sull’ID transazione e regole basate su una finestra temporale. La scelta giusta dipende dagli identificatori disponibili nella tua integrazione e dalla possibilità che i clienti effettuino legittimamente più conversioni. Una regola troppo ampia può eliminare vendite o iscrizioni valide.

Definisci i criteri prima di confrontare le soluzioni

Valuta ogni soluzione in base a tre criteri: blocca gli eventi ripetuti? Mantiene le conversioni ripetute legittime? Puoi testarla senza interrompere le campagne attive? Annota questi criteri prima di modificare il flusso dei postback. In caso contrario, una diminuzione delle conversioni potrebbe sembrare un successo anche se la regola ha soppresso attività valide.

Definisci cosa si intende per duplicato per l’azione che stai misurando. Per un acquisto una tantum, è probabile che lo stesso ordine registrato due volte sia un duplicato. Per il rinnovo di un abbonamento, invece, due acquisti effettuati dallo stesso cliente in momenti diversi possono essere entrambi validi. La definizione deve essere specifica per l’evento, non solo per la campagna.

Conserva i dati necessari per confrontare i risultati: l’evento di origine, gli eventuali ID evento o transazione, i tentativi di invio del postback, le risposte dell’endpoint e il report delle conversioni di Adgora. Se un campo non è disponibile, annota la mancanza invece di dare per scontato che due record si riferiscano alla stessa azione. Un semplice registro di test è più utile di una vaga affermazione secondo cui le conversioni «sembrano gonfiate».

Segui una conversione lungo il percorso del postback

Scegli una conversione segnalata e seguila dall’azione iniziale fino alla schermata dei report. Parti dall’evento di origine, ad esempio la conferma di un ordine, l’invio di un modulo o un’azione nell’app. Annotane l’ora e gli eventuali identificatori associati in quel momento. Poi individua il postback in uscita corrispondente e il record presente nell’endpoint di ricezione.

Confronta gli identificatori e gli orari in ogni passaggio. Se l’origine contiene un solo evento ma l’endpoint presenta due record corrispondenti, il secondo record è stato inserito da qualche parte tra l’invio del postback e il salvataggio nell’endpoint. Se l’endpoint ha un solo record ma Adgora mostra due conversioni, verifica il percorso di reporting o di importazione invece di modificare la deduplicazione dell’endpoint.

Individua il punto preciso in cui i dati divergono. Per esempio, un evento inviato dal browser e uno lato server potrebbero segnalare entrambi lo stesso acquisto, oppure un nuovo tentativo potrebbe raggiungere un endpoint che salva ogni richiesta come evento nuovo. Sono due modalità di errore diverse e richiedono soluzioni diverse. Se entrambi i percorsi usano lo stesso ID evento, sarà più facile confrontarli; altrimenti, potrebbe essere necessario aggiungerne uno all’origine.

Registra i passaggi nell’ordine in cui avvengono: evento di origine, generazione del postback, tentativo di invio, risposta dell’endpoint, record salvato e report di Adgora. In questo modo il team avrà una sequenza concreta da verificare. Eviterai anche una deviazione frequente: incolpare la campagna prima di aver controllato se l’endpoint ha già creato due record.

Confronta le strategie di deduplicazione

La deduplicazione dei postback con ID evento è di solito l’opzione più chiara quando la stessa conversione può usare un identificatore univoco e stabile dall’origine al sistema ricevente. L’endpoint salva il primo evento e considera già elaborata una richiesta successiva con lo stesso ID. Verifica che l’ID rimanga invariato durante i nuovi tentativi e nei percorsi browser o server che possono segnalare la stessa azione.

Il confronto tra ID transazione e finestra temporale aiuta a scegliere un criterio adatto agli identificatori disponibili e al tipo di evento. I controlli basati sull’ID transazione possono funzionare bene per gli acquisti, quando ogni ordine ha un riferimento stabile. Sono meno adatti a un modulo per contatti, all’avvio di una prova gratuita o ad altri eventi che non generano naturalmente un ID transazione. Verifica anche l’ambito di validità: un riferimento può essere univoco solo all’interno di un account o di un negozio, quindi la chiave di deduplicazione potrebbe dover includere anche quel contesto.

Le regole basate su una finestra temporale sono un’alternativa quando l’integrazione non dispone di un ID evento o transazione stabile. Possono considerare come un unico evento conversioni corrispondenti avvenute a poca distanza l’una dall’altra, ma «a poca distanza» non significa «lo stesso evento». Un cliente potrebbe completare due azioni valide nell’intervallo scelto. Scegli l’intervallo più breve che risolva il problema di duplicazione osservato e verifica le ripetizioni legittime prima di applicare la regola su larga scala.

La stessa attenzione vale per chi analizza più in generale la misurazione delle campagne, comprese le fonti di traffico e le definizioni di conversione. La guida alle opzioni di targeting delle reti pubblicitarie crypto di Adgora può aiutarti a valutare le scelte di targeting, ma modificare il targeting non corregge un duplicato creato dopo che il postback raggiunge l’endpoint.

Verifica il comportamento dei nuovi tentativi e delle risposte

Un timeout non dimostra che il postback non sia andato a buon fine. L’endpoint potrebbe aver salvato l’evento senza restituire una conferma chiara, inducendo il mittente a riprovare. Verifica come il mittente gestisce i timeout, quali codici di risposta fanno scattare un nuovo tentativo e se l’endpoint risponde solo dopo aver salvato l’evento.

Prima di attribuire i duplicati ai nuovi tentativi, esamina i log effettivi delle richieste e delle risposte. Controlla il numero di tentativi, gli orari, i codici di risposta e se ogni tentativo includeva lo stesso ID evento. Poi verifica il comportamento documentato dell’endpoint nell’ambiente che utilizzi.

La distinzione pratica è questa: se ogni richiesta ripetuta ha lo stesso ID ma l’endpoint le salva tutte, potrebbe essere necessario gestire le richieste in modo idempotente sul sistema ricevente. Se invece le richieste ripetute hanno ID diversi pur riferendosi alla stessa azione di origine, verifica dove vengono generati gli ID. La sola politica sui nuovi tentativi non basta a spiegare questa discrepanza.

Testa le soluzioni con eventi duplicati e ripetuti

Prima di applicare una regola, verifica due casi controllati. Per prima cosa, invia due volte lo stesso postback di conversione con lo stesso identificatore. Il risultato atteso è un solo record salvato. Poi genera due conversioni legittime con identificatori distinti, ad esempio due ordini separati, e verifica che siano entrambe visibili.

Per entrambi i casi, confronta il log di origine, il log degli invii, i record dell’endpoint e il report di Adgora. La soluzione funziona solo se elimina l’evento ripetuto senza cancellare la seconda conversione valida. Se usi una regola basata su una finestra temporale, prova il caso di ripetizione all’interno dell’intervallo proposto: un test al di fuori dell’intervallo non rivelerà se la regola è troppo ampia.

Quando possibile, mantieni il test separato dall’ottimizzazione delle campagne attive. Usa una campagna di test, un endpoint di staging o un evento di test chiaramente identificato, così da non influire sulle decisioni relative alle campagne. Se è indispensabile eseguire un controllo in produzione, concorda l’evento di test e il periodo di osservazione con i responsabili dei report prima di inviarlo.

Se le campagne tracciano anche le azioni nell’app, assicurati che il test rispecchi il modo in cui vengono inviati questi eventi. Una panoramica di pubblicità crypto per campagne di installazione di app può offrire un contesto utile sulla campagna, ma per verificare i duplicati devi comunque seguire lo specifico evento di installazione o in-app lungo il relativo percorso di postback.

Procedi gradualmente e prepara un piano di ripristino

Inizia con un’implementazione limitata: un tipo di evento, un endpoint o una campagna di test. Prima di modificare la regola, salva la configurazione attuale e annota i conteggi di riferimento per gli eventi di origine, i postback inviati, i record dell’endpoint e le conversioni riportate. Senza questi dati iniziali, sarà difficile interpretare un eventuale calo successivo.

Monitora entrambi gli aspetti del problema. Una diminuzione dei duplicati è positiva solo se le conversioni legittime restano intatte. Controlla se mancano record, se gli acquisti ripetuti calano in modo inatteso, se aumentano gli errori di invio o se emerge una discrepanza tra i dati salvati nell’endpoint e quelli riportati da Adgora. Se noti uno di questi segnali, sospendi la modifica e confronta gli ID evento o i riferimenti alle transazioni interessati.

Definisci prima del lancio una condizione chiara per il ripristino. Per esempio, annulla la modifica se una conversione di test nota viene soppressa o se gli eventi ripetuti validi scompaiono dal log dell’endpoint. Mantieni disponibile la regola precedente finché quella nuova non è stata verificata sui dati reali della campagna.

Documenta cosa è stato modificato, quando e quali tipi di evento sono interessati. Questo aiuta a distinguere una correzione dei postback da altre modifiche alla campagna. Inoltre, permette a chi subentra di ripristinare rapidamente il comportamento precedente se il conteggio delle conversioni cambia in modo inatteso.

In sintesi: privilegia l’identificazione del singolo evento, quando possibile

Usa un identificatore univoco e stabile dell’evento se l’integrazione lo supporta e se può viaggiare dall’evento di origine all’endpoint ricevente. In questo modo, il sistema ricevente può riconoscere direttamente una richiesta ripetuta senza considerare duplicata ogni conversione avvenuta a breve distanza da un’altra.

Se non è disponibile un ID evento adatto, usa un ID transazione per gli acquisti quando il relativo riferimento è affidabile. Per gli altri eventi, una regola basata su una finestra temporale può essere l’alternativa più circoscritta disponibile, ma va verificata sulle conversioni ripetute legittime prima dell’implementazione. In un caso come quello delle conversioni duplicate nelle campagne Adgora dopo un postback, la soluzione migliore elimina il record ripetuto senza cancellare la seconda azione reale, non quella che si limita a ridurre il totale.