Caso studio
Tre mesi di acquisti inviati senza identità: enrichment retroattivo con conservazione a 48 ore
Gli eventi erano già stati inviati, e un evento inviato non si modifica. Li abbiamo rispediti con email e telefono cifrati senza generare un solo duplicato, e reso ripetibile l'operazione su ogni sessione futura.
Un brand di moda premium su Shopify, prezzo unitario alto e volumi di ordine contenuti, appena migrato da una piattaforma con tracciamento carente.
Il vincolo: gli eventi erano già stati inviati. Tre mesi di acquisti erano arrivati alla Conversions API con i dati di prodotto corretti e la sezione dell’identità utente vuota, e un evento inviato non si modifica. In più il problema non era solo passato: gli eventi a monte dell’acquisto nascono anonimi per costruzione, perché l’email compare solo al checkout.
Il risultato: i tre mesi di storico rispediti con email e telefono cifrati, senza generare un solo evento duplicato, e un servizio che ripete la stessa operazione in automatico su ogni sessione futura entro una finestra di 48 ore.
Qui sotto c’è il meccanismo che rende possibile riscrivere un evento già ricevuto, come abbiamo dimensionato la finestra di conservazione, e cosa dichiariamo al cliente prima di partire.
Cosa contiene questo caso
- come capire se un punteggio di corrispondenza basso dipende da quanti eventi mandi o da cosa contengono
- come rispedire un evento già inviato senza che venga contato due volte
- come dimensionare una finestra di conservazione dati fra utilità e costo
- come dichiarare un comportamento di piattaforma non documentato senza rinunciare a usarlo
Indice
- Il cliente e il punto di partenza
- Recupero dello storico
- Servizio di enrichment di sessione
- Nota di metodo sui numeri
- Cosa non ha funzionato
- Cosa faremmo adesso
- Conclusione
Il cliente e il punto di partenza
Moda premium, prezzo unitario alto, volumi di ordine bassi rispetto a un e-commerce generalista. È la configurazione in cui ogni singola conversione pesa di più, perché non ci sono migliaia di eventi al mese che assorbono il rumore.
Il progetto nasceva da una migrazione verso Shopify. L’infrastruttura nuova era corretta: canale server attivo, deduplica fra browser e server configurata, analytics e piattaforma di email marketing collegate. Nella corsa al rilascio era però rimasta indietro la mappatura dei dati utente verso la Conversions API.
Lo stato iniziale, con la fonte di ciascun dato:
| Dato | Situazione | Fonte |
|---|---|---|
| Eventi acquisto ricevuti | tutti, senza errori | Events Manager |
| Sezione identità utente sugli acquisti | vuota su tutti | ispezione payload |
| Dati cliente nel gestionale | presenti su ogni ordine | registro ordini Shopify |
| Durata del difetto | 3 mesi | confronto date rilascio |
La domanda che ha aperto il lavoro è arrivata dal cliente: la Conversions API era attiva da tre mesi, gli eventi arrivavano tutti, e il punteggio di corrispondenza restava basso.
Recupero dello storico: rispedire tre mesi senza duplicare
IN SINTESI
Cosa abbiamo fatto: ricostruito ogni acquisto dei tre mesi precedenti dal registro ordini e rispedito lo stesso evento con l’identità aggiunta.
Perché: i dati esistevano nel gestionale e non erano mai arrivati alla piattaforma pubblicitaria, quindi il recupero era possibile senza chiedere niente all’utente.
Cosa abbiamo trovato: la deduplica nativa su identificativo evento permette di riscrivere un evento già ricevuto.
Il numero della sezione: 3 mesi di acquisti rispediti, zero eventi duplicati in Events Manager.
La prima verifica è stata sulla quantità, perché è quella che costa meno. Quando un punteggio di corrispondenza è basso la spiegazione più comune è che manchino eventi, e si controlla in pochi minuti confrontando i conteggi.
I conteggi tornavano. Gli acquisti a sistema e gli acquisti ricevuti dalla piattaforma erano allineati. Il problema non era la quantità.
Ogni evento inviato alla Conversions API ha due sezioni. Una descrive cosa è successo, con valore, valuta e prodotti. L’altra descrive chi l’ha fatto, con email e telefono cifrati, nome e città. La prima era compilata correttamente, la seconda non c’era.
Il punto tecnico che rende possibile il recupero è che la piattaforma riconosce gli eventi già ricevuti dall’identificativo univoco. Rimandare lo stesso evento con lo stesso identificativo non ne crea un secondo.
Il processo è a quattro passaggi. Esportazione degli ordini del periodo con i dati cliente. Cifratura dei dati personali secondo lo standard richiesto, con normalizzazione preventiva di formato. Ricostruzione del corpo della chiamata con gli identificativi, i nomi evento, gli orari e i dati di prodotto originali, più la sezione identità aggiornata. Reinvio in sequenza.
Nel reinvio si conservano tutti i campi originali, inclusi orario dell’evento, indirizzo IP, user agent e indirizzo di pagina. Non si costruisce un evento nuovo che somiglia a quello vecchio, si rimanda quello vecchio completato. È la condizione perché la piattaforma, dovendo scegliere quale versione tenere in deduplica, veda un corpo coerente.
Cosa ha funzionato
Aver verificato la quantità prima del contenuto. È il controllo che costa meno e che, escludendo la spiegazione comune, ha indirizzato tutto il resto del lavoro sulla direzione giusta al primo tentativo.
Servizio di enrichment di sessione: risolvere anche il futuro
IN SINTESI
Cosa abbiamo fatto: costruito un servizio che conserva gli eventi anonimi di una sessione e li rispedisce arricchiti appena compare l’email.
Perché: il recupero dello storico si fa una volta, ma il problema si ripresenta a ogni sessione futura.
Cosa abbiamo trovato: il cookie del browser è una chiave di aggregazione sufficiente, perché è presente su tutti gli eventi.
Il numero della sezione: finestra di conservazione a 48 ore, con cancellazione automatica alla scadenza.
Il recupero storico chiudeva il passato. Il problema strutturale però restava aperto, perché gli eventi a monte dell’acquisto arrivano prima che l’utente abbia lasciato la propria email, che compare solo al checkout o alla registrazione. Ogni visualizzazione di prodotto e ogni aggiunta al carrello nasce anonima per costruzione.
Il servizio riceve in parallelo una copia di ogni evento inviato dal container server, la conserva indicizzata per il cookie del browser, e quando in quella stessa sessione compare un dato personale rispedisce tutti gli eventi precedenti con l’identità aggiunta, usando gli stessi identificativi originali.
L’identità si accumula per pezzi. Il checkout porta l’email, un evento successivo può portare il telefono, l’iscrizione alla newsletter può portare il nome. Ogni nuovo pezzo fa ripartire l’arricchimento di tutti gli eventi precedenti con l’identità completa aggiornata.
La finestra di conservazione è di 48 ore. Il dimensionamento nasce da due vincoli opposti. Oltre quel termine il reinvio arricchito ha rendimenti decrescenti, perché la finestra utile della piattaforma si assottiglia. Sotto, si perdono le sessioni che tornano il giorno dopo. La scadenza funziona anche da cancellazione automatica, quindi non resta nessun dato personale oltre quel termine e non serve nessuna procedura di pulizia.
Il consenso è gestito a monte. Se l’utente non ha acconsentito, il tag verso il servizio non parte e quegli eventi il servizio non li vede mai. La conformità è garantita dall’architettura invece che da una logica applicativa, che è la configurazione con meno punti di rottura.
Il servizio risponde immediatamente confermando la ricezione e lavora in coda, quindi non introduce attesa sull’invio originale.
Cosa ha funzionato
Aver scelto il cookie del browser come chiave di aggregazione. È presente su tutti gli eventi, è la stessa chiave che usa la piattaforma internamente, e non richiede che l’utente sia registrato.
Nota di metodo sui numeri
Fonte di verità dichiarata: il registro ordini Shopify. Gli eventi rispediti sono stati ricostruiti da lì, non dai report della piattaforma pubblicitaria.
| Numero pubblicato | Fonte | Finestra | Modello |
|---|---|---|---|
| 3 mesi di storico | registro ordini Shopify | dal rilascio all’intervento | ordini con dati cliente presenti |
| zero duplicati | Events Manager | dopo il reinvio | conteggio eventi acquisto sul periodo |
| 48 ore di conservazione | configurazione del servizio | per sessione | scadenza automatica sul cookie browser |
La distanza fra dato di piattaforma e dato di backend su questo cliente non è stata quantificata in percentuale, perché il lavoro nasceva da un problema di contenuto degli eventi e non di conteggio. I conteggi erano allineati fin dall’inizio, ed è esattamente questo che ha indirizzato l’analisi.
Cosa non siamo in grado di misurare, e con che grado di certezza.
Il miglioramento del punteggio di corrispondenza dopo il reinvio è stimabile con confidenza bassa, e non lo pubblichiamo. Il motivo è dichiarato e vale la pena scriverlo per esteso, perché riguarda il meccanismo su cui poggia tutto l’intervento.
Che il reinvio con lo stesso identificativo non generi duplicati è documentato e verificato: lo abbiamo controllato sul conteggio eventi dopo l’operazione. Che la piattaforma usi i dati aggiuntivi per rivedere l’abbinamento di un evento già ricevuto è il comportamento atteso ma non dichiarato dalla documentazione ufficiale.
È una scelta a rischio asimmetrico, e la dichiariamo al cliente prima di partire. Se il comportamento è quello atteso, il segnale storico migliora. Se non lo è, il reinvio viene scartato in deduplica e non produce alcun effetto, né positivo né negativo. Con quel profilo di rischio l’intervento si fa, ma chi promette una percentuale di miglioramento su questa operazione sta dichiarando una cosa che la piattaforma non pubblica.
Per misurare l’effetto servirebbe un confronto fra due popolazioni di eventi omogenee, una arricchita e una no, sullo stesso periodo. Non è stato impostato.
Cosa non ha funzionato
Abbiamo rilasciato un tracciamento senza una verifica sul contenuto degli eventi. La mappatura dell’identità utente era rimasta indietro nella corsa al rilascio, e il difetto è passato perché i controlli di collaudo guardavano i volumi e non i campi. Tre mesi di acquisti sono arrivati privi di identità prima che qualcuno se ne accorgesse. Cosa abbiamo fatto invece: il collaudo adesso include l’apertura di un singolo evento per tipo con lettura campo per campo, prima di guardare qualunque conteggio. Un impianto che perde eventi lo dichiara subito perché i numeri non tornano, un impianto che manda eventi incompleti non lo dichiara mai.
Abbiamo scelto la durata della conservazione senza misurarla. Le 48 ore sono state fissate su una stima del ciclo di acquisto tipico di quel negozio, non su una distribuzione reale delle sessioni. È un numero ragionevole ma non verificato, e su un business con ciclo più lungo sarebbe sbagliato. Cosa abbiamo fatto invece: la finestra è configurabile e non cablata nel codice, così può essere corretta senza rilasciare di nuovo. La misura della distribuzione resta fra le cose da fare.
Cosa faremmo adesso
Misurare la distribuzione reale del tempo fra primo evento e rilascio dell’email. È il dato che dice se 48 ore sono la finestra giusta per questo negozio o se ne bastano 24, oppure se ne servono 72.
Misurare la quota di sessioni effettivamente arricchite. Il servizio funziona solo su chi lascia un’email nella stessa sessione. Sapere quanto è quella quota dice quanto vale l’intervento, ed è un dato che oggi non abbiamo.
Impostare il confronto fra popolazioni omogenee. È l’unico modo per trasformare il rischio asimmetrico in una misura, e richiede di tenere per un periodo una quota di eventi non arricchiti come termine di paragone.
Estendere l’accumulo dell’identità agli eventi di ritorno. Oggi l’aggregazione è per sessione. Un utente che torna dopo tre giorni riparte da zero, e su un ciclo di acquisto lungo è una perdita evitabile.
Conclusione
Tre mesi di acquisti sono stati rispediti con l’identità del cliente, senza generare un solo evento duplicato, e da lì in avanti ogni sessione che lascia un’email arricchisce da sola gli eventi che l’hanno preceduta entro una finestra di 48 ore.
Quello che questo lavoro lascia, ripreso dai quattro punti iniziali.
Come capire se il problema è quantità o contenuto: si confrontano prima i conteggi con il gestionale, perché è il controllo che costa meno. Se tornano, il problema è dentro gli eventi.
Come rispedire un evento senza duplicarlo: si usa lo stesso identificativo e si conservano tutti i campi originali, aggiungendo solo la parte mancante.
Come dimensionare una finestra di conservazione: si mette da una parte il rendimento decrescente del recupero e dall’altra il costo di tenere i dati, e si rende la soglia configurabile invece che cablata.
Come dichiarare un comportamento non documentato: si separa quello che è verificato da quello che è atteso, si spiega cosa succede se l’atteso non si realizza, e si lascia al cliente la decisione con il profilo di rischio in mano.
Quando questo lavoro ha senso, e quando no
Ha senso se hai un volume di ordini contenuto e un valore unitario alto, perché ogni conversione abbinata a una persona reale pesa di più, e se il tuo funnel è breve abbastanza da far comparire l’email nella stessa sessione degli eventi che la precedono.
Non ha senso su un negozio ad alto traffico e bassa conversione, dove la sovrapposizione fra sessioni con eventi a monte e sessioni con email è troppo bassa perché il recupero valga la costruzione. E non ha senso se ti aspetti una percentuale di miglioramento garantita, perché il meccanismo su cui poggia non è dichiarato dalla piattaforma.
Il primo passo è aprire un evento acquisto nel pannello della piattaforma e guardare se la sezione identità utente contiene qualcosa. Se è vuota, i dati sono nel tuo gestionale e non stanno arrivando.