Snapshots and slow change management

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.

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

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.

Type	Strategy	Usage	Example
Type 1	Overwrite	When the old value is no longer needed	Fix a typo in the name
Type 2	New row with validity date	When full history is needed	Subscription plan change
Type 3	"Previous value" column + "current value"	When only the immediately preceding change is needed	Previous vs current registered office

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. If customer_id è nuovo, inserisce una riga con valid_from = now e valid_to = NULL
4. If 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 with columns 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. Which concrete decision should this lesson improve?
2. Which unit of analysis makes the problem measurable?
3. Which baseline would you use to avoid a naive reading?
4. Which typical mistake could change the conclusion?
5. Which output would you deliver to a non-technical stakeholder?

Summary

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.

---

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