import pandas as pd

Final math problem set with guided solutions

Il problem set finale non serve a dimostrare che ricordi le formule. Serve a verificare se sai scegliere lo strumento giusto quando il problema non arriva già etichettato. In un progetto reale nessuno ti dice “usa Bayes”, “usa un intervallo di confidenza” o “controlla la distanza coseno”: devi riconoscere il segnale da solo. Qui la matematica diventa una pratica professionale, e ogni esercizio va letto come una piccola decisione: quale fenomeno sto misurando, quale incertezza devo esplicitare, quale assunzione può rompere il risultato.

Come affrontare gli esercizi

Lavora su questi casi come faresti prima di presentare un’analisi a un team. Niente calcoli scollegati, niente formule usate per impressionare, niente conclusioni senza controllo: ogni soluzione deve lasciare una traccia leggibile del ragionamento. Davanti a ogni testo conviene chiedersi quale domanda decisionale si nasconde dietro le parole, quale passaggio matematico riduce davvero l’incertezza, e quale risposta daresti se il dato fosse incompleto o rumoroso.

La categoria è Lab, ma il fine resta lo stesso del resto del modulo: capire quale scelta cambia quando il dato diventa più affidabile. Tieni quindi presente quale contesto rende un caso difficile, quale evidenza cambia davvero la decisione, e quale lezione resta valida fuori dal caso specifico.

Leggere il problem set come parte di un sistema

In un progetto reale un problem set non vive mai isolato. È parte di un sistema più ampio fatto di decisioni, dati disponibili, vincoli tecnici, incentivi organizzativi e qualità dell’esecuzione. Il rischio dell’analista principiante è trattare il tema come una definizione: imparare il nome, ricordare due formule, applicare un template. Il lavoro professionale è diverso, perché bisogna capire quale problema risolve un metodo, quali assunzioni contiene e cosa succede quando quelle assunzioni non sono vere.

La prima domanda da fare non è quale metrica calcolo, ma quale decisione dovrà essere presa grazie a questa analisi. Una dashboard, una query o un modello statistico hanno valore solo se riducono l’incertezza decisionale; se non cambiano una scelta, sono documentazione o teatro analitico. Un modo per impostare il lavoro è definire il problema in linguaggio business, identificare l’unità di analisi corretta tra utente, account, evento, sessione, ordine o campagna, controllare se i dati misurano davvero il fenomeno o solo una sua ombra, costruire una metrica interpretabile, segmentare per evitare che la media nasconda pattern opposti e trasformare il risultato in una raccomandazione verificabile.

Real case: Netflix and the discipline of metrics

Netflix è un esempio utile perché ha costruito molte decisioni di prodotto intorno a segnali comportamentali osservabili: completamento degli episodi, tempo di ricerca prima della riproduzione, abbandono dopo pochi minuti, ritorno nella settimana successiva, efficacia delle raccomandazioni. Il punto non è che ogni azienda debba copiare Netflix, ma che il dato non viene trattato come ornamento, bensì come infrastruttura decisionale.

Quando Netflix valuta una modifica all’esperienza, che sia una nuova riga di raccomandazioni, una diversa immagine di copertina o un algoritmo di ranking, non misura solo il click immediato. Misura anche segnali di qualità: l’utente guarda davvero il contenuto, torna nei giorni successivi, riduce il tempo speso a cercare, aumenta la soddisfazione implicita. Questa disciplina impedisce di ottimizzare vanity metric che sembrano positive nel breve ma danneggiano valore nel lungo periodo. Lo stesso vale per ogni esercizio del problem set: la soluzione va collegata a un outcome, e se il risultato non aiuta a scegliere tra due azioni alternative l’analisi è incompleta.

SQL example: building a control view

The following pattern is intentionally generic but executable in most modern warehouses. The goal is to create an analytical base with metric, segment, and time window, so you can compare periods and groups without rewriting logic each time.

WITH base_events AS (
  SELECT
    user_id,
    account_id,
    event_type,
    event_time,
    DATE_TRUNC('week', event_time) AS week,
    source,
    device_type
  FROM events
  WHERE event_time >= CURRENT_DATE - INTERVAL '180 days'
    AND user_id IS NOT NULL
),
weekly_user_metrics AS (
  SELECT
    week,
    user_id,
    COALESCE(source, 'unknown') AS source,
    COALESCE(device_type, 'unknown') AS device_type,
    COUNT(*) AS total_events,
    COUNT(DISTINCT DATE(event_time)) AS active_days,
    COUNT(DISTINCT event_type) AS event_diversity,
    MAX(CASE WHEN event_type IN ('purchase', 'subscribe', 'activation') THEN 1 ELSE 0 END) AS reached_key_outcome
  FROM base_events
  GROUP BY week, user_id, source, device_type
)
SELECT
  week,
  source,
  device_type,
  COUNT(DISTINCT user_id) AS users,
  ROUND(AVG(active_days), 2) AS avg_active_days,
  ROUND(AVG(event_diversity), 2) AS avg_event_diversity,
  ROUND(AVG(reached_key_outcome) * 100, 2) AS key_outcome_rate
FROM weekly_user_metrics
GROUP BY week, source, device_type
ORDER BY week, source, device_type;

La query non pretende di essere la risposta finale. Serve a creare una superficie di osservazione fatta di trend, segmenti, differenze tra canali e variazioni nel tempo, da cui l’analista può formulare ipotesi più precise.

Python example: checking stability and anomalies

A useful metric must be stable enough to guide decisions and sensitive enough to signal real changes. In Python, we can check for anomalous week-over-week variations.

# df contiene: week, segment, users, key_outcome_rate
# key_outcome_rate espresso in percentuale, es. 12.4

df = df.sort_values(['segment', 'week']).copy()
df['previous_rate'] = df.groupby('segment')['key_outcome_rate'].shift(1)
df['wow_change_pp'] = df['key_outcome_rate'] - df['previous_rate']
df['rolling_mean'] = df.groupby('segment')['key_outcome_rate'].transform(
    lambda s: s.rolling(4, min_periods=2).mean()
)
df['rolling_std'] = df.groupby('segment')['key_outcome_rate'].transform(
    lambda s: s.rolling(4, min_periods=2).std()
)
df['z_score'] = (df['key_outcome_rate'] - df['rolling_mean']) / df['rolling_std']

anomalies = df[df['z_score'].abs() >= 2].sort_values('z_score')
print(anomalies[['week', 'segment', 'key_outcome_rate', 'wow_change_pp', 'z_score']])

Il valore di questo controllo è pratico: evita di reagire a ogni oscillazione casuale, ma segnala quando una variazione merita un’investigazione. In azienda questo tipo di analisi può alimentare alert, review settimanali e retrospettive di prodotto.

Lab a tre livelli

Al livello base, prendi un esercizio e scrivi una scheda di una pagina: la decisione da supportare, la metrica primaria, la baseline, il rischio principale e l’azione se il segnale è confermato. Se non riesci a nominare la decisione, l’esercizio è ancora trattato come un calcolo astratto.

Al livello intermedio, costruisci una tabella con tre segmenti, periodi o scenari. Per ciascuno indica cosa cambia, quale spiegazione alternativa è plausibile e quale controllo useresti prima di raccomandare un’azione, includendo almeno un caso in cui il segnale non basta per decidere.

Al livello research-grade, prepara un decision memo completo: ipotesi, dati richiesti, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio dopo la decisione. Per i materiali usa dataset numerici, simulazioni, matrici, campioni e notebook; se non hai accesso a dati reali, crea un dataset sintetico con almeno 200 righe, una dimensione temporale, una dimensione segmento e una metrica di outcome.

Errori comuni e controllo di qualità

Il primo errore è lavorare su dati aggregati troppo presto, perché una media globale può nascondere due segmenti che si muovono in direzioni opposte. Il secondo è non controllare la qualità del dato: eventi duplicati, tracking incompleto, timezone incoerenti e cambi di definizione producono conclusioni false. Il terzo è confondere correlazione e causalità, perché chi usa una feature potrebbe convertire di più semplicemente in quanto già più motivato.

C’è poi un errore più strutturale: usare un metodo come etichetta invece che come processo. Succede quando si mostra un grafico senza decisione, una metrica senza baseline o una conclusione senza indicare quale assunzione potrebbe invalidarla. La domanda di controllo è semplice: se questo risultato fosse instabile, quale scelta sbaglierei? Prima di portare un’analisi in una decisione, controlla sempre completezza, duplicati, timezone, definizioni cambiate e segmenti esclusi, perché molte analisi apparentemente sofisticate falliscono perché il dato di partenza misura un comportamento diverso da quello che il team crede di osservare.

Checkpoint

Chiudi ogni esercizio rispondendo a cinque domande. Quale decisione concreta dovrebbe migliorare la soluzione? Quale unità di analisi rende il problema misurabile? Quale baseline useresti per evitare una lettura ingenua? Quale errore tipico potrebbe cambiare la conclusione? E quale output consegneresti a uno stakeholder non tecnico?

Summary

Il problem set matematico finale va trattato come uno strumento decisionale, non come un argomento da manuale. Il valore nasce quando colleghi problema, dati, metrica, segmentazione e azione, e quando in ogni esercizio sai scegliere lo strumento giusto invece di applicare formule in sequenza. Una buona soluzione non termina con “il numero è salito” o “il numero è sceso”, ma con una frase operativa: quale decisione prendiamo, con quale livello di confidenza, e quale metrica useremo per sapere se avevamo ragione.