Articoli
Un racconto a puntate sul meraviglioso mondo dei dati. Questa storia verrà raccontata da chi i dati li “tocca con mano” ogni giorno e cerca con essi di raggiungere nuovi obiettivi sempre più ambiziosi.
Durante il precedente articolo, abbiamo discusso e ampiamente spiegato le origini del dato: in questo articolo andremo invece a trattare e approfondire come mai i dati siano così importanti.
Innanzitutto è necessario capire quale dato possa avere un valore e quale invece non lo abbia.
Inoltre, occorre comprendere come estrarre questo valore: per fare ciò bisogna aggregare i dati e vederne la ripartizione tra i nostri clienti.
Per esempio, conoscere il cognome dei nostri clienti non è un dato che abbia un valore, perché anche aggregato non ci da un valore aggiunto, stessa cosa per la via di residenza. Sapere invece la provincia o la città dei clienti, ci permette di capire come il nostro servizio sia distribuito sul territorio.
Questa informazione può infatti guidare la nostra decisione di aprire oppure no un altro store, e dove sia meglio farlo.
Se volessimo acquistare un appartamento per metterlo a rendita in affitto, di quali informazioni avremmo bisogno? Le informazioni fondamentali di cui necessitiamo in questo caso, sono: avere per ogni area la domanda, il costo affitto medio ed il valore degli immobili. Queste semplici 3 informazioni sono fondamentali per avviare un business di quel tipo. Se riportassimo questo scenario sugli affitti di breve periodo, vedremmo come siti come booking.com abbiano degli insight fondamentali per il settore immobiliare, in quanto per ogni area sono in grado di definire l’affitto medio, i giorni medi di affitto annuo e quindi stimare la rendita annuale.
Tornando al tema delle informazioni riguardanti la città/provincia, vi è mai capitato che alla cassa di un negozio vi venga chiesto il CAP di residenza? Ecco questo è un modo semplice per raccogliere in maniera anonima un dato aggregato relativo alla distribuzione sul territorio dei propri clienti.
Altri modi di raccogliere informazioni, e quindi dati, sono:
Una volta raccolti i dati, è necessario che questi vengano salvati in meno sistemi possibili: innanzitutto per un motivo tecnico di aggiornamento informazioni, ma al tempo stesso perché avere copie dell’intero set di dati su più sistemi è dispendioso e non porta alcun vantaggio, ed inoltre espone la società al rischio di data breach.
Ipotizziamo di avere un CRM dove siano memorizzati tutti i dati e un sistema di comunicazione marketing multicanale. La via, la città e la regione, sono dati da trasferire su questo sistema di comunicazione integrata? A meno che lo scopo non sia fare clusterizzazione secondo questi campi, la risposta è decisamente no.
All’interno del CRM, questi dati sono utili per poter contattare il cliente e per effettuare reportistica, ma all’interno di un sistema di comunicazione non servono affatto.
Se ci dovessimo integrare con un e-commerce, che l’e-commerce sappia quante comunicazioni l’utente abbia ricevuto non è un dato importate, mentre per la profilazione utente sono importanti informazioni come i prodotti acquistati di recente.
Quando si effettua reportistica, con l’analisi dei dati per il marketing, dopo aver raccolto il dato è importante capire quale sia l’obiettivo del report e quali siano gli insight che si vogliano estrapolare.
Prendiamo ad esempio gli iscritti e disiscritti ad un DB.
Questo grafico mostra la variazione giornaliera di iscritti e disiscritti:
Il prossimo grafico contiene la stessa informazione, ma al posto di mostrare il delta giornaliero mostra il totale: (i dati non corrispondono)
Nel primo grafico è ben visibile e chiaro come variano gli iscritti ed i disiscritti nel DB, quindi è facile comprendere se ci siano iniziative che in un certo lasso temporale abbiano portato ad un incremento del DB performando come sperato.
Questa informazione non è altrettanto visibile nell’ultimo grafico, perché mostra si l’andamento del DB ma avendo (iscritti-discritti + valore di ieri) non ci permette di capire cosa sia realmente accaduto in un certo giorno/mese.
Questa seconda visualizzazione rende invece più semplice analizzare se il trend del DB sia crescente o decrescente.
Se invece dovessimo considerare ad oggi quanti siano gli iscritti ed i disiscritti, sicuramente la torta renderebbe più immediata la lettura dell’informazione.
Vorrei chiudere con una piccola “provocazione”: per chi conosce le candele giapponesi, anche questo potrebbe rappresentare il trend di un DB:
Ipotizzando il timeframe mensile, in questo modo non avremo una semplice fotografia del fine mese, ma avremo tutte le 4 informazioni che le candele giapponesi esprimono: