import pandas as pd

import matplotlib.pyplot as plt

Python per marketing data science

Questa lezione tratta Python come una disciplina di lavoro, non come una gara di librerie. Un notebook produce segmenti, previsioni e grafici convincenti, ma una campagna ha bisogno di output puliti, ripetibili e spiegabili. Il punto non è accumulare definizioni, ma capire quale decisione cambia quando il dato diventa più affidabile e quando il codice riduce davvero l’ambiguità operativa.

Il problema che vedi sul campo

Il problema non è conoscere Python in astratto. È decidere cosa fare quando il team ha dati incompleti, metriche ambigue o vincoli tecnici che rendono fragile la lettura del fenomeno. Una lezione utile separa il segnale dal rumore, indica una baseline credibile e dice quale azione diventa più difendibile dopo l’analisi. Il codice utile non impressiona: importare dati, creare feature, valutare modelli e consegnare risultati devono restare tracciabili.

Come ragionare sul fenomeno

Conviene seguire una sequenza fissa che lega la domanda al dato e poi all’azione. Senza questo filo, una nozione tecnica diventa rituale.

Passaggio	Domanda da fare	Output atteso
Decisione	Che cosa cambia se capiamo meglio il problema?	Scelta esplicita
Segnale	Quale dato osservabile riduce l’incertezza?	Metrica o evento
Baseline	Rispetto a cosa interpretiamo il risultato?	Confronto credibile
Vincolo	Che cosa puo falsare la lettura?	Assunzione da dichiarare
Azione	Quale passo operativo segue?	Raccomandazione controllabile

Ogni passaggio deve rendere più chiaro il costo di una decisione sbagliata.

Rendere esplicite le assunzioni

Formalizzare non complica la lezione, rende visibili le assunzioni: così uno stakeholder può discutere il criterio decisionale invece di fidarsi del risultato per autorità.

Elemento	Definizione operativa	Controllo minimo
Unita di analisi	Oggetto su cui misuri il fenomeno	Utente, account, evento, ordine o periodo
Variabile osservata	Segnale che rappresenta il comportamento	Definizione stabile e tracciabile
Baseline	Stato contro cui confronti il segnale	Periodo, segmento, controllo o benchmark
Soglia decisionale	Punto in cui cambia l’azione	Criterio scritto prima della lettura
Rischio residuo	Errore che puo restare anche dopo l’analisi	Sensitivity check o revisione qualitativa

Da SQL al DataFrame: il laboratorio dei dati

Il punto di partenza di ogni analisi di marketing data science è il dato grezzo, spesso frammentato tra data warehouse, log di eventi e API di terze parti. Se SQL è il bisturi per estrarre insiemi di dati specifici, pandas è il laboratorio in cui questi dati vengono puliti, trasformati e arricchiti per diventare materia prima per modelli complessi. La sua struttura centrale, il DataFrame, è molto più di una semplice tabella: è un oggetto flessibile che consente operazioni vettorializzate, manipolazioni di serie storiche e aggregazioni complesse con una sintassi intuitiva.

Feature engineering: il caso RFM

Immagina di dover costruire un dataset per un modello di churn prediction. Una query SQL può estrarre l’elenco degli utenti e le loro transazioni, ma il dato grezzo è raramente utilizzabile “così com’è”. Devi ingegnerizzare delle features, cioè variabili che catturino il comportamento dell’utente in modo quantitativo. Qui pandas eccelle. Partendo da una tabella di transazioni con user_id, timestamp e amount, puoi calcolare metriche RFM (Recency, Frequency, Monetary) in poche righe di codice. La Recency (quanto tempo è passato dall’ultimo acquisto) si calcola sottraendo il timestamp dell’ultimo acquisto di ogni utente dalla data odierna. La Frequency (quanti acquisti ha fatto in un dato periodo) si ottiene con un groupby('user_id').count(). La Monetary (il valore medio o totale degli acquisti) con un groupby('user_id').sum().

Esempio: la decisione, non la definizione

Immagina un team che deve usare Python per decidere se cambiare una pipeline, una metrica, un investimento o una dashboard. La domanda non è quale sia la definizione corretta, ma quale scelta diventa meno rischiosa se l’analisi è fatta bene.

Situazione	Lettura prudente	Decisione
Il dato migliora ma la baseline e debole	Il segnale potrebbe essere reale o dipendere dal campione	Rafforzare il confronto prima di scalare
La metrica cambia in un solo segmento	L’effetto medio nasconde eterogeneita	Separare coorti o casi d’uso
Il costo operativo aumenta	Il beneficio va valutato sul margine	Applicare una soglia economica esplicita
Il sistema produce numeri incoerenti	La fiducia nel dato e parte della decisione	Correggere ownership e controlli

Lab ed esercizio

Al livello base, scrivi in cinque righe quale decisione concreta dovrebbe migliorare grazie a una pipeline Python pulita. Indica metrica, unità di analisi, baseline e rischio principale. Se non riesci a nominare la decisione, la lezione è ancora troppo astratta.

Al livello intermedio costruisci una tabella con quattro colonne: segnale osservato, interpretazione prudente, controllo necessario, azione consigliata. Inserisci almeno un caso in cui il segnale non basta per decidere.

Al livello research-grade trasforma l’esercizio in un memo decisionale, con assunzioni, criteri di esclusione, soglia di intervento, sensitivity check e una proposta di monitoraggio dopo la decisione. Per i dati ti basta un export reale, una tabella sintetica, una dashboard interna o un notebook di studio, purché contenga almeno una dimensione di segmento, una metrica osservabile e un periodo o baseline di confronto.

Errore tipico da evitare

L’errore più comune è usare Python come etichetta tecnica invece che come criterio di scelta. Succede quando il team presenta un numero senza dire quale decisione cambia, quale baseline lo rende interpretabile e quale rischio resta aperto. In quel caso il dato sembra preciso, ma non guida l’azione. Cinque domande di controllo aiutano a evitarlo: quale decisione dovrebbe migliorare, quale unità di analisi rende il problema misurabile, quale baseline evita una lettura isolata, quale assunzione cambierebbe la conclusione se fosse falsa, e quale controllo presenteresti prima di raccomandare un’azione.

Riepilogo operativo

Python per marketing data science è utile quando riduce l’incertezza su una scelta reale. La forma corretta della lezione resta sempre la stessa: decisione, segnale, baseline, rischio e azione. Quando un esempio, una formula o un frammento tecnico non chiarisce almeno uno di questi punti, trattalo come dettaglio secondario. La tabella qui sotto riassume i controlli da mantenere quando colleghi domanda, dato, baseline e decisione.

Area	Controllo da mantenere
Domanda	Quale scelta deve cambiare dopo l’analisi
Dato	Quale evento, tabella o metrica rende osservabile il problema
Qualita	Quale errore di raccolta, modellazione o interpretazione puo alterare il risultato
Baseline	Quale confronto impedisce una lettura isolata
Azione	Quale raccomandazione diventa piu difendibile