Final math problem set with guided solutions

Anche questo problem set appartiene al binario ml-tabellare: ogni esercizio parte da una tabella, reale o immaginata, e chiede di scegliere lo strumento giusto. 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 di usare Bayes, un intervallo di confidenza o la distanza coseno: devi riconoscere il segnale da solo. Qui la matematica diventa pratica professionale. Ogni esercizio va letto come una piccola decisione: quale fenomeno sto misurando, quale incertezza devo esplicitare e quale assunzione può rompere il risultato.

Che cosa verifica davvero questo problem set

Il problem set verifica se sai scegliere lo strumento statistico giusto quando il problema non arriva già etichettato.

Come lavorare su ogni esercizio

1. Traduci il testo in una domanda decisionale con unità di analisi e metrica primaria.
2. Identifica il tipo di incertezza: stima, confronto, relazione o aggiornamento di credenze.
3. Scegli lo strumento corrispondente tra intervalli, test, regressione o Bayes.
4. Dichiara assunzioni, baseline e soglia prima di calcolare.
5. Esegui il calcolo e verifica la stabilità su segmenti e periodi diversi.
6. Chiudi con una raccomandazione che nomina confidenza e monitoraggio successivo.

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 e 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 quello 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.

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. Molte analisi apparentemente sofisticate falliscono perché il dato di partenza misura un comportamento diverso da quello che il team crede di osservare.

SQL example: building a control view

La vista seguente crea una base analitica con metrica, segmento e finestra temporale, così puoi confrontare periodi e gruppi senza riscrivere la logica ogni volta.

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;

Python example: checking stability and anomalies

Il controllo seguente segnala variazioni anomale settimana su settimana senza reagire a ogni oscillazione casuale.

# 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 caso Moneyball: scegliere lo strumento giusto

Nella stagione 2002 gli Oakland Athletics di Billy Beane vinsero 20 partite consecutive, record dell’American League, con uno dei budget più bassi del campionato. Il front office aveva smesso di valutare i battitori con la media battuta e puntava su on-base percentage e slugging, cioè sulle metriche che la loro analisi collegava davvero alla produzione di punti. Michael Lewis raccontò la storia nel libro “Moneyball” del 2003. Il caso resta la dimostrazione più famosa di problem solving quantitativo: vincere non scegliendo lo strumento più prestigioso, ma quello giusto per la domanda.

Verdetto: vince lo strumento giusto per la domanda, non il più prestigioso: traduci ogni esercizio in una domanda decisionale, scegli tra intervalli, test, regressione e Bayes in base al tipo di incertezza, e chiudi con una raccomandazione che nomina confidenza e monitoraggio.

Le domande che contano alla fine

1. Davanti a un testo senza etichette, come riconosci se serve un test o un intervallo?
2. Quale assunzione controlleresti per prima in un esercizio su code pesanti?
3. Quando una soluzione corretta nei calcoli resta una cattiva raccomandazione?
4. Cosa deve contenere un memo decisionale per essere difendibile in riunione?