I quattro
mucchi

La simulazione qui sopra ha mostrato il problema grosso. Adesso quello che ne discende, e che è più utile: due decisioni tue, prese prima di far girare qualsiasi cosa, determinano il risultato molto più dell'algoritmo che sceglierai.

La prima è quante colonne, e quali. Se segmenti i clienti su fatturato e frequenza, ti escono gruppi per fatturato e frequenza. Se ci aggiungi la provincia, ti escono gruppi geografici, perché la geografia divide bene e prende il sopravvento. Se ci metti trenta colonne, non esce niente: in trenta dimensioni tutti i punti sono lontani da tutti, la distanza smette di significare qualcosa e l'algoritmo produce mucchi arbitrari. Si chiama maledizione della dimensionalità, ed è il motivo per cui una segmentazione su tre colonne scelte bene batte quasi sempre una su trenta prese tutte.

La seconda è la scala. Il fatturato va da 100 a 900.000. La frequenza va da 1 a 40. Se non normalizzi, il fatturato è mille volte più grande e i tuoi gruppi saranno solo fasce di fatturato, con la frequenza che non conta niente. Questo è il singolo errore tecnico che trovo più spesso nelle segmentazioni fatte in casa, ed è invisibile: i gruppi escono, hanno senso, e sono la stessa cosa che avresti ottenuto ordinando i clienti per fatturato in Excel.

Se dopo un progetto di segmentazione i gruppi che escono sono «i grandi, i medi, i piccoli», hai speso tre settimane per fare un ORDER BY fatturato. Succede spessissimo, ed è quasi sempre la scala non normalizzata. La differenza è che adesso ha un nome inglese e nessuno osa dire che è banale.

La sequenza che uso, ed è noiosa apposta:

1. Scegli le colonne partendo dalla decisione, non dai dati che hai. Se la decisione è «a chi mando quale offerta», le colonne sono quelle che cambiano l'offerta. La provincia non c'entra, e va tolta anche se è lì.
2. Tre o quattro colonne, non trenta. Se non riesci a spiegare a voce perché ognuna c'è, non c'è.
3. Normalizza, sempre. E su fatturati e frequenze usa il logaritmo prima, perché sono distribuzioni con una coda lunghissima e senza logaritmo i tre clienti enormi si prendono un gruppo per sé.
4. Calcola la silhouette. Se sta sotto 0,25 hai finito: non ci sono gruppi, e va detto. È il momento in cui un consulente onesto si distingue, perché la slide con la torta la potrebbe fare lo stesso e nessuno se ne accorgerebbe.

Sono quelle che faccio quando qualcuno mi mostra la sua. Non le faccio per cattiveria: se una segmentazione le supera è buona, e da quel momento la difendo io.

1. «Cosa farete di diverso con il gruppo 2 rispetto al gruppo 3?»
   Se la risposta è «comunicheremo in modo diverso», chiedi come, precisamente. Se non c'è una risposta concreta, quei due gruppi sono lo stesso gruppo, e vanno uniti. Una segmentazione ha esattamente tanti gruppi quante sono le cose diverse che sai fare. Se le offerte sono tre, i gruppi sono tre, e non importa cosa dice il gomito nel grafico.
2. «Quanti clienti cambiano gruppo ogni mese?»
   Nessuno lo calcola mai, ed è il numero più informativo di tutti. Se il 40% dei clienti salta da un gruppo all'altro ogni mese, quei gruppi non descrivono delle persone: descrivono il rumore di quel mese. Ed è la conseguenza diretta della simulazione qui sopra: se i gruppi li ha inventati l'algoritmo, i confini sono arbitrari e i clienti ci passano sopra in continuazione. Sotto il 10% di migrazione mensile la segmentazione è stabile e ci si può costruire sopra qualcosa.
3. «Chi la usa, e l'ha aperta nell'ultimo mese?»
   La domanda del capitolo sulla produzione, applicata qui. Le segmentazioni sono le regine del cassetto: bellissime, condivise, mai aperte. Se la risposta è «l'abbiamo presentata in comitato», non la usa nessuno.

La prima domanda è quella che uccide di più, e vale la pena spiegarla al contrario, perché è così che si costruisce una segmentazione buona: parti dalle azioni. Cosa sai fare di diverso? So mandare un'offerta aggressiva, so mandare un promemoria gentile, so far chiamare un commerciale, e so non fare niente. Quattro azioni. Allora i gruppi sono quattro, e il problema smette di essere «trova i gruppi». Diventa «per ogni cliente, quale delle quattro azioni?». Che è una domanda con una risposta verificabile, ed è la classificazione, non il clustering.

Quasi ogni volta che qualcuno chiede una segmentazione, il problema vero era un altro: assegnare a ogni cliente una delle azioni che sai già fare. Quello si misura, si collauda, e si può sbagliare. Il clustering non si può sbagliare, e per questo non serve a niente.

Questa è la parte che mi fa perdere qualche progetto e che dico lo stesso. Esiste una segmentazione che funziona quasi ovunque si venda qualcosa a qualcuno più di una volta, ha cinquant'anni, la usavano le aziende di vendita per corrispondenza negli anni Settanta, e si scrive in venti righe di SQL. Si chiama RFM, e sono tre domande:

• Recency: quanto tempo è passato dall'ultimo acquisto.
• Frequency: quante volte ha comprato.
• Monetary: quanto ha speso.

Dividi ciascuna in tre o cinque fasce, e hai i tuoi gruppi. Chi ha comprato ieri, spesso, e tanto, è il tuo cliente migliore. Chi ha comprato tanto e spesso ma non si vede da otto mesi è quello da chiamare oggi, ed è il gruppo che vale più soldi di tutti gli altri messi insieme. Chi ha comprato una volta, poco, tre anni fa, non è un cliente.

Perché batte il k-means, e non è nostalgia:

1. I gruppi hanno un nome che significa qualcosa, e non gliel'ho dato io a posteriori guardando un grafico. «Comprava spesso e ha smesso» è una descrizione che un commerciale capisce e su cui agisce stamattina. «Cluster 3» no.
2. I confini li hai scelti tu, quindi sono stabili. Il k-means li muove ogni volta che rigiri i dati, e il cliente al confine oggi è nel gruppo 2 e domani nel 3, senza aver fatto niente.
3. Recency, frequency e monetary sono già quasi tutto il segnale che c'è nel comportamento d'acquisto. Le altre venti colonne che vorresti aggiungere sono, nella grande maggioranza dei casi, correlate a queste tre.
4. Si spiega in trenta secondi, e questo determina se verrà usata, come nel capitolo sulla fiducia.

Quando invece serve qualcosa di più: quando il comportamento ha una forma che RFM non cattura. Chi compra solo in saldo. Chi compra solo una categoria. Chi ordina in modo stagionale contro chi ordina uniforme. Quelle sono colonne che ti costruisci a mano, e a quel punto sì, un clustering su quelle tre o quattro colonne può tirare fuori qualcosa che non sapevi. Ma parti dalla RFM, e chiedi al clustering di batterla: se non la batte, ha vinto la RFM e hai risparmiato tre settimane.

Il metodo che uso adesso, e che ho costruito dopo aver consegnato un certo numero di torte colorate che non ha usato nessuno. Si fa al contrario di come lo fanno tutti.

1. Si parte dalle azioni, in una riunione senza dati. «Cosa sapete fare di diverso a un cliente?» Escono sempre fra le tre e le sei cose: sconto, chiamata, campione gratuito, visita, promemoria, niente. Quelle sono le uniche divisioni che possono servire, perché sono le uniche che esistono.
2. Per ogni azione, si scrive a chi andrebbe fatta. A voce, in italiano. «Il campione gratuito serve a chi non ha mai preso quella categoria ma compra le altre.» Adesso hai una regola, e l'hai avuta senza dati.
3. Si guarda quanti clienti finiscono in ciascuna. Se una regola prende tre clienti, quella è una telefonata, non un segmento. Se ne prende il 90%, non divide niente. Qui i dati servono, e servono per contare, che è il loro mestiere migliore.
4. Solo adesso, se avanza tempo, si prova il clustering, per vedere se trova una divisione che nessuno aveva pensato. A volte succede. È un bonus, non il progetto.

Il punto tre nasconde la cosa più utile di questo capitolo. Il conto che decide tutto è: quanto vale, in euro, trattare un cliente in modo diverso invece che uguale a tutti? Se mandare l'offerta giusta invece di quella standard vale il 2% di conversione in più su un gruppo di 400 clienti da 300 euro, sono 2.400 euro l'anno. Una segmentazione che costa tre settimane per generare 2.400 euro non si fa, e questo conto si fa prima, in cinque minuti, non dopo.

Un segmento vale la pena di esistere quando trattarlo in modo diverso rende più di quanto costa trattarlo in modo diverso. Sembra ovvio scritto così, e nella pratica quasi nessuno fa quella sottrazione, perché il costo di gestire quattro comunicazioni invece di una non compare in nessuna slide.

Qui c'è la parte per cui vale la pena leggere questa risorsa. Ogni tabella clienti che ho visto tratta i clienti come righe indipendenti: ognuno con il suo fatturato, la sua provincia, la sua storia. È una finzione, ed è comoda, ed è il motivo per cui certe cose non le vedi.

I tuoi clienti sono collegati. Tre società diverse con la stessa sede legale. Due aziende che comprano sempre lo stesso prodotto insieme nella stessa settimana. Un fornitore da cui dipendono, senza che tu lo sappia, sette dei tuoi dieci clienti principali. L'amministratore che compare in quattro anagrafiche diverse. Nessuna di queste informazioni è una colonna della tabella clienti, e nessuna query con un GROUP BY te la farà mai vedere.

Un grafo è la struttura che le rende visibili: nodi (clienti, prodotti, fornitori, persone) e archi (chi è collegato a chi, e come). Le tre cose che ci si fanno e che nella mia esperienza valgono soldi veri:

1. Il rischio nascosto. Sette dei tuoi dieci clienti principali dipendono dallo stesso fornitore. Se quel fornitore chiude, tu perdi il 40% del fatturato in un mese, e nel tuo gestionale questa informazione non esiste da nessuna parte. Si trova solo guardando gli archi, e quando la trovi cambia una decisione strategica, non una campagna.
2. Il gruppo societario che nessuno aveva mappato. Quattro clienti che tratti come quattro clienti sono in realtà lo stesso gruppo, e stanno negoziando con te separatamente ottenendo quattro sconti diversi. Si vede unendo le anagrafiche per amministratori e sedi condivise. Questo lo trovo praticamente sempre, in tutte le aziende, e si ripaga da solo alla prima trattativa.
3. La comunità di prodotti. Non «chi compra A compra anche B», che è la raccomandazione. Ma: quali prodotti formano un blocco che i clienti prendono insieme. Quei blocchi sono cataloghi, kit, e a volte la scoperta che due categorie che tu tieni separate per ragioni storiche, per i clienti sono una cosa sola.

Il punto tecnico che rende questa roba fattibile in un pomeriggio, e che tolgo di mezzo subito: quasi sempre non ti serve un database a grafo. Ti serve una query con un self-join sulla tabella che hai già. «Dammi tutte le coppie di clienti che condividono un indirizzo» è una riga di SQL. Il grafo è un modo di pensare al problema, e nella grande maggioranza dei casi resta un modo di pensare: la tecnologia dedicata serve quando gli archi sono milioni e le domande sono «trovami il percorso più corto fra questi due nodi», che nelle aziende italiane medie non capita quasi mai.

Il valore dei grafi, nella mia esperienza, non sta negli algoritmi famosi. Sta nel gesto di guardare i clienti come collegati invece che come righe. Quel cambio di sguardo, applicato con venti righe di SQL, trova cose che nessun modello sulla tabella piatta troverà mai, perché lì dentro quell'informazione è stata distrutta il giorno in cui è stato disegnato il database.

Dopo l'entusiasmo del capitolo precedente, la parte onesta, perché su questa famiglia ho visto sprecare parecchi soldi.

• Se gli archi non li hai, non li fa nascere il grafo. Questo è il fallimento numero uno. «Colleghiamo i clienti fra loro» presuppone che nel tuo database ci sia qualcosa che li collega: un indirizzo condiviso, un ordine comune, un referente. Se ogni cliente ha solo i suoi campi, non c'è nessun arco, e nessuna tecnologia lo inventa. Prima di qualunque progetto sui grafi la domanda è: quali archi ho, e quanti sono? Se la risposta è «pochi e sporchi», il progetto è un progetto di pulizia dell'anagrafica, e va chiamato con il suo nome.
• Gli archi sporchi sono peggio che nessun arco. «Via Roma 1» e «V.le Roma, 1» sono lo stesso indirizzo e per il tuo database sono due cose diverse. Metà del lavoro di un progetto sui grafi è normalizzare le stringhe, ed è un lavoro noioso che nessuno vuole preventivare. Se lo salti, il grafo che ottieni è un grafo di errori di battitura.
• Le comunità sono il clustering, con gli stessi difetti. Gli algoritmi che trovano le «comunità» in un grafo hanno esattamente il problema della simulazione in cima a questa pagina: le trovano sempre, anche in un grafo casuale. Esiste anche qui un numero che ti avverte, si chiama modularità, e come la silhouette non lo guarda quasi nessuno.
• Le reti neurali sui grafi, quasi mai. Sono una cosa bellissima e in un'azienda italiana media non le ho mai viste ripagare. Servono quando hai milioni di nodi e un problema di previsione sul grafo stesso. Sotto quella scala, un self-join e un'occhiata di un umano trovano il 90% del valore in un pomeriggio.

La regola che uso per decidere se c'è un progetto: disegna venti nodi su un foglio, a mano, con i loro archi veri presi dal database. Se guardandoli qualcuno del mestiere dice «ah, ma allora questi due sono la stessa cosa», hai un progetto. Se dice «sì, lo sapevamo», non ce l'hai, e l'hai scoperto in un pomeriggio invece che in tre mesi.

Come per le decisioni, qui non ci sono token da pagare e non serve nessuna GPU. Il conto è tutto in giornate di persone, e la buona notizia è che sono poche.

• La RFM: due giorni. Venti righe di SQL e una riunione per decidere le fasce. Nella maggior parte dei casi il progetto finisce qui e va bene così.
• Il clustering fatto come si deve: una settimana, di cui quattro giorni per scegliere e pulire le tre colonne giuste e uno per far girare l'algoritmo. Se il rapporto ti sembra sbilanciato, è perché è esattamente quello il mestiere.
• Il grafo delle relazioni: da tre giorni a tre settimane, e la forbice sta tutta nella pulizia dell'anagrafica. Chiedi di vedere dieci indirizzi presi a caso prima di dare un numero.
• La concentrazione del rischio: mezza giornata. È il miglior rapporto valore-su-costo di tutta questa serie di risorse, e nessuno la fa.

L'ordine che consiglio a chi parte da zero, ed è pensato per scoprire presto se c'è qualcosa:

1. RFM, due giorni. Se risolve, hai finito e hai speso due giorni.
2. Concentrazione del rischio, mezza giornata. Fallo comunque, anche se nessuno l'ha chiesto: è il punto in cui è più probabile trovare un numero che sorprende il proprietario.
3. Gruppi societari nascosti, se l'anagrafica non è un disastro. Si ripaga alla prima trattativa.
4. Clustering, alla fine, e solo per vedere se batte la RFM. Con la silhouette calcolata e detta ad alta voce.

Su questa famiglia ho un consiglio che vale più del resto: se qualcuno ti propone una segmentazione come primo progetto di dati, chiedi cosa cambierà il lunedì mattina. È il progetto più facile da vendere, il più bello da mostrare, e quello con la più alta probabilità di finire in un cassetto senza che nessuno se ne accorga, perché non produce nemmeno un errore di cui lamentarsi.

1. Quanti gruppi ci sono nei tuoi clienti?
   Quanti ne chiedi. Il numero non è nei dati: chiedi quattro mucchi e l'algoritmo ti dà quattro mucchi, chiedine sette e te ne dà sette, altrettanto convincenti.
2. Il clustering può dirti che non ci sono gruppi?
   No, non è una risposta che ha nel repertorio. Su una nuvola senza nessuna struttura ti restituisce comunque segmenti pieni e colorati.
3. Qual è l'unico numero che ti avverte?
   La silhouette. Sopra 0,5 la struttura c'è, fra 0,25 e 0,5 è debole e quasi sempre l'ha inventata l'algoritmo. Il tranello è che su una nuvola non esce zero: esce circa 0,33, che passa per un risultato mediocre invece che per un fallimento.
4. I gruppi che escono sono «i grandi, i medi, i piccoli». Cos'è successo?
   Quasi sempre la scala non normalizzata: il fatturato va da 100 a 900.000 e schiaccia tutte le altre colonne. Hai pagato tre settimane per un ORDER BY.
5. Meglio tre colonne o trenta?
   Tre, scelte partendo dalla decisione. In trenta dimensioni tutti i punti sono lontani da tutti, la distanza smette di significare qualcosa e i mucchi diventano arbitrari.
6. Quanti gruppi deve avere una segmentazione?
   Tanti quante sono le cose diverse che sai fare. Se le offerte sono tre, i gruppi sono tre, e non importa cosa dice il gomito nel grafico.
7. Il 40% dei clienti cambia gruppo ogni mese. Cosa vuol dire?
   Che quei gruppi descrivono il rumore di quel mese, non delle persone. Sotto il 10% di migrazione mensile la segmentazione è stabile.
8. Cosa batte il k-means quasi sempre?
   La RFM: recency, frequency, monetary. Cinquant'anni, venti righe di SQL, gruppi con un nome che un commerciale capisce, e confini stabili perché li hai scelti tu.
9. «Trovami il gruppo dei clienti a rischio.» Che richiesta è?
   Una classificazione travestita da segmentazione. Il rischio è una probabilità per ogni cliente, non un cluster. Serve un'etichetta e una soglia.
10. Cosa vedi in un grafo che non vedrai mai in una tabella?
    Che sette dei tuoi dieci clienti principali dipendono dallo stesso fornitore. Che quattro clienti sono lo stesso gruppo e negoziano separatamente. Nessuna delle due è una colonna.
11. Serve un database a grafo?
    Quasi mai. Serve un self-join sulla tabella che hai già. Il grafo è un modo di pensare al problema, e nella maggior parte dei casi resta un modo di pensare.
12. Qual è il fallimento numero uno di un progetto sui grafi?
    Non avere gli archi. Se ogni cliente ha solo i suoi campi, non c'è niente da collegare e nessuna tecnologia lo inventa. E se gli archi ci sono ma sono sporchi, il grafo che ottieni è un grafo di errori di battitura.

Due cose che si fanno in mezza giornata e che quasi nessuno ha fatto. La prima: calcolare la silhouette della segmentazione che hai già, e sapere se descrive i tuoi clienti o le tue istruzioni. La seconda: una query per vedere quanto del tuo fatturato dipende da una cosa sola che non controlli.

La seconda, nella mia esperienza, è quella che produce la faccia più sorpresa nella stanza.

Se vuoi guardarle insieme, scrivimi su WhatsApp.