Snapshot e gestione del cambiamento lento

Un cliente cambia segmento, piano, stato CRM e owner commerciale nel tempo. Se guardi solo lo stato attuale, perdi la storia che spiegava una decisione passata. Snapshot e gestione del cambiamento lento insegna a preservare versioni temporali quando la domanda business richiede memoria.

Una scena da cui partire

Leggi questa lezione come scelta tra stato e storia. Snapshot e slowly changing dimensions non sono dettagli da modellazione: decidono se puoi ricostruire il contesto corretto di una metrica nel tempo.

• Contesto: Quale decisione rende utile il concetto?
• Metodo: Quale conflitto tra team o metriche devi anticipare?
• Applicazione: Quale frase useresti per spiegarlo in riunione?

Cosa sono le Slowly Changing Dimensions

Una SCD è una dimensione i cui attributi cambiano nel tempo, e tu hai bisogno di sapere il valore in ogni momento storico. Non ti basta lo stato attuale: devi poter rispondere a “qual era il piano di abbonamento del cliente X il 15 marzo 2023?”

Esistono otto tipi di SCD (teorizzati da Ralph Kimball). I più usati nei data warehouse moderni sono tre:

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 è il più comune e il più potente. Aggiunge colonne di validità temporale a ogni riga:

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 questa struttura, qualsiasi query può filtrare per il periodo di interesse: WHERE '2023-08-01' BETWEEN valid_from AND COALESCE(valid_to, '2099-12-31').

dbt snapshots: l’implementazione automatica del Type 2

dbt ha un modulo specifico per gli snapshots. Invece di scrivere la logica di versionamento a mano, definisci la strategia e dbt la applica a ogni esecuzione.

File: snapshots/customer_subscriptions_snapshot.sql

{% snapshot customer_subscriptions_snapshot %}

{{
    config(
        target_database='analytics',
        target_schema='snapshots',
        unique_key='customer_id',
        strategy='timestamp',
        updated_at='updated_at',
    )
}}

SELECT
    customer_id,
    plan,
    status,
    updated_at
FROM {{ source('production', 'subscriptions') }}

{% endsnapshot %}

Cosa fa questo snapshot: Ogni volta che esegui dbt snapshot, dbt:

1. Legge la tabella subscriptions dalla source
2. Confronta ogni riga con la versione già salvata nello snapshot
3. Se customer_id è nuovo → inserisce una nuova riga con valid_from = now, valid_to = NULL
4. Se customer_id esiste ma updated_at è cambiato → chiude la riga corrente (valid_to = now) e ne crea una nuova
5. Se non è cambiato nulla → ignora

Strategie disponibili:

• strategy: timestamp: Usa una colonna updated_at per rilevare cambiamenti. Adatto quando la fonte ha un timestamp affidabile di ultima modifica.

• strategy: check: Confronta un insieme di colonne. Se qualsiasi colonna nella lista check_cols cambia valore, scatta lo snapshot:

{{
    config(
        unique_key='customer_id',
        strategy='check',
        check_cols=['plan', 'status', 'billing_country'],
    )
}}

Caso reale: come Monzo gestisce la storicizzazione

Monzo, la banca digitale britannica con oltre 8 milioni di clienti, ha documentato pubblicamente il proprio uso di dbt snapshots. La loro architettura dati deve rispondere a requisiti normativi stringenti: ogni cambiamento nello stato di un conto, nel piano tariffario o nei dati anagrafici deve essere tracciabile con data esatta.

Monzo ha snapshot su:

• account_status (active, frozen, closed)
• overdraft_limit
• customer_tier (standard, plus, premium)
• linked_address

Ogni snapshot viene eseguito ogni ora. Il team di data engineering ha stimato che senza snapshots dbt, la stessa logica avrebbe richiesto ~4000 righe di stored procedure custom e 6 mesi di sviluppo. Con dbt, sono 120 righe di Jinja e 2 settimane di lavoro.

Un insight emerso dagli snapshots: analizzando i cambi di piano tariffario nel tempo, Monzo ha scoperto che i clienti che passano da standard a plus entro i primi 30 giorni hanno un LTV del 43% più alto di chi aspetta più di 90 giorni. Questo ha portato a un redesign dell’onboarding che promuove l’upgrade già al giorno 15.

Errori comuni con gli snapshots

Errore 1: unique_key che non è univoco nel tempo

Se usi unique_key='email' e un cliente cambia email, l’istantanea considera il nuovo record come un cliente diverso — non un aggiornamento del cliente esistente. Usa sempre un ID immutabile (es. customer_id generato dal sistema).

Errore 2: updated_at inaffidabile

Alcune tabelle sorgente aggiornano updated_at anche per modifiche irrilevanti (es. un campo last_api_call). In questi casi, strategy: check con check_cols specifici è meglio di strategy: timestamp.

Errore 3: Query sugli snapshots senza valid_to

Interrogare uno snapshot con WHERE is_current = true restituisce lo stato attuale. Ma per analisi storiche, devi usare il range di validità:

SELECT customer_id, plan
FROM {{ ref('customer_subscriptions_snapshot') }}
WHERE '2024-03-15'::date >= dbt_valid_from
  AND ('2024-03-15'::date < dbt_valid_to OR dbt_valid_to IS NULL);

Errore 4: Snapshots eseguiti troppo raramente

Se esegui gli snapshots una volta al giorno, perdi i cambiamenti intra-day. Se un cliente cambia piano due volte nello stesso giorno, lo snapshot intermedio non viene registrato. La frequenza deve essere allineata alla finestra di cambiamento dei dati (per dati finanziari: ogni ora; per dati anagrafici: una volta al giorno può bastare).

Laboratorio pratico

Crea uno snapshot per una tabella product_prices che cambia ogni volta che il team commerciale aggiorna un prezzo. La tabella ha product_id, price, currency, updated_at, updated_by.

Task: Implementa lo snapshot. Poi scrivi una query che, per ogni prodotto, mostra la sequenza di cambi di prezzo con data, prezzo vecchio, prezzo nuovo e differenza percentuale.

Suggerimento: usa LAG sulla tabella snapshot per ottenere il prezzo precedente.

---

Riferimenti:

• Kimball, R. & Ross, M. (2013). The Data Warehouse Toolkit, 3rd ed. Wiley. Capitolo 5: “Slowly Changing Dimensions.”
• dbt Labs. (2024). “Snapshots.” dbt Documentation.
• Monzo. (2022). “How We Use dbt at Monzo.” Monzo Engineering Blog.

Controllo di qualità

Prima di usare snapshot e gestione del cambiamento lento in una decisione, controlla sempre completezza, duplicati, timezone, definizioni cambiate e segmenti esclusi. Molte analisi apparentemente sofisticate falliscono perché il dato di partenza misura un comportamento diverso da quello che il team crede di osservare.

Interpretazione per segmenti

La media aggregata è solo il punto di partenza. Segmenta per canale, coorte, piano, paese, device e maturità dell’utente. Se due segmenti si muovono in direzioni opposte, la media non rappresenta nessuno dei due e può portare a una decisione sbagliata.

Problema reale

Nel dominio di analytics engineering, Snapshot e gestione del cambiamento lento serve a risolvere questo problema: trasformare dati grezzi in modelli testati, documentati e riusabili dal business. La lezione non va trattata come teoria isolata, ma come un modo per migliorare una scelta concreta con dati, assunzioni esplicite e controlli minimi.

Obiettivo operativo: Comprendere il problema analitico e il contesto decisionale; Applicare esempi, metriche e controlli a casi reali. Se alla fine non sai indicare quale decisione cambia, quale dato osservi e quale errore vuoi evitare, la lezione non è ancora diventata competenza applicata.

Modello concettuale

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

Il modello concettuale è intenzionalmente semplice: decisione, dato, controllo, azione. Ogni approfondimento tecnico deve rafforzare almeno uno di questi quattro punti.

Formalizzazione rigorosa

Per rendere Snapshot e gestione del cambiamento lento analizzabile, definisci prima l’unità di lavoro: source, model, test, mart, metrica o esposizione. Poi collega questa unità a una metrica osservabile: freshness, lineage, test coverage, costo modello e fiducia stakeholder. Infine dichiara la decisione attesa: modello dbt, semantic layer, contratto, test o pipeline di release.

Elemento	Specifica richiesta
Unità di analisi	source, model, test, mart, metrica o esposizione
Segnale principale	freshness, lineage, test coverage, costo modello e fiducia stakeholder
Baseline	Periodo precedente, gruppo comparabile, benchmark o scenario controfattuale
Decisione	modello dbt, semantic layer, contratto, test o pipeline di release
Rischio	Scambiare un numero disponibile per una prova sufficiente

La formalizzazione e solida quando un altro analista può riprodurre la logica, criticare le assunzioni e ottenere la stessa decisione partendo dagli stessi dati.

Esempio o caso studio

Un cliente era nel piano Pro quando ha fatto upgrade, ma oggi è Enterprise e il CRM mostra solo lo stato attuale. Lo snapshot permette di ricostruire il segmento corretto al momento dell’evento, evitando di attribuire decisioni passate a condizioni future.

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

Lab / esercizio

Livello base

Scrivi una scheda di una pagina per Snapshot e gestione del cambiamento lento: decisione da supportare, metrica primaria, baseline, rischio principale e azione se il segnale e confermato.

Livello intermedio

Costruisci una tabella con tre segmenti, periodi o scenari. Per ciascuno indica cosa cambia, quale spiegazione alternativa e plausibile e quale controllo useresti prima di raccomandare un azione.

Livello research-grade

Prepara un decision memo: ipotesi, dati richiesti, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio dopo la decisione.

Dataset e materiali consigliati

Usa dbt, warehouse, sorgenti CRM, eventi, marts, semantic layer e lineage. Se non hai accesso a dati reali, crea un dataset sintetico con almeno 200 righe, una dimensione temporale, una dimensione segmento e una metrica di outcome.

Errore tipico da evitare

L’errore più comune e usare Snapshot e gestione del cambiamento lento come etichetta invece che come processo. Succede quando il team mostra un grafico senza decisione, una metrica senza baseline, o una conclusione senza indicare quale assunzione potrebbe invalidarla.

La domanda di controllo è: se questo risultato fosse instabile, quale scelta sbaglierei? Se la risposta non è concreta, manca ancora il collegamento tra analisi e azione.

Quiz o checkpoint

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 operativo

Snapshot e gestione del cambiamento lento diventa utile quando produce una decisione più chiara, non quando aggiunge terminologia. Usa il framework problema, modello, formalizzazione, esempio, lab e checkpoint per trasformare la lezione in pratica verificabile. Categoria: Decisione. Difficoltà: advanced. Tempo stimato: 18 min.