Customer journey and funnel analytics

Il percorso intero, non l’ultimo click

Questa lezione cammina sul binario tabellare: i percorsi si ricostruiscono da tabelle di eventi, i funnel si leggono come catene di tassi e ogni rottura si quantifica prima di intervenire. L’obiettivo è ricostruire i percorsi utente dagli eventi grezzi, misurare il funnel per segmenti e quantificare il valore di ogni rottura prima di agire.

Un utente vede un reel su Instagram, una settimana dopo cerca il brand su Google, apre due email senza cliccare, legge tre recensioni su un comparatore, torna da diretto e compra. Il report di attribuzione assegna il 100% del merito alla ricerca branded. Il budget si sposta tutto lì, il social viene giudicato inutile e tre mesi dopo la domanda branded cala del 20%. Nessuno collega i due fatti, perché nessuno ha mai guardato il percorso intero.

Questo è il lavoro del customer journey mapping e del funnel analytics: ricostruire la sequenza di passi che porta qualcuno da “non ti conosco” a “compro e torno”, misurare dove il flusso si rompe e decidere dove intervenire con il miglior rapporto tra costo ed effetto. Non è disegnare frecce carine su una slide. È trasformare log di eventi frammentati in una struttura che risponde a domande operative: quale passaggio perde più soldi, per quale segmento e con quale fix.

La sequenza di lavoro in sette passi

Ecco l’ordine con cui si costruisce un’analisi di journey che regge:

1. Classifica ogni evento in esposizione, interazione o transizione di stato prima di mappare.
2. Unifica le identità in cascata, prima deterministico poi probabilistico, registrando la confidenza di ogni fusione.
3. Raggruppa gli eventi in sessioni con una soglia calibrata sul tuo ciclo reale, non sui 30 minuti di default.
4. Estrai i primi 20 percorsi per volume con conversione e durata mediana, raggruppando la coda lunga in bucket.
5. Definisci ogni funnel con finestra temporale, coorte di ingresso e regola sui passi saltabili.
6. Segmenta ogni tasso per device, sorgente e coorte prima di dichiarare il collo di bottiglia.
7. Quantifica ogni fix come utenti allo step per guadagno di tasso per margine, e valida con holdout o test sulla conversione a valle.

Perché l’ultimo click mente (e quando invece basta)

Il modello “ultimo touchpoint prende tutto” sopravvive perché è semplice da implementare: ogni conversione ha un responsabile unico, ogni canale un ROI apparente. Il problema è che confonde il punto di raccolta con il lavoro di costruzione. La ricerca branded e il traffico diretto sono quasi sempre raccoglitori di domanda creata altrove: intercettano utenti già convinti. Tagliare i canali di scoperta perché “non convertono” equivale a chiudere il vivaio perché le piante si comprano in negozio.

Detto questo, il journey mapping completo non serve sempre. Con cicli d’acquisto brevissimi — un utente cerca “pizzeria vicino a me”, clicca e chiama — il percorso è banale e l’ultimo click descrive la realtà con approssimazione accettabile. Il mapping paga quando valgono almeno due di queste condizioni: il ciclo dura più di una sessione, il ticket giustifica più interazioni, esistono touchpoint offline o cross-device che i report standard perdono.

La prima scelta operativa è definire cosa conta come passo del percorso. Non tutti gli eventi meritano lo stesso peso: una pageview accidentale da social non è un confronto prezzi da comparatore. Una tassonomia pratica distingue tre livelli. Le esposizioni (impression, apertura email, visualizzazione video sopra una soglia) costruiscono familiarità ma non misurano intento. Le interazioni (click, ricerca sito, aggiunta al carrello, chat avviata) segnalano intento crescente. Le transizioni di stato (lead qualificato, trial attivato, primo ordine, secondo ordine) sono i nodi che contano davvero per il business. Mappare tutto allo stesso livello produce spaghetti illeggibili; mappare solo le transizioni di stato produce una mappa povera ma già decisionale.

Livello di evento	Examples	What it measures	Rischio se lo ignori
Esposizione	impression, open email, view video >50%	Copertura e familiarità	Sovrastimi l’efficienza dei canali di raccolta
Interazione	click, ricerca interna, add-to-cart	Intento e attrito	Non sai dove il percorso si rompe
Transizione di stato	lead, trial, primo e secondo ordine	Avanzamento reale	Ottimizzi micro-conversioni che non portano ricavi

Verdetto: mapping completo solo con cicli multi-sessione, ticket che giustifica più interazioni e touchpoint persi dai report; altrove l’ultimo click basta.

Dagli eventi grezzi ai percorsi: identità e sessioni

Il dato grezzo di partenza è quasi sempre un disastro onesto: cookie diversi per browser, ID pubblicitari mobile che cambiano, utenti loggati su un device e anonimi su un altro, eventi server-side con timestamp in fusi diversi. Prima di disegnare qualsiasi mappa servono due operazioni ingrate ma decisive: capire chi è chi e raggruppare gli eventi in unità sensate.

L’identity stitching risponde alla domanda “questi tre identificatori sono la stessa persona?”. Esistono due famiglie di approcci con trade-off netti. Il metodo deterministico unisce solo su chiavi certe — login con stessa email, stesso ID CRM, stesso numero d’ordine — e produce pochi falsi positivi ma lascia fuori gran parte del traffico anonimo. Quello probabilistico usa segnali deboli (stesso dispositivo, stesso IP e finestra temporale, fingerprint) per proporre fusioni, recuperando copertura al prezzo di qualche fusione sbagliata. In pratica si usano in cascata: prima il deterministico come scheletro affidabile, poi il probabilistico con soglie conservative per il resto. La regola d’oro è tenere traccia del livello di confidenza di ogni fusione: un journey costruito su identità incerte va trattato come ipotesi, non come evidenza.

Poi arriva la sessionizzazione: raggruppare eventi contigui dello stesso utente in sessioni separate da inattività. La soglia standard di 30 minuti nasce dal web analytics generalista e va adattata. Per un e-commerce va bene; per un configuratore B2B dove l’utente apre il preventivo la mattina e lo rivede il pomeriggio, spezza un percorso unico in due. Per un’app di contenuti con consumo serale lungo, 30 minuti frammentano la serata in tre sessioni finte. Un buon test: se più del 15-20% delle conversioni avviene alla prima sessione successiva a una interrotta dalla soglia, la soglia è troppo corta per il tuo contesto.

Il risultato di queste due fasi è la tabella fondativa di tutto il resto: una riga per evento con utente unificato, sessione, timestamp normalizzato in UTC, tipo di evento secondo la tassonomia a tre livelli, canale e campagna. Se questa tabella è sporca — timestamp incoerenti, canali con UTM mancanti, eventi duplicati da doppia implementazione client e server — ogni analisi a valle eredita il problema. Vale la pena di investire qui un giorno di pulizia piuttosto che una settimana a interpretare artefatti.

Verdetto: deterministico come scheletro affidabile, probabilistico con soglie conservative per il resto, e ogni fusione incerta trattata come ipotesi fino a conferma.

Costruire la mappa: nodi, archi e granularità giusta

Con la tabella eventi pulita, il journey diventa un grafo: i nodi sono gli stati o i touchpoint, gli archi sono le transizioni osservate con le relative probabilità. La tentazione è mappare tutto — ogni pagina, ogni click — e ottenere un diagramma che impressiona in riunione e non serve a niente. La granularità giusta dipende dalla domanda. Per una decisione di budget tra canali, i nodi sono i canali stessi: social > comparatore > branded > diretto. Per ridisegnare l’onboarding, i nodi sono le schermate. Per capire perché il B2B perde deal, i nodi sono gli stadi del CRM.

Una tecnica che funziona bene è partire dai percorsi più frequenti, non da tutti. Estrai i primi 20 percorsi per volume con il loro tasso di conversione e la durata mediana, e guarda cosa emerge. Spesso scopri che tre o quattro pattern coprono il 60-70% degli utenti, e che i percorsi lunghi non sono necessariamente quelli che convertono meglio. La query qui sotto fa esattamente questo su un log eventi pulito: ricostruisce la sequenza di canali per utente, conta i touchpoint, misura la durata e calcola la conversione per percorso.

-- Ricostruisce i percorsi di canale per utente e calcola la conversione per pattern.
-- Commenti in italiano: ogni CTE ha un solo compito, per ispezioni intermedie facili.
WITH user_events AS (
  SELECT
    unified_user_id,          -- utente dopo identity stitching, non il cookie grezzo
    event_timestamp,          -- già normalizzato in UTC a monte
    event_name,
    marketing_channel
  FROM clean_events_log
  WHERE event_timestamp >= '2023-01-01'
),
user_conversion AS (
  -- Flag di conversione: 1 se l'utente ha almeno un acquisto nel periodo
  SELECT
    unified_user_id,
    MAX(CASE WHEN event_name = 'purchase_completed' THEN 1 ELSE 0 END) AS converted
  FROM user_events
  GROUP BY unified_user_id
),
journey_paths AS (
  -- Un percorso = sequenza ordinata di canali toccati da un utente
  SELECT
    e.unified_user_id,
    STRING_AGG(e.marketing_channel, ' > ' ORDER BY e.event_timestamp) AS journey_path,
    COUNT(*) AS total_touchpoints,
    DATEDIFF('day', MIN(e.event_timestamp), MAX(e.event_timestamp)) AS journey_duration_days
  FROM user_events e
  GROUP BY e.unified_user_id
)
SELECT
  jp.journey_path,
  COUNT(DISTINCT jp.unified_user_id) AS number_of_users,
  AVG(jp.total_touchpoints) AS avg_touchpoints,
  AVG(jp.journey_duration_days) AS avg_duration,
  -- Tasso di conversione del pattern: convertiti / utenti con quel percorso * 100
  ROUND(SUM(uc.converted) * 100.0 / COUNT(DISTINCT jp.unified_user_id), 2) AS conversion_rate
FROM journey_paths jp
JOIN user_conversion uc ON jp.unified_user_id = uc.unified_user_id
GROUP BY jp.journey_path
ORDER BY number_of_users DESC
LIMIT 20;

Due avvertenze oneste su questa query. Primo, STRING_AGG sui canali grezzi esplode in migliaia di varianti se non normalizzi prima: raggruppa le long tail in bucket (altro paid, altro organic) prima di aggregare. Secondo, la correlazione percorso-conversione non è causalità: se il percorso che include il comparatore converte di più, può darsi che gli utenti più motivati usino il comparatore, non che il comparatore li convinca. La query ti dice dove guardare, non cosa concludere.

Leggere un funnel senza farsi ingannare

Se il journey è il territorio, il funnel è una strada tracciata dentro: una sequenza obbligata di passi (vista pagina > signup > attivazione > pagamento) dove misuri quanti avanzano e quanti cadono a ogni gradino. Serve quando il percorso desiderato è noto e vuoi quantificare l’attrito passo per passo.

Le due metriche fondamentali sono il tasso di passaggio tra step adiacenti e il tasso complessivo end-to-end:

$c_i = \frac{n_{i+1}}{n_i} \qquad C = \prod_{i=1}^{k-1} c_i = \frac{n_k}{n_1}$

where $n_i$ sono gli utenti che raggiungono lo step $i$. La formula sembra banale ma nasconde tre scelte che cambiano i numeri. La finestra temporale: conti come convertito chi passa allo step successivo entro 24 ore o entro 30 giorni? La definizione di coorte: analizzi tutti insieme o per settimana di ingresso, così da vedere se le modifiche al prodotto migliorano davvero? La gestione dei salti: se uno step è skippabile, lo escludi o lo tratti come passaggio implicito? Senza queste tre specifiche scritte da qualche parte, due analyst calcolano lo stesso funnel e ottengono numeri diversi.

Prendi un onboarding fintech realistico — download, registrazione, verifica identità, collegamento conto, primo trasferimento — con 10.000 download iniziali: 6.500 si registrano ($c_1 = 65\%$), 3.900 completano la verifica ($c_2 = 60\%$), 2.730 collegano il conto ($c_3 = 70\%$), 1.640 fanno il primo trasferimento ($c_4 = 60\%$). Il tasso complessivo è $16{,}4\%$. Il gradino peggiore in percentuale è la verifica identità, ed è lì che ogni punto recuperato vale di più in assoluto: un miglioramento da 60% a 70% su quel singolo passo porta 650 utenti aggiuntivi al passaggio successivo, più di qualsiasi ottimizzazione a valle. Questo è il ragionamento che il funnel abilita: non “miglioriamo tutto”, ma “il collo di bottiglia che paga di più è questo”.

Il funnel diventa diagnostico quando lo segmenti. Stesso funnel per iOS e Android, per paese, per sorgente di acquisizione, per coorte settimanale. Se la verifica identità crolla solo su Android di fascia bassa, il problema è tecnico (fotocamera, memoria, rete), non di fiducia. Se crolla solo per una sorgente, stai attirando il pubblico sbagliato. E il tempo mediano tra step trasforma la fotografia in film: uno step con conversione decente ma tempo mediano di sei giorni nasconde un’indecisione che un reminder o una semplificazione potrebbero risolvere.

Trovare attriti e scorciatoie con l’analisi dei percorsi

Il funnel misura una strada nota; la path analysis esplora tutte quelle percorse davvero, comprese le deviazioni che non avevi previsto. Loop tra pagina prezzi e FAQ, ritorni ossessivi al carrello senza mai chiudere, scorciatoie che i power user trovano e i nuovi no: sono segnali che nessun funnel prefissato cattura.

Lo strumento operativo è la matrice di transizione: per ogni coppia di stati $(a, b)$, la probabilità empirica di andare da $a$ a $b$:

$P(b \mid a) = \frac{N(a \to b)}{\sum_{x} N(a \to x)}$

where $N(a \to b)$ conta le transizioni osservate. Le righe con alta probabilità verso l’uscita identificano i punti di abbandono; le transizioni frequenti all’indietro (checkout > scheda prodotto > checkout) segnalano dubbi dell’ultimo minuto, tipicamente costi nascosti o spedizione poco chiara. La visualizzazione standard è il diagramma di Sankey, dove lo spessore dei flussi rende immediato dove si concentra il traffico e dove si disperde.

In Python il passaggio chiave è ordinare gli eventi per utente e timestamp, poi usare lo spostamento di una riga per accoppiare ogni pagina alla successiva:

import pandas as pd

# df: una riga per evento, con colonne user_id, timestamp, page
df = df.sort_values(["user_id", "timestamp"]).copy()

# Pagina successiva dello STESSO utente: shift(-1) dentro ciascun gruppo
df["next_page"] = df.groupby("user_id")["page"].shift(-1)

# Ultimo evento di ogni utente non ha successore: va escluso dai conteggi
transitions = df.dropna(subset=["next_page"])

# Matrice di transizione empirica: P(next | current)
counts = transitions.groupby(["page", "next_page"]).size().rename("n")
prob = (counts / counts.groupby("page").sum()).rename("p").reset_index()

# I punti di abbandono veri richiedono anche le uscite: confronta con i volumi per pagina
top_exits = prob.sort_values(["page", "p"]).groupby("page").tail(1)

Il trucco sta nel denominatore: le probabilità condizionate dicono dove va chi lascia una pagina, ma non quanta gente passa di lì. Incrocia sempre la matrice con i volumi assoluti per pagina, altrimenti ottimizzi un incrocio secondario ignorando l’autostrada. E attenzione ai loop apparenti dovuti a problemi di tracciamento — doppie implementazioni che sparano lo stesso evento due volte creano auto-transizioni finte con probabilità altissima.

Perché lo stesso percorso converte diversamente per segmenti diversi

Un journey medio è una finzione statistica: la media di comportamenti eterogenei che si compensano. Lo stesso percorso social > comparatore > branded può convertire al 9% su mobile e al 2% su desktop, o viceversa, e la media del 5% non descrive nessuno dei due. Segmentare i journey non è un raffinamento: è il punto in cui l’analisi diventa azionabile, perché ogni segmento suggerisce un fix diverso.

Le dimensioni di segmentazione che pagano più spesso sono quattro. Il dispositivo e il contesto tecnico (OS, fascia di prezzo del telefono, velocità di rete) rivelano attriti tecnici: un funnel di verifica identità che crolla solo su Android economici punta a fotocamera e memoria, e il fix è compressione adattiva o fallback, non copy migliore. La sorgente di acquisizione distingue intento: chi arriva da branded cerca conferma, chi arriva da social va educato. La coorte temporale separa effetti di prodotto e stagionalità: se i nuovi iscritti di marzo convertono peggio di quelli di gennaio a parità di percorso, qualcosa è cambiato nel prodotto o nel traffico. Il comportamento precoce — cosa fa l’utente nei primi 10 minuti — è spesso il miglior predittore: chi completa il profilo e avvia una prima azione significativa nella prima sessione ha probabilità di retention molto superiori a chi si limita a esplorare.

Un caso istruttivo è quello di un’app finanziaria con abbandono alto nella verifica identità da fotocamera. L’analisi aggregata diceva solo “il 40% abbandona lì”. La segmentazione per modello di dispositivo, condizioni di rete e tipo di documento mostrò tre problemi distinti: timeout su reti lente, errori di messa a fuoco su fotocamere deboli, rigetto di alcuni documenti. Tre fix mirati — retry con compressione adattiva, guida contestuale inquadratura, fallback manuale per documenti problematici — alzarono il completamento di 18 punti percentuali. Senza segmentazione, il team avrebbe riscritto l’intera schermata e forse peggiorato le cose per il segmento che già funzionava.

Dal journey alla decisione: dove mettere il prossimo euro

Una mappa senza decisione è decorazione. Il passaggio dall’analisi all’azione segue un ordine preciso: quantifica il valore di ogni rottura, stima costo e confidenza del fix, ordina per impatto atteso. Per ogni gradino del funnel o arco del journey, il valore annuo approssimativo di un miglioramento è:

$\text{valore} = \text{utenti allo step} \times \Delta c \times \text{margine per convertito}$

where $\Delta c$ è il guadagno realistico di tasso di passaggio. Un esempio: 40.000 utenti al mese arrivano alla verifica identità, il passaggio è al 60%, il margine medio per utente attivato è 25 euro. Un fix che porta il passaggio al 68% vale $40.000 \times 0{,}08 \times 25 = 80.000$ euro al mese. Confrontalo con il costo di sviluppo del fix e con alternative — magari un intervento sul recupero carrello da 15.000 euro di costo che vale 30.000 al mese ha un rapporto migliore. Questa aritmetica elementare batte qualsiasi heatmap per decidere la roadmap.

Quando il fix tocca budget media o messaggi, la validazione richiede esperimenti, non opinioni. L’holdout geografico resta lo strumento più solido per i journey lunghi: tieni ferma una regione o un segmento comparabile, cambia il resto, confronta la differenza di conversioni end-to-end (non dei click intermedi). Per fix di prodotto puntuali — una schermata, un’email, un reminder — i test A/B randomizzati a livello utente bastano, purché la metrica primaria sia la conversione a valle e non il click sullo step modificato. Ottimizzare il click locale a scapito della conversione finale è l’errore più comune: un bottone più accattivante che attira curiosi e abbassa la qualità del traffico a valle sembra vincere nel breve e perde nel conto economico.

Cosa rompe davvero le analisi di journey

Gli insuccessi ricorrenti hanno poche cause riconoscibili. La prima è il tracciamento incoerente: UTM mancanti sui canali paid, eventi duplicati da doppia implementazione, timestamp in fusi diversi, consensi privacy che bucano alcuni browser più di altri. Se Safari perde il 30% degli eventi per le restrizioni sui cookie e Chrome il 5%, ogni confronto cross-device è distorto in partenza. Un audit minimo — volumi per browser e device nel tempo, quota di eventi senza canale attribuito, duplicati per chiave utente più timestamp — costa poche ore e previene settimane di interpretazioni fantasiose.

La seconda è confondere correlazione e causa nei percorsi. Gli utenti che leggono le recensioni convertono di più? Forse le recensioni convincono, o forse chi è già convinto legge le recensioni per confermarsi. Prima di investire sul touchpoint “vincente”, verifica con un test: esponi un campione casuale a quel contenuto e misura la conversione incrementale contro un controllo. Senza controfattuale, stai premiando i raccoglitori di domanda e affamando i creatori.

La terza è l’ossessione per la completezza della mappa. Un journey con 200 nodi non si legge e non si agisce; uno con 6-10 nodi ben scelti guida tre decisioni chiare. Parti dai pattern che coprono la maggioranza degli utenti e del valore, segmenta solo dove i numeri divergono davvero, documenta soglie e definizioni così che il prossimo analyst ottenga gli stessi numeri. E prima di presentare una raccomandazione, fatti la domanda che separa l’analisi seria dal teatro dei dati: se questo risultato fosse falso o instabile, quale decisione sbaglieresti e quanto costerebbe? Se non sai rispondere, il lavoro non è finito — manca la baseline, il controllo o l’esperimento che lo rende affidabile.

Il benchmark che quantifica la frizione: Baymard Institute

Il Baymard Institute mantiene il benchmark più citato sull’abbandono del carrello: una sintesi di 49 studi indipendenti, aggiornata al 2024, che fissa il tasso medio intorno al 70%. La causa dominante non è il prezzo ma la frizione del percorso, con i costi extra mostrati tardi in testa alle motivazioni dichiarate dagli utenti. È la conferma empirica del metodo di questa lezione: il valore sta nel gradino specifico dove il flusso si rompe, non nel giudizio sul canale che ha portato il traffico. Prima di tagliare la sorgente con il checkout peggiore, misura il passaggio carrello-pagamento per device e rimuovi la frizione più costosa.

Domande per metterti alla prova

Prima di chiudere, mettiti alla prova con queste domande:

1. Quando l’ultimo click descrive la realtà e quando invece distrugge il budget prospecting?
2. Quale soglia di sessionizzazione spezza un percorso B2B unico in due sessioni finte?
3. Perché la matrice di transizione va sempre incrociata con i volumi assoluti per pagina?
4. Quale formula ordina i fix del funnel prima di qualsiasi heatmap?