import pandas as pd

import matplotlib.pyplot as plt

Python for 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.

Step	Question to ask	Expected output
Decision	Che cosa cambia se capiamo meglio il problema?	Scelta esplicita
Signal	Quale dato osservabile riduce l’incertezza?	Metrica o evento
Baseline	Rispetto a cosa interpretiamo il risultato?	Credible comparison
Vincolo	Che cosa puo falsare la lettura?	Assunzione da dichiarare
Action	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à.

Element	Operational Definition	Controllo minimo
Unit of analysis	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

The starting point of every marketing data science analysis is raw data, often fragmented across data warehouses, event logs, and third-party APIs. If SQL is the scalpel to extract specific datasets, 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 excels. Starting from a transactions table with user_id, timestamp e amount, puoi calcolare metriche RFM (Recency, Frequency, Monetary) in poche righe di codice. La Recency (how much time has passed since the last purchase) is calculated by subtracting the timestamp of each user's last purchase from today's date. The Frequency (how many purchases were made in a given period) is obtained with a groupby('user_id').count()count. The Monetary (the average or total value of purchases) with a 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.

Situation	Cautious interpretation	Decision
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	Average effect hides heterogeneity	Separate cohorts or use cases
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.

Typical mistake to avoid

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.

Operational Summary

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
Question	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
Action	Quale raccomandazione diventa piu difendibile