JSON, array e semi-structured analytics

I dati che arrivano alle query analitiche non hanno più la forma ordinata della tabella relazionale classica. Un ordine porta dentro di sé un array di prodotti, un evento porta un oggetto di proprietà, una risposta API porta JSON annidato su più livelli. Lavorare con questo materiale è una scelta, non solo un esercizio di sintassi: decidi quale campo estrai, come interpreti i valori opzionali e a quale rischio ti esponi quando il formato cambia sotto i tuoi piedi.

Quando il dato non è una tabella

Le query analitiche raramente partono da tabelle pulite. Il formato è semi-strutturato: JSON, array, oggetti che contengono altri oggetti. Il problema concreto è scrivere query affidabili quando i campi sono opzionali, quando la granularità non è ovvia e quando la struttura non è garantita riga per riga. Qui la difficoltà non è tecnica in senso stretto. È capire quali dati usare, come leggerli e quali errori evitare prima di portare un numero davanti a una decisione.

Una mappa per orientarsi

Prima di estrarre qualunque campo serve fissare quattro punti, perché un valore staccato dal contesto non significa nulla.

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

È lo stesso ciclo che separa un dato grezzo da un insight su cui qualcuno può agire.

Definire l’unità di analisi

Con i dati semi-strutturati il primo passo è dichiarare l’unità di analisi. Può essere una riga, una partizione, una finestra temporale, un join o una coorte. Solo dopo scegli il segnale da osservare, che sia correttezza, performance, presenza di duplicati, granularità o stabilità del risultato. Infine fissi la baseline di confronto e la decisione che ti aspetti di prendere.

Elemento	Specifica richiesta
Unità di analisi	riga, partizione, finestra, join, coorte o metrica temporale
Segnale principale	correttezza, performance, duplicati, granularità e stabilità
Baseline	periodo precedente, gruppo comparabile, benchmark o scenario controfattuale
Decisione	query, modello intermedio, test SQL o pattern riusabile
Rischio	scambiare un numero disponibile per una prova sufficiente

Definito questo, l’analisi diventa riproducibile e le sue assunzioni restano discutibili invece di sparire dentro la query.

Esplodere un array di ordini

Considera un ordine Deliveroo che contiene un array di items. L’ordine è una riga sola, ma per analizzare i singoli prodotti serve esplodere l’array in righe separate. In PostgreSQL il pattern è questo:

SELECT
  o.order_id,
  o.order_time,
  item->>'name' AS item_name,
  (item->>'quantity')::int AS quantity,
  (item->>'price')::numeric AS price
FROM orders o
CROSS JOIN LATERAL jsonb_array_elements(o.items) AS item;

Con questa trasformazione è emerso che il 12% degli item più ordinati generava il 56% del fatturato. Senza l’unnesting lo stesso risultato avrebbe richiesto un ETL molto più pesante.

Costruire l’analisi a tre profondità

Parti da una scheda sintetica della lezione: la decisione che supporti, la metrica principale, la baseline, il rischio e l’azione da prendere se il segnale viene confermato. Questo fissa il legame tra il dato e la scelta prima ancora di scrivere SQL.

Da lì sali di un livello. Costruisci una tabella con tre segmenti o periodi e, per ciascuno, scrivi cosa cambia, una spiegazione alternativa plausibile e quale controllo useresti prima di raccomandare un’azione. Le spiegazioni alternative servono a non scambiare il rumore per un effetto.

Il passo più ambizioso è un memo decisionale completo: ipotesi, dati necessari, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio. Per gli esercizi usa dati di ordini, eventi, sessioni, coorti, revenue e tabelle temporali. Se non ne hai, genera un dataset sintetico di almeno 200 righe con una dimensione temporale, una di segmento e una metrica di outcome.

L’errore che svuota l’analisi

Il rischio più comune è trattare i dati semi-strutturati come un’etichetta invece che come un processo. Capita quando si mostra un grafico senza una decisione collegata, una metrica senza baseline o una conclusione che nasconde le assunzioni critiche. La domanda da farsi è semplice: se il risultato fosse instabile, quale decisione sbaglierei? Se non riesci a rispondere in concreto, manca proprio il ponte tra analisi e azione.

Verifica di comprensione

Per controllare se la lezione è entrata, prova a rispondere a queste domande. Qual è la decisione concreta che questo lavoro aiuta a migliorare? Quale unità di analisi rende il problema misurabile? Quale baseline evita una lettura ingenua dei dati? Quale errore tipico può invalidare la conclusione? E come sintetizzeresti il risultato per uno stakeholder che non conosce SQL?

Riepilogo operativo

I dati semi-strutturati sono ovunque perché sono flessibili, ma quella flessibilità va disciplinata per arrivare a decisioni affidabili. Estrarre campi JSON, esplodere array e attraversare oggetti annidati sono tecniche di base. Da sole, senza un modello concettuale e un’unità di analisi dichiarata, producono rumore più che insight. Il ciclo decisione, dato, controllo, azione è quello che ti tiene in controllo quando la struttura del dato non è garantita.