Advanced lab: professional queries on real cases

FashionHub è un retailer con 85 negozi in Italia e un e-commerce. Il CMO vuole capire quali canali marketing generano vero revenue incrementale, il team prodotto vuole confrontare il valore dei clienti omnicanale con quelli single channel, e il CFO chiede di riconciliare il revenue tra Shopify e il data warehouse, dove restano discrepanze dell’1.8%. I dati non sono pronti all’uso. Vanno puliti, riconciliati e interpretati prima che possano sostenere una decisione.

Dal numero alla decisione

Con SQL avanzato non basta scrivere query che producono numeri. Serve un processo che trasformi dati grezzi in decisioni affidabili, e che lasci esplicite le assunzioni, i controlli applicati e i rischi rimasti aperti. Questo lab segue un flusso che assomiglia al lavoro reale, in cui ogni passaggio riduce un po’ di incertezza e aggiunge un po’ di credibilità a quello che porterai in riunione.

Come impostare l’analisi

Quattro domande tengono insieme l’analisi e la rendono difendibile. Quale scelta reale stai cercando di migliorare, quale segnale osservi per misurarla, quale baseline rende quel segnale interpretabile e cosa cambia concretamente dopo che hai finito.

Phase	What to clarify	Output
Question	Quale scelta reale migliorare?	Decision to make
Measure	Quale segnale osservare?	Metrica o dato
Control	Quale baseline rende interpretabile?	Credible comparison
Action	Cosa cambia dopo l’analisi?	Next operational step

Lo schema è semplice di proposito. Serve a evitare che l’analisi resti un esercizio fine a sé stesso e diventi invece uno strumento per decidere.

Definire le unità di lavoro

Prima di toccare il SQL conviene fissare quattro cose. L’unità di analisi, cioè se ragioni per riga, per coorte o per finestra temporale. Il segnale principale, che può riguardare la correttezza, i duplicati o la performance. La baseline, di solito il periodo precedente o un gruppo comparabile. E la decisione attesa, che sia una query, un modello o un test. Senza questo passaggio l’analisi resta ambigua e nessun altro riesce a riprodurla.

Element	Specifica
Unit of analysis	riga, partizione, coorte, metrica temporale
Signal	correttezza, duplicati, stabilità
Baseline	periodo precedente, benchmark
Decision	query, modello, test
Risk	confondere un numero con una prova

Cosa copre il lab

Il lab mette insieme deduplica, retention, attribution, segmentazione e riconciliazione su dataset reali. L’obiettivo non è la query più corta, ma codice leggibile, testabile e che puoi difendere davanti a chi prende la decisione. La deduplica delle transazioni, per fare un esempio, rimuove i duplicati tenendo solo la riga più recente con status “completed”.

La tabella sotto raccoglie tre situazioni tipiche e come leggerle senza saltare a conclusioni affrettate.

Evidence	Cautious interpretation	Recommended action
Numero migliora	Potrebbe essere variazione normale	Cercare segmenti e confronti
Segmento cambia	Media aggregata nasconde differenze	Separare coorti o casi
Costo cresce	Impatto va letto sul margine	Stimare trade-off

Esercitarsi a tre livelli

Puoi lavorare su questo materiale a profondità diverse a seconda del tempo che hai.

Per cominciare, descrivi in una pagina la decisione da supportare, la metrica primaria, la baseline, il rischio e l’azione che intraprenderesti se il segnale fosse confermato.

A un livello intermedio, costruisci una tabella con i segmenti o gli scenari rilevanti, indicando per ciascuno cosa cambia, quali spiegazioni alternative sono plausibili e quali controlli servono prima di concludere.

Se vuoi spingerti oltre, prepara un decision memo completo: ipotesi, dati, criteri di esclusione, controlli, soglia decisionale, rischi residui e piano di monitoraggio. Per qualsiasi livello, usa dati reali o sintetici con almeno 200 righe, una dimensione temporale, dei segmenti e una metrica di outcome.

L’errore da evitare

Il rischio più comune è presentare grafici o metriche senza collegarli a una decisione concreta, senza una baseline o senza dichiarare i rischi. La domanda di controllo che conviene tenere sempre in mente è semplice: se il risultato fosse instabile, quale scelta sbaglierei? Se non sai rispondere, l’analisi non è ancora pronta per la riunione.

Vale la pena verificare di aver chiuso il cerchio. Quale decisione concreta migliora grazie a questo lavoro, quale unità di analisi rende il problema misurabile, quale baseline evita letture ingenue, quale errore potrebbe ribaltare la conclusione e quale output consegneresti a uno stakeholder non tecnico.

Operational Summary

Questo lab serve a qualcosa solo se produce decisioni più chiare, non se aggiunge termini o numeri. Il percorso che va dal problema al modello, dalla formalizzazione all’esempio fino agli esercizi e al controllo finale, trasforma la lezione in pratica verificabile.

---

Caso studio: FashionHub

FashionHub ha tre richieste sul tavolo. Il CMO vuole il revenue incrementale per canale marketing, non quello solo attribuito. Il team prodotto vuole confrontare l’LTV dei clienti omnicanale con quello dei clienti single channel. Il CFO chiede la riconciliazione del revenue tra Shopify e il data warehouse.

Per lavorarci hai quattro tabelle principali: customers, transactions, marketing_touchpoints, shopify_settlements.

Pulizia e preparazione

Identifica le transazioni duplicate e conserva solo la più recente con status “completed”. Cerca poi i giorni senza dati marketing, perché segnalano probabili problemi di tracking che falserebbero ogni analisi a valle.

Analisi di coorte per canale marketing

Assegna ogni cliente al canale del primo touchpoint, poi calcola retention e revenue cumulativo a 1, 3, 6 e 12 mesi. Confronta l’LTV tra canali riportando gli intervalli di confidenza, così la differenza non viene letta come certa quando non lo è.

Segmentazione omnicanale e single channel

Etichetta come omnicanale i clienti con transazioni su più canali negli ultimi 12 mesi. Confronta le metriche chiave tra i due gruppi e verifica la significatività statistica della differenza. Costruisci infine un funnel di migrazione con una curva di Kaplan-Meier.

Riconciliazione del revenue

Confronta mese per mese il revenue del data warehouse con quello di Shopify. Segmenta per giorno e per giorno della settimana per capire dove nascono le discrepanze, e usa un anti-join per individuare le transazioni mancanti da una delle due fonti.

Raccomandazione finale

Sintetizza insight, raccomandazioni con impatto stimato e rischi in una tabella che riporti anche la query di evidenza per ciascun punto, pronta da consegnare al CMO.

Delivery

Crea le view SQL in uno schema analytics_fashionhub, con nomi chiari e commenti, eseguibili in sequenza per ricostruire l’intera pipeline analitica.

---

References: Kimball & Ross (2013), Amazon Retail Analytics Documentation (2023).