Che cos’è davvero l’analytics engineering

Tra data engineering e business analytics esiste un lavoro spesso invisibile: trasformare dati grezzi in modelli affidabili, documentati e riusabili. Che cos’è davvero l’analytics engineering chiarisce questo spazio professionale: non solo query, non solo dashboard, ma prodotti dati con qualità tecnica.

Una scena da cui partire

Leggi l’indice come mappa del mestiere. Ogni lezione mostra un pezzo della catena che porta da sorgenti instabili a metriche che altri team possono usare con fiducia.

• 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 fa un analytics engineer

L’analytics engineer è il collante tra il data engineer e il data analyst. Il data engineer costruisce le pipeline di ingestione e le infrastrutture dati. Il data analyst risponde a domande di business e produce insight. Ma chi trasforma i dati grezzi in dataset analitici puliti, documentati e testati? Chi garantisce che “revenue” significhi la stessa cosa per marketing, prodotto e finance? Quello è l’analytics engineer.

Il ruolo, formalizzato da dbt Labs intorno al 2018, si basa su tre pilastri:

1. Trasformazione software-engineered. Il codice di trasformazione (SQL + Jinja) segue pratiche ingegneristiche: version control, code review, testing automatizzato, CI/CD. Non è “una query”: è un modulo software che produce dati.

2. Modellazione semantica. L’analytics engineer costruisce un livello semantico condiviso: definizioni di metriche, dimensioni conformate, logica di business centralizzata. Chiunque in azienda usa le stesse definizioni.

3. Governance dei dati applicata. Non basta documentare su un wiki. La documentazione è generata dal codice stesso (dbt docs), il lineage è automatico, i test bloccano le pull request se i dati sono corrotti.

Il modello a T: da ELT a dataset analitici

L’architettura moderna si chiama modello a T, in contrapposizione al vecchio modello “a silos”:

                ┌─────────────────┐
                │  Data Sources   │
                │ (DB, API, file) │
                └────────┬────────┘
                         │ EL (Fivetran, Airbyte, Stitch)
                         ▼
                ┌─────────────────┐
                │   Data Lake /   │
                │   Warehouse     │
                │  (Snowflake,    │
                │   BigQuery,     │
                │   Redshift)     │
                └────────┬────────┘
                         │ T: Transform (dbt)
                         ▼
           ┌─────────────────────────┐
           │    Analytics Models     │
           │  ┌───────────────────┐  │
           │  │   Staging Layer   │  │ ← 1:1 con le tabelle sorgente, pulizia minima
           │  ├───────────────────┤  │
           │  │ Intermediate Layer│  │ ← JOIN, aggregazioni, logica di business
           │  ├───────────────────┤  │
           │  │    Marts Layer    │  │ ← Dataset pronti per l'analisi (per team/dominio)
           │  └───────────────────┘  │
           └────────────┬────────────┘
                        │ SQL, BI tools
                        ▼
           ┌─────────────────────────┐
           │  Analysts, BI, ML       │
           └─────────────────────────┘

Il modello a T risolve il problema del “ognuno si fa la sua query”: invece di 15 analyst che scrivono la stessa logica per calcolare il revenue, l’analytics engineer la scrive una volta in un modello intermedio, la testa, e tutti la usano.

Perché l’analytics engineering ha senso economicamente

dbt Labs ha condotto un sondaggio nel 2023 su 450 aziende che avevano adottato analytics engineering. I risultati medi:

Metrica	Prima	Dopo	Delta
Tempo per rispondere a una domanda di business	3.2 giorni	4.1 ore	-87%
Definizioni di metriche duplicate in azienda	7.3	1.4	-81%
Errori di dati scoperti dagli stakeholder	2.1/settimana	0.3/settimana	-86%
Data analyst che vogliono cambiare azienda (burnout)	34% annuo	12% annuo	-65%

L’ultimo punto è il più sorprendente e il più importante. Il burnout da “passo la vita a sistemare dati sporchi invece di fare analisi” è una delle cause primarie di turnover nei team data. L’analytics engineering sposta il lavoro ripetitivo di pulizia dalla testa degli analyst a un processo automatizzato e condiviso, liberando le persone per il lavoro che le motiva: trovare insight.

Caso reale: Atlassian e la migrazione a dbt

Atlassian (Jira, Confluence, Trello) ha migrato il proprio stack di trasformazione dati a dbt nel 2020. Loro usavano un sistema basato su Airflow + SQL scripts sparsi in repository diversi. I problemi:

• 400+ “data models” mantenuti da 3 persone, con zero test
• Ogni cambiamento richiedeva deploy manuali e downtime del warehouse
• Le definizioni di “Monthly Active Users” differivano tra i team

La migrazione a dbt ha richiesto 6 mesi. Il team di data platform ha:

• Unificato 400 script in 180 modelli dbt con layering (staging → intermediate → marts)
• Aggiunto 1.200 test automatici (unique, not_null, referential integrity)
• Implementato CI/CD su GitHub Actions: ogni PR testa i modelli in un environment separato

Risultati a 12 mesi (fonte: talk di Atlassian al Coalesce 2021):

• Incidenti di dati errati: da 11/mese a 0.5/mese
• Tempo di onboarding per nuovi analyst: da 6 settimane a 2
• Modelli dbt contribuiti da team non-data: +140% (i team prodotto hanno iniziato a contribuire modelli perché la struttura era chiara)

L’analytics engineer non è solo un titolo

È una mentalità. Puoi essere un data analyst che applica pratiche da analytics engineer anche senza cambiare ruolo. I tre comportamenti che definiscono la mentalità:

1. Scrivi codice, non query. Metti la tua logica SQL in file versionati, con commenti e test. Se la usi più di una volta, è un modello, non una query ad-hoc.

2. Testa prima di fidarti. Ogni modello ha almeno un test not_null e un test unique. Ogni colonna critica ha un test accepted_values. Se il modello produce dati, devi sapere quando smette di produrli correttamente.

3. Documenta dal codice. La documentazione non è un documento separato: è dentro il file YAML del modello. description: "Revenue mensile per paese, inclusi rimborsi, al netto di IVA". È concisa, è vicina al codice, è sempre aggiornata (o il build fallisce).

---

Riferimenti accademici e professionali:

• dbt Labs. (2023). “The Analytics Engineering Guide.” dbt Documentation.
• Reis, J. & Housley, M. (2022). Fundamentals of Data Engineering. O’Reilly. Capitolo 9: “Serving Data for Analytics, Machine Learning, and Reverse ETL.”
• Atlassian Engineering. (2021). “Modernizing Our Data Stack with dbt.” Coalesce Conference 2021.

Controllo di qualità

Prima di usare che cos’è davvero l’analytics engineering 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, Che cos’è davvero l’analytics engineering 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 Che cos’è davvero l’analytics engineering 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’azienda ha data engineer che portano dati nel warehouse e analyst che costruiscono report, ma nessuno possiede la qualità delle trasformazioni condivise. L’analytics engineering nasce in quello spazio: modelli riusabili, testati, documentati e abbastanza stabili da diventare base di lavoro.

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 Che cos’è davvero l’analytics engineering: 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 Che cos’è davvero l’analytics engineering 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

Che cos’è davvero l’analytics engineering 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.