Pipeline di dati marketing: dal clic alla vendita

La concessionaria online: quando una vendita offline scompare

Luca vede un annuncio su Meta, “BMW usate sotto 30.000 euro”.

Clicca e arriva su una piattaforma di vendita auto online. Quello che sembra un semplice accesso al sito è il momento in cui la pipeline di tracking comincia a costruire il contesto della sua visita.

Il primo contatto: da dove arriva Luca?

Quando Luca atterra sulla pagina, il sistema di tracking registra il pageview.

In quel momento non sa ancora chi sia. Può però conoscere la campagna da cui è arrivato, i parametri UTM e gli identificatori pubblicitari disponibili, come fbc e fbp (i cookie che Meta usa per riconoscere clic e sessione).

Queste informazioni possono essere associate a un profilo anonimo legato alla sua navigazione.

Per chi gestisce le campagne non è necessario conoscere ogni dettaglio del database utilizzato. Conta soprattutto la sua funzione, conservare memoria del primo contatto.

Senza quella memoria, ogni passaggio successivo rischia di sembrare un evento isolato.

In una configurazione server-side, il pageview può essere inviato a Meta dal server anziché esclusivamente dal browser. Questo riduce una parte delle perdite causate da blocchi e problemi lato client, ma non elimina i vincoli tecnici o di identificazione.

La navigazione: quali segnali lascia l’utente?

Luca usa i filtri BMW, massimo 25.000 euro, massimo 80.000 chilometri, benzina.

Apre quattro schede auto e passa dodici minuti sul sito.

Ogni interazione può aggiornare il profilo associato alla visita: filtri utilizzati, veicoli consultati e tempo trascorso sulle diverse pagine.

Questi eventi aiutano il team marketing a ricostruire il comportamento dell’utente. Quando vengono inviati alle piattaforme pubblicitarie, possono anche fornire segnali utili ai loro sistemi di ottimizzazione.

Ma Luca è ancora anonimo. Il sistema conosce il suo comportamento, non la sua identità.

Il preventivo: il profilo diventa riconoscibile

Luca si ferma su una BMW Serie 3 del 2021, con 45.000 chilometri e un prezzo di 23.500 euro.

Compila il form di richiesta preventivo inserendo nome, email, telefono e interesse per il finanziamento.

È uno dei momenti più delicati della pipeline.

Il sistema dispone ora di un collegamento tra due gruppi di informazioni, ciò che Luca ha fatto prima di identificarsi e i dati che ha inserito nel form.

In una configurazione corretta, queste informazioni vengono associate allo stesso profilo.

Email e telefono possono essere normalizzati e sottoposti a hashing prima di essere inviati alle piattaforme pubblicitarie.

Meta riceve l’evento Lead insieme agli identificatori e ai cookie disponibili. Google Ads riceve la conversione relativa alla richiesta di preventivo.

L’aggiunta di chiavi valide può aumentare la capacità delle piattaforme di associare l’evento alla persona e alla campagna corretta. Non garantisce da sola l’attribuzione, ma offre più elementi rispetto a un evento anonimo.

Nel frattempo, il sistema può verificare che lo stesso form non venga contato più volte.

Se Luca lo invia due volte per errore, il secondo evento può essere riconosciuto come duplicato prima di raggiungere le piattaforme.

Il punto in cui molte pipeline si interrompono

Dopo il preventivo, Luca chiude il browser.

Tre giorni più tardi torna sul sito digitando direttamente l’indirizzo. Se l’identificatore è ancora disponibile, la nuova visita può essere collegata al profilo precedente.

La campagna iniziale, le auto consultate e il preventivo richiesto continuano così a fare parte dello stesso percorso.

Poi Luca entra in concessionaria, firma il finanziamento e acquista l’auto.

La vendita non avviene sul sito. Viene registrata nel CRM.

È qui che molte pipeline si spezzano.

La piattaforma pubblicitaria conosce il clic e il lead. Il CRM conosce la vendita. Ma, se i due sistemi non comunicano, nessuno segnala a Meta che quel lead ha generato un acquisto da 23.500 euro.

Ads Manager mostra quindi una campagna con clic e richieste di preventivo, ma nessuna vendita.

Il responsabile marketing potrebbe considerarla poco efficace, ridurre il budget o spegnerla.

Il ricavo esiste. È solo rimasto chiuso dentro il CRM.

Come collegare l’acquisto offline alla campagna

Il CRM può inviare al sistema di tracking un evento quando la vendita viene confermata.

Questo evento non arriva dal browser di Luca. Arriva direttamente dal CRM e contiene le informazioni disponibili sull’acquisto: cliente, prodotto, valore e stato della transazione.

Il sistema di tracking deve quindi ritrovare il profilo costruito durante la navigazione e recuperare gli elementi utili a collegare la vendita al contatto pubblicitario iniziale.

Se il collegamento riesce, Meta riceve un evento Purchase con il valore reale dell’acquisto e gli identificatori disponibili.

La piattaforma non vede più soltanto un lead. Dispone anche del segnale che quel percorso ha prodotto una vendita.

Finestre di attribuzione, qualità dei dati e regole della piattaforma continuano comunque a incidere, quindi l’attribuzione automatica non è garantita. Meta però dispone ora degli elementi necessari per tentare di ricostruire il percorso completo.

Senza questo meccanismo, la campagna può risultare meno efficace di quanto sia davvero. Con questo meccanismo, il marketer dispone di una rappresentazione più vicina al risultato reale.

Le quattro funzioni di una pipeline di dati marketing

Per capire gli altri casi non serve memorizzare una classificazione tecnica dei database. È più utile distinguere quattro funzioni.

1. Registrare ciò che accade

Un sistema operativo registra una vendita, un ordine, una richiesta di preventivo o una modifica all’inventario.

Deve farlo rapidamente e senza creare stati incoerenti.

Molte applicazioni usano database relazionali per questo scopo. Sono sistemi organizzati in tabelle, righe e colonne, progettati per gestire operazioni frequenti e collegate tra loro.

Quando viene confermato un ordine, per esempio, il sistema può registrare il pagamento e ridurre la disponibilità del prodotto. Le operazioni devono rimanere coerenti, senza un ordine pagato che non risulti registrato correttamente.

2. Conservare il contesto

Un altro sistema può mantenere nel tempo le informazioni utili su una persona o una sessione:

• provenienza
• identificatori disponibili
• interazioni
• dati inseriti
• acquisti
• preferenze

Un database document-based, come Firestore o Stape Store, è una delle tecnologie utilizzabili per costruire profili flessibili.

Le informazioni relative a un’entità possono essere raccolte in un documento che cresce nel tempo. La struttura non deve essere identica per tutti gli utenti.

Un cliente può avere tredici acquisti e due indirizzi. Un altro può avere soltanto una visita anonima e un parametro UTM.

3. Eseguire controlli rapidi

Alcune informazioni servono per operazioni quasi immediate, come verificare se un evento è già stato elaborato, se una sessione è ancora attiva o se un valore è presente in cache.

Questi controlli possono essere gestiti con sistemi in memoria, come Redis, oppure con soluzioni equivalenti.

Qui conta soprattutto evitare che un controllo semplice e frequente rallenti il resto della pipeline. I microsecondi, di per sé, sono un dettaglio.

4. Analizzare lo storico

I dati vengono infine raccolti in un ambiente progettato per analisi più ampie.

I data warehouse, come BigQuery, permettono di lavorare su grandi quantità di dati storici e rispondere a domande come:

• Qual è stato il tasso di conversione per canale negli ultimi sei mesi?
• Quanto tempo passa tra il primo contatto e l’acquisto?
• Quale canale genera clienti con un valore più alto?
• Dove si interrompe più spesso il funnel?

Servono a leggere lo storico e trasformarlo in informazioni utilizzabili, non a gestire direttamente una vendita alla cassa.

Le tecnologie possono cambiare da un’azienda all’altra.

La domanda utile per chi gestisce il marketing non è quale nome abbia ogni componente. È se queste quattro funzioni esistono e riescono a comunicare tra loro.

Il negozio fisico: registrare una vendita non significa analizzarla

Marco entra in un negozio di abbigliamento, prende una felpa dagli scaffali e paga 49 euro con il bancomat.

Trenta secondi di interazione. Dietro quei trenta secondi, diversi sistemi possono lavorare in parallelo.

La cassa registra la transazione

Quando il cassiere passa la felpa sul lettore, il software della cassa può avviare più operazioni collegate: registrare la vendita con data, ora e importo, ridurre di una unità l’inventario, aggiornare l’incasso della giornata.

Il database della cassa ha un compito operativo.

Deve assicurarsi che la vendita e le informazioni collegate rimangano coerenti. La struttura è prevedibile, con campi fissi come prodotto, quantità, importo e orario.

Preso da solo, questo sistema sa che una felpa taglia M è stata venduta a 49 euro alle 15:32, ma non sa ancora chi sia Marco.

La carta fedeltà aggiunge il profilo cliente

Marco utilizza la carta fedeltà. A quel punto la vendita può essere associata al suo profilo.

Il sistema può conoscere la sua taglia, un indirizzo di consegna, gli acquisti precedenti e le preferenze di comunicazione.

Dopo la vendita, il profilo viene aggiornato con il nuovo ordine, il totale speso e la data dell’ultimo acquisto.

L’esempio serve a distinguere la registrazione della transazione dalla conservazione di un profilo che cambia nel tempo, indipendentemente dalla tecnologia usata dal programma fedeltà.

Il dato arriva nell’archivio analitico

Quella sera, un processo automatico raccoglie i dati delle casse dei diversi punti vendita e li trasferisce nel data warehouse.

Il mattino successivo, l’analista può confrontare vendite per negozio, fasce orarie, categorie di prodotto, margine medio e andamento nel tempo.

Il sistema che registra la vendita e quello che analizza mesi di storico svolgono funzioni diverse.

Il collegamento tra i due non compare automaticamente. Deve esistere un processo che estragga i dati dalla sorgente, li prepari e li carichi nella destinazione.

Questo processo viene spesso chiamato ETL o ELT, a seconda dell’ordine con cui avvengono trasformazione e caricamento.

Per il marketer, la distinzione terminologica è secondaria. Il punto è che qualcuno o qualcosa deve costruire e mantenere quel ponte.

Registrare una vendita non significa averla già resa disponibile nel luogo in cui verrà presa una decisione.

Tracking Shopify: quando una vendita arriva da due strade

Sara vede un annuncio Instagram, “Sneaker primavera, 20% di sconto”.

Clicca e arriva su uno store Shopify.

La pipeline ha una particolarità. Il database interno di Shopify non è accessibile direttamente, e la piattaforma espone i dati attraverso strumenti come API, webhook e Custom Pixel.

A differenza della concessionaria e del negozio fisico, qui il problema è evitare che la stessa vendita arrivi due volte, da due canali diversi, più che ricongiungere online e offline.

Il Custom Pixel osserva il percorso nello store

Il Custom Pixel è uno dei principali punti di ingresso per gli eventi che avvengono nelle pagine dello store e nel checkout.

Quando Sara arriva sul sito, il pixel può intercettare il pageview e inviarlo a un container server-side di Google Tag Manager.

Da lì, l’evento viene distribuito alle destinazioni configurate.

Meta CAPI può ricevere il PageView insieme agli identificatori disponibili. GA4 può registrare l’evento e renderlo disponibile per le analisi successive.

Nel frattempo viene creato un profilo associato alla navigazione di Sara, con gli identificatori pubblicitari e i parametri della campagna disponibili.

Il meccanismo è simile a quello visto nella storia di Luca.

Il funnel produce eventi in ogni passaggio

Sara guarda un paio di sneaker bianche, sceglie la taglia 38 e le aggiunge al carrello.

Il sistema registra l’evento add_to_cart.

Il profilo viene aggiornato con il prodotto scelto. Meta può ricevere AddToCart con il valore dell’articolo. GA4 registra lo stesso passaggio per l’analisi del funnel.

Sara entra nel checkout e inserisce email e indirizzo.

Il profilo anonimo acquisisce informazioni identificative. Quando previsto dalla configurazione, email e telefono vengono normalizzati, sottoposti a hashing e inviati alle piattaforme.

Anche in questo caso, l’obiettivo è collegare ciò che è accaduto prima dell’identificazione con ciò che avviene dopo.

La conversione arriva dal browser e dal server

Quando Sara completa l’ordine, possono arrivare due segnali distinti.

Il primo nasce dall’interazione sul sito ed è intercettato dal Custom Pixel. È rapido, ma dipende dal browser, dalla connessione e dal completamento corretto dell’esecuzione.

Il secondo arriva tramite un webhook inviato dai server di Shopify quando il pagamento viene confermato.

Il webhook è normalmente più robusto rispetto a un segnale esclusivamente lato browser, ma deve comunque essere gestito correttamente, con controlli, retry e deduplicazione.

I due canali devono funzionare in modo complementare, senza generare due acquisti duplicati.

Se l’evento intercettato dal pixel arriva per primo, il sistema può inviare subito la conversione alle piattaforme.

Quando arriva il webhook, controlla se lo stesso ordine è già stato elaborato. Se lo è, il secondo evento viene scartato.

Se invece l’evento lato browser non è arrivato, per esempio perché la pagina è stata chiusa troppo presto o si è verificato un problema di rete, il webhook permette di recuperare la vendita.

La qualità della pipeline dipende quindi anche dalla sua capacità di rispondere a due domande:

• Riesce a recuperare una conversione se un canale fallisce?
• Riesce a evitare di contarla due volte se entrambi funzionano?

Il profilo finale del cliente Shopify

Alla fine del percorso, il profilo associato a Sara può contenere gli identificatori pubblicitari della prima sessione, i parametri della campagna, i dati identificativi disponibili, il prodotto acquistato, il valore dell’ordine e l’ID cliente Shopify.

Il profilo non nasce completo al primo pageview. Si arricchisce man mano che Sara interagisce con lo store.

Questa memoria permette di collegare eventi che arrivano da canali diversi e in momenti diversi.

BigQuery e Dataform: avere i dati non significa poterli usare

Gli eventi raccolti da GA4 possono essere esportati verso BigQuery quando l’integrazione è configurata.

Nel warehouse finiscono pageview, visualizzazioni di prodotto, aggiunte al carrello, passaggi del checkout e acquisti.

Avere questi dati non significa però avere automaticamente un funnel leggibile.

I dati grezzi di GA4 sono organizzati come eventi. Riflettono il modo in cui la piattaforma li registra, non necessariamente il modo in cui il business vuole analizzarli.

Per questo serve un livello di trasformazione.

Dataform è uno degli strumenti che può trasformare i dati grezzi in tabelle costruite secondo la logica aziendale.

Un modello può ricostruire il funnel di ogni utente, dalla prima visita all’acquisto.

Un altro può aggregare i risultati per canale di acquisizione e mostrare costo di acquisizione, tasso di conversione, valore medio del cliente, ritorno nel tempo e durata del percorso di acquisto.

Il mattino successivo, il responsabile marketing apre Looker Studio e lavora su dati già organizzati.

Lavora su modelli che riflettono le domande del business, senza dover interrogare direttamente una sequenza di eventi grezzi.

Dataform non è l’unica soluzione possibile.

Il punto è che tra raccolta e analisi deve esistere un livello che trasformi il dato tecnico in una struttura leggibile.

Senza quel livello, BigQuery rischia di essere un archivio pieno di informazioni ma difficile da utilizzare.

Cosa collega CRM, Shopify e piattaforme pubblicitarie

Il negozio fisico, la concessionaria e lo store Shopify sembrano casi diversi. La struttura sottostante è però simile.

In tutti e tre esiste un sistema operativo che registra ciò che accade: la cassa, il CRM, Shopify.

Esiste poi un livello che conserva il contesto del cliente o della sessione.

Possono esserci controlli rapidi per riconoscere duplicati, sessioni o eventi già processati.

Infine, esiste un ambiente analitico che raccoglie lo storico e lo trasforma in informazioni utili.

Il punto di connessione tra questi sistemi è la pipeline.

Riceve gli eventi, recupera il contesto disponibile, collega sorgenti diverse e distribuisce i dati alle destinazioni corrette: piattaforme pubblicitarie, strumenti di analisi, CRM, data warehouse.

La qualità di questo collegamento determina la qualità dei dati su cui vengono prese le decisioni di marketing.

Il caso più critico è spesso quello in cui una conversione arriva senza il contesto della navigazione iniziale.

Succede con l’acquisto offline di Luca. Succede con un webhook Shopify che arriva dal server e non dal browser.

In entrambi i casi, la vendita esiste. Il problema è capire se il sistema riesce a ricongiungerla al percorso che l’ha generata.

Come una pipeline incompleta altera le decisioni di budget

La pipeline di dati viene spesso trattata come un problema tecnico. Le conseguenze, però, sono economiche.

Ogni euro investito in advertising produce interazioni e dati. Quei dati vengono utilizzati per valutare le campagne e decidere dove investire il budget successivo.

Se la pipeline è incompleta, anche la rappresentazione delle performance è incompleta.

Può succedere perché:

• una vendita offline non viene inviata alle piattaforme
• la stessa conversione viene registrata due volte
• un passaggio del checkout non viene tracciato
• un evento arriva senza identificatori sufficienti
• il ciclo di vendita supera la finestra osservata dal team
• i dati esistono ma restano grezzi e difficili da interpretare

In questi casi il marketer prende comunque decisioni, ma usando una versione parziale o distorta dei dati.

Capire la pipeline vuol dire soprattutto saper fare le domande giuste, non costruirla da zero.

I tre sintomi più comuni di una pipeline di tracking rotta

1. Le conversioni dipendono soltanto dal browser

Per anni il tracking ha funzionato soprattutto attraverso pixel JavaScript eseguiti nel browser dell’utente.

Questo approccio è diventato progressivamente meno affidabile.

Adblocker, restrizioni dei browser, errori di rete, chiusura anticipata delle pagine e scelte di consenso possono impedire a una parte degli eventi di raggiungere le piattaforme.

Il tracking server-side permette di spostare una parte dell’elaborazione dal browser al server, riducendo la dipendenza da un unico canale fragile. Non elimina ogni perdita, e non sostituisce comunque il rispetto del consenso.

Il sintomo da osservare è semplice. Le vendite registrate nel sistema operativo sono più numerose di quelle ricevute dalle piattaforme pubblicitarie.

2. Gli eventi online e offline restano separati

È il problema della concessionaria.

Il cliente clicca su un annuncio, visita il sito e richiede un preventivo. Poi acquista in negozio o al telefono.

Se il CRM non restituisce la vendita alla pipeline, la piattaforma vede soltanto la prima metà del percorso.

La campagna può apparire piena di lead e povera di ricavi.

Di conseguenza, il budget viene spostato verso altri canali oppure la campagna viene fermata.

Per collegare i due momenti serve una memoria persistente del percorso e un identificatore che permetta di ritrovare il profilo corretto quando arriva l’evento offline.

Senza quel collegamento, online e offline rimangono due isole.

3. Il volume dei dati viene confuso con la qualità

Avere milioni di eventi in BigQuery non significa avere risposte affidabili.

Un funnel costruito per sessione può produrre una lettura diversa da uno costruito per utente.

Un acquisto duplicato può gonfiare il ritorno apparente di una campagna.

Un modello di valore cliente che non distingue correttamente i canali può produrre confronti fuorvianti.

Il problema non è soltanto raccogliere più dati. È costruire regole che li rendano coerenti con la domanda a cui devono rispondere.

Il sintomo più comune è una dashboard molto ricca che non riesce a risolvere domande semplici.

Quattro domande per controllare la propria pipeline

Una pipeline non va valutata dal numero di tecnologie che contiene. Va valutata dalle risposte che riesce a produrre.

1. Gli acquisti offline o registrati nel CRM vengono inviati alle piattaforme pubblicitarie?
2. Gli eventi che arrivano dal browser e dal server vengono deduplicati?
3. Il checkout è tracciato fino alla conferma effettiva del pagamento?
4. Sai quanto tempo passa tra il primo contatto e l’acquisto?

Sono domande di marketing. Le risposte vivono nella pipeline di dati.

Se non sai rispondere alla prima domanda, potresti sottovalutare le campagne che generano vendite offline.

Se non sai rispondere alla seconda, potresti sovrastimare le conversioni.

Se non sai rispondere alla terza, potresti perdere una parte del funnel senza accorgertene.

Se non sai rispondere alla quarta, potresti valutare troppo presto campagne che producono risultati dopo giorni o settimane.

Da quale dato iniziare a ricostruire la pipeline

La domanda iniziale non dovrebbe essere “Come costruisco una pipeline perfetta?”.

Una pipeline completa può richiedere tempo, competenze diverse e un investimento significativo.

La domanda utile è un’altra. Qual è il dato che mi manca oggi, quello che cambierebbe una decisione di marketing?

Se non sai quanti acquisti offline vengono attribuiti alle campagne online, il primo passo è verificare il collegamento tra CRM e piattaforme pubblicitarie.

Se non sai cosa succede nel checkout, il primo passo è controllare gli eventi disponibili e la loro continuità.

Se gli ordini reali non coincidono con le conversioni inviate, il primo passo è verificare recupero e deduplicazione.

Se i dati sono presenti ma restano grezzi, il primo passo è costruire un modello che li trasformi in funnel e metriche leggibili.

La pipeline di dati marketing si costruisce un pezzo alla volta, partendo dal dato che ha il valore più alto per le decisioni che devi prendere adesso, non tutta insieme.

Se non sai rispondere ad almeno due delle quattro domande diagnostiche, il primo passo non è rifare tutto da zero. È capire dove il percorso si interrompe.

Il check gratuito della pipeline dura 30 minuti e restituisce un riepilogo scritto di ciò che si sta perdendo, del punto in cui il dato si interrompe e della priorità da cui partire.

Domande frequenti sulle pipeline di dati marketing

Che cos’è una pipeline di dati marketing?

È il percorso attraverso cui gli eventi vengono raccolti, conservati, collegati e inviati alle piattaforme pubblicitarie, ai CRM e agli strumenti di analisi.

Perché un acquisto offline può non comparire in Meta?

Perché la vendita può essere registrata nel CRM senza essere collegata al clic, al lead e agli identificatori raccolti durante la navigazione online.

Qual è la differenza tra tracking browser-side e server-side?

Il tracking browser-side dipende dall’esecuzione nel browser dell’utente. Quello server-side sposta una parte della raccolta e dell’invio degli eventi sul server, riducendo la dipendenza da un unico canale.

Da dove conviene iniziare per migliorare la pipeline?

Dal dato mancante che incide maggiormente sulle decisioni attuali: acquisti offline non attribuiti, checkout incompleto, conversioni duplicate oppure dati grezzi difficili da analizzare.