Case Study — Smart Data Cleaning & Reporting

Nei contesti reali, i dataset raramente falliscono in modo evidente.

Molto più spesso falliscono **in silenzio**.

File CSV o Excel provenienti da e-commerce o CRM possono sembrare “utilizzabili”,

ma nascondono problemi che alterano i KPI senza generare errori tecnici.

I problemi più comuni:

- schema drift (colonne rinominate o mancanti)

- date in formati misti (YYYY-MM-DD / DD-MM-YYYY)

- numeri trattati come stringhe (prezzi con virgola)

- duplicati che gonfiano i totali

- missing distribuiti in modo non uniforme

Il rischio non è il crash della pipeline,

ma **decisioni sbagliate basate su KPI apparentemente corrette**.

In real projects, messy data rarely “breaks” a pipeline.

Most of the time it silently corrupts the numbers: the pipeline runs, the dashboard updates, and the business trusts KPIs that are wrong.

Typical symptoms:

• schema drift (renamed / missing columns)
• mixed formats for dates and numbers
• duplicates inflating totals
• inconsistent missing values (especially in critical fields)

The goal is not “clean for beauty”. The goal is reliable decisions.

L’obiettivo non è “pulire i dati” in senso generico,

ma costruire una pipeline **riproducibile, auditabile e spiegabile**.

Obiettivi chiave:

- standardizzare dataset reali e sporchi

- rendere esplicite le regole di cleaning

- misurare la qualità del dato prima e dopo

- separare chiaramente dati, KPI e report

- produrre output pronti per il business

Il focus non è la performance tecnica,

ma **l’affidabilità del processo decisionale**.

Build a reproducible and auditable process that turns messy exports into:

• a cleaned dataset
• a set of KPIs
• quality checks you can trust
• a report that explains what happened

Key requirements:

• explicit rules (no “magic” transformations)
• deterministic output (same input → same results)
• separated deliverables to reduce downstream errors

Il dataset di partenza simula un export reale di ordini e-commerce.

Caratteristiche principali:

- colonne eterogenee (ordini, date, prezzi, clienti)

- struttura simile a export PrestaShop / CRM

- dati numerici e temporali misti

- presenza intenzionale di rumore controllato

Il dataset “pulito” di base viene generato in modo deterministico,

per poter **misurare con precisione l’impatto del rumore** introdotto successivamente.

The starting point is a real-world export (e-commerce / CRM style).

Before doing any cleaning, we define a controlled input contract:

• expected columns (even if some may be missing)
• data types and parsing rules
• minimal fields required for KPIs
• how to treat nulls and placeholders

This makes the pipeline idiot-proof: when the input changes, we detect it and react consistently.

Per simulare uno scenario realistico, il dataset viene degradato in modo controllato.

Tipi di rumore introdotti:

- missing values su colonne selezionate

- duplicazione di righe

- date in formati misti

- numeri salvati come stringhe

- colonne opzionali rimosse o rinominate

Questo approccio consente di:

- testare la robustezza della pipeline

- verificare i quality checks

- confrontare input sporco e output pulito in modo oggettivo

This project focuses on issues that usually generate silent KPI errors:

• duplicates (same order/customer repeated)
• inconsistent identifiers (spaces, casing, formatting)
• broken dates (DD/MM vs MM/DD, strings, invalid values)
• numeric fields with commas/dots and currency symbols
• empty values represented in different ways (null, "", “N/A”, ”-”)

A good cleaning system must surface the problem, not hide it.

La pipeline è progettata seguendo un principio chiave:

**ogni trasformazione deve essere deterministica e spiegabile**.

Step principali:

1. parsing difensivo del file (encoding, separatori)

2. normalizzazione dei nomi colonna

3. parsing e standardizzazione delle date

4. conversione esplicita dei tipi numerici

5. deduplicazione basata su chiavi definite

6. rimozione di righe non valide con motivazione

Nessuna trasformazione “magica” o implicita:

ogni step è tracciabile e riproducibile.

The pipeline is structured in clear steps:

1. Ingest

   • load file(s)
   • basic sanity checks

2. Normalize

   • column names normalization
   • type parsing (dates, numbers)
   • standardize missing values

3. Deduplicate

   • define dedupe keys
   • keep rules explicit and traceable

4. Validate

   • schema checks
   • range checks (where meaningful)
   • critical-field completeness

5. Export

   • cleaned dataset
   • KPIs
   • quality report
   • narrative report

Each step writes logs and produces measurable signals.

La qualità del dato viene misurata e salvata in modo esplicito.

Metriche principali:

- numero di righe in input / output

- righe eliminate e motivazione

- duplicati rimossi

- missing values per colonna

- confronto before / after cleaning

Il risultato è un file quality.json

pensato per essere leggibile sia da umani che da sistemi automatici.

Quality checks are the “seatbelt” of the system.

Instead of trusting the output blindly, we compute:

• rows in / rows out
• dropped rows (and why)
• duplicate rate
• missingness on critical fields
• parsing errors (dates/numbers)

The point is to answer:

“Can I trust these KPIs?”

If the quality is below threshold, the pipeline should warn clearly.

La pipeline produce output separati e con responsabilità chiare:

- cleaned.csv

  Dataset finale pronto per analisi o import.

- kpi.json

  KPI calcolate sul dataset pulito.

- quality.json

  Riassunto completo delle operazioni di cleaning e qualità.

- report.md

  Report testuale leggibile che spiega cosa è successo e perché.

Questa separazione evita ambiguità

e rende il processo facilmente auditabile.

The pipeline produces a small set of portable outputs:

• cleaned.csv (or parquet)
• kpi.json
• quality.json
• report.md (human-readable narrative)

This separation is intentional:

• you can plug KPIs into a dashboard
• you can audit the quality independently
• you can share the report with non-technical stakeholders

The result is not just “data cleaned”: it’s proof that it’s safe to use.

Il progetto fa scelte esplicite e accetta alcuni compromessi.

Trade-off principali:

- regole deterministiche invece di modelli probabilistici

- maggiore verbosità a favore della chiarezza

- focus sulla qualità, non sulla velocità massima

Limiti attuali:

- regole specifiche per questo schema

- non adatto a streaming real-time

- validazione basata su regole, non su ML

Questi limiti sono **consapevoli** e documentati.

There is no perfect cleaning.

Key trade-offs we accept explicitly:

• strict validation may drop more rows (but increases trust)
• flexible parsing improves coverage (but can hide edge cases)
• business rules require context (not everything can be inferred)

The goal is not maximum retention. The goal is maximum decision quality.

La lezione principale è che la data quality non è un dettaglio tecnico,

ma una **responsabilità decisionale**.

Aspetti chiave emersi:

- dati sporchi raramente falliscono rumorosamente

- KPI errate sono più pericolose di pipeline rotte

- rendere esplicite le regole aumenta la fiducia

- separare output riduce errori a valle

Un buon sistema di cleaning

è prima di tutto un sistema di comunicazione.

The main lesson:

data quality is not a technical detail — it’s a decision responsibility.

Key takeaways:

• messy data rarely fails loudly
• wrong KPIs are more dangerous than broken pipelines
• making rules explicit increases trust
• separating outputs reduces downstream mistakes

A good cleaning system is, first of all, a communication system.

Possibili evoluzioni del progetto:

- supporto a schemi multipli

- configurazione dinamica delle regole

- validazioni basate su profili di business

- integrazione con sistemi di monitoring

- estensione verso forecasting o simulazione decisionale

Il progetto è pensato come **base solida**,

non come soluzione chiusa.

Possible evolutions:

• support multiple input schemas
• dynamic rule configuration (per client / per tenant)
• validations driven by business profiles
• monitoring and alerting (quality drift over time)
• extension toward forecasting or decision simulation

The project is designed as a solid base, not a closed solution.