Data cleaning: come preparare i dati prima di visualizzarli

Chi lavora con i dati conosce bene la sensazione: hai un dataset, hai un obiettivo, hai uno strumento aperto davanti a te. L’impulso naturale è iniziare subito a costruire il grafico. È un riflesso comprensibile, ma quasi sempre produce lavoro da rifare.

Il data cleaning — la pulizia e la preparazione dei dati prima della visualizzazione — è la fase che determina se quello che mostri è vero, leggibile e utile. Non è una questione di perfezionismo tecnico: è una questione di credibilità. Un’analisi costruita su dati con errori, duplicati o struttura sbagliata porta a conclusioni distorte, e un grafico elegante costruito su basi fragili è più pericoloso di nessun grafico, perché trasmette una falsa certezza.

In questa guida vediamo il processo completo: come leggere un dataset grezzo con occhio critico, quali operazioni di pulizia fare e in quale ordine, come strutturare i dati in funzione del messaggio che vuoi comunicare, e perché conviene prototipare la visualizzazione su carta prima di toccare il software. Lungo tutto il percorso teniamo presente un rischio specifico — il bias del tool — che condiziona le scelte di chi lavora coi dati più di quanto si voglia ammettere.

Perché il data cleaning viene sempre sottovalutato

La risposta onesta è che pulire i dati è faticoso, poco visibile e raramente applaudito. Nessuno ti chiede “come hai gestito i valori mancanti?” — ti chiedono il grafico. Questa asimmetria di attenzione spinge molti professionisti a comprimere o saltare la fase di preparazione, con conseguenze che emergono sempre nel momento peggiore: durante una presentazione al management, o quando qualcuno fa una domanda sul dato che non torna.

C’è però un secondo motivo, più sottile. Molti strumenti di visualizzazione moderni sono progettati per essere avviati subito: carichi un file, il software genera qualcosa, e quella cosa sembra già un risultato. Questa fluidità è un vantaggio di usabilità, ma nasconde un rischio: ti fa credere che i dati siano pronti quando non lo sono ancora. Il tool non sa se quel campo “data” è formattato in modo incoerente, se quella colonna “fatturato” ha valori in valute diverse, se quei 200 record duplicati stanno gonfiando artificialmente una metrica. Lo sa solo chi ha guardato il dataset con attenzione prima di trascinarlo nell’interfaccia.

La pulizia dei dati non è una fase preliminare al lavoro vero: è parte integrante del lavoro analitico. Chi la salta non risparmia tempo — lo accumula in debito, da pagare con gli interessi quando i problemi emergono a valle.

Il bias di Maslow applicato ai dati

Abraham Maslow, descrivendo la tendenza umana a risolvere i problemi con gli strumenti che si conoscono meglio, sintetizzò il concetto così: se il tuo unico strumento è un martello, ogni problema ti sembrerà un chiodo. Applicato al lavoro con i dati, questo principio descrive qualcosa di molto concreto.

Chi conosce bene Excel tende a strutturare ogni dataset in modo che funzioni bene in Excel. Chi usa Power BI pensa in termini di modelli a stella e tabelle di fatto. Chi lavora con Python e pandas ha automatismi mentali che portano a certe trasformazioni prima di altre. Il tool che usiamo ogni giorno non è neutro: orienta il modo in cui leggiamo i dati, le domande che ci facciamo e le soluzioni che consideriamo.

Il problema emerge quando il dataset che hai davanti non si adatta al tuo strumento preferito, ma invece di cambiare approccio forzi i dati dentro lo schema che conosci. Il risultato è quasi sempre una struttura subottimale, che poi si ripercuote sulla qualità della visualizzazione. La soluzione non è imparare tutti gli strumenti possibili, ma sviluppare un metodo di lettura dei dati che sia indipendente dal tool — e applicarlo prima di aprire qualsiasi software.

Come leggere un dataset grezzo prima di qualsiasi operazione

Il primo passo del data cleaning non è un’operazione tecnica: è un’osservazione. Prima di filtrare, trasformare o eliminare qualcosa, devi capire cosa hai davanti. Questo momento di lettura attiva è spesso il più trascurato, eppure è quello che determina la qualità di tutto ciò che viene dopo.

Capire la struttura prima di guardare i valori

Apri il dataset e chiediti: quante righe e quante colonne ha? Ogni riga rappresenta un’osservazione distinta o ci sono righe aggregate? Le colonne sono variabili indipendenti o alcune sono derivate da altre? Ci sono colonne con nomi ambigui che potrebbero significare cose diverse a seconda di chi ha creato il file?

Queste domande sembrano banali, ma nella pratica rivelano problemi frequenti. Un dataset esportato da un CRM può avere righe che rappresentano sia singoli contatti sia account aggregati, mescolati senza distinzione. Un report finanziario può avere colonne “Totale” che sommano altre colonne già presenti — e se non te ne accorgi, rischi di contare due volte gli stessi valori in un grafico.

Dedica qualche minuto a capire la granularità del dataset: qual è l’unità minima di osservazione? Una riga corrisponde a una transazione, a un cliente, a un giorno, a un prodotto? Se non riesci a rispondere con certezza, il dataset ha un problema di documentazione che devi risolvere prima di procedere.

Identificare le tipologie di dati presenti

Ogni colonna del dataset ha un tipo: numerico, testuale, data/ora, booleano, categorico. Identificarli non è solo un’operazione tecnica — ti dice immediatamente quali trasformazioni saranno necessarie e quali visualizzazioni sono possibili.

I problemi più comuni in questa fase riguardano i tipi misti: una colonna che dovrebbe essere numerica ma contiene alcune celle con testo (spesso perché qualcuno ha scritto “N/D” o “da verificare” al posto di un numero), oppure una colonna date in cui alcuni valori sono nel formato giorno/mese/anno e altri mese/giorno/anno. Questi problemi non sempre emergono a prima vista: alcuni strumenti li nascondono convertendo silenziosamente i tipi, introducendo errori che scopri solo guardando i risultati finali con attenzione critica.

Un takeaway operativo: prima di qualsiasi trasformazione, stampa o annota su carta la struttura del dataset — numero di colonne, tipo atteso per ciascuna, granularità delle righe. Questo schema manuale vale più di qualsiasi anteprima automatica del software.

Le operazioni di data cleaning: un percorso in sei passi

Una volta che hai una lettura chiara del dataset, puoi procedere con le operazioni di pulizia. L’ordine non è casuale: alcune operazioni creano le condizioni per le successive, e fare le cose nel verso sbagliato significa rifare il lavoro.

Passo 1 — Gestire i valori mancanti con criterio

I valori mancanti sono quasi sempre presenti, ma non tutti i valori mancanti sono uguali. Prima di decidere cosa farne, chiediti perché mancano. Un valore mancante può significare tre cose molto diverse: che l’informazione non era disponibile al momento della raccolta, che non era applicabile per quel record specifico, oppure che c’è stato un errore nel processo di raccolta o esportazione.

Queste tre cause richiedono trattamenti diversi. Se un campo “data di chiusura” è vuoto perché la trattativa è ancora aperta, eliminare quella riga sarebbe un errore — stai perdendo un’informazione reale. Se un campo “fatturato secondario” è vuoto perché quel cliente ha solo un flusso di ricavi, riempirlo con zero può essere corretto. Se manca per un errore di esportazione, devi risalire alla fonte.

La regola generale è: non eliminare mai un record con valori mancanti senza capire perché mancano. L’eliminazione sistematica introduce bias di selezione che distorcono qualsiasi analisi successiva.

Passo 2 — Trovare e gestire i duplicati

I duplicati sono insidiosi perché gonfiamo le metriche in modo silenzioso. Un dataset con il 5% di righe duplicate non sembra un problema grave, ma se quelle righe si concentrano su certi prodotti o certi periodi, il loro effetto sulla visualizzazione finale può essere significativo.

Identificare i duplicati richiede prima di aver chiarito la granularità del dataset (vedi Passo 0 di lettura). Se ogni riga dovrebbe rappresentare una transazione unica, i duplicati sono righe con lo stesso identificativo transazione. Se ogni riga rappresenta un cliente, i duplicati possono essere meno ovvi — stesso nome con email diversa, stesso codice fiscale con ragione sociale leggermente diversa.

Attenzione ai quasi-duplicati: record che rappresentano la stessa entità reale ma con piccole differenze nei campi testuali (maiuscole, spazi, abbreviazioni). Questi richiedono un giudizio umano che nessun algoritmo può sostituire completamente.

Passo 3 — Standardizzare i valori categorici

Le variabili categoriche — regione, categoria prodotto, stato dell’ordine, canale di acquisizione — sono spesso il campo più disordinato di un dataset reale. Lo stesso valore viene scritto in modi diversi da persone diverse, esportato con codifiche diverse da sistemi diversi, tradotto o abbreviato in modo inconsistente.

“Nord Italia”, “Nord-Italia”, “NORD ITALIA”, “nord_italia” sono quattro rappresentazioni dello stesso valore che un software tratta come quattro categorie distinte. In un grafico a barre, quelle quattro categorie appariranno come barre separate — un errore di visualizzazione che nasce da un problema di pulizia, non di design.

Standardizzare significa scegliere una forma canonica per ogni valore e applicarla in modo coerente a tutto il dataset. Questo lavoro è manuale o semi-automatico, ma non può essere saltato.

Passo 4 — Correggere i tipi e i formati

Una volta che i valori sono standardizzati, verifica che i tipi siano corretti. Le date devono essere nel formato che il tuo strumento riconosce come data (non come testo). I numeri devono essere numerici, non stringhe con simboli di valuta incorporati. I booleani devono essere coerenti (non un mix di “Sì/No”, “1/0”, “True/False” nella stessa colonna).

Questo passo è particolarmente critico per le date, che sono la variabile più frequentemente malgestita. Un dataset con date in formati misti — alcuni in formato europeo, altri in formato americano — produce errori di ordinamento temporale che in un grafico a linee si traducono in curve che sembrano caotiche quando in realtà i dati sono ordinati.

Passo 5 — Gestire gli outlier con consapevolezza

Gli outlier — valori estremi che si discostano significativamente dalla distribuzione degli altri — non sono necessariamente errori. Possono essere eventi reali e informativi: una vendita eccezionale, un picco di traffico, un’anomalia che vale la pena investigare.

Prima di eliminare un outlier, chiediti se è un errore di inserimento (un numero con uno zero di troppo, un valore negativo dove non ha senso) oppure un dato reale. Nel secondo caso, eliminarlo dalla visualizzazione significa nascondere informazioni potenzialmente importanti. La scelta giusta dipende dal messaggio che vuoi comunicare: se stai mostrando l’andamento tipico, puoi escluderlo esplicitandolo; se stai cercando anomalie, è esattamente quello che devi mostrare.

Passo 6 — Strutturare i dati in funzione del messaggio

L’ultimo passo della preparazione non riguarda la pulizia in senso stretto, ma la struttura. I dati puliti non sono necessariamente dati pronti per la visualizzazione: spesso vanno riorganizzati in funzione del grafico che intendi costruire e del messaggio che vuoi far passare.

La distinzione più importante è quella tra dati in formato wide (ogni variabile è una colonna, ogni riga è un’osservazione) e dati in formato long (ogni riga è una combinazione osservazione-variabile). Molti strumenti di visualizzazione lavorano meglio con il formato long per grafici che confrontano più serie; altri preferiscono il formato wide. Questa trasformazione — che in gergo viene chiamata data shaping — è la cerniera tra la pulizia dei dati e la visualizzazione.

Capire quale struttura serve richiede di avere già in mente il grafico che vuoi costruire. Ed è qui che entra in gioco il prototipo su carta.

Prototipare a mano prima di aprire il software

Questa indicazione sembra anacronistica nell’era degli strumenti di BI interattivi, ma ha una logica precisa. Quando apri subito un software di visualizzazione, il tool ti propone immediatamente alcune opzioni — un tipo di grafico predefinito, una configurazione di assi, una palette di colori. Quelle proposte non sono neutrali: ti portano verso le visualizzazioni che il software gestisce meglio, non necessariamente verso quelle più adatte al tuo messaggio.

Prototipare su carta — anche solo uno schizzo approssimativo — ti costringe a prendere decisioni prima che il software le prenda per te. Cosa va sull’asse X? Cosa sull’asse Y? Quante serie devo confrontare? Il messaggio principale è un confronto, un andamento, una distribuzione? Queste domande, se fatte davanti a un foglio bianco, producono risposte più libere e più aderenti al messaggio reale.

Il secondo vantaggio del prototipo manuale è che rivela i requisiti di struttura dei dati. Se disegni un grafico a barre raggruppate per regione e per trimestre, capisci subito che il tuo dataset deve avere una colonna “regione”, una colonna “trimestre” e una colonna con il valore da misurare — in formato long. Se invece il tuo dataset ha una colonna per ogni trimestre (formato wide), sai già che dovrai fare una trasformazione prima di visualizzare.

Come fare un prototipo utile in cinque minuti

Non serve essere bravi a disegnare. Prendi un foglio e traccia gli assi del grafico che hai in mente. Scrivi le etichette degli assi. Disegna a mano le barre, la linea o le forme che rappresentano i dati — anche in modo approssimativo. Aggiungi un titolo che descriva il messaggio, non il contenuto (“Le vendite nel Nord crescono più velocemente del Sud” invece di “Vendite per regione”).

Questo esercizio, che richiede cinque minuti, produce tre risultati concreti: chiarisce il messaggio che vuoi comunicare, rivela i requisiti di struttura del dataset, e ti permette di valutare se il grafico che hai in mente funziona davvero prima di investire tempo nel costruirlo.

Se durante il prototipo ti rendi conto che il grafico non riesce a mostrare quello che vuoi, è il momento giusto per cambiare approccio — non dopo aver passato un’ora a configurare il software.

Gli errori più comuni nella preparazione dei dati

Conoscere gli errori tipici aiuta a riconoscerli prima che diventino problemi nella visualizzazione finale. Questi sono i più frequenti nel lavoro quotidiano con i dati.

Confondere la pulizia con la selezione

Pulire i dati non significa selezionare solo quelli che confermano la tesi. È una distinzione che sembra ovvia, ma nella pratica è sottile. Eliminare gli outlier “perché disturbano il grafico”, escludere i periodi anomali “perché non sono rappresentativi”, filtrare i segmenti con performance basse “perché non sono rilevanti per l’analisi” — tutte queste operazioni, se non documentate e giustificate, trasformano la pulizia in manipolazione.

La regola è semplice: ogni operazione di esclusione deve avere una ragione tecnica (il dato è un errore) o una ragione dichiarata esplicitamente nell’analisi (“abbiamo escluso il periodo X perché…”). Mai eliminare dati scomodi senza dirlo.

Lavorare sul dataset originale senza una copia

È un errore operativo banale ma con conseguenze serie. Se lavori direttamente sul file originale e fai un’operazione sbagliata, non puoi tornare indietro. Conserva sempre una copia immutabile del dataset grezzo e lavora su una versione separata. Questo vale anche quando usi strumenti che sembrano “non distruttivi”: non fidarti, mantieni il backup.

Non documentare le trasformazioni

Ogni operazione di pulizia che fai dovrebbe essere documentata: cosa hai fatto, perché, e quale impatto ha avuto sul dataset. Questa documentazione serve a te quando devi rifare l’analisi su dati aggiornati, serve ai colleghi che devono verificare il tuo lavoro, e serve a chiunque debba riprodurre o estendere l’analisi in futuro.

La documentazione non deve essere elaborata — può essere un file di testo con una lista di operazioni in ordine cronologico. L’importante è che esista.

Saltare la verifica finale prima della visualizzazione

Prima di passare alla costruzione del grafico, fai un ultimo controllo sul dataset pulito: il numero di righe è coerente con quello atteso? I totali aggregati corrispondono a quelli che conosci da altre fonti? Le distribuzioni sembrano plausibili? Questo controllo di sanità — in gergo sanity check — è il filtro finale che intercetta i problemi rimasti.

Problema	Causa tipica	Azione correttiva
Valori mancanti	Raccolta incompleta o export parziale	Investigare la fonte; non eliminare senza capire
Duplicati	Più export sovrapposti o join errati	Verificare la chiave univoca del dataset
Categorie inconsistenti	Inserimento manuale non standardizzato	Definire vocabolario canonico e applicarlo
Tipi misti	Dati da fonti eterogenee	Normalizzare il tipo prima di qualsiasi calcolo
Outlier non verificati	Errori di inserimento o eventi reali	Distinguere errore da segnale prima di agire

Questa sintesi non sostituisce il ragionamento caso per caso: ogni dataset ha la sua storia e i suoi problemi specifici. Ma avere in mente i pattern più frequenti accelera la diagnosi.

Dal dato pulito al dato pronto: il data shaping come ponte

Il data cleaning porta i dati a uno stato corretto. Il data shaping — la fase successiva — li porta a uno stato utile per la visualizzazione specifica che hai in mente. È la differenza tra un ingrediente fresco e un ingrediente preparato per la ricetta.

Le operazioni di shaping più comuni includono: aggregare i dati al livello di granularità giusto (da transazioni a settimane, da settimane a mesi), calcolare metriche derivate (tassi, variazioni percentuali, medie mobili), pivotare il dataset tra formato wide e long, unire dataset provenienti da fonti diverse mantenendo la coerenza delle chiavi.

Ognuna di queste operazioni richiede che la pulizia sia già stata completata. Se aggrego dati con duplicati, ottengo totali gonfiati. Se calcolo variazioni percentuali su date mal formattate, ottengo sequenze temporali sbagliate. Se unisco due dataset con categorie inconsistenti, ottengo un join che produce righe spurie.

L’ordine corretto è sempre: prima pulire, poi strutturare, poi visualizzare. Invertire i passi non risparmia tempo — lo spreca.

Se vuoi approfondire il metodo completo di data shaping — dalla lettura del dataset grezzo alla struttura pronta per la visualizzazione — la Data Shaping Masterclass di Data Storytelling Academy percorre questo processo in modo operativo, con esercitazioni su dataset reali.

Come scegliere gli strumenti senza farsi condizionare da essi

La scelta dello strumento per il data cleaning dipende da diversi fattori: la dimensione del dataset, il tipo di trasformazioni necessarie, le competenze del team, e l’integrazione con gli strumenti di visualizzazione a valle. Non esiste uno strumento universalmente migliore.

Quello che conta è non scegliere lo strumento prima di aver capito il problema. Il bias di Maslow descritto all’inizio si manifesta esattamente qui: si apre lo strumento che si conosce meglio e si adattano i dati a quello, invece di scegliere lo strumento in funzione di ciò che i dati richiedono.

Un criterio utile è separare mentalmente le operazioni: la lettura e l’ispezione del dataset possono essere fatte con qualsiasi strumento, anche il più semplice. La pulizia vera e propria — gestione dei mancanti, deduplicazione, standardizzazione — richiede un ambiente che permetta di tracciare e ripetere le operazioni. Il data shaping per la visualizzazione può richiedere strumenti diversi a seconda della complessità delle trasformazioni.

L’importante è che il processo sia riproducibile: se devi aggiornare l’analisi la settimana prossima con dati nuovi, devi poter ripetere le stesse operazioni senza ripartire da zero. Questo requisito di riproducibilità è spesso il criterio più pratico per scegliere tra un approccio manuale e uno automatizzato.

Domande frequenti

Quanto tempo dovrebbe richiedere il data cleaning rispetto all’analisi complessiva?

Non esiste una proporzione fissa, ma nella pratica la preparazione dei dati occupa spesso più tempo dell’analisi vera e propria, specialmente con dataset provenienti da fonti eterogenee. Pianifica almeno quanto tempo dedichi alla costruzione della visualizzazione: sottostimare questa fase è la causa più frequente di ritardi e rework nei progetti analitici.

È possibile automatizzare il data cleaning completamente?

Alcune operazioni si prestano bene all’automazione: conversione di tipi, rimozione di duplicati esatti, standardizzazione di formati. Altre richiedono giudizio umano: decidere se un outlier è un errore o un segnale, capire perché un valore manca, scegliere quale forma canonica adottare per una categoria. Un processo ibrido — automazione per le operazioni ripetibili, revisione umana per le decisioni ambigue — è quasi sempre la scelta più solida.

Qual è la differenza tra data cleaning e data wrangling?

I termini vengono spesso usati in modo intercambiabile, ma c’è una distinzione utile. Il data cleaning riguarda la correzione degli errori: rimuovere duplicati, gestire mancanti, standardizzare valori. Il data wrangling (o data shaping) include anche le trasformazioni strutturali: aggregare, pivotare, unire dataset, calcolare metriche derivate. Il cleaning è una fase del wrangling, non il processo completo.

Come gestisco un dataset con molti valori mancanti senza distorcere l’analisi?

Prima di tutto, capisce il pattern dei valori mancanti: sono distribuiti casualmente o concentrati su certi segmenti? Se sono sistematici (mancano sempre per una certa categoria o periodo), qualsiasi trattamento introduce un bias che va dichiarato esplicitamente nell’analisi. L’imputazione statistica può essere appropriata per mancanze casuali su variabili numeriche; per mancanze sistematiche, la soluzione più onesta è spesso mostrare l’incompletezza nel grafico stesso.

Perché prototipare su carta invece di usare direttamente il software?

Il software di visualizzazione propone opzioni predefinite che orientano le tue scelte verso ciò che il tool gestisce meglio, non verso ciò che serve al tuo messaggio. Prototipare su carta prima di aprire il software ti costringe a decidere il messaggio, la struttura del grafico e i requisiti dei dati in modo indipendente dal tool. Cinque minuti su carta risparmiano spesso ore di configurazione e rework.

Come tratto gli outlier in un dataset prima di visualizzare?

La prima domanda è se l’outlier è un errore o un dato reale. Se è un errore di inserimento, va corretto o eliminato con documentazione. Se è un dato reale, la scelta dipende dal messaggio: se stai mostrando l’andamento tipico, puoi escluderlo dichiarandolo esplicitamente; se stai cercando anomalie, è esattamente il dato più importante. Non esiste una regola universale: dipende dal contesto e dall’obiettivo dell’analisi.

Il data cleaning va rifatto ogni volta che i dati si aggiornano?

Sì, ma non necessariamente da zero. Se hai documentato le operazioni di pulizia e usato un approccio riproducibile (script, query, pipeline), puoi applicare le stesse trasformazioni ai dati aggiornati in modo semi-automatico. Resta comunque necessaria una verifica manuale: i nuovi dati possono introdurre problemi nuovi che il processo precedente non copre. La riproducibilità riduce il lavoro, ma non elimina la supervisione.

Un metodo, non una lista di operazioni

Il data cleaning efficace non è l’esecuzione meccanica di una checklist. È un processo di comprensione progressiva: prima leggi il dataset con occhio critico, poi intervieni con operazioni mirate e documentate, poi strutturi i dati in funzione del messaggio che vuoi comunicare. Ogni passo dipende dal precedente, e saltarne uno crea problemi che emergono sempre nel momento meno opportuno.

Il filo conduttore di questo metodo è tenere il messaggio al centro: non si pulisce per avere dati perfetti in astratto, ma per avere dati che supportino una visualizzazione specifica e un argomento preciso. Questo orientamento — dall’obiettivo al dato, non dal dato all’obiettivo — è ciò che distingue la preparazione dei dati come pratica analitica dalla pulizia dei dati come operazione tecnica.