Le tre colonne che ingannano qualsiasi modello di previsione delle cancellazioni

Tre colonne che quasi ogni estrazione dal gestionale contiene sembrano predire le cancellazioni meglio di qualsiasi altra cosa, e non predicono niente: il posto auto richiesto, la camera assegnata diversa da quella prenotata e il tipo di deposito. Il motivo è sempre lo stesso. Quei campi prendono il loro valore definitivo dopo che l’esito della prenotazione è già deciso.

Chi costruisce un modello se ne accorge tardi. In fase di prova il modello sembra quasi perfetto: separa cancellate e non cancellate con una precisione che nessun fenomeno commerciale reale consente. Poi lo si mette a lavorare su una notte a trenta giorni di distanza, dove nessuna di quelle tre informazioni esiste ancora, e la previsione scende al livello del tirare a indovinare.

I numeri che seguono sono una nostra elaborazione su un dataset pubblico di ricerca. Non è un campione italiano e non va letto come tale: quello che si trasferisce è il meccanismo, non il livello.

Da dove vengono questi numeri#

Il dataset è quello pubblicato da Nuno Antonio, Ana de Almeida e Luis Nunes su Data in Brief nel 2019: 119.390 prenotazioni di due strutture portoghesi, un resort e un city hotel, con date di arrivo fra il 2015 e il 2017. È il dataset più usato al mondo negli esercizi di previsione delle cancellazioni, ed è anche la ragione per cui gli stessi tre errori si ripetono da anni in centinaia di modelli costruiti sopra di esso.

Tutte le percentuali che seguono sono nostra elaborazione su quel dataset pubblico. Valgono per due hotel portoghesi di dieci anni fa: il tasso di cancellazione di una struttura italiana oggi è un’altra cosa, e chi lo cita come riferimento di mercato sta facendo un errore. Quello che resta identico, in qualunque paese e con qualunque gestionale, è il rapporto fra il momento in cui un dato viene scritto e la sua apparente capacità predittiva.

Prima colonna: il posto auto che non si cancella mai#

Nel dataset ci sono 7.416 righe con almeno un posto auto richiesto, il 6,2 per cento del totale. Il loro tasso di cancellazione è zero. Non basso: zero, senza una sola eccezione su settemila e quattrocento prenotazioni.

Un tasso esattamente pari a zero su migliaia di righe non è mai un comportamento. È una definizione. Il posto auto, in quella struttura, viene assegnato quando l’ospite si presenta: una prenotazione cancellata non riceve nessun posto, quindi quel campo resta a zero per costruzione. La colonna non dice che chi chiede il parcheggio non cancella. Dice che chi è arrivato non ha cancellato, che è una tautologia.

Qualsiasi algoritmo di classificazione trova per prima cosa questa colonna, perché è l’unica che separa una parte del campione senza nessun errore. E qualsiasi cruscotto costruito sopra quel modello mostrerà numeri splendidi finché resta chiuso in ufficio.

Seconda colonna: la camera assegnata diversa da quella prenotata#

Il secondo caso è meno vistoso e per questo passa più spesso. Quando la camera effettivamente assegnata risulta diversa dalla tipologia prenotata, il tasso di cancellazione è del 5,4 per cento. Quando coincidono, è del 41,6 per cento. Una differenza di questa ampiezza, in un modello, vale più del canale e dell’anticipo messi insieme.

Il meccanismo è identico al primo. L’assegnazione della camera fisica avviene al momento dell’arrivo o poche ore prima: un upgrade, un declassamento, uno spostamento per una manutenzione riguardano solo chi si presenta davvero. Se la prenotazione è stata cancellata due mesi prima, la camera assegnata resta quella di listino e i due campi coincidono. Il campo non descrive una scelta commerciale del cliente: registra il fatto che il cliente è arrivato.

C’è una sfumatura che vale la pena tenere. Alcuni gestionali assegnano la camera fisica con giorni di anticipo, per organizzare le pulizie o per gestire i gruppi. In quel caso la colonna contiene anche un’informazione lecita, perché esiste già prima del momento in cui vuoi decidere. Ma resta pericolosa, perché viene sovrascritta al check-in senza lasciare traccia della versione precedente. Nella tua estrazione di oggi non c’è modo di sapere quale delle due cose stai leggendo.

Terza colonna: il deposito non rimborsabile cancellato nel 99,4 per cento dei casi#

Questo è il caso più controintuitivo e anche il più costoso, perché produce un errore commerciale e non solo un errore di modello. Nel dataset ci sono 14.587 righe con deposito non rimborsabile, il 12,2 per cento del totale. Di queste risulta cancellato il 99,4 per cento: poco più di novanta prenotazioni non rimborsabili, su oltre quattordicimila, arrivano a destinazione.

Letto senza riflettere, il numero dice una cosa assurda: la tariffa prepagata, quella che dovrebbe essere la più solida, sarebbe la più fragile del listino. Nessuno che abbia lavorato un mese in un ricevimento ci crede.

La spiegazione non è commerciale, è contabile. In quel gestionale una prenotazione prepagata che non si presenta viene chiusa con lo stato di cancellata, perché l’importo è già stato incassato e la camera va liberata: la riga resta lì come cancellata con deposito non rimborsabile. La colonna non misura una tariffa che respinge i clienti. Misura una convenzione di registrazione che marca i mancati arrivi già addebitati.

Vale la pena essere espliciti su che cosa vuol dire questo. Una prenotazione non rimborsabile addebitata e non consumata, per il conto economico, è un incasso pieno con costi variabili quasi nulli. Nel campo dello stato risulta identica a una cancellazione a novanta giorni che ti lascia la camera vuota e nessun ricavo. Sono due eventi opposti registrati con la stessa parola.

La regola generale: in che momento viene scritto quel dato#

I tre casi sono lo stesso caso. Una colonna è utilizzabile per una previsione solo se il suo valore definitivo esiste già nell’istante in cui la previsione va fatta. Se il valore si forma dopo, quella colonna sta trasportando informazione dal futuro verso il passato, ed è quello che in gergo si chiama fuga di informazione.

Per applicarla serve avere in testa la linea del tempo di una prenotazione: creazione, eventuali modifiche, cancellazione oppure conferma, assegnazione della camera fisica, check-in, soggiorno, partenza, chiusura del conto. Ogni campo della tua estrazione nasce in uno di questi punti. La domanda da fare per ognuno è una sola, e non è una domanda tecnica: in quale di questi momenti il gestionale scrive questo valore per l’ultima volta.

C’è una trappola in più. Quasi tutti i gestionali sovrascrivono i campi sul posto, senza conservare le versioni precedenti. L’estrazione che hai in mano non descrive lo stato della prenotazione a trenta giorni dall’arrivo: descrive lo stato di oggi, a soggiorno concluso. Anche una colonna nata al momento della prenotazione, come il numero di ospiti o la tipologia richiesta, può essere stata corretta al ricevimento. Se ti servono i dati storici come erano a una certa distanza dall’arrivo, l’unico modo pulito è congelarli: salvare ogni notte una fotografia del portafoglio e costruire il modello su quelle, non sulla tabella corrente.

Come si smaschera una colonna sospetta in dieci minuti#

Non serve un data scientist. Servono due controlli, entrambi fattibili con una tabella pivot.

Il primo è incrociare ogni colonna candidata con l’esito. Qualunque campo che produca un tasso dello 0 per cento o del 100 per cento su migliaia di righe va tolto e discusso, non festeggiato. In un fenomeno commerciale vero non esistono separazioni perfette: dove le trovi, hai trovato una regola del gestionale, non un comportamento dei clienti.

Il secondo è misurare quanto pesa la colonna. Si addestra il modello con e senza, e si guarda la differenza.

Un campo legittimo sposta l’accuratezza di qualche punto. Un campo che da solo ne sposta decine non è un predittore fortunato: sta leggendo la risposta. La stessa logica vale se al posto dell’accuratezza usi l’area sotto la curva o qualsiasi altra misura: cambia la scala, non il ragionamento.

La verifica che quasi nessuno fa: dividere per data, non a caso#

C’è un terzo controllo che costa poco e smaschera molto. Quasi tutti dividono le righe fra addestramento e verifica in modo casuale: una prenotazione del 2016 finisce nel gruppo di prova, una del 2017 in quello di addestramento, e il modello impara da un futuro che al momento della decisione non conosceva. La divisione corretta è temporale: si addestra sulle prenotazioni create fino a una certa data e si verifica solo su quelle create dopo. Se l’accuratezza crolla passando dalla divisione casuale a quella temporale, il modello stava vivendo di informazioni che nella realtà non avrebbe avuto. È lo stesso problema delle tre colonne, visto da un’altra angolazione.

Le due righe sulla camera assegnata non hanno un conteggio perché non lo abbiamo isolato: quello che abbiamo verificato è il tasso di cancellazione dei due gruppi, non la loro numerosità. Riportare un conteggio che non abbiamo calcolato sarebbe esattamente il tipo di scorciatoia che questo pezzo sta criticando.

Che cosa si può usare davvero#

Tolte le tre colonne inquinate, resta un modello meno spettacolare e finalmente utile. Le informazioni disponibili nel momento in cui devi decidere sono queste.

• L’anticipo di prenotazione. È il predittore più solido che esista, nasce con la prenotazione e non cambia mai. Chi prenota con molti mesi di anticipo ha più tempo per cambiare idea e spesso ha prenotato più strutture in parallelo.
• Il canale e il segmento. Un portale con pagamento alla struttura e cancellazione libera produce un comportamento diverso da un contratto corporate o da una prenotazione diretta prepagata. Il canale è scritto all’origine e non viene toccato.
• La durata del soggiorno e la composizione. Numero di notti, adulti, bambini, tipologia richiesta: tutto presente alla creazione. Attenzione solo alle correzioni fatte al ricevimento, che nella tabella corrente non si distinguono.
• Le richieste speciali. Nel dataset chi scrive una richiesta cancella meno, ed è plausibile: chi si è preso la briga di chiedere un piano alto o una culla ha già deciso. Ma verifica una cosa sola: se il tuo gestionale permette di aggiungere richieste dopo l’arrivo senza registrare la data, la colonna diventa inutilizzabile come le altre tre.
• Lo storico di cancellazione del cliente. Legittimo, a una condizione: va calcolato solo sui soggiorni precedenti al momento della previsione. Se lo calcoli sull’intero storico, comprese le prenotazioni successive, hai reintrodotto il futuro nel passato dalla porta di servizio.
• Il mercato di provenienza. Presente all’origine, stabile, e in molte strutture italiane è la variabile che separa meglio i comportamenti.
• Il prezzo della prenotazione rispetto alla media di quella data. Chi ha bloccato una tariffa molto più bassa della media attuale ha meno motivi di cancellare, chi ha pagato molto di più ne ha di più. Il confronto va fatto con la media come era al momento della previsione.

Un modello costruito solo su queste variabili non separerà mai perfettamente. Sbaglia, e sbaglia in modo visibile. È il prezzo da pagare per avere un numero che funziona anche il giorno in cui devi usarlo.

Quanto vale la differenza, in camere#

La conseguenza pratica si vede sull’overbooking. Un modello che ha imparato dalle colonne inquinate, messo a lavorare su un portafoglio futuro dove nessuno ha ancora un posto auto, una camera assegnata o un conto chiuso, tende a prevedere pochissime cancellazioni: per lui quasi tutte le prenotazioni assomigliano a quelle che si sono presentate. Il risultato è che non si accetta nessuna prenotazione in sovrapprenotazione e la notte chiude con camere vuote.

L’esempio è costruito per questo pezzo e presuppone che la domanda residua a sette giorni ci sia davvero: se non c’è nessuno da accettare, la previsione migliore non serve a niente. Presuppone anche che le 19 cancellazioni siano le stesse nei due scenari, il che è una semplificazione. Serve solo a dare la scala del problema: la differenza fra i due modelli non si misura in punti percentuali di accuratezza, si misura in camere vuote.

Cosa fare lunedì mattina#

1. Prendi l’ultima estrazione che hai usato per qualsiasi analisi sulle cancellazioni e scrivi, accanto a ogni colonna, in quale momento della vita della prenotazione il gestionale ne fissa il valore. Le colonne su cui non sai rispondere vanno segnate e chieste al fornitore.
2. Fai una tabella pivot di ogni colonna candidata contro l’esito. Ogni tasso pari a 0 o a 100 per cento su più di qualche centinaio di righe va tolto dal modello e portato alla riunione come domanda, non come scoperta.
3. Chiedi al fornitore del gestionale con quale stato vengono chiusi i mancati arrivi delle tariffe prepagate. Se finiscono fra le cancellazioni, tutte le tue statistiche sulle non rimborsabili sono da rifare.
4. Separa nei report i mancati arrivi addebitati dalle cancellazioni vere. Sono due eventi economici opposti e vanno contati in due righe diverse.
5. Attiva da subito una fotografia notturna del portafoglio: data, notte di riferimento, camere prenotate, tariffa media. Fra sei mesi avrai il solo archivio su cui si possa addestrare qualcosa di onesto.
6. Ricalcola il tuo tasso di cancellazione per anticipo di prenotazione e per canale, sulle tue righe, senza usare nessun riferimento di settore. Sono i due tagli che spiegano di più e che hai già a disposizione.
7. Se qualcuno ti presenta un modello con un’accuratezza superiore al novanta per cento, chiedi quali colonne usa e quando vengono scritte prima di guardare qualunque altra cosa.