Privacy and compliance in data collection

Anche qui il binario è quello tabellare: i dati personali finiscono in tabelle, e la conformità si gioca su cosa ci finisce dentro, per quanto tempo e con quale base giuridica. Un evento può essere tecnicamente utile e comunque sbagliato da raccogliere. Succede se espone dati personali non necessari, se il consenso non è chiaro o se non hai deciso quando cancellarlo. La privacy fa parte del design della misura, non è un vincolo che arriva dopo. L’obiettivo è raccogliere meno, raccogliere meglio e restare analizzabili a lungo.

Perché la privacy decide la qualità del dato

La raccolta conforme minimizza i dati personali, registra il consenso e conserva solo aggregati utili così che l’analisi resti possibile nel tempo. In una frase: meno dati personali, più anni di analisi.

Il percorso verso la conformità

1. Elenca ogni campo personale raccolto con la decisione che supporta.

2. Assegna a ogni campo base giuridica, owner e tempo di conservazione.

3. Sostituisci identificativi diretti con pseudonimi prima dello storage analitico.

4. Aggrega i micro-eventi e cancella i grezzi oltre la soglia definita.

5. Testa cancellazione e accesso su tutti i sistemi prima dell’audit.

GDPR per chi analizza dati

Quattro principi toccano direttamente chi disegna la raccolta. Primo: serve una base legale per trattare dati personali, come consenso, legittimo interesse, contratto o obbligo di legge. Secondo: vale la minimizzazione, quindi raccogli solo ciò che serve. Terzo: l’utente ha diritto di accesso e cancellazione, quindi i sistemi devono poterlo fare davvero. Quarto: i dati dei cittadini europei restano in EU o in paesi con garanzie adeguate. Questo limita dove appoggi lo storage.

Verdetto: base giuridica esplicita più minimizzazione batte qualsiasi raccolta totale giustificata dopo.

Practical implementation

La traduzione operativa passa per quattro scelte. Una consent management platform raccoglie il consenso granulare per analytics, marketing e funzionali. Solo dopo attivi il tracking. La pseudonimizzazione usa un hash of user_id invece dell’email in chiaro nei log. Una retention policy cancella i grezzi dopo un numero definito di mesi e conserva le aggregazioni anonime più a lungo. Il diritto all’oblio richiede un processo che cancelli davvero da warehouse, CRM, backup e log.

Verdetto: consenso granulare più hash plus retention scritta batte banner generico senza cancellazione reale.

Il trade-off tra privacy e analytics

Raccogliere meno protegge la privacy ma limita l’analisi. Il bilanciamento sta negli aggregati. Invece di salvare ogni page view per sempre, aggreghi al giorno per utente e cancelli i grezzi dopo 90 giorni. Perdi la granularità del singolo evento, ma mantieni trend, retention e funnel. È quasi sempre il compromesso giusto per restare conformi senza spegnere l’analisi.

Verdetto: aggregato giornaliero con grezzi a 90 giorni batte conservazione infinita senza uso.

Una vista SQL su dati pseudonimizzati

La vista seguente crea una base settimanale per fonte e dispositivo per 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;

Lavora sempre su tabelle pseudonimizzate e verifica che nessun campo identifichi direttamente la persona.

Un controllo Python con retention applicata

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

Esegui il controllo su dati aggregati e con retention applicata, non su grezzi infiniti.

Typical mistakes

L’errore più frequente è trattare la privacy come etichetta invece che come criterio di scelta. Si pubblica un numero senza decisione, senza baseline e senza rischio dichiarato. Poi si aggrega troppo presto e si nascondono segmenti opposti. Duplicati, tracking incompleto e timezone incoerenti producono conclusioni false. Infine, correlazione non è causalità.

Verdetto: campo senza base giuridica e senza decisione si elimina dal plan.

Il caso che ha cambiato le regole

Nel maggio 2023 l’autorità irlandese per la protezione dei dati multa Meta per 1,2 miliardi di euro per i trasferimenti di dati europei verso gli Stati Uniti dopo la sentenza Schrems II senza una base valida. È la sanzione GDPR più alta mai inflitta e colpisce pipeline globali disegnate quando i dati potevano muoversi liberamente. La lezione è entrata nei tracking plan di mezza Europa: residenza dei dati, minimizzazione e base giuridica si decidono prima di accendere il tag perché spegnerlo dopo costa molto di più.

[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

Mettiti alla prova

1. Quale base giuridica giustifica ogni campo personale che raccogli?

2. Come sostituisci email in chiaro con pseudonimi nei log analitici?

3. Dopo quanti giorni cancelli i grezzi e cosa conservi in forma aggregata?

4. Come verifichi che la cancellazione copra warehouse, CRM e backup?