Snapshot e gestione del cambiamento lento

Un cliente cambia segmento, piano, stato CRM e owner commerciale nel corso del tempo. Se guardi solo lo stato attuale del database, perdi la storia che spiegava una decisione presa sei mesi fa. Gli snapshot servono proprio a questo: a tenere traccia di come un attributo è cambiato, così da poter ricostruire il contesto corretto di una metrica in qualsiasi momento del passato.

Il problema che cambia le decisioni

In analytics engineering il lavoro consiste nel trasformare dati grezzi in modelli testati, documentati e riusabili dal business. Quando non gestisci il cambiamento lento, finisci per prendere decisioni basate su dati che non rispecchiano più il contesto storico in cui un evento è accaduto. Il segnale che la lezione è diventata competenza vera è semplice: sai dire quale decisione cambia, quale dato osservi e quale errore vuoi evitare. Se quei tre punti non sono chiari, hai ancora una definizione e non una pratica.

Un modello per restare ancorati alla decisione

Prima di toccare il codice conviene fissare quattro domande, perché è facile costruire snapshot eleganti che non servono a nessuno.

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

Lo schema tiene il focus sulla decisione invece che sulla terminologia, ed è il filo che lega tutto il resto della lezione.

Come rendere analizzabile il cambiamento

Perché la gestione del cambiamento lento sia riproducibile, conviene dichiarare in modo esplicito gli elementi che la compongono. L’unità di analisi può essere una source, un model, un test, un mart, una metrica o un’esposizione. Il segnale principale è di solito freshness, lineage, copertura dei test, costo del modello o fiducia degli stakeholder. La baseline arriva da un periodo precedente, da un gruppo comparabile, da un benchmark o da uno scenario controfattuale. La decisione attesa riguarda un modello dbt, un semantic layer, un contratto, un test o una pipeline di release. Il rischio costante è scambiare un numero disponibile per una prova sufficiente. La formalizzazione regge quando un altro analista riprende la stessa logica e arriva alla stessa decisione.

Cosa sono le slowly changing dimensions

Una Slowly Changing Dimension (SCD) è una dimensione i cui attributi cambiano nel tempo, dove ti serve conoscere il valore in ogni momento storico e non solo l’ultimo. Lo stato attuale non basta: devi poter rispondere a domande come “qual era il piano di abbonamento del cliente X il 15 marzo 2023?”.

I tipi più usati si distinguono per come trattano il valore vecchio.

Tipo	Strategia	Uso	Esempio
Type 1	Sovrascrivi	Quando il vecchio valore non serve più	Correzione di un typo nel nome
Type 2	Nuova riga con data di validità	Quando serve storico completo	Cambio di subscription plan
Type 3	Colonna “valore precedente” + “valore attuale”	Quando serve solo il cambiamento immediatamente precedente	Sede legale precedente vs attuale

Il Type 2 è quello su cui si lavora più spesso, perché conserva la storia completa aggiungendo colonne di validità temporale.

customer_id	plan	valid_from	valid_to	is_current
C001	free	2023-01-10	2023-06-15	false
C001	pro	2023-06-15	2023-12-01	false
C001	enterprise	2023-12-01	NULL	true

Con una struttura così filtri per il periodo che ti interessa. Per sapere quale piano aveva il cliente il primo agosto 2023 scrivi:

WHERE ‘2023-08-01’ BETWEEN valid_from AND COALESCE(valid_to, ‘2099-12-31’)

Gli snapshot di dbt come Type 2 automatico

dbt mette a disposizione un modulo per gli snapshot che automatizza il versionamento. Tu dichiari la strategia e dbt la applica a ogni esecuzione. Nel caso più comune definisci customer_id come unique key e usi una strategia timestamp basata sulla colonna updated_at.

A ogni dbt snapshot accade questo:

1. Legge la tabella sorgente
2. Confronta ogni riga con la versione salvata
3. Se customer_id è nuovo, inserisce una riga con valid_from = now e valid_to = NULL
4. Se updated_at è cambiato, chiude la riga precedente e ne crea una nuova
5. Se nulla è cambiato, ignora

Le due strategie principali coprono casi diversi. Con strategy: timestamp ti affidi a una colonna di ultima modifica. Con strategy: check confronti un insieme di colonne e lo snapshot scatta se almeno una è cambiata, utile quando non ti fidi del campo di timestamp.

Caso pratico: Monzo

Monzo, banca digitale con 8 milioni di clienti, usa gli snapshot di dbt per tracciare ogni cambiamento di stato conto, piano tariffario e dati anagrafici con la data esatta. Senza snapshot la stessa logica avrebbe richiesto migliaia di righe di codice e mesi di lavoro; con dbt sono bastate poche righe e qualche settimana.

Da quei dati storici è emerso un dettaglio operativo: i clienti che passano da standard a plus entro 30 giorni hanno un LTV del 43% più alto di chi aspetta 90 giorni. È un’informazione che esiste solo se conservi la storia, e ha portato a rivedere l’onboarding.

Gli errori che rovinano uno snapshot

Quasi tutti i problemi nascono da poche scelte sbagliate all’inizio. Una unique_key non immutabile è la prima trappola: vanno usati ID generati dal sistema, mai email o altri campi che il cliente può modificare. Quando updated_at non è affidabile conviene passare a strategy: check sulle colonne specifiche che contano. Una query storica senza filtro temporale restituisce risultati sbagliati, quindi va sempre usato il range di validità. Infine la frequenza: se i dati cambiano più volte al giorno, uno snapshot giornaliero perde le variazioni intermedie.

Esercizio guidato

Crea uno snapshot per la tabella product_prices con le colonne product_id, price, currency, updated_at, updated_by. Implementa lo snapshot, poi scrivi una query che per ogni prodotto mostri la sequenza dei cambi di prezzo con data, prezzo vecchio, prezzo nuovo e differenza percentuale. Per ottenere il prezzo precedente usa la funzione LAG.

Sopra questo lab puoi costruire tre livelli di approfondimento. Al livello base scrivi una scheda sintetica con la decisione da supportare, la metrica primaria, la baseline, il rischio principale e l’azione da prendere se il segnale è confermato. Al livello intermedio prepari una tabella con tre segmenti o periodi, indicando per ciascuno cosa cambia, le spiegazioni alternative e i controlli da fare prima di agire. Al livello research-grade scrivi un decision memo completo con ipotesi, dati richiesti, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio. Per gli strumenti usa dbt, il warehouse, le sorgenti CRM, gli eventi, i marts, il semantic layer e il lineage; se non hai dati reali, costruisci un dataset sintetico di almeno 200 righe con una dimensione temporale, un segmento e una metrica di outcome.

L’errore tipico da evitare

Il modo più comune di sbagliare è trattare “snapshot e gestione del cambiamento lento” come un’etichetta invece che come un processo. Succede quando manca la decisione, la baseline o il legame tra analisi e azione. La domanda da farsi è una sola: se il risultato fosse instabile, quale scelta sbaglierei? Se non sai rispondere, il collegamento tra analisi e decisione non c’è ancora.

Checkpoint

Prima di considerare chiusa la lezione, prova a rispondere a queste domande.

1. Quale decisione concreta dovrebbe migliorare questa lezione?
2. Quale unità di analisi rende il problema misurabile?
3. Quale baseline useresti per evitare una lettura ingenua?
4. Quale errore tipico potrebbe cambiare la conclusione?
5. Quale output consegneresti a uno stakeholder non tecnico?

Riepilogo

Gli snapshot servono solo se producono decisioni più chiare, non terminologia in più. Il percorso problema, modello, formalizzazione, esempio, lab e checkpoint trasforma la lezione in qualcosa che puoi verificare e difendere davanti a un collega.

---

Riferimenti: Kimball & Ross (2013), dbt Labs (2024), Monzo Engineering Blog (2022).