Gestione inventory
Previsione disponibilita
Gruppo editoriale primario
Il Contesto
Il progetto e stato realizzato per RCS (Corriere della Sera), gruppo editoriale italiano di primaria importanza, e copre l'inventory pubblicitario online di testate come Corriere della Sera e Gazzetta dello Sport. In una concessionaria di questa scala l'inventory, cioe lo stock di spazi pubblicitari disponibili, e un asset finanziario a tutti gli effetti: ogni posizione (homepage, sezioni verticali, formati video, native) ha un volume di impression atteso che varia per giorno, fascia oraria, dispositivo e geografia.
Il team commerciale deve poter rispondere a una domanda semplice ma costosa da calcolare: "per questa campagna, su queste sezioni, in queste date, quante impression posso ancora vendere senza sovrascrivere prenotazioni gia confermate?". Ho lavorato come sviluppatore frontend / full-stack sul gestionale che risponde a questa domanda, con focus sulla UI di forecasting e sul layer di interrogazione dei dati. Per riservatezza non vengono divulgati volumi, tariffe o dati di vendita reali.
Il Problema
Prima di un gestionale dedicato, la previsione di disponibilita dell'inventory poggiava su strumenti frammentati ed estrazioni manuali. Questo generava tre criticita ricorrenti, tipiche delle concessionarie editoriali di grandi dimensioni:
- Frammentazione dei dati: le impression erogate vivevano nei log dell'ad server, le prenotazioni in un altro sistema, i dati anagrafici delle sezioni in un terzo. Ricostruire la disponibilita reale di una posizione richiedeva incrociare fonti diverse a mano.
- Lentezza nella risposta al cliente: ogni richiesta di availability per una campagna significativa poteva richiedere ore, con il rischio concreto di promettere spazi gia impegnati (overbooking) o di lasciare invenduto inventory disponibile.
- Forecasting non interrogabile in tempo reale: le proiezioni vivevano in fogli e report statici, non in un'interfaccia che il commerciale potesse interrogare in autonomia filtrando per testata, sezione, formato e periodo.
L'obiettivo era centralizzare la gestione dell'inventory in un unico gestionale e trasformare il forecasting da report statico a vista interattiva, in modo che chiunque in area commerciale potesse stimare la disponibilita residua su un orizzonte di settimane o mesi senza passare dall'IT.
La Soluzione
L'architettura ad alto livello e quella classica di un gestionale data-intensive: un layer di aggregazione che precalcola i dati pesanti, un'API che li espone in modo coerente e un frontend che li rende navigabili e interrogabili.
Layer di aggregazione su Elasticsearch
Il cuore della performance e Elasticsearch: i volumi di impression e le prenotazioni vengono indicizzati e pre-aggregati per dimensione (testata, sezione, formato, periodo, dispositivo). Calcolare la disponibilita residua non significa scansionare miliardi di righe a runtime, ma interrogare aggregazioni gia pronte. Le query di forecasting sfruttano date histogram e aggregazioni annidate per restituire serie temporali di disponibilita in millisecondi, anche su orizzonti lunghi.
Backend Node.js e modello dati su MySQL
Un backend Node.js orchestra le query Elasticsearch, applica le regole di business (overbooking, priorita, sezioni escluse) e normalizza i risultati in un contratto API stabile per il frontend. I dati anagrafici e relazionali - listino sezioni, configurazioni, prenotazioni confermate - vivono su MySQL, mentre Elasticsearch resta la fonte per le interrogazioni analitiche ad alto volume.
Frontend React/TypeScript con stato prevedibile
L'interfaccia e una SPA in React tipizzata end-to-end con TypeScript. Lo stato applicativo - filtri attivi, selezione di testata e sezioni, risultati di forecasting, prenotazioni in corso di simulazione - e gestito con Redux Toolkit, scelta deliberata per un dominio dove molte viste condividono e mutano gli stessi dati. Il commerciale costruisce uno scenario (campagna, sezioni, date) e vede la disponibilita aggiornarsi, con tabelle e grafici di proiezione che rendono leggibile l'inventory residuo posizione per posizione.
Tecnologie Chiave
Lo stack e stato scelto per reggere volumi editoriali enterprise mantenendo un frontend tipizzato e manutenibile nel tempo.
TypeScript
Tipizzazione end-to-end del dominio inventory: contratti API e modelli condivisi senza ambiguita.
Elasticsearch
Aggregazioni e date histogram sull'inventory: forecasting in millisecondi su grandi volumi di impression.
MySQL
Sorgente relazionale per anagrafiche sezioni, configurazioni e prenotazioni confermate.
Node.js
Backend che orchestra le query, applica le regole di overbooking e normalizza i risultati per la UI.
React
SPA del gestionale: viste di forecasting, tabelle dense e grafici di disponibilita interattivi.
Redux Toolkit
Stato applicativo prevedibile dove filtri e risultati di forecasting sono condivisi tra molte viste.
Il Risultato
Il gestionale ha portato la previsione e la gestione dell'inventory in un unico strumento interrogabile dall'area commerciale. I risultati sintetizzati di seguito sono indicativi e stimati, riferiti a un progetto enterprise soggetto a riservatezza: non rappresentano metriche di vendita verificate del cliente.
Gestione inventory in un unico gestionale, fine della frammentazione tra sistemi.
Previsione disponibilita interattiva per testata, sezione, formato e periodo.
In produzione per un gruppo editoriale italiano di primaria importanza.
Nota: le voci sopra sono indicative e stimate, su progetto soggetto a riservatezza. Volumi di impression, tariffe e dati di vendita reali non vengono divulgati.
Sfide Tecniche
Forecasting reattivo su volumi editoriali
La sfida principale era restituire una proiezione di disponibilita su orizzonti lunghi senza far attendere il commerciale. Calcolare a runtime la disponibilita residua di una sezione su mesi di impression sarebbe stato proibitivo. La soluzione e stata spostare il peso sull'indicizzazione: dati pre-aggregati in Elasticsearch per le dimensioni rilevanti e query basate su date histogram e aggregazioni annidate, cosi che il backend Node.js componesse la risposta combinando aggregati gia pronti invece di scansionare i dati grezzi. Il risultato e un forecasting che risponde in modo interattivo anche cambiando i filtri di continuo.
Stato complesso e tipizzato lato frontend
La seconda sfida era gestire un frontend dove molte viste leggono e modificano gli stessi dati: filtri, selezione di sezioni, scenario di campagna simulato e risultati di forecasting devono restare coerenti. Affidarsi allo stato locale dei componenti avrebbe generato duplicazione e bug di sincronizzazione. La scelta e stata Redux Toolkit come singola fonte di verita, con tutto il dominio descritto in TypeScript: i tipi rendono espliciti i contratti tra API e UI e fanno emergere a compile time gli errori che altrimenti sarebbero arrivati a runtime davanti al commerciale.
Servizi Correlati
Se hai un gestionale data-intensive da costruire o modernizzare, questi contenuti approfondiscono metodo e ambito di intervento:
Sviluppo Web e Gestionali su Misura
Frontend React/TypeScript e backend Node.js per applicazioni gestionali data-intensive e dashboard enterprise.
Altri Progetti Realizzati
Web app, piattaforme fintech, sistemi AI e automazioni: il portfolio completo dei progetti.
Per il profilo professionale e l'esperienza nello sviluppo di gestionali e dashboard vedi la pagina Chi sono; per gli altri lavori vedi il portfolio completo.
