Che cos’è davvero l’analytics engineering

Prima di parlare di dbt, layer e test, conviene capire che problema risolve davvero l’analytics engineering e perché è nata proprio adesso. È la porta d’ingresso del modulo: una disciplina che trasforma dati grezzi in dataset analitici versionati, testati e documentati, così che tutta l’azienda possa riusarli con fiducia. Se ti sei mai chiesto perché due dashboard dicono cose diverse, qui trovi la risposta.

L’idea in una frase

L’analytics engineering trasforma dati grezzi in dataset analitici versionati, testati e documentati che tutta l’azienda può riusare con fiducia.

La sequenza in cinque passi

1. Individua la decisione di business che i dati devono migliorare e il proprietario di quella decisione.
2. Porta le sorgenti nel warehouse con caricamento EL e senza logica di business nel caricamento.
3. Trasforma con dbt in staging, intermediate e marts con test e documentazione dal codice.
4. Esponi metriche condivise con definizioni uniche e lineage tracciabile fino alle sorgenti.
5. Misura freshness, copertura dei test e adozione dei modelli prima di dichiarare successo.

Cosa fa un analytics engineer

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. Non è una query isolata, ma un modulo software che produce dati. Il secondo è la modellazione semantica: un livello condiviso con definizioni di metriche, dimensioni conformate e logica centralizzata, usato da tutta l’azienda. Il terzo è la governance applicata: la documentazione nasce dal codice con dbt docs, il lineage è automatico e i test bloccano le pull request quando i dati sono corrotti.

Il modello a T: da ELT a dataset analitici

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.

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

Il burnout di chi sistema dati sporchi invece di analizzarli è una causa principale di turnover. L’analytics engineering sposta il lavoro ripetitivo dentro processi automatizzati e libera gli analyst per attività a maggior valore.

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 di completezza, unicità e valori ammessi sulle colonne critiche. Documentare dal codice, cioè tenere la documentazione nel file YAML del modello, sempre aggiornata.

Errori da evitare

L’errore tipico è usare l’analytics engineering come etichetta invece che come processo: un grafico senza decisione, una metrica senza baseline e una conclusione che non dichiara le assunzioni critiche. Prima di decidere sui dati verifica completezza, duplicati, timezone, definizioni e segmenti esclusi. Non fidarti della sola media aggregata: segmenta per canale, coorte, piano, paese, device e maturità utente, perché segmenti in direzioni opposte rendono la media inutile.

Verdetto: il modello a T con definizioni uniche e test automatici batte i silos di query sparse ogni volta che una metrica deve valere per tutta l’azienda.

Un esempio che ha fatto scuola

Atlassian migra nel 2020 da Airflow e script SQL sparsi a dbt. Prima della migrazione conta 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 arriva a 180 modelli dbt organizzati in staging, intermediate e marts, con 1200 test automatici e una pipeline CI/CD su GitHub Actions che testa ogni pull request. A dodici mesi gli incidenti da dati errati scendono 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 crescono del 140 per cento.

Domande per verificare la comprensione

1. Quale decisione aziendale migliora quando una metrica ha una sola definizione condivisa?
2. Dove vive la logica di business nel modello a T e chi la mantiene?
3. Quali tre test minimi applichi a ogni modello prima di fidarti dei suoi numeri?
4. Come verifichi che una dashboard mostri dati freschi e tracciabili fino alle sorgenti?