import pandas as pd

Terminology and glossary of data tracking

Due team usano la parola “lead” per indicare cose diverse: per uno è un form compilato, per l’altro un contatto qualificato, per un terzo un’opportunità creata nel CRM. Il problema non è lessicale, è operativo, perché metriche omonime guidano decisioni incompatibili. Questo glossario serve a mettere ordine prima che il disallineamento arrivi nei report. Leggilo come un esercizio di contratto semantico: evento, proprietà, entità, identità, sessione, conversione e attribution window devono significare la stessa cosa per chi implementa e per chi decide.

Il problema vero

Il problema non è conoscere la terminologia in astratto, ma decidere cosa fare quando hai dati incompleti, metriche ambigue o vincoli tecnici che rendono fragile la lettura di un fenomeno. Una definizione condivisa separa il segnale dal rumore 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: se non cambia una scelta, la metrica è documentazione o teatro analitico.

Come ragionare sui termini

Conviene tenere a mente una sequenza che lega la decisione al dato e al rischio, così un termine tecnico 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 i termini sono condivisi?	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 osservata, 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

Entities and identifiers

Lo User è la persona reale, identificata da user_id quando è autenticata e da anonymous_id quando non lo è. La Identify call associa un anonymous_id to a user_id quando l’utente fa login, e tutti gli eventi passati vengono attribuiti retroattivamente. Il Group è un’organizzazione o un account in contesti B2B, e il group_id permette analisi a livello azienda. L’Alias unisce due identità, per esempio due email della stessa persona.

Events

Un Track event è una qualsiasi azione dell’utente, come page_view, add_to_cart o purchase. Page e Screen event sono tipi specifici di track dedicati alla navigazione. Le Event properties sono gli attributi dell’evento, per esempio amount, currency, product_id. Il Context raccoglie i metadati automatici come URL, user agent e IP, che non sono proprietà di business. I Semantic events sono eventi con significato standardizzato secondo la Segment Spec: Order Completed, per esempio, ha sempre order_id, total e products[].

Pipeline and infrastructure

Il Collector è l’endpoint che riceve gli eventi dagli SDK tramite API HTTP. La Source è l’app o il sito che invia gli eventi, mentre la Destination è il sistema che li riceve dalla pipeline, come un warehouse, un CRM o un tool di analytics. Il Webhook è il meccanismo server-to-server per inviare eventi in tempo reale. L’SDK è la libreria client che spedisce gli eventi, per esempio analytics.js o il Segment iOS SDK.

Quality and governance

Lo Schema enforcement fa rifiutare al collector gli eventi che non rispettano lo schema definito. Il Sampling processa solo una frazione degli eventi per ridurre volume e costi, ed è tipico dei tool free-tier e delle metriche ad alta cardinalità. La Deduplication elimina gli eventi duplicati, per esempio quelli inviati due volte per un retry di rete. Il Protocol, o Tracking Plan, è il documento che definisce quali eventi esistono, con quali proprietà obbligatorie e quali tipi.

Il glossario come parte del sistema

In un progetto reale la terminologia 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 termine, 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 un glossario: ogni termine deve essere collegato a un outcome, altrimenti resta lessico inerte.

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.

[SQL]Try it yourself

Write a query that finds the average order amount for each user source (google, facebook, direct, linkedin). Show source and average amount, rounded to 2 decimals.

RunCtrl+Enter to runHintSolution

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 su un termine controverso del tuo team: 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, indicando per ciascuno 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 usa 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.

Common mistakes to avoid

L’errore più frequente è usare la terminologia 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à: se gli utenti che usano una feature convertono di più, non è detto che la feature causi la conversione. 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

La terminologia va trattata come strumento decisionale, non come elenco da manuale. 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.