What Analytics Engineering Really Is

Tra il data engineering e la business analytics si colloca un ruolo decisivo ma spesso invisibile: trasformare dati grezzi in modelli affidabili, documentati e riusabili. L’analytics engineering non è scrivere query o costruire dashboard, è produrre dati con qualità tecnica su cui un’azienda può basare le proprie decisioni con fiducia. Questa lezione apre il modulo e fa da mappa al mestiere.

Da dove partire

L’indice del corso è una mappa del mestiere: ogni lezione è un anello della catena che porta da sorgenti instabili a metriche condivise e utilizzabili da più team. Tre domande aiutano a entrare nel tema. La prima riguarda il contesto, cioè quale decisione rende utile il concetto. La seconda riguarda il metodo, cioè quale conflitto tra team o tra metriche conviene anticipare. La terza riguarda l’applicazione, cioè come spiegheresti il concetto in una riunione.

What an Analytics Engineer Does

L’analytics engineer è il ponte tra data engineer e data analyst. Il data engineer costruisce pipeline e infrastrutture, il data analyst risponde a domande di business, e nel mezzo l’analytics engineer trasforma dati grezzi in dataset analitici puliti, testati e documentati. Il suo lavoro garantisce che un termine come “revenue” significhi la stessa cosa in marketing, prodotto e finance.

Il ruolo, formalizzato da dbt Labs intorno al 2018, poggia su tre pilastri. Il primo è la trasformazione software-engineered: il codice SQL e Jinja segue pratiche ingegneristiche come version control, code review, test automatizzati e CI/CD, e quindi non è una query ma un modulo software che produce dati. Il secondo è la modellazione semantica: si costruisce un livello semantico condiviso, con definizioni di metriche, dimensioni conformate e logica di business centralizzata, usato da tutta l’azienda. Il terzo è la governance applicata: la documentazione è generata dal codice con dbt docs, il lineage è automatico e i test bloccano le pull request quando i dati sono corrotti.

The T model: from ELT to analytical datasets

L’architettura moderna, chiamata modello a T, supera il vecchio approccio 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 tabelle sorgente, pulizia minima │ ├───────────────────┤ │ │ │ Intermediate Layer│ │ ← JOIN, aggregazioni, logica di business │ ├───────────────────┤ │ │ │ Marts Layer │ │ ← Dataset pronti per analisi per team o dominio │ └───────────────────┘ │ └────────────┬────────────┘ │ SQL, BI tools ▼ ┌─────────────────────────┐ │ Analysts, BI, ML │ └─────────────────────────┘

Il modello elimina la duplicazione delle logiche, come il calcolo del revenue, che altrimenti ogni analyst riscriverebbe per conto proprio. L’analytics engineer scrive, testa e mantiene un modello unico che usano tutti.

Perché ha senso economico

Un sondaggio di dbt Labs su 450 aziende nel 2023 mostra risultati medi rilevanti.

Metric	Before	After	Delta
Time to answer a business question	3.2 days	4.1 hours	-87%
Definizioni metriche duplicate	7.3	1.4	-81%
Errori dati scoperti dagli stakeholder	2.1/week	0.3/week	-86%
Data analysts wanting to change company (burnout)	34% annually	12% annually	-65%

Il burnout di chi passa il tempo a sistemare dati sporchi invece di analizzarli è una delle cause principali di turnover. L’analytics engineering sposta il lavoro ripetitivo dentro processi automatizzati e libera gli analyst per attività a maggior valore.

Real case: Atlassian and the migration to dbt

Atlassian è migrata nel 2020 da Airflow e script SQL sparsi a dbt. Prima della migrazione aveva oltre 400 modelli mantenuti da 3 persone senza test, deploy manuali con downtime e definizioni di “Monthly Active Users” incoerenti tra i team. Dopo sei mesi era arrivata a 180 modelli dbt organizzati in staging, intermediate e marts, con 1.200 test automatici e una pipeline CI/CD su GitHub Actions che testava ogni PR. A dodici mesi gli incidenti da dati errati erano scesi da 11 a 0.5 al mese, l’onboarding di un nuovo analyst da 6 settimane a 2, e i contributi di modelli da parte di team non-data erano cresciuti del 140 per cento.

L’analytics engineer è una mentalità

Non serve un titolo per applicare queste pratiche, servono tre comportamenti. Scrivere codice e non query, cioè tenere la logica SQL in file versionati, commentati e testati. Testare prima di fidarsi, cioè dare a ogni modello test not_null, unique e accepted_values sulle colonne critiche. Documentare dal codice, cioè tenere la documentazione nel file YAML del modello, sempre aggiornata.

Il problema reale e il modello di lavoro

L’analytics engineering risolve il problema di trasformare dati grezzi in modelli testati, documentati e riusabili dal business. Non è teoria astratta, è un processo per migliorare decisioni concrete con dati, assunzioni esplicite e controlli. Se non sai quale decisione cambia, quale dato osservi e quale errore vuoi evitare, la competenza non è ancora acquisita.

Il modello di lavoro è semplice e gira attorno a quattro fasi.

Phase	What to clarify	Output
Question	Quale scelta reale migliorare?	Decision to make
Measure	Quale segnale rappresenta il problema?	Metric or source data
Control	Which baseline makes the result interpretable?	Credible comparison
Action	Cosa cambia dopo l’analisi?	Next operational step

Decisione, dato, controllo, azione: ogni approfondimento tecnico dovrebbe rafforzare almeno una di queste fasi.

Come impostare l’analisi

Per analizzare l’analytics engineering conviene definire l’unità di lavoro (source, model, test, mart, metrica, esposizione), collegarla a una metrica osservabile (freshness, lineage, coverage, costo, fiducia) e dichiarare la decisione attesa (modello dbt, semantic layer, contratto, test, pipeline).

Element	Specifica
Unit of analysis	source, model, test, mart, metrica, esposizione
Primary signal	freshness, lineage, test coverage, costo modello, fiducia stakeholder
Baseline	periodo precedente, gruppo comparabile, benchmark, scenario controfattuale
Decision	modello dbt, semantic layer, contratto, test, pipeline di release
Risk	scambiare un numero disponibile per prova sufficiente

Impostata così, l’analisi è solida quando un altro analista può riprodurre la logica, criticare le assunzioni e arrivare alla stessa decisione.

Esempio e caso studio

Pensa a un’azienda con data engineer e analyst ma senza qualità condivisa nelle trasformazioni. L’analytics engineering nasce proprio lì, per creare modelli riusabili, testati, documentati e stabili.

Observed evidence	Cautious interpretation	Recommended action
The number improves	Could be a real effect or normal variation	Cercare confronto e segmentazione
One segment changes more than others	La media nasconde differenze	Separate cohorts or use cases
Il costo cresce con il risultato	Impact must be read on the margin	Estimate trade-offs and sustainability

Lab ed esercizio

Al livello base, scrivi una scheda sintetica per l’analytics engineering: decisione da supportare, metrica primaria, baseline, rischio e azione se il segnale è confermato.

Al livello intermedio, costruisci una tabella con tre segmenti o scenari, indicando cosa cambia, le spiegazioni alternative e i controlli da fare prima di raccomandare un’azione.

Al livello research-grade, prepara un decision memo con ipotesi, dati, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio. Usa dbt, warehouse, CRM, eventi, marts, semantic layer e lineage. Senza dati reali, genera un dataset sintetico con almeno 200 righe, una dimensione temporale, un segmento e una metrica di outcome.

Errori da evitare e controlli prima di decidere

L’errore tipico è usare l’analytics engineering come etichetta invece che come processo. Succede quando si mostra un grafico senza decisione, una metrica senza baseline o una conclusione che non dichiara le assunzioni critiche. La domanda di controllo è: se il risultato fosse instabile, quale scelta sbaglierei? Se la risposta non è concreta, manca il collegamento tra analisi e azione.

Prima di decidere sui dati verifica completezza, duplicati, timezone, definizioni e segmenti esclusi, perché molte analisi falliscono quando il dato osservato non rappresenta il comportamento atteso. E non fidarti della sola media aggregata: segmenta per canale, coorte, piano, paese, device e maturità utente, perché segmenti che si muovono in direzioni opposte rendono la media inutile.

Quiz e checkpoint

1. Quale decisione concreta migliora questa lezione?
2. Which unit of analysis makes the problem measurable?
3. Quale baseline useresti per evitare letture ingenue?
4. Which typical mistake could change the conclusion?
5. Which output would you deliver to a non-technical stakeholder?

Operational Summary

L’analytics engineering è utile quando produce decisioni più chiare, non quando aggiunge terminologia. Il percorso passa da sorgenti instabili a metriche condivise grazie a modelli versionati, testati e documentati, dove la logica di business vive in un solo posto e il lineage racconta da dove arriva ogni numero. Usa il giro problema, modello, formalizzazione, esempio, lab e checkpoint per trasformare la lezione in pratica verificabile.