import pandas as pd

Privacy and compliance in data collection

Questa lezione è una scelta operativa, non un capitolo di diritto. Un evento può essere tecnicamente utile e comunque sbagliato da raccogliere se espone dati personali che non ti servono, se il consenso non è chiaro o se non hai deciso quando cancellarlo. La privacy nella data collection fa parte del design della misura, non è un vincolo che arriva dopo. Il punto di queste pagine è capire come raccogliere meno, raccogliere meglio e farlo in modo che il dato resti analizzabile a lungo.

Il problema vero

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

Nella pratica la domanda è sempre la stessa: questo dato serve davvero per la decisione che devo prendere, e che rischio introduce raccoglierlo? Minimizzazione, consenso, pseudonimizzazione e retention non sono dettagli legali separati dal lavoro analitico. Determinano cosa puoi misurare in modo sostenibile nel tempo.

Come ragionare sulla raccolta

Conviene tenere a mente una sequenza di lavoro che lega la decisione al dato e al rischio. Serve a evitare che una nozione tecnica diventi un rituale vuoto: a ogni passaggio dovrebbe diventare più chiaro quanto costa una scelta sbagliata.

Step	Question to ask	Expected output
Decision	Che cosa cambia se trattiamo bene privacy e compliance?	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 non complica la lezione, rende visibili le assunzioni. Così uno stakeholder può discutere il criterio decisionale invece di fidarsi del risultato per autorità. Definisci prima l’unità di analisi, poi la variabile che osservi, la baseline contro cui la confronti, la soglia che fa cambiare l’azione e il rischio che resta anche dopo l’analisi.

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

GDPR per chi analizza dati

Quattro principi del GDPR toccano direttamente chi disegna la raccolta. Ti serve una base legale per trattare dati personali, che sia il consenso, il legittimo interesse, il contratto o un obbligo di legge. Vale il principio di minimizzazione: raccogli solo ciò che serve, perché “tracciamo tutto, poi vediamo” non è una posizione legale. L’utente ha diritto di accedere ai propri dati e di chiederne la cancellazione, quindi i tuoi sistemi devono poterlo fare davvero. E i dati dei cittadini europei devono restare in EU o in paesi con garanzie adeguate, il che limita dove puoi appoggiare lo storage.

Practical implementation

La traduzione operativa di questi principi passa per quattro scelte concrete. Una consent management platform raccoglie il consenso granulare per categoria, distinguendo analytics, marketing e funzionali, e solo dopo il consenso attivi il tracking. La pseudonimizzazione ti fa usare un hash di user_id invece dell’email in chiaro nei log: i dati restano utili per l’analisi ma non sono riconducibili alla persona senza una chiave separata. Una data retention policy cancella i dati grezzi dopo un certo numero di mesi, mentre le aggregazioni anonime puoi conservarle più a lungo. Infine il right to be forgotten richiede un processo che cancelli davvero tutti i dati di un utente da warehouse, CRM, backup e log, e tecnicamente non è banale.

Il trade-off tra privacy e analytics

Raccogliere meno dati protegge la privacy ma limita l’analisi, e questo è il nodo che non puoi aggirare. Il bilanciamento sta negli aggregati. Invece di salvare ogni singola page view per sempre, aggreghi al giorno per utente e cancelli i dati grezzi dopo 90 giorni. Perdi la granularità del singolo evento, ma mantieni la capacità di leggere trend, retention e funnel. È quasi sempre il compromesso giusto per un team che vuole restare conforme senza spegnere l’analisi.

La privacy come parte del sistema

In un progetto reale privacy e compliance non vivono mai isolate. Fanno 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 è un altro: capire quale problema risolve un certo dato, quali assunzioni porta con sé e cosa succede quando quelle assunzioni saltano.

La prima domanda non è “quale metrica calcolo?” ma quale decisione dovrà essere presa grazie a questa analisi. Una dashboard, una query o un modello hanno valore solo se riducono l’incertezza di una scelta. Se non cambiano nulla, sono documentazione o teatro analitico. Per impostare il lavoro aiuta 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 principio vale qui: anche un dato raccolto in modo conforme 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.

[SQL]Try it yourself

Write a query that counts the distinct event types (page_view, purchase) generated by each user. Show username and number of different event types.

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

Parti dal livello base: scrivi in cinque righe quale decisione concreta dovrebbe migliorare grazie a una raccolta dati conforme. Indica metrica, unità di analisi, baseline e rischio principale. Se non riesci a nominare la decisione, il tema è ancora troppo astratto.

Al livello intermedio costruisci una tabella con quattro colonne: segnale osservato, interpretazione prudente, controllo necessario, azione consigliata. Includi almeno un caso in cui il segnale non basta per decidere.

Al livello research-grade trasforma l’esercizio in un memo decisionale che includa assunzioni, criteri di esclusione, soglia di intervento, sensitivity check e una proposta di monitoraggio dopo la decisione. Per i dati usa un export reale, una tabella sintetica, una dashboard interna o un notebook di studio, con almeno una dimensione di segmento, una metrica osservabile e un periodo di confronto.

Common mistakes to avoid

L’errore più frequente è usare la privacy come etichetta tecnica invece che come criterio di scelta: 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.

Sul piano analitico tornano sempre gli stessi tre inciampi. Lavorare su dati aggregati troppo presto, perché una media globale può nascondere due segmenti che si muovono in direzioni opposte. Non controllare la qualità del dato, 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, magari la usano perché sono già più motivati. 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.

Checkpoint

Prima di chiudere, rispondi a queste domande. Quale decisione concreta dovrebbe migliorare grazie a questa lezione? Quale unità di analisi rende il problema misurabile? Quale baseline useresti per evitare una lettura isolata? Quale assunzione, se falsa, cambierebbe la conclusione? E quale controllo presenteresti prima di raccomandare un’azione?

Summary

Privacy e compliance vanno trattate come strumento decisionale, non come argomento 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.