Test, contratti e fiducia nei modelli

Test, contratti e fiducia nei modelli vanno letti come un passaggio decisionale, non come definizioni isolate. Una metrica che cambia da un giorno all’altro raramente racconta una storia di business: molto più spesso è il sintomo di un campo rinominato a monte. Questa lezione tiene insieme la domanda, il dato, il controllo e l’azione, in modo che il lavoro tecnico resti agganciato a una scelta verificabile.

Quando il dato tradisce la fiducia

Nel lavoro quotidiano di analytics engineering, trasformare dati grezzi in modelli affidabili è una sfida costante. Capita spesso che una metrica cambi non perché il business si sia mosso, ma per un dettaglio tecnico come la rinomina di un campo in una sorgente. Senza test, contratti e una fiducia ben fondata nei modelli, si finisce per decidere su dati corrotti o incompleti senza accorgersene.

L’obiettivo è trasformare dati, assunzioni e controlli in un processo che regge scelte concrete. Se alla fine non sai quale decisione cambia, quale dato osservi e quale errore vuoi evitare, non hai ancora applicato davvero la lezione.

Il modello in quattro passi

Per costruire fiducia tecnica serve uno schema essenziale che orienti ogni controllo verso un impatto reale.

Phase	What to clarify	Output
Question	Which real choice needs improvement?	Decision to make
Measure	Which observable signal represents the problem?	Metric or source data
Control	Which baseline makes the result interpretable?	Credible comparison
Action	What changes after the analysis?	Next operational step

Definire i termini con precisione

Perché il processo sia riproducibile e criticabile, conviene fissare l’unità di analisi (source, model, test, mart, metrica o esposizione) e collegarla a un segnale osservabile come freshness, lineage, test coverage, costo del modello o fiducia degli stakeholder. La baseline può essere un periodo precedente, un gruppo comparabile, un benchmark o uno scenario controfattuale, mentre la decisione attesa riguarda un modello dbt, il semantic layer, un contratto, un test o la pipeline di release. Il rischio da tenere a mente è sempre lo stesso: scambiare un numero disponibile per una prova sufficiente. La formalizzazione regge quando un altro analista può ripercorrere la logica e arrivare alla stessa decisione.

La piramide dei test

dbt mette a disposizione una strategia di test stratificata per proteggere il warehouse. I livelli salgono di sofisticazione e cambia anche la severità con cui un fallimento blocca il lavoro.

Level	Test type	Coverage	Failure impact
Livello 1, fondamentali	unique, not_null on primary key	Every model	Blocks the PR
Livello 2, business	accepted_values, relationships	Every critical column	Blocks the PR
Livello 3, volume	Expected row count range	Key models	Warning
Livello 4, qualità statistica	Mean, standard deviation, distribution	Core metrics	Alert

I test built-in coprono la maggior parte dei casi comuni e fermano gli errori gravi. I test singolari aggiungono controlli specifici scritti in SQL, che per passare devono restituire zero righe. I test custom in Jinja sono riutilizzabili e diventano la base di una strategia matura.

I data contracts

Un data contract formalizza l’accordo tra chi produce e chi consuma i dati: definisce schema, semantica, garanzie di qualità e SLA di freschezza. Con la versione 1.5 dbt ha introdotto i model contracts, che verificano tipi e vincoli a build time. È uno spostamento netto: si passa dallo “speriamo che il dato sia corretto” al “il dato è garantito corretto, oppure il build fallisce”.

Caso reale: il calo di revenue spiegato male

Un e-commerce europeo ha visto il revenue mostrato in dashboard scendere del 31%. Il business non era cambiato: un aggiornamento minore di un payment provider aveva trasformato un campo da stringa a numero. Senza contratti, il problema è emerso solo dopo giorni di indagine manuale. Una volta introdotti i model contracts, un caso analogo è stato intercettato in pochi minuti e corretto in fretta.

Una strategia di adozione progressiva

Non serve testare tutto subito, e provarci di solito porta solo ad abbandonare. Conviene procedere per tappe.

1. Settimana 1: not_null e unique sulla primary key di ogni modello
2. Settimana 2: accepted_values sulle colonne critiche e relationships sulle foreign key
3. Mese 2: test singolari per le regole di business critiche
4. Mese 3: model contracts sui modelli staging delle fonti esterne
5. Quarter 2 in poi: test custom riusabili e test di qualità statistica

La pipeline CI/CD deve eseguire i test in automatico e bloccare la PR quando falliscono. Senza questo blocco, i test restano documentazione che nessuno legge.

Controlli prima di fidarsi

Prima di affidarti a test e contratti, verifica completezza, duplicati, timezone, definizioni cambiate e segmenti esclusi. Molte analisi falliscono perché il dato misura qualcosa di diverso da ciò che si crede.

Leggere i segmenti, non solo la media

La media aggregata può nascondere differenze che contano. Segmenta per canale, coorte, piano, paese, device e maturità utente. Quando due segmenti si muovono in direzioni opposte, la media inganna e porta a decisioni sbagliate.

Chiudere con una scelta

Ogni analisi dovrebbe concludersi con una scelta concreta: continuare, fermare, iterare, investire, rimuovere o approfondire. Se test, contratti e fiducia nei modelli non cambiano nessuna decisione, manca il collegamento tra metrica e azione.

Esempio: quando il dato resta plausibile ma sbagliato

A marketing source stops sending campaign_id per alcune righe, ma il mart attribution continua a produrre numeri plausibili. È proprio il caso più insidioso, e spiega perché i test di not-null, accepted values e relationship devono fallire presto, prima che la dashboard mostri dati fuorvianti.

Observed evidence	Cautious interpretation	Recommended action
The number improves	Could be a real effect or normal variation	Cercare confronto e segmentazione
One segment changes more than others	La media nasconde differenze	Separate cohorts or use cases
Cost grows along with the result	Impact must be read on the margin	Estimate trade-offs and sustainability

Mettere in pratica

Allenati su tre livelli di difficoltà crescente. Per iniziare, scrivi una scheda sintetica con la decisione da supportare, la metrica primaria, la baseline, il rischio principale e l’azione prevista se il segnale è confermato. Al livello intermedio, costruisci una tabella con tre segmenti, periodi o scenari, indicando per ciascuno cosa cambia, una spiegazione alternativa plausibile e il controllo da usare prima di raccomandare qualcosa. Per arrivare a un decision memo completo, aggiungi ipotesi, dati richiesti, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio.

Come materiale lavora su dbt, warehouse, sorgenti CRM, eventi, marts, semantic layer e lineage. Se non hai dati reali, un dataset sintetico di almeno 200 righe con dimensione temporale, segmento e metrica di outcome basta per esercitarsi.

L’errore tipico

Capita di usare “test, contratti e fiducia nei modelli” come etichetta invece che come processo. Lo riconosci quando compare un grafico senza decisione, una metrica senza baseline o una conclusione che non dichiara quale assunzione potrebbe invalidarla. La domanda di controllo è semplice: se questo risultato fosse instabile, quale scelta sbaglierei? Quando la risposta non è concreta, il collegamento tra analisi e azione non esiste.

Operational Summary

Test, contratti e fiducia nei modelli diventano utili solo quando portano a decisioni più chiare, non quando aggiungono terminologia. Il percorso che va dal problema al modello, dalla formalizzazione all’esempio fino all’esercizio e al controllo è ciò che trasforma la lezione in una pratica verificabile.