Chi comprerà, chi se ne va,
chi non paga

Prima di aprire qualunque strumento, il lavoro è distinguere. Le tre domande sotto arrivano sempre mescolate, e chi le tiene mescolate costruisce la cosa sbagliata con grande efficienza.

1. Classificare: a quale gruppo appartiene? Questo ticket è urgente. Questo lead è caldo. Questa pratica va rivista. Ti serve una categoria, e a valle qualcuno fa una cosa diversa a seconda della categoria. La difficoltà vera sta nelle etichette: se «urgente» lo decidono cinque persone con cinque criteri, stai insegnando al modello i loro disaccordi.
2. Dare un punteggio: quanto è probabile? Probabilità che compri, che abbandoni, che non paghi. Qui non ti serve la categoria: ti serve l'ordinamento, perché domani mattina un commerciale ha tempo per venti telefonate e vuole le venti migliori. È il caso più frequente in assoluto, ed è quello in cui la calibrazione (capitolo 04) decide se il numero è utilizzabile.
3. Prevedere quando: fra quanto succede? Quando finirà il prodotto, quando si romperà la macchina, quando quel cliente smetterà di ordinare. Questa domanda ha una matematica sua, l'analisi di sopravvivenza (capitolo 13), e quasi nessuno la usa: la si schiaccia dentro la seconda, chiedendo «abbandonerà nei prossimi 90 giorni?», e si butta via metà dell'informazione.

Il cliente chiede sempre la prima. Quasi sempre gli serve la seconda. E la domanda che gli cambierebbe l'anno è la terza.

Un esempio concreto, da un lavoro vero. Un'azienda di consumabili voleva «prevedere chi abbandona». Abbiamo costruito il punteggio di abbandono, funzionava, e non è cambiato niente: perché quando il modello diceva «questo cliente sta per andarsene» era già andato. La domanda utile era un'altra: quando finirà il materiale che ha comprato. Stesso identico storico, matematica diversa, e la telefonata parte tre settimane prima invece che tre settimane dopo. Il modello di abbandono era corretto e inutile.

È successo davvero, e quel giorno ho capito che il problema non era statistico. Nessuno aveva scritto una frase in italiano.

Chiediti cos'è un cliente perso. Le risposte possibili, tutte difendibili:

• Chi ha disdetto formalmente. Pulita, oggettiva, e nella maggior parte delle aziende B2B non esiste: nessuno disdice, semplicemente smette.
• Chi non ordina da 90 giorni. E allora il cliente che ordina ogni quattro mesi da dodici anni risulta perso ogni singolo anno.
• Chi non ordina da 180. E allora te ne accorgi quando è troppo tardi per farci qualcosa.
• Chi ha ridotto del 70% ma è ancora lì. Che è il caso più interessante e quello che nessuno modella, perché serve una soglia su una quantità continua.
• Chi ha spostato gli acquisti sul concorrente pur continuando a comprare le briciole da te. Questo è il caso da prendere, e nei tuoi dati non c'è scritto da nessuna parte.

A seconda di quale scegli ottieni dataset diversi, modelli diversi, azioni diverse e ritorni diversi. Non c'è una risposta giusta in astratto: c'è la risposta giusta rispetto alla decisione che vuoi cambiare. Se l'azione è «il commerciale lo chiama», la definizione deve accendersi quando chiamare serve ancora.

Se ti danno tre definizioni di «perso» e nessuno vuole scegliere, non hai un problema di dati. Hai tre reparti che misurano tre cose e le chiamano con lo stesso nome.

Le quattro trappole dell'etichetta, in ordine di quanto le vedo:

1. L'etichetta che arriva troppo tardi. «Insoluto» diventa vero dopo 120 giorni. Se addestri su quello, il modello impara a riconoscere gli insoluti quando ormai lo sa anche il centralino.
2. L'etichetta scritta da chi decide. Se «lead caldo» lo assegna il commerciale che poi lo lavora, stai imparando le sue preferenze e le chiami previsioni. Il modello dirà che sono caldi i lead a cui lui parla volentieri.
3. L'etichetta corretta a posteriori. Le anagrafiche sistemate mesi dopo, i resi riclassificati, le pratiche riaperte. Nel database sembrano dati di allora, e non lo erano. Questo è leakage puro, e ne parlo al capitolo 11.
4. L'etichetta che non c'è. Il caso migliore di tutti: quello che vuoi prevedere nessuno l'ha mai registrato. Qui la risposta onesta è che il progetto comincia da sei mesi di raccolta, non da un modello.

Il consiglio operativo che do sempre, e che costa un pomeriggio: prendi trenta casi a caso e falli etichettare a mano da due persone brave, separatamente. Se sono d'accordo su ventotto, il target esiste e puoi partire. Se sono d'accordo su diciotto, hai appena scoperto che il tuo modello imparerà la media di due opinioni, e nessuna quantità di gradient boosting sistemerà quella cosa lì.

Un punteggio di abbandono al 91% non fa niente da solo. Serve che qualcuno, alle nove di lunedì, apra una lista e chiami. E quella persona ha tre caratteristiche che decidono il destino del progetto, e che nessun capitolato menziona:

• Ha una capacità finita. Venti telefonate, non trecento. Quindi il tuo modello non deve dire «chi abbandonerà»: deve produrre i venti nomi migliori. È un problema diverso, e lo affronto al capitolo 08.
• Non si fida, ed è ragionevole. Se il sistema le dice di chiamare un cliente che lei sa essere fedele da vent'anni, ha ragione lei e il sistema ha perso credibilità per sei mesi. Per questo la spiegazione conta più di due punti di accuratezza.
• Non ti dirà mai che ha smesso di usarlo. Continuerà ad aprire il cruscotto quando passi tu. Il progetto risulterà attivo e sarà morto.

Da qui discendono due regole che applico prima di scrivere una riga.

1. Il modello consegna una lista, non una probabilità. Ordinata, lunga quanto la capacità reale, con accanto il motivo in italiano. «Vale la pena chiamare Rossi perché ha dimezzato gli ordini da due mesi e l'anno scorso in questo periodo aveva già riordinato.»
2. Si misura quello che succede dopo la telefonata. Altrimenti fra un anno, alla domanda «quanto ci ha fatto guadagnare?», la risposta sarà un aneddoto. E la risposta seria richiede di lasciare fuori una quota di clienti che il sistema non tocca: ne parlo nel capitolo sui cicli di feedback della risorsa madre, e vale ogni riga.

Un punteggio senza una persona che agisce, una capacità che lo limita e una misura che lo verifica non è un progetto. È un file.

L'AUC misura questo, e nient'altro. È una proprietà di ordinamento. Ha un pregio enorme, cioè non dipende dalla soglia né da quanto è raro l'evento, e per questo è diventato il numero standard. Ma ha una conseguenza che quasi nessuno tira: puoi prendere tutte le probabilità del tuo modello, elevarle al quadrato, e l'AUC non si muove di un millesimo. L'ordine è identico. Le probabilità sono diventate tutte più basse. Il modello mente, e la metrica sorride.

Quando basta l'ordinamento e quando serve la probabilità vera? La regola è semplice e la uso sempre:

• Ti basta ordinare quando la capacità è fissa e decide lei. Venti telefonate al giorno: prendi i primi venti, e il valore assoluto del punteggio è irrilevante. Qui l'AUC è la metrica giusta e puoi smettere di preoccuparti.
• Ti serve la probabilità vera nel momento in cui il numero entra in un conto. «Se la probabilità di insoluto è 8% e il margine è 12%, vendo lo stesso.» Quel confronto ha senso solo se l'8% è davvero l'8%. E serve anche quando sommi: il valore atteso del portafoglio è la somma delle probabilità, e se sono gonfie del 30% hai un budget gonfio del 30%.

La domanda che decide quale delle due ti serve: il numero finisce in una lista ordinata, o dentro una moltiplicazione? Nel secondo caso, l'AUC non ti sta dicendo se puoi fidarti.

La definizione è quella che hai visto nella simulazione in cima: prendi tutti i casi a cui il modello ha dato circa il 70%, guarda quanti sono davvero successi, e speri di trovare il 70%. Ripeti per ogni fascia. Se la curva sta sulla diagonale, il modello è calibrato e le sue probabilità sono una moneta di scambio: ci puoi fare aritmetica sopra. Se sta sopra o sotto, il numero è un ordinamento travestito da probabilità.

Da dove viene lo scalibrato, perché non è sfortuna ma tre cause precise:

1. Il ricampionamento. Il caso più comune di tutti. L'evento è raro, il modello impara poco, e allora si bilancia il dataset: si tengono tutti i 500 abbandoni e si scartano 19.500 dei 19.500 fedeli. Il modello adesso vive in un mondo dove l'abbandono è al 50%, e sputa probabilità di quel mondo. In produzione l'abbandono è al 2,5%. Ogni probabilità che dice è gonfia di venti volte, e nessuno se ne accorge perché l'AUC è ottimo.
2. L'algoritmo. Alcuni modelli sono scalibrati per costruzione. Le SVM danno distanze da un iperpiano, non probabilità. Il random forest fa una media di voti e schiaccia gli estremi: fatica a dire 0,02 e 0,98. Il gradient boosting con la log-loss è invece ragionevolmente calibrato di suo, ed è uno dei motivi per cui lo uso.
3. Il tempo. Il modello era calibrato a gennaio, il mercato è cambiato, e adesso dice 70% dove la realtà fa 55%. La calibrazione è la prima cosa che si rompe con la deriva, e siccome l'ordinamento regge, l'AUC resta bello e nessuno suona l'allarme.

Come si aggiusta, e costa pochissimo: si prende un pezzo di dati che il modello non ha mai visto e si impara una funzione che rimappa i punteggi sulle frequenze osservate. Due modi standard:

• Platt scaling: una regressione logistica sopra il punteggio. Due parametri, robusta anche con pochi dati, assume una forma a S.
• Isotonic regression: una scala monotona che segue i dati senza imporre una forma. Più flessibile, vuole più dati, altrimenti impara il rumore.

Entrambe hanno una proprietà che le rende gratis: non cambiano l'ordine, quindi l'AUC resta identico. Aggiungi solo l'onestà. È una delle poche cose in questo mestiere che si può fare senza rinunciare a niente.

Tre clienti su cento abbandonano. Scrivo un modello di una riga, return false, che dice a tutti «non abbandonerà». Accuratezza: 97%. È il modello più accurato che avrai mai e vale zero. Questa battuta la trovo scritta sul serio: il 97% è il primo numero che finisce nelle slide di metà dei progetti che vedo, ed è il motivo per cui l'accuratezza, sugli eventi rari, andrebbe vietata.

Le metriche che si guardano davvero:

• Precision: dei casi che ho segnalato, quanti erano veri. È la fatica sprecata dell'operatore.
• Recall: dei casi veri, quanti ne ho presi. È il danno che ti sfugge.
• PR-AUC: la sintesi delle due al variare della soglia. Sugli eventi rari dice molto più dell'AUC, perché non si lascia impressionare dalla montagna di negativi facili.

Precision e recall si muovono in direzioni opposte, sempre. Alzi la soglia e diventi preciso ma ti sfugge roba; la abbassi e prendi tutto ma affoghi l'operatore. La simulazione qui sotto rende la cosa toccabile.

Cosa fare quando l'evento è raro, in ordine di quanto funziona sul serio:

1. Cambia metrica, non dataset. Prima di toccare i dati, guarda PR-AUC e la precision alla capacità che hai davvero (capitolo 08). Spesso il modello andava già bene e il problema era il righello.
2. Pesa gli errori invece di buttare dati. Quasi tutte le librerie hanno class_weight o scale_pos_weight: dici al modello che sbagliare su un abbandono costa venti volte. Ottieni lo stesso effetto del bilanciamento senza gettare via il 97% dello storico.
3. Se ricampioni, ricalibra. Sempre. Il sottocampionamento è legittimo per far girare le cose, ma ti restituisce probabilità del mondo finto che hai creato. Rimettile nel mondo vero prima di usarle in un conto.
4. Diffida dei dati sintetici. SMOTE e parenti inventano abbandoni interpolando fra abbandoni veri. In alta dimensione questo genera casi che non esistono in natura, e il modello impara a riconoscere la tua interpolazione. L'ho visto migliorare i numeri in laboratorio e peggiorare tutto in produzione.

Ecco la tabella che tengo a mente, con la colonna che di solito manca: quando quella metrica ti inganna.

Se puoi portare un numero solo in direzione, porta gli euro. Se puoi portarne due, porta gli euro e la precision alla capacità che avete davvero.

Una nota sull'onestà della misura, che vale per tutte le righe della tabella: quel numero deve venire da dati che il modello non ha mai visto, e che appartengono a un periodo successivo a quello di addestramento. Su questi problemi il tempo c'è sempre, anche quando sembra di no: i clienti di gennaio hanno abbandonato con le regole di gennaio. Se mescoli gli anni e fai una divisione a caso, il numero che ottieni è ottimista e falso. È lo stesso identico meccanismo che ho spiegato nel capitolo sul leakage della risorsa madre, e lo riprendo sui casi veri al capitolo 11.

Ogni classificatore, in fondo, fa questo: calcola una probabilità e poi la confronta con 0,5. Se sopra, dice sì. Quel confronto sta scritto dentro predict(), arriva gratis con la libreria, e implica una cosa precisa: sbagliare in un senso costa esattamente quanto sbagliare nell'altro. Nella tua azienda questo è falso praticamente sempre.

• Chiamare per sbaglio un cliente fedele: cinque minuti di un commerciale, e forse gli fa pure piacere.
• Non chiamare un cliente che se ne va: il suo margine annuo, per gli anni che sarebbe rimasto.

Il rapporto fra i due costi, in un caso del genere, è di uno a mille. E la soglia giusta si scrive in una riga.

Perché quasi nessuno lo fa, e non è pigrizia. Perché per usare quella formula bisogna rispondere a due domande che in azienda nessuno ha mai messo per iscritto: quanto costa disturbare un cliente per niente, e quanto vale un cliente perso. Ho visto riunioni intere fermarsi lì. E quando finalmente li quantificano, succede la cosa interessante: scoprono che la policy in vigore da anni corrisponde a un rapporto di costi che nessuno sceglierebbe consapevolmente. La domanda è arrivata con l'AI, la risposta non aveva bisogno dell'AI.

Due avvertenze, perché la formula è semplice e le semplificazioni si pagano:

1. Vale se le probabilità sono calibrate. Se il modello dice 8% dove la realtà fa 30%, tagliare a 0,0099 non fa quello che credi. Prima taratura (capitolo 04), poi soglia.
2. I costi non sono uguali per tutti. Perdere il cliente da 200.000 euro l'anno non costa come perdere quello da 800. Il passo successivo, che vale ancora più della soglia, è ordinare per impatto atteso: probabilità per valore. Ne parlo nel capitolo 17.

La soglia del capitolo precedente assume che tu possa agire su tutti quelli che superano il taglio. Con costi molto sbilanciati la soglia ottima diventa bassissima, e ti ritrovi con quattromila clienti da chiamare e due persone al telefono. A quel punto la soglia teorica è corretta e inapplicabile.

La riformulazione che uso, e che cambia il progetto: il modello non produce una probabilità, produce la lista dei venti. Da qui discendono tre cose concrete.

1. La metrica diventa precision@k. Dei primi venti che ti ho dato, quanti erano veri? Questo numero parla la lingua dell'operatore, si misura la settimana dopo, e non si lascia impressionare dalla rarità.
2. L'ordinamento torna a essere l'unica cosa che conta. Se la capacità decide il taglio, la calibrazione serve meno per questa decisione. Ti serve ancora per il conto economico, ma la lista di domani la fa l'ordine.
3. Il problema diventa di allocazione. Venti telefonate, mille candidati, valori diversi: è esattamente un problema di ottimizzazione sotto vincolo, cugino di quelli che stanno nella parte sull'ottimizzazione della risorsa madre. E la funzione da massimizzare diventa probabilità per valore per recuperabilità, dove la probabilità da sola è solo il primo dei tre fattori.

Quel terzo fattore è quello che nessuno mette. Un cliente che sta per andarsene con probabilità 95% spesso è già andato: chiamarlo è teatro. Il valore sta nei clienti al 60%, dove la telefonata può ancora cambiare la storia.

E qui si apre la porta della cosa più importante di tutto il capitolo, che merita la sua risorsa e che ti anticipo. La domanda giusta non è «chi abbandonerà». È «su chi la mia telefonata cambia l'esito». Sono due liste diverse, e si sovrappongono meno di quanto immagini: contengono clienti che se ne andrebbero comunque, clienti che resterebbero comunque, e la fetta sottile su cui la chiamata fa la differenza. Distinguerle si chiama uplift modeling, e richiede un esperimento: un gruppo che chiami e uno che deliberatamente non chiami. Chi ha letto il capitolo sulla causalità sa già perché non se ne esce senza.

Nella risorsa madre c'è la tabella generale degli algoritmi. Qui li guardo da vicino sul caso che ci interessa: una tabella con ventimila clienti, cinquanta colonne, e un sì o no da prevedere.

1. Regressione logistica. Il baseline obbligatorio, e a volte il vincitore. Ti dà coefficienti che una persona legge, probabilità naturalmente calibrate, e gira in un istante. Il suo limite è che vede solo relazioni lineari: le interazioni («il ritardo conta solo per i clienti piccoli») gliele devi scrivere tu a mano. Parti sempre da qui, se non altro per avere un numero contro cui misurare tutto il resto.
2. Gradient boosting (XGBoost, LightGBM, CatBoost). Il vincitore nella stragrande maggioranza dei casi reali, e lo è ancora oggi contro il deep learning sulle tabelle. Trova le interazioni da solo, mangia valori mancanti e variabili categoriche senza fare storie, e con la log-loss esce ragionevolmente calibrato. Il prezzo: adora il leakage e non estrapola.
3. Random forest. Robusto, quasi zero tuning, ottimo secondo posto. Il difetto che conta qui: schiaccia le probabilità verso il centro, perché fa una media di voti. Fatica a dire 0,02 e 0,98, e quindi va tarato prima di metterlo in un conto.
4. SVM. Utile con pochi dati e molte colonne, tipicamente sul testo. Su ventimila clienti scala male e ti dà distanze, non probabilità. Oggi è di nicchia.
5. kNN. Raramente il modello finale, spesso lo strumento migliore per la spiegazione: «i tre clienti più simili a questo se ne sono andati tutti e tre». È il nonno della ricerca vettoriale ed è la cosa che convince un commerciale in due secondi.
6. PCA. Serve a preparare i dati, e da sola non predice niente. Comprime colonne correlate, e ti costa la spiegabilità: dopo la PCA nessuno sa più cosa vuol dire una variabile. Sulle tabelle aziendali, dove la spiegazione serve, la uso poco.
7. Reti neurali. Sulle tabelle costano dieci volte tanto per fare peggio. Servono quando dentro ci sono segnali (testo, immagini, sequenze lunghe), e allora si combinano: la rete estrae, il boosting decide.

Regressione logistica per capire, gradient boosting per vincere, kNN per spiegare. Il resto, su una tabella di clienti, è quasi sempre lusso.

Una cosa che vale più della scelta dell'algoritmo, e che dico controvoglia perché è poco affascinante: la differenza fra il miglior algoritmo e il secondo è di solito un punto di AUC. La differenza fra la feature giusta e la sua assenza è dieci. Se hai un pomeriggio, non spenderlo a provare un modello nuovo. Spendilo a parlare con chi lavora lì da vent'anni. È il capitolo che segue.

Su un problema di abbandono in B2B, tre colonne fanno quasi tutto il lavoro. Le conoscono con una sigla vecchia di decenni, RFM, e battono regolarmente modelli molto più eleganti:

• Recency: quanti giorni dall'ultimo ordine. Da sola, la variabile più predittiva che esista in quasi ogni azienda.
• Frequency: quanti ordini in un periodo, e soprattutto come sta cambiando il ritmo rispetto al ritmo abituale di quel cliente.
• Monetary: quanto vale, e come si sta muovendo il valore.

La parte che quasi tutti sbagliano sta in quel «rispetto al ritmo abituale». Un cliente che ordina ogni quattro mesi e non ordina da tre è in perfetto orario. Un cliente che ordina ogni settimana e non ordina da tre è già andato. La feature giusta si scrive «giorni dall'ultimo ordine diviso il suo intervallo tipico», e quel rapporto vale molto più del numero secco. Una divisione, e il modello smette di confondere abitudini diverse.

Le famiglie di colonne che aggiungo sempre, in ordine di ritorno:

1. I rapporti, non i valori assoluti. Il fatturato di questo trimestre diviso la media dei quattro precedenti dice cento volte di più del fatturato.
2. Il calendario vero. Giorni lavorativi del mese, agosto, festività mobili, chiusura del bilancio del cliente. Una colonna «numero di sabati nel mese» ha risolto più problemi di certe reti neurali.
3. Le derivate. Non «quanti ticket ha aperto», ma «quanti ne ha aperti negli ultimi 30 giorni rispetto ai suoi soliti».
4. Il testo trasformato in colonne. Le note del commerciale, le mail, i verbali. È l'80% dell'informazione aziendale e nessun modello tabellare l'ha mai potuta leggere. Oggi si può, e come si fa lo racconto nella risorsa madre: è la leva più sottovalutata del momento.

E il metodo per trovarle, che vale più di qualsiasi tecnica automatica: siediti con il commerciale più bravo e chiedigli come fa a capire che sta per perdere un cliente. Ti dirà cose come «quando cominciano a chiedere il DDT separato», «quando smettono di chiamare per le urgenze», «quando l'ordine arriva via mail invece che per telefono». Ognuna di quelle frasi è una colonna, e quasi sempre è nei tuoi dati, solo che a nessuno era venuto in mente di guardarla.

Il novanta per cento del valore di un data scientist bravo è saper fare le domande giuste a quella persona. Il modello lo sa allenare chiunque.

Nel capitolo sul leakage della risorsa madre ho spiegato il meccanismo. Qui lo applico ai quattro casi di questa pagina, perché ognuno ha la sua trappola tipica e la riconosci solo se l'hai già vista.

1. Insoluti: i solleciti. Fra le colonne c'è «numero di solleciti inviati». L'AUC arriva a 0,98 e c'è festa. Peccato che i solleciti si mandino dopo che il cliente non ha pagato. Il modello ha imparato a leggere il passato e lo chiama profezia.
2. Abbandono: l'anagrafica aggiornata. Lo stato del cliente diventa «cessato» in anagrafica, e quel campo lo leggi da una tabella che riporta la situazione di oggi, non di allora. Sembra un dato innocente. È la risposta scritta a matita sul banco.
3. Guasti: la manutenzione registrata. Fra le feature c'è «ore di fermo macchina nell'ultimo mese». Il fermo è la conseguenza del guasto che stai cercando di prevedere. Il modello prevede benissimo guasti già successi.
4. Lead: l'assegnazione al commerciale. «Assegnato al senior» predice benissimo la chiusura. Certo: al senior i lead buoni glieli danno perché sono buoni. Il modello ha imparato la politica interna dell'ufficio commerciale.

La domanda che smaschera tutte e quattro, e che va fatta a ogni singola colonna, in forma brutale: «alle nove di lunedì, quando devo decidere, ho questo valore in mano, e ha esattamente questo valore?» Se la risposta è «beh, quasi», è no. Se è «sì ma viene caricato a fine mese», è no. Se è «sì ma qualcuno lo corregge dopo», è il caso peggiore di tutti, perché nel database c'è e sembra a posto.

Il sintomo universale lo ripeto perché mi ha salvato più volte di qualunque strumento: va troppo bene. In ventisei anni, un risultato splendido ottenuto al primo colpo è stato un errore nel novanta per cento dei casi. Il modello che funziona davvero, all'inizio, funziona così così.

La difesa strutturale, per chi lavora su dati che valgono soldi, si chiama point-in-time correctness: registrare non solo il valore, ma da quale istante era conoscibile, e ricostruire il training «come si vedeva allora». È lavoro serio, si fa una volta, e trasforma la domanda «stiamo barando?» da opinione a interrogazione. Chi ha letto la risorsa su Entity Framework sa che questa cosa non nasce nel modello: nasce nello strato dati, in come sono scritte le tabelle e in cosa succede quando qualcuno aggiorna una riga senza storicizzarla.

Il caso è questo: cinquemila articoli, e la coda lunga ha tre vendite l'anno a testa. Un modello per articolo non sta in piedi. Un modello unico per tutti tratta il ricambio raro come il consumabile che gira ogni settimana. Le due strade comode sono entrambe sbagliate.

La via di mezzo si chiama modello gerarchico, ed è una delle idee più eleganti della statistica applicata. Il ragionamento è quello che farebbe una persona di buon senso: se di questo articolo so pochissimo, parto da quello che so della sua famiglia, e mi sposto da lì solo quanto i suoi pochi dati mi autorizzano a spostarmi. Tre vendite non mi fanno cambiare idea di molto. Trecento sì.

Le alternative pratiche, quando non vuoi tirare fuori l'artiglieria bayesiana:

• Un modello solo, con la famiglia come colonna. Il boosting impara da sé a usare il livello di famiglia quando l'articolo non ha storia. Semplice, funziona, e nel 70% dei casi basta.
• Target encoding con smoothing: la media della categoria, tirata verso la media generale in proporzione a quanti dati ha. È lo stesso identico compromesso della formula, scritto come feature. Attenzione a calcolarlo solo sul training, o hai appena fatto leakage.
• Rinunciare, e dirlo. Per l'articolo con due vendite la risposta onesta è che non si può prevedere. Un sistema che risponde sempre è un sistema che mente bene: meglio una regola esplicita («sotto cinque vendite, scorta minima fissa e amen») che una previsione inventata con tre decimali.

La domanda arriva così: «quanto dura in media un cliente?». Il modo naturale di rispondere è aprire lo storico, prendere quelli che se ne sono andati, misurare quanto sono rimasti e fare il conto. Il numero esce, sembra ragionevole, ed è sistematicamente troppo basso.

Il motivo è che hai escluso dal conto tutti quelli che sono ancora qui. E quelli, per definizione, sono i più duraturi: il cliente entrato dieci anni fa e ancora attivo non compare nella tua media, perché la sua durata non è ancora finita. Sai solo che è almeno dieci anni. Quel «almeno» è informazione preziosa, e buttarla via è l'errore più diffuso che vedo su questa domanda.

Il termine tecnico è censura a destra: conosci l'inizio, sai che alla data di oggi non è ancora successo niente, e non sai quando succederà. La statistica ha una risposta a questo problema da settant'anni, si chiama stimatore di Kaplan-Meier, e usa tutti: chi se n'è andato contribuisce con la sua durata, chi è ancora qui contribuisce con il suo «almeno».

Cosa ti dà in più questa famiglia di modelli, oltre a non sbagliare la media:

1. Una curva invece di un numero. Non «il 12% abbandonerà», ma «ecco la probabilità di essere ancora qui fra 3, 6, 12 mesi». Da lì esce la mediana, che è la domanda che ti fanno: fra quanto ne perdo metà?
2. Il rischio istantaneo (l'hazard): non «se» ma «quando è pericoloso». Nella maggior parte dei business non è costante: c'è un picco nei primi 90 giorni, poi si calma. Sapere dove sta il picco ti dice quando spendere l'attenzione.
3. L'effetto delle variabili sul tempo. Con un modello di Cox o con un boosting per sopravvivenza chiedi «questa promozione allunga la vita del cliente, e di quanto?». Risposta in mesi, non in probabilità.

Chiedere «abbandonerà nei prossimi 90 giorni?» invece di «quando?» è comodo, si fa col classificatore che sai già usare, e butta via la metà più utile dell'informazione.

Il cliente compra un consumabile: toner, filtri, reagenti, ricambi, materiale d'irrigazione, qualunque cosa si esaurisca. Tu sai cosa ha comprato e quando. Da lì puoi stimare quando finirà, e chiamarlo la settimana prima. Non quando è troppo tardi, non a caso ogni tre mesi: la settimana prima.

Cosa cambia, in concreto:

• Il commerciale chiama con un motivo vero e non con una scusa. «Le sta finendo il materiale» è una telefonata che il cliente ringrazia.
• Il concorrente non fa in tempo a entrare. La finestra in cui si cambia fornitore è esattamente quella in cui il prodotto sta finendo.
• Le telefonate scendono di numero e salgono di resa. Chiami venti clienti giusti invece di duecento a caso.

Come si costruisce, in ordine di sofisticazione, e il primo gradino basta più spesso di quanto pensi:

1. Il consumo medio del cliente. Quantità comprata diviso i giorni fra un ordine e l'altro. Ti dà il ritmo personale di quel cliente, che è tutto ciò che serve nella maggior parte dei casi. Costa una query.
2. Il ritmo che cambia. Il consumo non è costante: c'è stagionalità (l'irrigazione d'estate), ci sono le campagne, ci sono gli anni buoni. Qui entra il forecasting vero, quello della risorsa madre.
3. La sopravvivenza applicata al riordino. Invece di una data secca, una curva: «probabilità che abbia finito entro il giorno X». E allora la telefonata parte quando quella probabilità supera la soglia che esce dai tuoi costi (capitolo 07). Tutto si tiene.

Le tre trappole, tutte viste sul campo:

• Il cliente che ha scorte. Ha comprato per sei mesi ma ne usa per tre: ha il magazzino pieno. Se non lo sai, chiami sempre troppo presto e diventi quello che rompe.
• Il cliente che compra anche altrove. Il tuo consumo stimato è sbagliato per costruzione, perché vedi solo la tua fetta. E questo è proprio il segnale che vorresti: se consuma più di quanto compra da te, qualcun altro sta servendo la differenza.
• Il dato censurato di nuovo. Chi non ha ancora riordinato sta dicendo «non ancora», e tu lo stai leggendo come «mai più». È lo stesso identico errore del capitolo prima, applicato all'articolo invece che al cliente.

Questa è la previsione che i clienti ti pagano volentieri, perché non chiede a nessuno di cambiare mestiere: dice solo al commerciale chi chiamare lunedì. E si costruisce sopra dati che hai già.

Il valore del ciclo di vita, o CLV, mette insieme i due pezzi dei capitoli precedenti: quanto margine fa un cliente per periodo e per quanti periodi resterà. Il secondo è esattamente la curva di sopravvivenza. È il punto in cui tutta questa matematica smette di essere un esercizio e diventa un budget.

A cosa serve, in pratica, e sono tutte decisioni che oggi qualcuno prende a naso:

1. Quanto posso spendere per acquisire un cliente. Se vale 3.000 euro di margine attualizzato, spenderne 900 per prenderlo è ottimo e spenderne 3.500 è follia. Metà delle campagne che ho visto non sapeva rispondere a questa domanda.
2. Quanto posso spendere per tenerlo. Lo sconto di retention ha senso finché è sotto il valore che salvi. E il valore che salvi dipende da quanto sarebbe rimasto, non da quanto ha speso finora.
3. Chi chiamo per primo. Non chi ha la probabilità di abbandono più alta: chi ha probabilità per valore più alto. Un cliente da 200 euro al 90% vale meno di uno da 50.000 al 20%.
4. Quanto vale l'azienda. Il portafoglio clienti è un attivo, e questo è il modo di stimarlo con dei numeri difendibili.

Due errori che rendono il CLV pericoloso invece che utile:

• Usare il fatturato al posto del margine. Il cliente che compra tantissimo con lo sconto massimo e chiama l'assistenza ogni giorno può avere un CLV negativo. Succede più spesso di quanto le direzioni commerciali vogliano sapere.
• Guardare indietro invece che avanti. Sommare quanto ha speso finora produce nostalgia, non una previsione. Il CLV è una previsione, con tutta l'incertezza delle previsioni, e va dato con un intervallo, come spiego nel capitolo sull'incertezza della risorsa madre.

Quattro problemi diversi, una regola sola: la trappola non sta mai nel modello. Sta in una colonna che non potevi avere, in un'etichetta che arriva tardi, o in una decisione umana che il modello ha imparato scambiandola per la realtà.

Il conto si fa così, e ci vuole un foglio. Prendi il caso dell'abbandono, con numeri che vedo spesso:

1. Quanti eventi all'anno. Diecimila clienti, il 3% se ne va: 300 abbandoni.
2. Quanto vale ognuno. Non il fatturato: il margine per gli anni che sarebbe rimasto, cioè il CLV del capitolo 15. Diciamo 1.500 euro.
3. Quanti ne intercetti e quanti ne recuperi. Ed è qui che i business case mentono. Il modello ne segnala 200 dei 300 (recall 67%), tu ne chiami quanti la capacità consente, e di quelli chiamati ne recuperi una frazione. Non il 100%: se va molto bene, il 20%.
4. Quanto costa la macchina. Le telefonate, il tempo, il presidio del modello.

Con questi numeri: 200 intercettati per 20% recuperato fa 40 clienti salvati, per 1.500 euro fa 60.000 euro l'anno. Poi togli il costo delle telefonate inutili (i falsi positivi, che a 5 euro l'una sono spiccioli) e il presidio. Resta un numero che si può portare in direzione senza vergognarsi, ed è quasi sempre molto più piccolo di quello che promette chi vende software, e molto più credibile.

Il moltiplicatore che tutti dimenticano è il terzo: quanti ne recuperi davvero fra quelli che chiami. Un progetto che assume il 100% è un progetto che non ha mai fatto una telefonata.

E adesso la domanda cattiva, quella che rende questo capitolo diverso da un business case qualunque: quel 20% di recupero, come lo sai? Se non hai mai tenuto un gruppo di clienti che il sistema segnala e che nessuno chiama, non lo sai: lo stai supponendo. E l'unica misura onesta del progetto è la differenza fra i chiamati e i non chiamati. Costa qualche decina di clienti l'anno, e compra l'unica risposta possibile alla domanda che prima o poi arriva dal consiglio. La spiego per intero nel capitolo sulla causalità della risorsa madre, e vale ogni riga.

Se ne reggi otto su dodici senza aprire, questa risorsa ha fatto il suo lavoro.

Sono Matteo Migliore, ho fondato Sviluppatore Migliore e sono ventisei anni che costruisco sistemi in cui il software deve decidere qualcosa e poi risponderne. Le cose di questa pagina vengono dalle volte in cui ho creduto a un AUC che era leakage, dalle soglie lasciate a 0,5 per mesi, e dalla telefonata partita tre settimane dopo che il cliente era già andato.

Se hai uno storico di clienti, ordini o macchine, nella maggior parte dei casi in mezza giornata si capisce se c'è un progetto oppure no. E se non c'è, te lo dico: è la cosa che fa risparmiare più tempo a me e più soldi a te.

Scrivimi su WhatsApp, risponde Silvia e fissiamo mezz'ora.