Progetto finale: un mini analytics stack completo

Un progetto finale di analytics engineering deve collegare sorgenti grezze, modelli staging, marts, test, documentazione e un output usabile da stakeholder reali. Progetto finale: un mini analytics stack completo mette insieme tutto il modulo in una consegna che dimostra affidabilità, non solo abilità tecnica.

Una scena da cui partire

Leggi il progetto come una prova di produzione: ogni modello deve avere una ragione, ogni test deve proteggere un rischio e ogni mart deve rispondere a una domanda business senza richiedere spiegazioni laterali.

• Contesto: Quale contesto rende il caso difficile?
• Metodo: Quale evidenza cambia davvero la decisione?
• Applicazione: Quale lezione resta valida fuori dal caso specifico?

Il contesto: StyleShop

StyleShop è un e-commerce di moda con 50 dipendenti. I dati provengono da tre fonti:

1. Shopify (e-commerce): ordini, clienti, prodotti
2. Google Analytics 4 (web analytics): sessioni, eventi, conversioni
3. Facebook Ads (marketing): campagne, spesa, conversioni

Queste fonti sono già state caricate in Snowflake (o BigQuery a scelta) tramite Fivetran. I dati grezzi sono in uno schema raw_data, con tabelle come:

• raw_data.shopify.orders, raw_data.shopify.customers
• raw_data.ga4.events, raw_data.ga4.sessions
• raw_data.facebook_ads.campaigns, raw_data.facebook_ads.ad_performance

Il tuo compito è costruire l’intero pipeline di trasformazione con dbt.

Fase 1: Setup del progetto (30 min)

Task 1.1 — Inizializza il progetto:

dbt init styleshop_analytics
cd styleshop_analytics

Task 1.2 — Configura profiles.yml per il tuo warehouse:

styleshop_analytics:
  outputs:
    dev:
      type: snowflake  # o bigquery
      account: "{{ env_var('SNOWFLAKE_ACCOUNT') }}"
      user: "{{ env_var('SNOWFLAKE_USER') }}"
      schema: dbt_dev
      ...
  target: dev

Task 1.3 — Definisci le sources nel file YAML:

# models/staging/shopify/src_shopify.yml
sources:
  - name: shopify
    database: raw_data
    schema: shopify
    tables:
      - name: orders
      - name: customers
      - name: products

Fase 2: Staging Layer (1 ora)

Crea un modello staging per ogni tabella sorgente. Ricorda: 1:1, solo pulizia e cast.

Esempio: stg_shopify__orders.sql

WITH source AS (
    SELECT * FROM {{ source('shopify', 'orders') }}
),
renamed AS (
    SELECT
        id AS order_id,
        customer_id,
        CAST(total_price AS NUMERIC(10,2)) AS total_amount_eur,
        CAST(created_at AS TIMESTAMP) AS order_date,
        financial_status,
        fulfillment_status,
        test
    FROM source
)
SELECT * FROM renamed
WHERE test = FALSE  -- unico filtro, tecnico non business

Crea staging per tutte e 9 le tabelle sorgente (3 per fonte × ~3 tabelle).

Fase 3: Intermediate Layer (1.5 ore)

Costruisci modelli intermediate con la logica di business condivisa.

int_order_attribution.sql — attribuisce ogni ordine al canale del primo touchpoint:

WITH first_touches AS (
    SELECT
        customer_id,
        FIRST_VALUE(channel) OVER (
            PARTITION BY customer_id ORDER BY session_date
            ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING
        ) AS acquisition_channel,
        FIRST_VALUE(campaign_id) OVER (
            PARTITION BY customer_id ORDER BY session_date
        ) AS acquisition_campaign,
        MIN(session_date) AS first_touch_date
    FROM {{ ref('stg_ga4__sessions') }}
    WHERE channel IS NOT NULL
)
SELECT
    o.order_id,
    o.customer_id,
    o.total_amount_eur,
    o.order_date,
    ft.acquisition_channel,
    ft.acquisition_campaign,
    ft.first_touch_date,
    CASE
        WHEN o.order_date < ft.first_touch_date + INTERVAL '30 days'
        THEN 'new_customer'
        ELSE 'returning_customer'
    END AS customer_type
FROM {{ ref('stg_shopify__orders') }} o
LEFT JOIN first_touches ft ON o.customer_id = ft.customer_id

int_daily_metrics.sql — metriche giornaliere per tutte le analisi downstream:

SELECT
    DATE(o.order_date) AS metric_date,
    o.acquisition_channel,
    COUNT(DISTINCT o.order_id) AS total_orders,
    SUM(o.total_amount_eur) AS total_revenue,
    COUNT(DISTINCT o.customer_id) AS unique_customers,
    SUM(CASE WHEN o.customer_type = 'new_customer' THEN 1 ELSE 0 END) AS new_customer_orders
FROM {{ ref('int_order_attribution') }} o
GROUP BY DATE(o.order_date), o.acquisition_channel

Fase 4: Marts Layer (1 ora)

Crea i dataset pronti per il consumo.

mrt_marketing__channel_performance.sql:

SELECT
    DATE_TRUNC('month', metric_date) AS month,
    acquisition_channel,
    SUM(total_revenue) AS monthly_revenue,
    SUM(total_orders) AS monthly_orders,
    AVG(total_revenue / NULLIF(total_orders, 0)) AS avg_order_value,
    SUM(new_customer_orders) AS new_customer_orders,
    -- Join con spesa marketing per calcolare ROAS
    COALESCE(SUM(fb.spend), 0) AS ad_spend,
    CASE
        WHEN COALESCE(SUM(fb.spend), 0) > 0
        THEN SUM(total_revenue) / SUM(fb.spend)
        ELSE NULL
    END AS roas
FROM {{ ref('int_daily_metrics') }} dm
LEFT JOIN {{ ref('stg_facebook_ads__ad_performance') }} fb
    ON dm.acquisition_channel = 'facebook_ads'
    AND dm.metric_date = DATE(fb.date)
GROUP BY DATE_TRUNC('month', metric_date), acquisition_channel

mrt_product__order_details.sql: Dataset piatto per il team prodotto, con ogni ordine arricchito con dati cliente e prodotto.

Fase 5: Test e documentazione (45 min)

Aggiungi test a ogni modello:

# models/marts/marketing/mrt_marketing.yml
models:
  - name: mrt_marketing__channel_performance
    columns:
      - name: month
        tests:
          - not_null
      - name: acquisition_channel
        tests:
          - not_null
      - name: monthly_revenue
        tests:
          - not_null

Genera documentazione:

dbt docs generate
dbt docs serve  # esplora il lineage graph

Fase 6: CI/CD (30 min)

Configura GitHub Actions:

# .github/workflows/dbt_ci.yml
name: dbt CI
on: [pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: pip install dbt-snowflake
      - run: |
          dbt deps
          dbt build --select state:modified+ --target ci

Fase 7: Semantic Layer (30 min, opzionale avanzato)

Definisci le metriche core:

metrics:
  - name: total_revenue
    label: "Total Revenue"
    type: simple
    type_params:
      measure: total_revenue
  - name: roas
    label: "Return on Ad Spend"
    type: derived
    type_params:
      expr: total_revenue / ad_spend
      metrics:
        - name: total_revenue
        - name: ad_spend

Consegna

Il progetto completo deve includere:

• 9 modelli staging con source YAML
• 3-5 modelli intermediate con logica di business
• 4-6 modelli marts per dominio
• Test not_null e unique su ogni primary key
• PR template con checklist di review
• CI/CD configurato con GitHub Actions
• dbt docs generato
• (Opzionale) metriche nel semantic layer

---

Criteri di valutazione:

• Il build dbt build è verde senza errori
• Il lineage graph è connesso e senza cicli
• Ogni modello ha un nome che rivela layer e dominio
• Un collega può capire l’architettura in 10 minuti leggendo i nomi dei modelli e la documentazione

Problema reale

Nel dominio di analytics engineering, ‘Progetto finale: un mini analytics stack completo’ 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 ‘Progetto finale: un mini analytics stack completo’ 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

Il mini stack parte da sorgenti orders, customers ed events, costruisce staging puliti, mart revenue e retention, test di unicità e freshness, più una exposure per il dashboard finale. Il caso è completo solo se un altro analyst può eseguire il progetto e capire perché ogni modello esiste.

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 ‘Progetto finale: un mini analytics stack completo’: 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 ‘Progetto finale: un mini analytics stack completo’ 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

‘Progetto finale: un mini analytics stack completo’ 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: Lab. Difficoltà: advanced. Tempo stimato: 28 min.

Approfondimento di pratica

Per consolidare ‘Progetto finale: un mini analytics stack completo’, trattala come una piccola prova di lavoro dentro un progetto dbt o semantic layer in cui una metrica deve diventare affidabile per altri team. Non basta dire di aver capito la lezione: devi produrre un modello dati testato, documentato e accompagnato da ownership chiara. Questo passaggio serve a rendere la conoscenza trasferibile, perché obbliga a separare contesto, misura, azione e limite.

Esempio operativo

Parti da una domanda semplice: quale scelta diventerebbe migliore se applicassi bene questa lezione? Nel modulo analytics engineering, la risposta deve sempre collegare un problema reale a un output osservabile. Se stai studiando una lezione di tipo Lab, costruisci un esempio con tre righe: il contesto in cui nasce la domanda, il dato o il modello che useresti per leggerla, e la decisione che prenderesti dopo aver controllato i rischi.

Un esempio valido non deve essere grande. Può essere una tabella con una baseline e due segmenti, una query che verifica una definizione, un disegno di esperimento, un controllo su un modello o un memo di dieci righe. La qualità non dipende dalla complessità tecnica, ma dalla tracciabilità del ragionamento: chi legge deve capire perché hai scelto quella metrica, quale alternativa hai scartato e quale evidenza ti farebbe cambiare idea.

Checkpoint di lavoro

• Scrivi la decisione che questa lezione dovrebbe migliorare, usando un verbo operativo: allocare, fermare, correggere, lanciare, misurare, priorizzare o investigare.
• Definisci il segnale principale e almeno un guardrail. Il segnale dice dove guardi; il guardrail evita che una scelta localmente buona rovini il sistema.
• Aggiungi una baseline. Senza baseline non sai se il numero e alto, basso, stabile, anomalo o solo raccontato male.
• Esplicita il rischio più probabile: trasformare dati instabili in una tabella elegante ma non governabile. Scrivilo prima della raccomandazione, non dopo.
• Chiudi con un output consegnabile: dashboard, query, schema, memo, esperimento, notebook o checklist. Deve essere qualcosa che un reviewer possa aprire e criticare.

Riepilogo di padronanza

Hai davvero assimilato ‘Progetto finale: un mini analytics stack completo’ quando riesci a usarla in tre modi: spiegare il concetto senza gergo inutile, applicarlo a un caso piccolo ma realistico, e difendere una raccomandazione includendo limiti e prossimi controlli. Se manca uno di questi tre elementi, torna al modello concettuale e riduci l’ambizione dell’esempio. Meglio una prova piccola ma rigorosa di un grande progetto che non rende verificabile la decisione.