Presentazione del dataset

La società Share’NGo mi ha reso disponibili alcuni dati utili per avviare un’analisi statistica. Prima di poter iniziare con l’analisi vera è propria, sono stati necessari i processi di data cleaning e creazione di un dataset.

Il database cui ho avuto accesso, proveniente direttamente dalle piattaforme di archiviazione dell’azienda, riguardava la totalità dei viaggi compiuti da tutti gli iscritti al servizio, sin dal giorno di avvio dell’attività (3 giugno 2015) fino a giorno di estrazione dei dati (25 agosto 2016). Quindi circa un anno e tre mesi di osservazione.

67

In questo periodo sono stati registrati viaggi per un totale di 607.302, perciò 607.302 erano le osservazioni presenti sul database. Per ogni utente figuravano riga per riga tutti i viaggi che avessero compiuto nel periodo in esame.

L’architettura del database e il tipo di informazioni che ne scaturiva non erano molto congeniali al fine di un’analisi basata, come espressamente richiesto, sull’utente ed il suo comportamento. Di seguito, in figura 7, un breve estratto di come si presentava il database in origine.

Figura 7 – Database di origine.

Pertanto è stato doveroso un primo lungo processo di ridefinizione del database, trasformandolo da un database “basato sui viaggi” ad uno “basato sull’utente”. In questa fase il mio compito è stato quello di valutare ogni variabile disponibile e comprendere in quale modo poterla “ribaltare” e leggere nel nuovo database. Le variabili disponibili, tra le altre, fornivano le seguenti informazioni:

 Giorno e orario di partenza del singolo viaggio, e giorno e orario di fine dello stesso, da cui ho ricavato la durata della corsa ed il giorno della settimana della corsa stessa.

68

 Il chilometraggio che segnava l’auto all’inizio e alla fine della corsa, da cui ho derivato i km percorsi.

 Stessa cosa per la batteria, ovvero il livello di carica ad inizio e fine del viaggio, così da derivarne il consumo.

 L’indirizzo (via e città) e le coordinate GPS di partenza e arrivo del viaggio.

In figura 8, come si presentava il database revisionato con gli appena citati accorgimenti.

Figura 8 – Database, dopo le prime modifiche.

Come ho detto, il primo passaggio fondamentale è stato quello di creare un database “basato sugli utenti”, ovvero formare una matrice di dati dove sulle righe avrei avuto tutti i singoli utenti, e non le singole corse compiute da ogni utente, e sulle colonne le variabili ad essi associate.

I primi calcoli sono stati le medie e gli aggregati delle suddette variabili, infatti ho calcolato la durata media e complessiva per ogni utente, i chilometri percorsi medi e complessivi ed il consumo medio di batteria, trasformazione necessaria se volevamo andare a osservare nel dettaglio come si comportava ogni consumatore

69

piuttosto che studiare le singole corse. Per quanto riguarda le variabili chilometri medi, complessivi e consumo medio della batteria, una volta realizzate mi sono reso conto che tali valori non erano sufficientemente affidabili, infatti, oltre a riportare spesso valori negativi, il chilometraggio e il consumo della batteria risulta per la maggior parte dei casi pari a 0 quando invece, si deduce, dalle altre informazioni, che la corsa è stata compiuta. Pertanto è stato preferito non considerare, categoricamente, queste tre informazioni.

Altre variabili sono state realizzate indirettamente come il numero di corse compiute da ciascun utente, oppure i giorni di utilizzo al servizio, calcolati dal giorno della prima corsa e dell’ultimo che ha viaggiato.

Il database appena costruito prevede esclusivamente informazioni di carattere comportamentale, perciò tale mole di dati è stata associata ad un altro database, sempre fornito dall’azienda, con informazioni anagrafiche ottenute direttamente dagli utenti in fase di iscrizione al servizio, utili per la targetizzazione.

Così è stato possibile dare un’identità al comportamento di ogni utente. Le nuove variabili ottenute riguardano: il genere, il giorno di nascita, e quindi l’età, il paese, la provincia e la città di nascita, la flotta di appartenenza, ovvero in quale città il dato utente sfrutta il servizio (Milano, Firenze o Roma), il CAP e l’indirizzo di residenza e la data di registrazione al servizio oltre ad altre informazioni meno fruibili in un’analisi, come il nome e cognome e indirizzo email. Di seguito, in figura 9, un estratto del database fornito dall’azienda (sono stati oscurati i dati sensibili).

70

Figura 9 – Database con informazioni demografiche.

A questo punto è stato possibile realizzare il dataset completo di tutte le variabili osservabili, così da avviare un’analisi compiuta sul comportamento degli utenti al fine di conoscere più nel profondo come è composto il bacino di utenza. Un estratto del dataset sarà presentato, di seguito, in figura 10.

Figura 10 – Dataset finale, proprio per essere analizzato.

E’ facilmente osservabile che il nuovo database offre una lettura più chiara qualora il nostro focus siano gli utenti e non le corse effettuate. Difatti la voce

71

“CustomerID” mostra riga per riga tutti gli utenti presi una volta sola, mentre nel database di origine, consultabile in figura… , la variabile “CustomerID” raffigurava più volte i singoli utenti, tante volte quanti i viaggi da loro effettuati. In questo modo è stato così possibile ridurre la mole di dati del database passando dalle 607.302 voci originali (corse compiute) alle 34.958 del nuovo database (utenti registrati al servizio).

La necessaria fase successiva è stata quella di “pulire” il database, infatti, la fase di “data cleaning” ha permesso di togliere dall’analisi i valori anomali o gli errori causati nell’acquisizione dei dati. Per favorire un’analisi esclusiva sui clienti è stato ritenuto opportuno eliminare dal database anche i nominativi dei dipendenti dell’azienda in quando il loro comportamento poteva invalidare l’analisi. Infatti, i dipendenti del settore meccanico e logistico spesso utilizzano le auto per motivi lavorativi, come spostamenti da un luogo ad un altro ad esempio per la manutenzione. Il database risulta così formato da 34.642 utenti. Altro fattore importante, è stato convenuto che, al fine di un’analisi più chiara e puntuale, fosse utile suddividere ed analizzare separatamente il database in: “Viaggiatori”, ovvero coloro che hanno effettuato almeno un viaggio dal giorno di iscrizione sino al 23 agosto 2016 (giorno di estrazione dei dati) e “Non viaggiatori” coloro che nonostante siano iscritti al servizio non hanno mai praticato. Inoltre un'altra suddivisione doverosa è per città di utilizzo. Il servizio di Share’NGo è previsto, sino ad oggi, nelle città di Milano, Firenze e Roma, però è stato ritenuto opportuno analizzare separatamente questi tre mercati. Sono stati realizzati a questo scopo 6 database. Maggiormente qualificabili ai fini della ricerca sono 3, ovvero i “Viaggiatori” nelle 3 città osservate.

72