Nella prima parte ho raccontato come ho strutturato la memoria con i file .md, caricato e trasformato i dati in Power Query, e costruito il modello dati. In questa seconda parte arrivo al risultato concreto: le misure DAX, le sette pagine del report e i due visual Python che hanno reso questo progetto più interessante del previsto
Le misure DAX: il valore è nella domanda giusta
Ho creato circa venti misure DAX distribuite in una tabella dedicata _Misure, convenzione professionale che tengo anche nei progetti reali perché mantiene il modello ordinato. Ma più che il codice, quello che ha contato è stato capire quale domanda stava dietro ogni misura.
Il caso più istruttivo è stato customer_unique_id. Come avevo spiegato nella Parte 1, ogni ordine genera un customer_id diverso per lo stesso cliente fisico, quindi per misurare quanti clienti hanno fatto più di un ordine devi usare customer_unique_id, non customer_id. Una distinzione che se non capisci all’inizio produce analisi sbagliate per tutta la durata del progetto, con numeri che sembrano plausibili ma non lo sono.
Le misure di time intelligence hanno confermato quello che il trend mensile già suggeriva: la crescita costante di Olist dal 2016 al 2017 con il picco netto di novembre 2017, il Black Friday brasiliano, e poi la stabilizzazione intorno a 6.500-7.000 ordini mensili nel 2018.
Una nota tecnica che vale la pena condividere: le misure di time intelligence in DAX — DATESMTD, DATESYTD, DATEADD — funzionano correttamente solo se la DimDate è collegata a una colonna di tipo Date puro, non a un campo datetime. Nel mio caso order_purchase_timestamp era un campo datetime, quindi ho creato in Power Query una colonna aggiuntiva order_date con solo la parte data e collegato la DimDate a quella. Un passaggio che sembra banale ma che se salti produce misure che restituiscono valori errati senza dare errori visibili.
Il report: quello che i dati hanno raccontato
Sette pagine, venti misure DAX, due drill-through e due visual Python. Ma più che la struttura tecnica, quello che mi ha colpito sono le storie che i dati hanno raccontato, alcune attese, altre no.
La storia della retention è quella più sorprendente. Solo il 2,91% dei clienti ha effettuato più di un ordine. Su 96.096 clienti unici, appena 3.000 sono tornati a comprare. Il dato diventa ancora più interessante se lo incroci con i review score:il punteggio medio è 4,16 su 5 e il punteggio 5 è di gran lunga il più frequente. I clienti sono soddisfatti ma non tornano. È un tema di business che esula dall’analisi dati, ma i dati lo pongono in modo inequivocabile.
La storia della logistica è invece positiva e misurabile. I tempi medi di consegna sono scesi da 15-16 giorni a gennaio 2018 a meno di 9 giorni ad agosto 2018. Olist stava migliorando la propria infrastruttura logistica in modo significativo e il dato lo mostra chiaramente nel trend mensile. L’8,11% di ordini in ritardo rispetto alla data stimata si concentra prevalentemente negli stati del nordest brasiliano, visibile immediatamente nella mappa a bolle colorate.
La storia delle categorie sorprende chi si aspetta che un marketplace brasiliano sia guidato dall’elettronica. health_beauty e watches_gifts dominano con oltre un milione di R$ (real brasiliano).. Ma l’AOV racconta una storia più sfumata: watches_gifts ha un valore medio per ordine di R$214 contro i R$110 di bed_bath_table. Volume e valore non vanno sempre nella stessa direzione.
La storia dei prezzi emerge dai visual Python (due grafici costruiti con matplotlib e seaborn integrati direttamente nel report tramite il visual Python nativo di Power BI. La mediana dei prezzi è R$127, la media è R$283) una differenza enorme che indica una distribuzione fortemente asimmetrica con una coda lunga verso destra. La maggior parte dei prodotti è di fascia bassa-media, ma una minoranza di prodotti ad alto valore tira su la media in modo significativo. Stesso discorso per la heatmap degli ordini per giorno e ora, i picchi tra le 10 e le 16 dal lunedì al venerdì emergono con una chiarezza che un bar chart standard non avrebbe mai comunicato. Una nota tecnica per chi volesse replicarlo: il backend grafico va impostato su non-interattivo con matplotlib.use(‘Agg’) altrimenti i visual non renderizzano in Power BI.
La storia degli acquisti completa il quadro: i picchi di ordini tra le 10 e le 16 dal lunedì al venerdì, con il martedì e il mercoledì come giorni di punta, sono esattamente il tipo di informazione che un e-commerce usa per decidere quando inviare le newsletter promozionali.
Riflessioni finali: cosa cambia quando hai un interlocutore tecnico
Il valore dell’AI in questo progetto non è stato nella velocità , il progetto ha richiesto comunque diverse sessioni distribuite su più giorni. È stato nel ragionamento preventivo. Sapere prima dove si nascondono i problemi, verificare le decisioni architetturali prima di costruirci sopra il modello, ricevere la correzione giusta al momento giusto.
Un limite reale: l’AI non vede il tuo schermo. Ogni problema devi descriverlo, e a volte uno screenshot vale più di mille parole. Ma è un limite gestibile.
La competenza tecnica devi averla tu, l’AI non la sostituisce, la amplifica.
Se vuoi esplorare il report completo — tutte e sette le pagine, le misure DAX e i visual Python — puoi richiedere il file .PBIX scrivendomi a f_e@intdata.it o contattandomi direttamente su LinkedIn. Lo condivido volentieri con chi vuole studiarlo o usarlo come punto di partenza per i propri progetti.
