20 domande frequenti di colloquio per Data Scientist. Data Science è un ambito molto richiesto che trasforma dati di prodotto, clienti e business in decisioni, esperimenti, modelli e insight misurabili. Le domande coprono livelli diversi e puoi esercitarti a rispondere a voce nel nostro simulatore di colloquio.
1How do you explain foundational metrics like conversion rates or statistical significance to non-technical business stakeholders without using technical jargon?
When communicating foundational metrics to non-technical stakeholders, the key is to translate abstract formulas and statistical mechanics into intuitive user stories, decision confidence, and business risk. For conversion rate, rather than presenting a bare ratio or abstract percentage, frame it around concrete user counts: 'Out of every 100 people who landed on the checkout page, 5 completed a purchase.' This grounds the metric directly in observable customer behavior. For statistical significance, avoid formal null hypothesis terminology like alpha levels or rejection regions. Instead, explain it as confidence that an observed uplift is real rather than random noise or lucky timing. For instance: 'A statistically significant result means we are 95% confident this improvement reflects a genuine change in user behavior rather than random fluke. Rolling this out gives us high confidence of a positive outcome instead of reacting to random noise.'
## Experiment Results: New Checkout Flow
- Baseline Conversion: 5.0% (5 out of 100 visitors buy)
- Variant Conversion: 5.8% (5.8 out of 100 visitors buy, a +16% relative lift)
- Decision Confidence: 96% confidence (p = 0.04)
- Business Takeaway: The risk that this lift was just random chance is under 4%. Rolling this out is estimated to bring +$45k in monthly revenue.
2Qual è la differenza concettuale tra inner join, left join, right join e full outer join, e in che modo ciascuna scelta influisce sulla popolazione analitica e sulla gestione dei valori NULL nel calcolo delle metriche a valle?
Le operazioni di inner, left, right e full outer join definiscono quali record vengono mantenuti quando si combinano tabelle in base a chiavi corrispondenti: - Inner Join: mantiene solo i record in cui la chiave di join coincide in entrambe le tabelle. - Left (Outer) Join: mantiene tutti i record della tabella di sinistra e popola le colonne della tabella di destra con NULL quando non vi è corrispondenza. - Right (Outer) Join: mantiene tutti i record della tabella di destra, popolando le colonne senza corrispondenza della tabella di sinistra con NULL. - Full Outer Join: mantiene tutti i record di entrambe le tabelle, inserendo NULL da una parte o dall'altra in assenza di corrispondenza. Popolazione analitica e impatto sulle metriche a valle: la scelta del tipo di join controlla direttamente la coorte analitica e i denominatori utilizzati nel calcolo delle metriche. Una inner join non intenzionale tra la base utenti e una tabella di attività/transazioni esclude gli utenti inattivi, riducendo il denominatore ai soli utenti attivi e gonfiando artificialmente i tassi di conversione o di retention. Al contrario, le outer join preservano l'intera popolazione di riferimento ma introducono valori NULL per le righe prive di corrispondenza. I calcoli a valle devono tenere conto di questi NULL: le funzioni di aggregazione SQL (Structured Query Language) standard come SUM() o AVG() ignorano i valori NULL, COUNT(colonna) conta solo le voci non NULL mentre COUNT(*) conta tutte le righe, e le operazioni aritmetiche su valori NULL non gestiti con coalesce restituiscono NULL.
-- Inner join silently shrinks denominator to purchasers only
SELECT COUNT(o.order_id) * 1.0 / COUNT(u.user_id) AS inner_conv_rate
FROM users u
INNER JOIN orders o ON u.user_id = o.user_id;
-- Left join preserves full user base for accurate metric computation
SELECT COUNT(o.order_id) * 1.0 / COUNT(u.user_id) AS true_conv_rate
FROM users u
LEFT JOIN orders o ON u.user_id = o.user_id;
3In product experimentation, what does randomization achieve that simple before-after comparison usually cannot, and how would you explain the core causal claim an A/B test is designed to support?
In product experimentation, a simple before-after comparison compares metrics across different time periods, which confounds the effect of a feature change with external temporal factors such as seasonality, day-of-week patterns, concurrent marketing campaigns, macro trends, and natural user maturation. Randomization assigns eligible units simultaneously to treatment and control groups, balancing both observed and unobserved confounding variables across groups in expectation. This establishes internal validity. The core causal claim supported by an A/B test relies on counterfactual reasoning: because the control group is subjected to the exact same external conditions over the exact same time window, it serves as an empirical estimate of the counterfactual—what would have happened to the treatment group had they not received the feature. Therefore, any statistically significant difference in outcomes can be causally attributed to the treatment intervention.
# Naive Before-After Comparison:
# Effect_estimate = Metric_t1 (Holiday Launch) - Metric_t0 (Pre-Holiday Baseline)
# Problem: Lift is confounded by holiday shopping surge and marketing spend.
# Randomized A/B Test:
# Effect_estimate = E[Metric_Holiday | Treatment] - E[Metric_Holiday | Control]
# Solution: Both arms experience the exact same external shocks simultaneously.
4A cosa mira tipicamente l'analisi esplorativa dei dati prima della modellazione formale o della sperimentazione, e in che modo si distingue l'EDA (Exploratory Data Analysis) dall'analisi confermativa?
L'analisi esplorativa dei dati (EDA, Exploratory Data Analysis) è un processo a finale aperto finalizzato a comprendere la struttura sottostante di un dataset, individuare pattern, identificare anomalie o problemi di qualità dei dati, valutare le assunzioni sulle distribuzioni e generare ipotesi prima di costruire modelli statistici formali o eseguire esperimenti.
La distinzione fondamentale tra EDA e analisi confermativa risiede nelle loro finalità e metodologie: l'EDA è flessibile, orientata all'esplorazione e alla generazione di ipotesi; impiega riepiloghi descrittivi, correlazioni e visualizzazioni per esaminare ciò che i dati suggeriscono senza vincoli prefissati rigidi. Al contrario, l'analisi confermativa (come i test di ipotesi o la valutazione degli A/B test) è strutturata, inferenziale e orientata alla verifica delle ipotesi: è progettata per testare rigorosamente ipotesi falsificabili e predefinite, controllando al contempo i tassi di errore statistico (ad esempio l'errore di tipo I). Trattare i risultati scoperti durante l'EDA come conclusioni confermate sullo stesso dataset può portare al data dredging (p-hacking) e all'overfitting.
import numpy as np
import pandas as pd
# 1. EDA Phase: Open-ended discovery and hypothesis generation
df = pd.DataFrame({'engagement_score': np.random.normal(50, 10, 1000)})
summary = df['engagement_score'].describe()
# 2. Confirmatory Phase: Testing pre-registered hypothesis on fresh test/experiment data
# (e.g., two-sample t-test with fixed significance level alpha = 0.05)
5Che cos'è il target leakage nel contesto dell'apprendimento supervisionato e in cosa differisce da una forte correlazione legittima tra una feature e l'etichetta?
Il target leakage si verifica quando una feature inclusa nell'addestramento del modello contiene informazioni sull'etichetta target che non sarebbero legittimamente disponibili al momento dell'inferenza, quando il modello esegue previsioni nel mondo reale. Ciò accade frequentemente quando una feature viene raccolta cronologicamente dopo l'evento di interesse o rappresenta un artefatto diretto o una conseguenza a valle del risultato target (come l'utilizzo del timestamp di cancellazione di un account o dell'ID di un rimborso per prevedere l'abbandono dei clienti). Al contrario, una forte correlazione legittima riflette una relazione predittiva o causale autentica e preesistente che è completamente nota e disponibile prima del momento della previsione (come la frequenza di accesso di un cliente negli ultimi 30 giorni). Sebbene entrambe evidenzino un'elevata importanza delle feature o metriche di valutazione eccellenti, un modello affetto da target leakage otterrà punteggi di validazione offline irrealisticamente alti, ma fallirà in produzione poiché la feature anomala non può essere nota al momento dell'inferenza.
# Scenario: Predicting whether a user will cancel their subscription (is_churned)
# LEAKY FEATURE:
# 'cancellation_survey_submitted' -> Occurs after the decision to churn has executed.
# LEGITIMATE FEATURE:
# 'login_count_last_30_days' -> Observed strictly before the prediction cut-off date.
6Qual è lo scopo della suddivisione dei dati in set di training, validazione e test, e in che modo ciascuna partizione dovrebbe guidare lo sviluppo iterativo del modello?
La suddivisione dei dati in set di training, validazione e test isola l'addestramento del modello, l'ottimizzazione degli iperparametri e la valutazione finale, garantendo la capacità di generalizzazione su dati mai visti.
- Training set: utilizzato per addestrare i parametri interni del modello (ad esempio pesi e bias nelle reti neurali, soglie di divisione negli alberi di decisione).
- Validation set: utilizzato durante lo sviluppo iterativo per la selezione del modello, l'ottimizzazione degli iperparametri, la feature selection e il rilevamento dell'overfitting. Guida le decisioni su quale architettura o configurazione offra le prestazioni migliori senza intaccare i dati di valutazione finale.
- Test set: funge da campione rigorosamente riservato e rappresentativo dei dati reali di produzione. Viene valutato una sola volta alla fine del progetto per fornire una stima imparziale dell'errore di generalizzazione. Ottimizzare nuovamente i modelli in base ai risultati del test set ne invalida l'obiettività e introduce un bias ottimistico.
from sklearn.model_selection import train_test_split
from sklearn.datasets import make_classification
X, y = make_classification(n_samples=1000, n_features=10, random_state=42)
# Step 1: Split off final test set (20%)
X_dev, X_test, y_dev, y_test = train_test_split(
X, y, test_size=0.20, random_state=42, stratify=y
)
# Step 2: Split remaining development data into train (75% of dev = 60% total) and validation (25% of dev = 20% total)
X_train, X_val, y_train, y_val = train_test_split(
X_dev, y_dev, test_size=0.25, random_state=42, stratify=y_dev
)
print(f"Train size: {len(X_train)}, Val size: {len(X_val)}, Test size: {len(X_test)}")
7Qual è la differenza tra apprendimento supervisionato e non supervisionato, e in che modo la disponibilità delle etichette e gli obiettivi di business determinano quale paradigma scegliere?
Gli algoritmi di apprendimento supervisionato apprendono una mappatura matematica dalle feature di input (X) a etichette target note (y) utilizzando dati storici etichettati per stimare i risultati su nuove osservazioni non viste. L'apprendimento non supervisionato analizza invece dataset contenenti solo feature (X) per scoprire strutture intrinseche, raggruppamenti naturali (clustering) o rappresentazioni ridotte senza etichette di destinazione predefinite. La scelta tra i due paradigmi è guidata dalla disponibilità delle etichette e dagli obiettivi di business: se sono disponibili etichette di riferimento certe (ground truth) o se è fattibile raccoglierle, e l'obiettivo di business è una previsione mirata (ad esempio il rilevamento delle frodi, la stima del churn o la previsione dei prezzi), l'apprendimento supervisionato è la scelta appropriata. Se le etichette di riferimento non esistono, sono eccessivamente costose da acquisire o l'obiettivo è un'esplorazione aperta (come la segmentazione dei clienti o il rilevamento di anomalie senza etichette note), si opta per l'apprendimento non supervisionato.
import numpy as np
from sklearn.linear_model import LogisticRegression
from sklearn.cluster import KMeans
X = np.array([[10, 2], [12, 3], [1, 8], [2, 9]])
y = np.array([0, 0, 1, 1])
# Supervised: Learns mapping X -> y
clf = LogisticRegression().fit(X, y)
# Unsupervised: Discovers clusters directly from X
kmeans = KMeans(n_clusters=2, random_state=42, n_init=10).fit(X)
8Cos'è una North Star Metric (metrica stella polare) e come si distingue una North Star efficace da una metrica di vanità (vanity metric) quando si valuta lo stato di salute di un prodotto?
Una North Star Metric (NSM) è la metrica principale che cattura al meglio il valore fondamentale offerto da un prodotto ai propri clienti, guidando al contempo risultati di business sostenibili (ad esempio, "Notti prenotate" per Airbnb o "Ore settimanali di streaming attivo" per una piattaforma musicale). Allinea i team di prodotto attorno al valore per il cliente a lungo termine piuttosto che a una crescita superficiale.
Per distinguere una North Star efficace da una vanity metric:
1. Allineamento del valore: una North Star efficace riflette l'utilità reale per l'utente e il coinvolgimento attivo, mentre una vanity metric misura volumi superficiali (come gli utenti registrati totali, i download cumulativi dell'app o le visualizzazioni di pagina grezze) che possono crescere anche quando gli utenti abbandonano immediatamente l'app.
2. Azionabilità e correlazione: una North Star efficace si correla alla retention degli utenti, alla salute del prodotto e alla monetizzazione, rispondendo direttamente ai miglioramenti qualitativi del prodotto. Spesso le metriche di vanità non possono essere collegate a un'autentica retention o alla solidità del business e sono soggette a inflazione superficiale.
Platform: Vacation Rental App
Vanity Metric: Cumulative app downloads (increases continuously even if 95% of users uninstall immediately).
North Star Metric: Nights booked per active user (reflects actual value exchange between guests and hosts).
9Qual è la differenza pratica tra data drift e concept drift, e perché classificarli correttamente è essenziale per la manutenzione del modello dopo il rilascio?
Il data drift (spesso definito covariate shift) si verifica quando la distribuzione statistica delle feature di input P(X) cambia nel tempo, mentre la relazione condizionale tra gli input e la variabile target P(Y|X) rimane invariata. Al contrario, il concept drift si verifica quando cambia la relazione sottostante tra gli input e il target P(Y|X), il che significa che valori identici delle feature corrispondono ora a comportamenti o risultati target differenti. Classificarli correttamente è fondamentale per la manutenzione post-rilascio perché le relative strategie di risoluzione differiscono in modo sostanziale. Con il data drift, i pattern storici rimangono validi; la manutenzione si concentra sull'estensione della copertura di addestramento a nuove regioni di feature, sull'aggiornamento del preprocessing o sull'applicazione del ricalcolo dei pesi dei campioni. Con il concept drift, le etichette storiche non riflettono più la realtà attuale; la manutenzione richiede la raccolta di nuovi dati etichettati, la rimozione degli esempi storici obsoleti e il riaddestramento o la riprogettazione del modello.
# Data Drift (Covariate Shift):
# User demographics or devices change (P(X) shifts),
# but genuine vs fraudulent transaction patterns remain identical (P(Y|X) unchanged).
# Concept Drift:
# Fraudsters adapt tactics to mimic normal shopping patterns;
# identical feature inputs now have a higher probability of fraud (P(Y|X) shifts).
10Qual è la differenza tra un parametro di popolazione e una statistica campionaria, e in che modo la variabilità campionaria influisce sull'interpretazione delle metriche?
Un parametro di popolazione è una caratteristica numerica fissa, tipicamente non nota, di un'intera popolazione (come la vera media della popolazione μ o la proporzione p). Una statistica campionaria è un valore sintetico calcolato a partire dai dati osservati di un campione (come la media campionaria x̄ o la proporzione campionaria p̂), utilizzato per stimare il parametro sconosciuto. La variabilità campionaria si riferisce alla variazione naturale delle statistiche campionarie tra diversi campioni casuali estratti dalla stessa popolazione. A causa della variabilità campionaria, qualsiasi metrica calcolata su un singolo campione è soggetta a errore casuale e raramente corrisponde con esattezza al vero parametro della popolazione. Nell'interpretazione delle metriche, non tenere conto di questa variabilità porta a scambiare il rumore casuale per un cambiamento reale. Gli analisti devono quantificare l'incertezza della stima utilizzando errori standard, intervalli di confidenza o test di ipotesi prima di concludere che una differenza osservata sia reale.
import numpy as np
# True population parameter (mean = 50, standard deviation = 10)
pop_mean = 50.0
pop_std = 10.0
# Draw multiple independent samples of size n=30
np.random.seed(42)
sample_means = [np.mean(np.random.normal(pop_mean, pop_std, size=30)) for _ in range(5)]
for i, sm in enumerate(sample_means, 1):
print(f"Sample {i} Mean (Statistic): {sm:.2f} | Error: {sm - pop_mean:+.2f}")
11Uno stakeholder pone una domanda ambigua come "La funzionalità Y funziona?". Come riformuli questa richiesta in un framework di analisi misurabile e orientato alle decisioni?
Quando uno stakeholder chiede "La funzionalità Y funziona?", inizio scomponendo la domanda nel suo intento sottostante: quale problema è stata creata per risolvere la funzionalità Y, a chi è destinata e quale decisione verrà presa in base alla risposta (ad esempio iterare, scalare o dichiarare deprecata la funzionalità)? Definisco quindi un framework di misurazione a più livelli composto da: 1. Adozione e coinvolgimento: gli utenti target scoprono e utilizzano la funzionalità come previsto? 2. Valore diretto / successo dell'attività: gli utenti completano con successo il flusso di lavoro principale abilitato dalla funzionalità? 3. Impatto aziendale a valle: l'adozione della funzionalità è correlata o traina metriche chiave di primo piano (ad esempio fidelizzazione, conversione, ricavi)? 4. Guardrail: la funzionalità ha generato effetti collaterali negativi indesiderati (ad esempio aumento della latenza, ticket di supporto, cannibalizzazione)? Infine, pre-concordo le soglie decisionali e i criteri di valutazione con lo stakeholder prima di eseguire l'analisi, garantendo l'allineamento su cosa costituisca il successo ed evitando di spostare gli obiettivi a posteriori.
Feature: Quick Checkout Button
1. Primary Decision: Keep & expand vs. Redesign vs. Deprecate
2. Evaluation Metrics:
- Adoption: % of checkout sessions clicking the quick button (Target: >= 15%)
- Funnel Completion: Checkout completion rate given button click (Target: >= 75%)
- Business Metric: Overall cart conversion lift (Target: +1.5% in A/B test)
- Guardrail: Support tickets for accidental purchases (Threshold: < 0.2% increase)
3. Pre-agreed Action Plan:
- If Target Met: Roll out to 100% and promote to mobile app.
- If Adoption Low but Completion High: Retain, optimize UI discovery.
- If Guardrail Exceeded: Halt rollout, add confirmation step.
12Durante la preparazione (data wrangling) di un dataset con una presenza considerevole di valori mancanti, come si sceglie tra analisi dei casi completi (complete-case analysis), imputazione semplice, flag indicatori di dato mancante e imputazione basata su modelli?
La scelta di una strategia per la gestione dei dati mancanti dipende principalmente dal meccanismo di assenza (MCAR, MAR, MNAR), dalla percentuale di dati mancanti, dalla destinazione d'uso finale (inferenza statistica rispetto a modellazione predittiva) e dal rischio di bias:
1. **Analisi dei casi completi (Complete-Case Analysis / rimozione delle righe):** Adeguata solo quando i dati mancano in modo completamente casuale (MCAR, Missing Completely at Random) e la quota mancante è minima (ad esempio <5%). Se i dati sono Missing at Random (MAR) o Not at Random (MNAR), eliminare le righe introduce un forte bias di selezione ed elimina potere campionario prezioso.
2. **Imputazione semplice (Media/Mediana/Moda):** Rapida e pratica per modelli predittivi di baseline, ma rischiosa per l'analisi statistica poiché riduce artificialmente la varianza delle feature, gonfia le statistiche dei test e distorce la struttura delle covarianze.
3. **Flag indicatori di dato mancante (Imputazione + flag binario):** Ideale per la modellazione predittiva (soprattutto con algoritmi basati su alberi) e nei casi in cui l'assenza del dato è informativa (MNAR, come nei campi opzionali non compilati). Preserva il segnale del dato mancante senza corrompere le distribuzioni numeriche valide.
4. **Imputazione basata su modelli (KNN, MICE, Iterative Imputer):** Preferibile quando i dati sono MAR, le correlazioni tra variabili sono forti ed è fondamentale preservare le relazioni multivariate o gli errori standard dei parametri (ad esempio nell'inferenza della regressione). Gli svantaggi sono la complessità computazionale, l'overhead di implementazione nelle pipeline di produzione e il rischio di data leakage se il fit non viene eseguito rigorosamente solo sui fold di addestramento.
from sklearn.impute import SimpleImputer
import pandas as pd
df = pd.DataFrame({'income': [50000, None, 75000, None, 120000]})
# Impute median while tracking missingness pattern
imputer = SimpleImputer(strategy='median', add_indicator=True)
imputed_data = imputer.fit_transform(df)
# Returns: [income_imputed, income_is_missing]
13Un team di prodotto confronta gli utenti che hanno attivato volontariamente una nuova funzionalità con quelli che non l'hanno fatto, rilevando un tasso di retention superiore del 20%. In che modo diagnosticheresti il bias di selezione e il confondimento, e come riprogetteresti la valutazione?
Il confronto tra utenti che hanno scelto di aderire (opt-in) e utenti che non l'hanno fatto risente del bias di autoselezione e del confondimento. Gli utenti che scelgono attivamente di adottare una nuova funzionalità presentano in genere un livello di base più elevato di interesse, engagement o competenza tecnica. Di conseguenza, la differenza del 20% osservata nella retention confonde il vero effetto causale della funzionalità con la motivazione preesistente dell'utente. Diagnosi del bias: 1. Confronto delle covariate pre-trattamento: confrontare gli attributi di base tra la coorte opt-in e quella non-opt-in prima dell'introduzione della funzionalità (ad es. attività storica, retention passata, anzianità dell'account, frequenza delle transazioni, composizione dei dispositivi). Differenze significative confermano la presenza di confondimento. 2. Verifiche sui trend pregressi / test placebo: valutare se gli utenti opt-in mostravano già una retention o un engagement più elevati nei periodi precedenti al lancio della funzionalità. Riprogettazione della valutazione: - Esperimento randomizzato (standard di riferimento): implementare un Randomized Encouragement Design (o un rilascio randomizzato della funzionalità). Tutti gli utenti idonei vengono assegnati casualmente al gruppo di Trattamento (a cui viene offerta la funzionalità / prompt) e di Controllo (a cui non viene offerta). Analizzare utilizzando l'Intention-to-Treat (ITT) per l'effetto complessivo dell'offerta e le Variabili Strumentali / Two-Stage Least Squares (2SLS) utilizzando l'assegnazione come strumento per stimare il Local Average Treatment Effect (LATE) sugli adottanti attivi. - Approcci quasi-sperimentali (se la randomizzazione non è fattibile): utilizzare il Propensity Score Matching (PSM), la Difference-in-Differences (DiD) o il Synthetic Control per controllare i fattori di confondimento osservabili alla baseline e i trend paralleli preesistenti.
import statsmodels.formula.api as smf
import pandas as pd
# df columns: ['user_id', 'post_period', 'opted_in', 'retained']
# Interaction term captures causal lift above baseline group differences
model = smf.ols('retained ~ opted_in + post_period + opted_in:post_period', data=df).fit()
print(model.summary().tables[1])
14Come progetteresti la segmentazione delle coorti per un'analisi di attivazione o retention per evitare che i confronti siano falsati da cambiamenti nella composizione del campione (mix shifts) o dal troncamento temporale (maturity truncation)?
Per progettare suddivisioni di coorti che evitino mix shift e maturity truncation: 1. **Standardizzare le finestre di anzianità (tenure windows)**: Allineare le coorti in base all'anzianità relativa (ad esempio, Giorno 0, Giorno 7, Giorno 30 dopo la registrazione/attivazione) anziché alle date di calendario, in modo da garantire confronti equi lungo il ciclo di vita. 2. **Gestire il troncamento temporale (Right-Censoring)**: Valutare solo le coorti che hanno completato l'intera finestra di osservazione. Escludere o contrassegnare esplicitamente le coorti recenti che non hanno ancora avuto a disposizione il tempo necessario per raggiungere il traguardo. 3. **Mitigare le variazioni di composizione (mix shifts)**: Segmentare le coorti lungo dimensioni influenti e confondenti (quali canale di acquisizione, piattaforma, paese o intento dell'utente). Se si riporta un valore aggregato, utilizzare una ponderazione tramite standardizzazione/post-stratificazione per evitare che le variazioni nel mix delle fonti di acquisizione distorcano il trend di retention rilevato.
WITH user_cohorts AS (
SELECT
user_id,
DATE_TRUNC('week', signup_time) AS cohort_week,
signup_time,
acquisition_channel
FROM users
-- Exclude cohorts that have not reached 7 full days of maturity
WHERE signup_time <= CURRENT_DATE - INTERVAL '7 days'
),
user_activity AS (
SELECT DISTINCT
c.user_id,
c.cohort_week,
c.acquisition_channel,
1 AS retained_d7
FROM user_cohorts c
JOIN events e ON c.user_id = e.user_id
WHERE e.event_time >= c.signup_time + INTERVAL '7 days'
AND e.event_time < c.signup_time + INTERVAL '8 days'
)
SELECT
c.cohort_week,
c.acquisition_channel,
COUNT(c.user_id) AS cohort_size,
COUNT(a.user_id) AS d7_active_users,
ROUND(100.0 * COUNT(a.user_id) / COUNT(c.user_id), 2) AS d7_retention_pct
FROM user_cohorts c
LEFT JOIN user_activity a ON c.user_id = a.user_id
GROUP BY 1, 2
ORDER BY 1 DESC, 2;
15Durante la valutazione, il modello ottiene una metrica insolitamente alta come un'AUC (Area Under the Curve) pari a 0,99, ma le prestazioni crollano nei test shadow. Come isoli e verifichi sistematicamente il target leakage?
Quando un modello ottiene una metrica offline irrealisticamente alta (ad esempio un'AUC pari a 0,99) che crolla nei test shadow in produzione, il target leakage è il principale indiziato. Un flusso di lavoro sistematico di isolamento e verifica comprende: 1. Importanza delle feature e attribuzione: calcolare i valori SHAP, le metriche di guadagno (gain) o la permutation importance per identificare le feature candidate con potere predittivo dominante. 2. Modelli a singola feature e studi di ablazione: addestrare modelli semplici a 1 feature (ad esempio alberi decisionali poco profondi o regressione logistica) sulle singole feature sospette. Se una singola feature ottiene una classificazione quasi perfetta, è molto probabile che stia causando target leakage. Rimuovere sequenzialmente le feature sospette e misurare il calo delle prestazioni offline. 3. Controllo della cronologia temporale e dei timestamp: verificare i timestamp esatti di creazione/aggiornamento delle feature candidate rispetto al timestamp limite di previsione (cutoff). Verificare se il valore della feature poteva essere noto solo dopo il verificarsi dell'evento target (ad esempio `cancellation_reason` o `refund_status` compilati al momento dell'abbandono/storno). 4. Lineage dei dati e verifica ingegneristica: esaminare la pipeline di dati a monte e la logica di mutazione delle tabelle (ad esempio tabelle mutabili aggiornate sul posto rispetto a log immutabili di solo accodamento) per verificare quando i campi vengono popolati.
from sklearn.metrics import roc_auc_score
from sklearn.tree import DecisionTreeClassifier
leakage_candidates = {}
for col in X_train.columns:
clf = DecisionTreeClassifier(max_depth=2)
clf.fit(X_train[[col]], y_train)
preds = clf.predict_proba(X_test[[col]])[:, 1]
auc = roc_auc_score(y_test, preds)
if auc > 0.85:
leakage_candidates[col] = auc
print("Candidate Leaky Features:", leakage_candidates)
16Come scegli tra la validazione incrociata K-Fold standard, Stratified K-Fold e Group K-Fold quando valuti dati strutturati reali?
La scelta tra K-Fold standard, Stratified K-Fold e Group K-Fold dipende dalla distribuzione della variabile target e dall'indipendenza delle righe:
1. **K-Fold standard**: suddivide i dati in modo casuale in K fold di uguali dimensioni. Presuppone che le osservazioni siano indipendenti e identicamente distribuite (IID, independent and identically distributed) ed è tipicamente utilizzata per target di regressione continui o dataset ben bilanciati.
2. **Stratified K-Fold**: assicura che ciascun fold mantenga la stessa percentuale delle classi del target rispetto all'intero dataset. È fondamentale per compiti di classificazione, in particolare in presenza di classi sbilanciate, per evitare che alcuni fold contengano troppi pochi campioni della classe di minoranza o nessuno.
3. **Group K-Fold**: garantisce che gruppi o entità distinte (ad esempio `user_id`, `patient_id`, `device_id`) non compaiano contemporaneamente nei fold di addestramento e di validazione. Quando più osservazioni provengono dalla stessa entità, una suddivisione standard causa una grave dispersione di dati (data leakage), poiché il modello memorizza caratteristiche specifiche dell'entità invece di apprendere segnali generalizzabili. Group K-Fold valuta l'effettiva capacità del modello di generalizzare su entità del tutto nuove.
17Come si sceglie tra regressione logistica, GBDT (Gradient Boosted Decision Tree) e architetture neurali non lineari per la classificazione di dati tabulari in presenza di vincoli di latenza e drift?
La scelta tra regressione logistica (LR, Logistic Regression), GBDT (Gradient Boosted Decision Tree) e reti neurali (NN) per la classificazione tabulare richiede di bilanciare accuratezza predittiva, budget di latenza di inferenza, spiegabilità e resilienza al data drift.
1. La regressione logistica eccelle in ambienti a bassissima latenza (<1-5ms p99) e con budget computazionali molto limitati. Poiché il calcolo del punteggio è un semplice prodotto scalare, risulta estremamente veloce e robusta. In condizioni di covariate drift o valori delle feature al di fuori della distribuzione, i modelli lineari estrapolano monotonicamente, il che può risultare prevedibile o rischioso a seconda delle pendenze regolarizzate, ma raramente genera comportamenti erratici a gradino. Tuttavia, la LR richiede un esteso feature engineering manuale (interazioni, binning non lineare) per raggiungere le prestazioni delle architetture non lineari.
2. I GBDT (ad es. XGBoost, LightGBM, CatBoost) rappresentano il benchmark predefinito del settore per i dati tabulari. Catturano nativamente interazioni complesse non lineari e gestiscono agevolmente tipi di dati eterogenei e valori mancanti. In termini di latenza, i GBDT ottimizzati (o compilati tramite Treelite/ONNX) soddisfano facilmente SLA inferiori a 10ms. In presenza di drift, i GBDT non possono estrapolare oltre i limiti osservati durante l'addestramento (bloccando le predizioni sulle foglie estreme), offrendo una protezione integrata contro estrapolazioni anomale, ma rischiando predizioni costanti e obsolete se le distribuzioni delle feature subiscono variazioni significative.
3. Le architetture neurali (ad es. FT-Transformer, TabNet, MLP) sono preferibili quando i dati tabulari sono multimodali (combinati con testo, embedding o immagini) o in scenari di apprendimento continuo online. Tuttavia, le NN esclusivamente tabulari presentano solitamente latenze di inferenza più elevate (richiedendo moltiplicazioni di matrici su più livelli o accelerazione GPU), sono più onerose da addestrare dal punto di vista computazionale e sono fortemente sensibili a input non scalati e al covariate drift.
In pratica: si parte con i GBDT come solida baseline prestazionale; se sono imposti requisiti rigorosi di latenza nell'ordine dei microsecondi o di semplice spiegabilità, si implementa la LR; si utilizzano le NN principalmente per architetture multimodali o per il trasferimento di embedding.
decision_matrix = {
"Logistic Regression": {"Latency": "<1ms (Ultra-low)", "Drift Behavior": "Linear extrapolation", "Tabular Baseline": "Moderate (needs feature engineering)"},
"GBDT (XGB/LightGBM)": {"Latency": "1-15ms (Fast)", "Drift Behavior": "Leaf clamping (no extrapolation)", "Tabular Baseline": "State of the Art"},
"Tabular Neural Net": {"Latency": "10-50ms+ (Higher)", "Drift Behavior": "Nonlinear extrapolation", "Tabular Baseline": "Competitive / High tuning cost"}
}
for model, traits in decision_matrix.items():
print(f"{model}: Latency={traits['Latency']}, Tabular Perf={traits['Tabular Baseline']}")
18La leadership deve decidere se procedere con il lancio di una funzionalità su scala nazionale in condizioni di incertezza, tra risultati di sperimentazione regionale contrastanti e finestre di lancio fisse. Come struttureresti il framework per la raccomandazione strategica?
Per strutturare una raccomandazione strategica a fronte di risultati regionali eterogenei e finestre di lancio rigide, occorre superare la logica di una scelta binaria del tipo go/no-go. In primo luogo, occorre scomporre i risultati aggregati identificando gli effetti eterogenei del trattamento tra segmenti di mercato, coorti di clienti e contesti operativi, per isolare dove la funzionalità ha successo, dove è in stallo e dove produce impatti negativi. In secondo luogo, bisogna definire una strategia di rilascio progressivo con copertura del rischio (come un rilascio a fasi regionali o deployment canary) che dia priorità ai segmenti ad alta confidenza isolando i rischi di coda negativi. In terzo luogo, vanno stabiliti parametri di salvaguardia (guardrail metrics) espliciti e prestabiliti, insieme a meccanismi automatici di interruzione (circuit breaker) e soglie di rollback per limitare gli scenari peggiori. Infine, la comunicazione verso l'executive team va impostata sul valore atteso, sul rischio asimmetrico di ribasso rispetto al costo commerciale di perdere la finestra fissa e su piani operativi (playbook) per correzioni di rotta in corso d'opera.
| Rollout Tier | Target Markets | Launch Exposure | Guardrail Circuit-Breaker | Expected Value / Risk Profile |
|---|---|---|---|---|
| Tier 1: Immediate Launch | Cohorts with stat-sig positive lift (e.g., Regions A, C) | 100% | Rollback if 48h conversion drops > 1.5% | High upside; verified market fit |
| Tier 2: Phased Staging | High-variance / neutral cohorts (e.g., Region B) | 10% -> 25% -> 50% over 14 days | Hold expansion if CSAT drops > 2.0% | Moderate upside; bounded downside |
| Tier 3: Hold & Re-test | Stat-sig negative cohorts (e.g., Region D) | 0% (Holdout / internal testing) | Launch blocked until root-cause resolution | Eliminates primary churn risk |
19Come progetteresti l'architettura di un livello semantico centralizzato su un data warehouse aziendale per garantire definizioni coerenti delle metriche di business tra diversi team di analytics?
La progettazione di un livello semantico centralizzato su un data warehouse aziendale richiede l'adozione di un layer dichiarativo e basato su codice per la definizione delle metriche (come MetricFlow/dbt Semantic Layer, Cube o LookML), in grado di disaccoppiare la logica di business dall'archiviazione fisica e dagli strumenti di fruizione a valle (piattaforme di BI, notebook Python/R, API). L'architettura principale definisce entità, dimensioni, misure e metriche derivate all'interno di repository con controllo di versione (Git), fornendo un'unica fonte di verità ed evitando discrepanze tra i team. Per supportare il multi-tenancy e la governance tra diverse business unit, è opportuno adottare un modello di governance federato: i KPI aziendali principali (ad esempio, ARR, utenti attivi) sono gestiti da un team centrale di data governance, mentre le metriche specifiche di dominio sono curate dai rispettivi team decentralizzati tramite modelli semantici isolati e convalidati tramite CI/CD. Il livello semantico espone quindi interfacce di query standardizzate (SQL, GraphQL, REST) con controllo degli accessi basato sui ruoli unificato e meccanismi di caching e pre-aggregazione per garantire elevate prestazioni e coerenza.
semantic_model:
name: orders
node_relation:
alias: fct_orders
dimensions:
- name: order_date
type: time
type_params:
time_granularity: day
- name: country
type: categorical
measures:
- name: total_revenue
expr: revenue_usd
agg: sum
- name: distinct_buyers
expr: user_id
agg: count_distinct
metrics:
- name: average_order_value
description: "Governed metric for AOV across all BI tools"
type: ratio
type_params:
numerator: total_revenue
denominator: distinct_buyers
20In un marketplace a due versanti (come le piattaforme di ridesharing o l'e-commerce), come progetteresti un esperimento per valutare una modifica all'algoritmo di matching tenendo conto della cannibalizzazione tra domanda e offerta e dell'interferenza spazio-temporale?
Nei marketplace a due versanti, la valutazione degli algoritmi di matching tramite normali A/B test a livello di utente viola l'ipotesi di non interferenza (SUTVA, Stable Unit Treatment Value Assumption). Quando le unità del gruppo di trattamento consumano risorse condivise scarse (come driver o scorte di magazzino), cannibalizzano le unità di controllo, causando un degrado fittizio del gruppo di controllo e una sovrastima dell'effetto del trattamento dovuta agli spostamenti dell'equilibrio di mercato. Per gestire l'interferenza spaziale e temporale, si adottano principalmente due architetture sperimentali: la randomizzazione basata su cluster e gli esperimenti switchback. Nella randomizzazione per cluster spaziali, mercati geografici o sotto-regioni isolate (ad esempio aree metropolitane distinte o celle spaziali esagonali partizionate su grafo) vengono assegnati casualmente al trattamento o al controllo. Questo approccio isola le interazioni dirette tra domanda e offerta, sebbene richieda metodi come i controlli sintetici o il difference-in-differences per gestire l'eterogeneità tra mercati. Negli esperimenti switchback (a finestre temporali alternate), interi mercati isolati alternano gli algoritmi di trattamento e controllo attraverso finestre temporali discrete (ad esempio alternando ogni 1-2 ore). Gli switchback mantengono l'equilibrio tra domanda e offerta all'interno dello stesso mercato in ciascuna finestra, ma introducono un bias di trascinamento temporale (carryover bias). Per mitigare tale bias, si introducono periodi di transizione o di washout tra una finestra e l'altra (scartando gli ordini durante le transizioni di stato) e si scelgono finestre temporali sufficientemente lunghe da riassorbire il riposizionamento dell'offerta, ma abbastanza brevi da preservare la potenza statistica. L'analisi deve infine tenere conto della correlazione seriale degli errori nelle serie storiche, raggruppando gli standard error a livello di blocco temporale o di mercato oppure ricorrendo a GEE (Generalized Estimating Equations) o stimatori di varianza di Newey-West.
import pandas as pd
import numpy as np
def generate_switchback_schedule(n_days=14, window_minutes=60, washout_minutes=15):
total_windows = int((n_days * 24 * 60) / window_minutes)
np.random.seed(42)
treatments = np.random.binomial(1, 0.5, size=total_windows)
schedule = []
for i, trt in enumerate(treatments):
start_min = i * window_minutes
eval_start_min = start_min + washout_minutes
end_min = (i + 1) * window_minutes
schedule.append({
'window_id': i,
'treatment': trt,
'start_min': start_min,
'eval_start_min': eval_start_min,
'end_min': end_min
})
return pd.DataFrame(schedule)