JSON, arrays, and 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.

Phase	What to clarify	Output
Question	Which real choice needs improvement?	Decision to make
Measure	Which observable signal represents the problem?	Metric or source data
Control	Which baseline makes the result interpretable?	Credible comparison
Action	What changes after the analysis?	Next operational step

È 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.

Element	Requested specification
Unit of analysis	row, partition, window, join, cohort, or temporal metric
Primary signal	correttezza, performance, duplicati, granularità e stabilità
Baseline	periodo precedente, gruppo comparabile, benchmark o scenario controfattuale
Decision	query, intermediate model, SQL test, or reusable pattern
Risk	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?

Operational Summary

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.