import pandas as pd

Quantitative and qualitative research for decisions

Le decisioni migliori nascono quasi sempre dall’incrocio di due tipi di evidenza. I numeri dicono quanto è grande un fenomeno e dove si concentra; la ricerca qualitativa spiega perché accade e cosa significa per chi lo vive. Questa lezione tratta i due approcci non come rivali, ma come metodi che si correggono a vicenda. La domanda di fondo non è quale sia la definizione corretta, ma quale scelta diventa meno rischiosa quando l’analisi è fatta bene.

Quando il numero non basta

Il problema reale non è conoscere la differenza tra metodo quantitativo e qualitativo in astratto. Il problema è decidere cosa fare quando hai dati incompleti, metriche ambigue o vincoli tecnici che rendono fragile la lettura. Una buona analisi separa il segnale dal rumore, dichiara la baseline che usa e indica quale azione diventa più difendibile dopo averla letta.

Il caso di Airbnb chiarisce il punto meglio di qualsiasi schema. L’azienda lavora con una cultura di ricerca mista. Quando notarono che gli host in Giappone avevano un tasso di risposta più basso, i dati quantitativi mostravano il problema ma non la causa. Le interviste qualitative rivelarono che gli host giapponesi trovavano scortese rispondere con messaggi brevi e preferivano non rispondere piuttosto che sembrare bruschi. La soluzione fu un template di risposta culturalmente appropriato, non una modifica tecnica. Il tasso di risposta salì del 21%.

Una mappa per impostare l’analisi

Prima di calcolare qualsiasi cosa conviene seguire una sequenza che lega la decisione al dato e all’azione. La tabella sotto serve proprio a evitare che un concetto tecnico diventi un rituale vuoto: ogni riga deve rendere più chiaro il costo di una scelta sbagliata.

Step	Question to ask	Expected output
Decision	Che cosa cambia se capiamo meglio il fenomeno?	Scelta esplicita
Signal	Quale dato osservabile riduce l’incertezza?	Metrica o evento
Baseline	Rispetto a cosa interpretiamo il risultato?	Credible comparison
Vincolo	Che cosa può falsare la lettura?	Assunzione da dichiarare
Action	Quale passo operativo segue?	Raccomandazione controllabile

Nel contesto della gestione data driven, la prima domanda non è quale metrica calcolare, ma quale decisione dovrà essere presa grazie all’analisi. Una dashboard, una query o un modello statistico hanno valore solo se riducono incertezza decisionale. Se non cambiano una scelta, sono documentazione o teatro analitico.

Rendere visibili le assunzioni

Formalizzare la lezione significa scriverla come una relazione tra decisione, evidenza e rischio. Non serve a complicare, serve a rendere discutibili le assunzioni, così uno stakeholder può criticare 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 può restare anche dopo l’analisi	Sensitivity check o revisione qualitativa

Una formalizzazione è solida quando un altro analista può riprodurre la logica, criticare le assunzioni e arrivare alla stessa decisione partendo dagli stessi dati. Survey e interviste, per esempio, danno segnali diversi: il quantitativo misura ampiezza e priorità, il qualitativo chiarisce meccanismo e linguaggio. La decisione diventa più solida quando i due metodi si correggono invece di competere.

Qualitative methods for the analyst

La ricerca qualitativa ha strumenti precisi che non richiedono campioni enormi. Cinque-otto user interview bastano per identificare i pattern principali, come mostrava Nielsen già nel 2000; non servono cinquanta interviste. Le session recording (Hotjar, FullStory) ti fanno guardare dieci-venti sessioni reali di utenti che abbandonano il funnel, e i problemi di UX saltano all’occhio. Una survey in-app con una domanda mirata nel momento esatto dell’abbandono, del tipo “Cosa ti ha fermato?”, ottiene un tasso di risposta tre-cinque volte superiore alle survey via email. Anche i support ticket sono dati qualitativi strutturati: categorizzali per topic e cerca i trend.

Integrate quantitative and qualitative into the workflow

Il flusso più affidabile alterna i due metodi invece di scegliere l’uno o l’altro. Funziona così.

1. Il dato quantitativo segnala un problema: il tasso di abbandono al checkout è salito dal 62% al 71%.
2. L’indagine qualitativa rivela la causa: le session recording mostrano che il form di pagamento si blocca su mobile.
3. L’ipotesi viene testata di nuovo coi numeri: il tasso di abbandono su mobile è 78% contro 52% su desktop.
4. La soluzione viene implementata e misurata: si corregge il form e si monitora il tasso di abbandono.

Questo va contro l’istinto di lavorare subito su dati aggregati. Una media globale può nascondere due segmenti che si muovono in direzioni opposte, e qui il qualitativo serve proprio a capire quale segmento osservare da vicino.

Netflix e la disciplina delle metriche

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, viene trattato come infrastruttura decisionale.

Quando Netflix valuta una modifica all’esperienza, per esempio una nuova riga di raccomandazioni, una diversa immagine di copertina o un algoritmo di ranking, non misura solo il click immediato. Guarda anche segnali di qualità: l’utente guarda davvero il contenuto, torna nei giorni successivi, riduce il tempo speso a cercare. Questa disciplina impedisce di ottimizzare vanity metric che sembrano positive nel breve periodo ma erodono valore nel lungo. Lo stesso principio vale qui: se il risultato non aiuta a scegliere tra due azioni alternative, l’analisi è incompleta.

SQL example: building a control view

Il pattern seguente è volutamente generico ma eseguibile nella maggior parte dei warehouse moderni. L’obiettivo è creare una base analitica con metrica, segmento e finestra temporale, così da 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;

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 qui l’analista formula ipotesi più precise, che poi conviene approfondire con metodi qualitativi.

Python example: checking stability and anomalies

Una metrica utile deve essere stabile abbastanza da orientare le decisioni e sensibile abbastanza da segnalare i cambiamenti reali. In Python puoi controllare le variazioni anomale settimana su settimana.

# 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 del controllo è pratico: eviti di reagire a ogni oscillazione casuale, ma vedi subito quando una variazione merita un’indagine. In azienda questo tipo di analisi alimenta gli alert, le review settimanali e le retrospettive di prodotto.

Errori tipici e come evitarli

Il primo errore è lavorare su dati aggregati troppo presto, perché la media nasconde i 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à: se chi usa una feature converte di più, non significa che la feature causi la conversione, potrebbe semplicemente attirare utenti già motivati.

C’è poi un errore più sottile, che è usare l’analisi 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. Il dato sembra preciso ma non guida nulla. Per ridurre tutti questi rischi, ogni analisi dovrebbe contenere almeno la definizione esplicita della metrica, il confronto per segmento e la verifica contro un periodo precedente o un gruppo di controllo.

Esercizio applicato

Parti dal livello base: scrivi in cinque righe quale decisione concreta dovrebbe migliorare grazie all’integrazione tra quanti e quali, indicando 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 e azione consigliata. Inserisci almeno un caso in cui il segnale da solo non basta per decidere, così sei costretto a chiamare in causa la ricerca qualitativa.

Al livello research-grade trasforma l’esercizio in un memo decisionale completo di assunzioni, criteri di esclusione, soglia di intervento, sensitivity check e proposta di monitoraggio dopo la decisione. Come materiale usa un export reale, una dashboard interna, OKR, decision log, retrospettive, interviste o survey. Se non hai dati reali, crea un dataset sintetico con almeno 200 righe, una dimensione temporale, una dimensione di segmento e una metrica di outcome.

Checkpoint

Prima di chiudere, verifica di saper rispondere a queste cinque domande.

1. Quale decisione concreta dovrebbe migliorare grazie a questa analisi?
2. Which unit of analysis makes the problem measurable?
3. Quale baseline useresti per evitare una lettura isolata?
4. Quale assunzione, se falsa, cambierebbe la conclusione?
5. Quale controllo presenteresti prima di raccomandare un’azione?

Summary

Integrare ricerca quantitativa e qualitativa è uno strumento decisionale, non un argomento da manuale. Il valore nasce quando colleghi problema, dati, metrica, segmentazione e azione, e quando lasci che i numeri dicano l’ampiezza e le interviste dicano la causa. Una buona analisi 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.