Terminology and glossary of data tracking

Anche questa lezione si muove nel mondo tabellare: eventi, proprietà e identità che popolano le tabelle su cui lavoriamo ogni giorno. Due team usano la parola lead per indicare cose diverse. Per uno è un form compilato, per un altro un contatto qualificato, per un terzo un’opportunità creata nel CRM. Il problema non è lessicale, è operativo. Metriche omonime guidano decisioni incompatibili. Questo glossario fissa un contratto semantico tra chi implementa e chi decide.

Perché le parole contano quanto i numeri

Il glossario di tracking fissa il significato operativo di eventi, proprietà, identità e sessioni così che chi implementa e chi decide usi le stesse definizioni. In breve: un termine, una definizione, una regola di calcolo.

Come si costruisce un glossario

1. Censire tutti i termini ambigui usati nei report con la loro definizione corrente.

2. Fissare una definizione operativa per ogni termine con unità di analisi e regola di calcolo.

3. Mappare ogni termine a eventi, proprietà e identificativi reali del tracking plan.

4. Validare le definizioni con una query di controllo su un periodo noto.

5. Congelare le definizioni approvate nel tracking plan versionato.

Entità e identità: chi è il soggetto

Lo User è la persona reale. È identificata da user_id quando è autenticata e da anonymous_id quando non lo è. La chiamata identify associa un anonymous_id to a user_id al login. Gli eventi passati vengono poi attribuiti retroattivamente. Il Group è un’organizzazione o un account in contesti B2B. Il group_id abilita analisi a livello azienda. L’alias unisce due identità, per esempio due email della stessa persona.

Verdetto: user_id autenticato fa fede e anonymous_id resta solo un ponte pre-login.

Eventi, proprietà e contesto

An event track è un’azione utente come page_view, add_to_cart o purchase. Page e Screen are track specializzati per la navigazione. Le event properties descrivono l’evento, per esempio amount, currency e product_idData drift context raccoglie metadati automatici come URL, user agent e IP. Resta separato dalle proprietà di business. I semantic events seguono la Segment Spec: Order Completed porta sempre order_id, total e products.

Verdetto: traccia azioni di business con proprietà esplicite e tieni il context fuori dalle proprietà di business.

Pipeline, schema e qualità

The collector è l’endpoint che riceve gli eventi dagli SDK via HTTPcount. The source è l’app o il sito che invia. La destination è il sistema che riceve, come warehouse, CRM o tool di analytics. Il webhook è l’invio server-to-server in tempo reale. Lo schema enforcement fa rifiutare al collector gli eventi fuori schema. Il sampling processa solo una frazione degli eventi per volumi ad alta cardinalità. La deduplication elimina i doppi invii da retry di rete. Il protocol è il documento con eventi, proprietà obbligatorie e tipi.

Verdetto: collector unico con schema rigido e deduplicazione batte SDK sparsi senza contratto.

Una vista SQL per controllare le definizioni

La vista seguente crea una base settimanale per fonte e dispositivo così puoi confrontare periodi e segmenti senza riscrivere la logica.

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;

Usala per separare trend reali da spostamenti di mix tra canali.

Un controllo Python di stabilità

Una metrica utile resta stabile per decidere e sensibile per segnalare cambiamenti reali.

# 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']])

Sotto soglia osservi, sopra soglia indaghi prima la qualità del dato e poi il business.

Typical mistakes

L’errore più frequente è usare i termini come etichette invece che come processo. Si pubblica un grafico senza decisione, una metrica senza baseline e una conclusione senza assunzione dichiarata. Poi si aggrega troppo presto e si nascondono segmenti opposti. Duplicati, tracking incompleto e timezone incoerenti producono conclusioni false. Infine, correlazione non è causalità: chi usa una feature e converte di più era forse già più motivato.

Verdetto: definizione esplicita più confronto per segmento più verifica su periodo precedente, sempre.

Il caso che ha giustificato ogni glossario

Nel settembre 2016 Facebook ammette di aver sovrastimato del 60-80 per cento il tempo medio di visione dei video perché conteggiava solo le visualizzazioni oltre i 3 secondi ed escludeva quelle più brevi dal denominatore. Inserzionisti e publisher avevano allocato budget su una metrica chiamata come quella di YouTube ma calcolata diversamente. Nell’ottobre 2019 la vicenda si chiude con un accordo da 40 milioni di dollari con gli inserzionisti. Stesso nome, definizioni incompatibili, decisioni incompatibili: il caso che giustifica ogni glossario.

[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

Domande per verificare

1. Quando usi user_id e quando anonymous_id per attribuire un evento?

2. Cosa distingue una event property dal context di un evento?

3. Quale controllo impedisce eventi fuori schema nel collector?

4. Come intercetti duplicati e sampling prima di fidarti di una metrica?