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.

Fase	Cosa chiarire	Output
Domanda	Quale scelta reale deve migliorare?	Decisione da prendere
Misura	Quale segnale osservabile rappresenta il problema?	Metrica o dato sorgente
Controllo	Quale baseline rende il risultato interpretabile?	Confronto credibile
Azione	Che cosa cambia dopo l’analisi?	Prossimo passo operativo

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.

Livello	Tipo di test	Copertura	Impatto del fallimento
Livello 1, fondamentali	unique, not_null su primary key	Ogni modello	Blocca la PR
Livello 2, business	accepted_values, relationships	Ogni colonna critica	Blocca la PR
Livello 3, volume	Range di row count atteso	Modelli chiave	Warning
Livello 4, qualità statistica	Media, deviazione standard, distribuzione	Metriche core	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

Una source marketing smette di inviare 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.

Evidenza osservata	Lettura prudente	Azione consigliata
Il numero migliora	Potrebbe essere effetto reale o variazione normale	Cercare confronto e segmentazione
Un segmento cambia più degli altri	La media nasconde differenze	Separare coorti o casi d’uso
Il costo cresce insieme al risultato	L’impatto va letto sul margine	Stimare trade-off e sostenibilità

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.

Riepilogo operativo

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.