import pandas as pd

Quickstart: data collection in 30 minutes

In mezz’ora non costruisci una piattaforma dati completa, ma puoi evitare gli errori che rendono inutili i primi report: eventi senza definizione, proprietà incoerenti, identità non risolta e nessun test di qualità. Questo quickstart guida un primo setup piccolo, verificabile e già governato. Trattalo come una prova controllata: scegli pochi eventi, definiscili bene, inviali in modo ripetibile e controlla subito che arrivino dove devono. La velocità qui non significa saltare la governance, ma ridurla alla forma minima che impedisce ambiguità.

Il problema vero

Il problema non è conoscere la data collection in astratto, ma decidere cosa fare quando hai dati incompleti, metriche ambigue o vincoli tecnici che rendono fragile la lettura di un fenomeno. Una guida utile separa il segnale dal rumore, dice quale baseline usare e indica quale azione diventa più difendibile dopo l’analisi.

La prima domanda non è “quale metrica calcolo?” ma quale decisione dovrà essere presa grazie a questi dati. Una dashboard o una query hanno valore solo se riducono l’incertezza di una scelta. Se non cambiano nulla, sono documentazione o teatro analitico.

Come ragionare prima di tracciare

Conviene tenere a mente una sequenza che lega la decisione al dato e al rischio, così una nozione tecnica non diventa un rituale vuoto. Ogni passaggio dovrebbe rendere più chiaro quanto costa una scelta sbagliata.

Step	Question to ask	Expected output
Decision	Che cosa cambia se tracciamo bene questi eventi?	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

Rendere esplicite le assunzioni

Una formalizzazione minima rende visibili le assunzioni, così uno stakeholder può discutere il criterio invece di fidarsi del risultato per autorità. Definisci l’unità di analisi, la variabile che osservi, la baseline, la soglia che fa cambiare l’azione e il rischio che resta.

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

Fase 1: setup di Segment (10 min)

Si parte dall’infrastruttura minima.

1. Crea un account gratuito su segment.com
2. Crea una “Source” di tipo JavaScript Website
3. Copy the analytics.js snippet into your site
4. Connetti una “Destination”, per esempio Google Sheets o PostgreSQL come warehouse gratuito

Fase 2: primi eventi (10 min)

Tre chiamate coprono i casi fondamentali: associare un utente, registrare un’azione di business e tracciare la navigazione.

// Identify: associate anonymous user to known ID
analytics.identify('user_123', {
  email: 'test@example.com',
  plan: 'pro',
  signup_date: '2024-01-15'
});

// Track: business event
analytics.track('Product Added to Cart', {
  product_id: 'SKU-456',
  product_name: 'Premium Hoodie',
  price: 49.99,
  quantity: 1,
  size: 'L'
});

// Page: navigation
analytics.page('Product Page', {
  name: 'Premium Hoodie',
  category: 'Apparel',
  url: '/products/premium-hoodie'
});

Fase 3: validazione (5 min)

Prima di fidarti dei dati, verifica che arrivino. Apri il Segment Debugger per vedere gli eventi in tempo reale, controlla che raggiungano la destination su Google Sheets o PostgreSQL e accertati che tutte le proprietà siano presenti e ben tipate.

Fase 4: definizione del tracking plan (5 min)

Documenta su un foglio Google Sheets l’evento Product Added to Cart, le sue proprietà con i tipi (product_id string, price number, quantity int), la fonte (web app, pagina prodotto), la metrica che alimenta (Add-to-Cart Rate, Conversion Funnel) e l’owner (Product Team). Questa scheda è ciò che impedisce a due persone di intendere lo stesso evento in modi diversi.

Final checklist

A fine setup dovresti poter spuntare cinque punti: SDK caricato sul sito, almeno tre eventi implementati (identify, track, page), eventi visibili nel debugger e nella destination, tracking plan documentato e un alert configurato se il volume di eventi scende del 50%.

Il quickstart come parte del sistema

In un progetto reale la data collection non vive mai isolata. Fa parte di un sistema più ampio fatto di decisioni, dati disponibili, vincoli tecnici, incentivi organizzativi e qualità dell’esecuzione. Il rischio dell’analista alle prime armi è trattare il tema come una definizione da memorizzare. Il lavoro vero è capire quale problema risolve un certo dato, quali assunzioni porta con sé e cosa succede quando quelle assunzioni saltano. Un buon modo per impostare il lavoro è seguire una sequenza ordinata:

1. define the problem in business language;
2. identificare l’unità di analisi corretta tra utente, account, evento, sessione, ordine, campagna;
3. check if the data truly measures the phenomenon or just its shadow;
4. build an interpretable metric;
5. segment to avoid the average hiding opposite patterns;
6. turn the result into a verifiable recommendation.

Cosa insegna la disciplina di Netflix

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. Non si tratta di copiare Netflix. Il punto è metodologico: il dato non è ornamento, è 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. Guarda anche se l’utente guarda davvero il contenuto, se torna nei giorni successivi, se 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 vale per il tuo primo setup: ogni evento che tracci deve essere collegato a un outcome, altrimenti l’analisi resta incompleta.

Esempio SQL: una vista di controllo

Il pattern seguente è volutamente generico ma eseguibile nella maggior parte dei warehouse moderni. 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;

La query non è la risposta finale. Serve a creare una superficie di osservazione fatta di trend, segmenti, differenze tra canali e variazioni nel tempo. Da lì l’analista formula ipotesi più precise.

Esempio Python: stabilità e anomalie

Una metrica utile deve essere abbastanza stabile da orientare decisioni e abbastanza sensibile da segnalare 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 è pratico: eviti di reagire a ogni oscillazione casuale, ma ti accorgi quando una variazione merita un’indagine. In azienda questo tipo di controllo alimenta alert, review settimanali e retrospettive di prodotto.

Lab ed esercizi

Al livello base scrivi una scheda di una pagina sul tuo setup: decisione da supportare, metrica primaria, baseline, rischio principale e azione se il segnale è confermato. Al livello intermedio costruisci una tabella con tre segmenti, periodi o scenari, e per ciascuno indica cosa cambia, quale spiegazione alternativa è plausibile e quale controllo useresti prima di raccomandare un’azione. Al livello research-grade prepara un decision memo con ipotesi, dati richiesti, criteri di esclusione, controlli di qualità, soglia decisionale, rischio residuo e piano di monitoraggio. Come materiali puoi usare tracking plan, log eventi, GA4, CDP, warehouse e dataset sintetici di sessioni; se non hai dati reali, generane uno con almeno 200 righe, una dimensione temporale, una di segmento e una metrica di outcome.

Per chiudere, prova questo esercizio sui dati grezzi.

[SQL]Try it yourself

Write a query to count how many 'purchase' events each source (Google, Facebook, Direct, LinkedIn) generated. Order by descending number of purchases.

RunCtrl+Enter to runHintSolution

Common mistakes to avoid

L’errore più frequente è usare il setup come etichetta invece che come processo: si mostra un grafico senza decisione, una metrica senza baseline o una conclusione senza dire quale assunzione potrebbe invalidarla. La domanda di controllo è semplice: se questo risultato fosse instabile, quale scelta sbaglierei? Se la risposta non è concreta, manca ancora il collegamento tra analisi e azione.

Sul piano dei dati tornano gli stessi tre inciampi. Aggregare troppo presto, perché una media globale nasconde due segmenti che vanno in direzioni opposte. Non controllare la qualità, perché eventi duplicati, tracking incompleto, timezone incoerenti e cambi di definizione producono conclusioni false. Confondere correlazione e causalità. Per ridurre questi rischi, ogni analisi dovrebbe avere almeno tre controlli: definizione esplicita della metrica, confronto per segmento e verifica contro un periodo precedente o un gruppo di controllo.

Summary

Il quickstart va trattato come uno strumento decisionale, non come una sequenza di click. Il valore nasce quando colleghi problema, dati, metrica, segmentazione e azione. Una buona analisi non finisce con “il numero è salito” o “è sceso”, ma con una frase operativa: quale decisione prendiamo, con quale confidenza, e quale metrica useremo per sapere se avevamo ragione. La forma corretta resta sempre la stessa, decisione, segnale, baseline, rischio e azione, e tutto il resto serve solo se rende più affidabile uno di questi passaggi.