Il problema: superare il Tier 1 per una previsione degli stock reale, dinamica e contestualizzata nei negozi fisici italiani

Le previsioni degli stock nei punti vendita italiani sono spesso limitate da dati aggregati, modelli statici e una scarsa integrazione tra contesto locale e comportamento reale. Il Tier 1 fornisce una base con previsioni aggregate e aggregazione giornaliera, ma non coglie la granularità essenziale per negozi con diversità produttiva, stagionalità regionale e eventi locali che influenzano il consumo. Il Tier 2 risponde a questa lacuna introducendo un modello ibrido centrato su dati di vendita POS in tempo reale, feature engineering avanzato su indicatori contestuali e tecniche di machine learning supervisionato calibrate su realtà italiana.

La sfida principale risiede nel trasformare volumi elevati di dati eterogenei – spesso imperfetti – in previsioni affidabili, con validazione rigorosa per evitare il rischio di overfitting o bias temporale. Solo con pipeline di acquisizione, pulizia, feature engineering mirato e validazione temporale si può costruire un modello robusto, replicabile e in grado di supportare decisioni operative quotidiane.

“La previsione negli store non è solo statistica: è un’arte di integrare dati locali, contestuali e comportamentali in un sistema predittivo reattivo.”

1. Fondamenti del Tier 2: dalla pipeline dati alla granularità spaziale-temporale

A differenza del Tier 1, basato su dati aggregati e previsioni di base, il Tier 2 integra:
– Pipeline ETL con Apache Spark per gestire migliaia di POS con interpolazione temporale e imputazione di valori mancanti via media ponderata e lag features
– Standardizzazione regionale: aggregazione giornaliera, codifica prodotti secondo ISIC aggiornata, normalizzazione per orario e formato locale
– Integrazione di variabili esterne contestuali: consumo energetico, traffico pedonale, previsioni meteo, eventi culturali/fiere, con correlazione diretta ai dati POS per aumentare la robustezza
– Feature engineering avanzato: vendite per metro quadrato, indici di stagionalità locale, “impatto eventi” calcolato con differenze giornaliere, trend a 7 giorni con rolling mean e lag features

Questi passaggi permettono di costruire un modello che non solo prevede, ma comprende il “perché” delle variazioni, cruciale per negozi in contesti regionali diversificati come il Nord Italia.

2. Pipeline ETL con Apache Spark: gestione di dati elevati e qualità operativa

La fase operativa inizia con una pipeline Apache Spark ottimizzata per:
– Caricamento parallelo di dati POS da 1.000+ punti vendita
– Pulizia automatica: rilevamento di anomalie tramite statistica descrittiva (median, deviazione standard) e imputazione con interpolazione lineare per gap temporali <24h e media ponderata per gap >48h
– Normalizzazione per orario (fascia oraria: mattino, pomeriggio) e località geografica (zona urbana vs periferica)
– Aggregazione giornaliera in formato coerente, con codifica ISIC aggiornata per categoria prodotti

Esempio di codice Spark pseudocodice:
from pyspark.sql import functions as F

def normalizza_orario(ora):
if ora in range(6,12): return “mattino”
elif ora in range(12,18): return “pomeriggio”
else: return “sera”

df = spark.read.parquet(“pds_raw”)
df = df.withColumn(“fascia_oraria”, F.when(df.ora < 12, “mattino”)
.when(df.ora < 18, “pomeriggio”)
.otherwise(“sera”))
df = df.withColumn(“local_zone”, F.when(df.regione == “Lombardia”, “centrale”)
.when(df.regione == “Toscana”, “toscana”)
.otherwise(“generale”))
df = df.groupBy(“data”, “prodotto”, “fascia_oraria”, “local_zone”) \
.agg(F.mean(“quantita_venduta”).alias(“vendite_medie_giornaliere”))
df.write.format(“parquet”).save(“pds_etl_processed”)

Questa pipeline garantisce dati puliti e pronti per feature engineering, riducendo errori di registrazione e aumentando affidabilità delle previsioni.

3. Feature engineering dettagliato: da dati grezzi a segnali predittivi

Il Tier 2 si distingue per feature ricche e contestualizzate:
– **Vendite per metro quadrato**: vendite totali / superficie negozio (indicatore di efficienza spaziale)
– **Indice di stagionalità locale**: rapporto tra vendite attuali e medie stagionali per mese, con pesatura per eventi regionali come sagre o feste natalizie
– **Impatto eventi**: differenza percentuale tra vendite durante evento e periodo normale, calcolata con finestre scorrevoli di 3 giorni prima e dopo
– **Trend recente**: rolling mean a 7 giorni con lag features per catturare dinamiche a breve termine

Queste feature, integrate in un dataframe strutturato, alimentano modelli predittivi che catturano variazioni non lineari e dipendenze temporali complesse.

4. Costruzione e calibrazione del modello: Prophet con validazione temporale rigorosa

Il modello scelto è Prophet, estensione di scikit-learn ottimizzata per serie temporali con stagionalità multipla e interventi (eventi).
– Training: 70% dati storici (minimi 18 mesi), test: 15%, validazione: 15% con split temporale cronologico (non casuale)
– Feature temporalmente sensibili: roll-up giornaliero, settimanale e mensile, lag features con ritardi di 1, 3, 7 giorni, indicatori eventi come variabili dummy

Esempio di valutazione modello:
from fbprophet import Prophet

model = Prophet(seasonality_mode=’multiplicative’, yearly_seasonality=True, weekly_seasonality=True, daily_seasonality=False)
model.add_country_holidays(country_name=”IT”)
model.fit(training_df)
future = model.make_future_dataframe(periods=90)
forecast = model.predict(future)

# Valutazione MAPE con test set
actual = test_df[[‘ds’, ‘y’]]
pred = forecast.loc[test_df[‘ds’], [‘ds’, ‘yhat’]]
mape = (abs((actual – pred)/actual) * 100).mean()
print(f”MAPE: {mape:.