Applicazione del framework strutturato: esempio di abbandono dei clienti
Questo esempio illustra il processo di definizione di una domanda di machine learning passo dopo passo. Si imparerà a combinare le conoscenze aziendali con il quadro di riferimento del trigger dell'evento, del target, del punto di previsione e delle caratteristiche per strutturare una domanda ben definita.
Il punto di partenza è il business case "Un cliente cancellerà la sottoscrizione?". Utilizzando il framework strutturato, ridurremo questo aspetto a qualcosa di più specifico che può essere previsto da un algoritmo di machine learning.
Trigger dell'evento
Il trigger dell'evento è un'azione o un evento che attiva la creazione di una nuova previsione. Identifichiamo il nostro trigger dell'evento come "un cliente ha stipulato una sottoscrizione". Questo viene rappresentato nei dati quando viene creato un nuovo cliente. Vogliamo prevedere, a livello di cliente, se cancellerà la sottoscrizione, quindi ogni riga deve rappresentare un singolo cliente.
Grazie alle nostre conoscenze aziendali e alla verifica dei dati, sappiamo che il tasso di abbandono è più elevato tra i nuovi clienti. Decidiamo quindi di concentrarci specificamente sui nuovi clienti. Il trigger dell'evento è l'iscrizione di un nuovo cliente e possiamo pensare che ogni cliente abbia una linea temporale individuale che inizia il giorno dell'iscrizione.
L'evento si attiva quando un nuovo cliente si iscrive. La linea orizzontale rappresenta il numero di giorni trascorsi dalla sottoscrizione.
Target
Il target è il risultato che stiamo cercando di prevedere. Vogliamo prevedere l'abbandono, quindi sappiamo che il nostro target generale è "Un cliente cancellerà la sottoscrizione?". Ma dobbiamo essere più specifici per creare un modello di machine learning di qualità. Per cominciare, decidiamo che per "abbandono" intendiamo la ricezione di una richiesta del cliente di cancellare la propria sottoscrizione.
L'esito target è la chiamata del cliente per cancellare la sottoscrizione.
Successivamente, si decide l'arco temporale (l'orizzonte) in cui deve essere effettuata la chiamata di cancellazione. Quando si esaminano più clienti che hanno cancellato la sottoscrizione, si nota che la timeline non è coerente. Alcuni clienti la cancellano dopo 45 giorni, mentre altri non lo fanno prima di 110 giorni.
Giorni dalla sottoscrizione fino alla chiamata del cliente per cancellarla. Ogni linea rappresenta un cliente diverso.
Abbiamo un programma di prova gratuito di 90 giorni e sappiamo che molti clienti lo abbandonano. Sulla base di questo contesto aziendale, la nostra idea iniziale è di utilizzare un orizzonte di 90 giorni. Grazie alla previsione di chi si prevede che cancellerà la sottoscrizione, possiamo raggiungere questi clienti prima del tempo e offrire loro incentivi (come sconti o funzioni aggiuntive della sottoscrizione) per incoraggiarli a rimanere.
Un istogramma di quanti giorni dopo l'iscrizione i clienti hanno disdetto conferma la nostra intuizione aziendale. Nella figura sono riportati i dati relativi a tutti i clienti che hanno cancellato la sottoscrizione negli ultimi tre anni.
Distribuzione delle chiamate di cancellazione sul numero di giorni dalla sottoscrizione. La maggior parte delle cancellazioni avviene circa 90 giorni dopo la sottoscrizione.
La scelta di un orizzonte di 90 giorni sembra un buon punto di partenza. Tuttavia, quando tracciamo questo orizzonte sul nostro istogramma, ci rendiamo conto che ci sono molti clienti che continuano a cancellare la sottoscrizione alcuni giorni dopo il periodo di prova di 90 giorni. Il motivo potrebbe essere che vedono l'addebito sulla carta di credito o ricevono un avviso che il metodo di pagamento è stato rifiutato qualche giorno dopo e solo allora chiamano per cancellare la sottoscrizione.
Un orizzonte a 90 giorni dalla sottoscrizione
Poiché vogliamo includere questi clienti come "con sottoscrizione cancellata" nel nostro modello, decidiamo che è più sensato utilizzare 110 giorni come orizzonte temporale. Utilizzando 110 giorni si rileva la maggior parte dei clienti il cui abbandono è probabilmente legato alla fine del programma di prova gratuito.
Un orizzonte a 110 giorni dalla sottoscrizione
Ora che abbiamo definito il nostro target, possiamo determinare dove sono memorizzati i dati e come devono essere ripuliti per costruire la colonna di destinazione nel set di dati. In questo esempio si procede come segue:
-
Prelevare lo stato del cliente da Salesforce.
-
Estrarre lo stato, la data di creazione del cliente e la data di cancellazione del cliente:
-
Pulire e trasformare i dati estratti nella colonna target:
Ora abbiamo definito il nostro trigger dell'evento (un nuovo cliente si è iscritto) e il nostro target (il cliente ha chiamato per cancellare la sottoscrizione entro 110 giorni dall'iscrizione). Sono illustrati sulla timeline nella figura.
Il trigger dell'evento è quando un nuovo cliente si iscrive (1), il risultato target è quando il cliente chiama per disdire (2) e l'orizzonte target è 110 giorni dopo la sottoscrizione (3).
Punto di previsione
Il punto di previsione è il momento designato in cui si smette di raccogliere dati per le caratteristiche e si prevede il target per ogni riga. Il punto di previsione può ricadere in qualsiasi punto tra il trigger dell'evento (il giorno di sottoscrizione) e l'orizzonte di riferimento (il giorno 110 dopo la sottoscrizione). Per scegliere un punto di partenza possiamo pensare all'azione che vogliamo intraprendere.
Nel nostro esempio, forse il team di assistenza clienti ha chiesto 30 giorni di tempo per contattare i clienti con offerte di fidelizzazione una volta che è stato previsto che i clienti cancellino la sottoscrizione. Ciò significa che, al massimo, vorremmo effettuare una previsione 30 giorni prima dell'orizzonte di riferimento, cioè entro l'80° giorno.
Il punto di previsione (2) è fissato al giorno 80, tra il trigger dell'evento (1) e l'orizzonte di riferimento (3).
Scegliendo il giorno 80 come punto di previsione, avremo 80 giorni per raccogliere dati sui nuovi clienti che arrivano. Questo intervallo di tempo tra il trigger dell'evento e il punto di previsione è chiamato finestra di accumulo dei dati. I dati raccolti durante la finestra di accumulo dei dati vengono utilizzati per generare le caratteristiche.
La finestra di accumulo dei dati è il tempo che intercorre tra il trigger dell'evento e il punto di previsione.
L'utilizzo del giorno 80 come punto di previsione lascia una finestra d'azione di 30 giorni, ovvero il tempo che intercorre tra il punto di previsione e l'orizzonte target. Questa è la finestra di 30 giorni richiesta dal team di assistenza clienti per contattare i clienti.
La finestra d'azione è il tempo che intercorre tra il punto di previsione e l'orizzonte di riferimento.
Oltre a pensare alla finestra d'azione minima necessaria per agire sulle previsioni, dobbiamo anche osservare l'istogramma dei giorni che mancano alla cancellazione della sottoscrizione. Applicando il punto di previsione del giorno 80, otterremmo quanto segue:
La distribuzione delle chiamate di cancellazione con la finestra di accumulo dei dati e la finestra di azione.
Osservando questo istogramma ci rendiamo conto che l'utilizzo di un punto di previsione di 80 giorni non riesce a massimizzare il valore aziendale. Sebbene 80 giorni di dati contribuiscano ad aumentare l'accuratezza del modello, ciò ha un costo elevato in termini di possibilità di azione:
-
In primo luogo, molti clienti hanno già cancellato la sottoscrizione al giorno 80, quindi hanno abbandonato durante la finestra di accumulo dei dati, prima ancora di effettuare previsioni. Ciò significa anche che non vorremmo includerli nel nostro set di dati per il training, perché conosceremmo il risultato prima di effettuare la previsione.
-
In secondo luogo, molti clienti abbandonano intorno all'ottantesimo-novantesimo giorno, quindi il team di customer success non avrebbe a disposizione tutti i 30 giorni necessari per contattare questi clienti.
I clienti che hanno annullato la sottoscrizione prima del punto di previsione non saranno inclusi nei dati di training.
Spostando il punto di previsione al giorno 60 si ottiene un migliore equilibrio tra accuratezza e fattibilità. Abbiamo ancora 60 giorni per raccogliere i dati da utilizzare per le caratteristiche del nostro modello, ma ora la previsione è abbastanza precoce da permettere al team di customer success di avere 30 giorni per contattare la maggior parte dei clienti per i quali si prevede l'abbandono. Riducendo la finestra di accumulo dei dati, possiamo aspettarci una piccola diminuzione dell'accuratezza del modello, ma una previsione molto più efficace.
Spostando il punto di previsione al giorno 60 si accorcia la finestra di accumulo dei dati, ma si ottiene una finestra di azione più lunga. Esclude un numero minore di clienti dai dati di training.
Caratteristiche
Definiti il trigger evento, il target e il punto di previsione, siamo pronti ad aggiungere la parte finale al nostro set di dati: le caratteristiche. Le caratteristiche sono gli attributi noti, o osservazioni, per ogni riga di dati nel set di dati di training, da cui gli algoritmi di machine learning apprendono modelli generali. Gli algoritmi utilizzano quindi le caratteristiche per fare previsioni quando viene presentata una nuova riga di dati nel set di dati di applicazione.
Considerare le caratteristiche come le proprie ipotesi, basate sulla conoscenza di business di ciò che influenza il risultato. Nel nostro esempio, alcune caratteristiche potrebbero essere la posizione del cliente, la fonte del lead, il mese di iscrizione, il numero di accessi o il numero di utenti attivi.
Esistono due categorie di caratteristiche:
-
Le caratteristiche fisse sono le più semplici perché non cambiano nel tempo. Nel nostro esempio, la posizione del cliente (al momento dell'iscrizione), la fonte del lead e il mese di iscrizione sono tutte considerate caratteristiche fisse. Sono note non appena un cliente si iscrive (in corrispondenza del trigger dell'evento) e non importa dove posizioniamo il nostro punto di previsione, saranno sia note che costanti.
-
Le caratteristiche dipendenti dalla finestra sono leggermente più complicate. Queste sono le caratteristiche che vengono ottenute in base alle informazioni raccolte tra il trigger evento e il punto di previsione. È importante assicurarsi di utilizzare solo dati noti nel tempo, altrimenti il modello potrebbe presentare perdite di dati. (Per ulteriori informazioni, vedere Perdita di dati.)
Un modello semplice potrebbe utilizzare solo le informazioni note al giorno 0, cioè solo le caratteristiche fisse. In questo modo si otterrebbe un punto di previsione al giorno 0, come mostrato nella figura.
Con un punto di previsione al giorno 0, abbiamo 0 giorni per raccogliere i dati e possiamo usare solo le caratteristiche fisse note al giorno 0. La finestra d'azione include 110 giorni interi.
Il set di dati risultante avrebbe un aspetto simile a questo:
Dati di training con sole caratteristiche fisse
Tuttavia, potremmo anche voler utilizzare i dati raccolti una volta che il cliente ha effettuato la sottoscrizione, come nel nostro esempio con il punto di previsione al 60° giorno.
Il punto di previsione al 60° giorno ci dà 60 giorni per raccogliere dati e 50 giorni per agire.
Ora possiamo utilizzare le informazioni raccolte nei primi 60 giorni dopo l'iscrizione di un cliente per aggiungere al nostro modello funzionalità dipendenti dalla finestra. Il nostro set di dati per questo modello potrebbe assomigliare alla seguente tabella, che ora include le caratteristiche dipendenti dalla finestra Accessi nei primi 60 giorni e Utenti attivi in 60 giorni.
Dati campione con caratteristiche dipendenti dalla finestra
Si noti che in questo esempio le caratteristiche riflettono l'intera finestra di accumulo dei dati. Possono anche essere più piccole. Ad esempio, potremmo misurare gli accessi dei primi 10 giorni o gli accessi dei giorni 30-60, purché le caratteristiche non includano informazioni oltre il punto di previsione.
Le caratteristiche dipendenti dalla finestra possono essere più complicate da raccogliere perché richiedono date e uno sforzo supplementare per garantire che rientrino nella finestra di accumulo dei dati per evitare perdite di dati. Ma possono anche essere alcune delle caratteristiche più potenti, perché possono riflettere informazioni raccolte molto più vicino al momento della previsione.
Domanda di machine learning risultante
Abbiamo iniziato con il semplice caso d'uso "Un cliente cancellerà la sottoscrizione?". Abbiamo quindi definito il nostro trigger evento come "Un nuovo cliente si iscrive", perché volevamo effettuare previsioni a livello di singolo cliente.
Abbiamo definito il nostro target con un risultato specifico: "Il cliente ha chiamato per cancellare la sottoscrizione (sì o no)" e abbiamo fissato l'orizzonte a 110 giorni, perché è il tempo entro il quale la maggior parte dei nostri clienti in prova annulla la sottoscrizione.
Osservando un istogramma di quanti giorni dopo l'iscrizione i clienti hanno chiamato per disdire negli ultimi tre anni, abbiamo deciso un punto di previsione di 60 giorni dopo l'iscrizione. In questo modo avremmo 60 giorni per raccogliere informazioni (la finestra di accumulo dei dati) prima di effettuare la nostra previsione, ma daremmo comunque al team di assistenza clienti il tempo di agire sulle previsioni per ridurre l'abbandono.
Infine, abbiamo raccolto i dati dei clienti che sarebbero stati disponibili prima del 60° giorno per generare le caratteristiche.
La domanda di machine learning che ne deriva è: "Dopo i primi 60 giorni di attività, un cliente chiamerà per disdire entro il 110° giorno?".
Il set di dati, ora pronto per essere utilizzato per il machine learning, si presenta come la tabella seguente. Posizione, Origine lead, Mese di iscrizione e Importo sottoscrizione sono caratteristiche fisse, Accessi nei primi 60 giorni e Utenti attivi a 60 giorni sono caratteristiche dipendenti dalla finestra e Abbandono entro 110 giorni è la colonna target.
Dati campione con caratteristiche fisse (1), caratteristiche dipendenti dalla finestra (2) e target (3)
