Identity Resolution: Da 6 Segnali a Un'Identità Cliente Unificata

I cookie di terze parti sono scomparsi, i tassi di login rimangono all'8%, ogni dispositivo ha un ID diverso, ogni canale genera un segnale differente. Un cliente e-commerce medio lascia 6 touchpoint distinti durante il suo percorso di acquisto, ma le piattaforme li registrano come 6 persone diverse. Questo è il problema più grande dei dati di marketing: l'identità digitale della stessa persona frammentata in 6 pezzi. L'identity resolution è la disciplina ingegneristica che riunisce questi frammenti — attraverso hash matching, probabilistic linking e household clustering. Costruire un identity graph funzionante in produzione non è solo tecnica, è gestire l'equilibrio tra privacy, performance e accuratezza.

Cos'è Identity Resolution e Perché È Critico Adesso

L'identity resolution è il processo di unificazione di frammenti di segnali provenienti da fonti diverse (email hash, device ID, browser fingerprint, IP, session cookie) sotto un profilo cliente unico. Nel 2026, l'eliminazione completa dei cookie di terze parti da parte di Google Chrome, la limitazione dello storage a 7 giorni da parte di Safari (ITP 2.3), e il tasso di opt-in dell'IDFA intorno al 15% dopo iOS 14.5 rendono il cross-device tracking impossibile affidandosi unicamente alle tecnologie piattaforma-dipendenti.

Un'analisi di Roibase condotta su clienti Shopify Plus nel Q4 2025 ha rivelato che lo stesso utente genera in media 3.2 ID anonimi distinti nel triangolo mobile web, desktop e app. Quando il cliente arriva al checkout e inserisce l'email, solo allora avviene l'"unione". Ma se non riesci a collegare i 4-5 touchpoint precedenti alla stessa persona, il tuo modello di attribuzione crolla — l'ultimo clic vince, il vero percorso rimane invisibile. L'identity resolution è quindi il livello infrastrutturale del moderno marketing misurato. I metodi deterministici (exact match: email, telefono) combinati con approcci probabilistici (combinazioni di IP + user-agent + timezone) puntano a un'accuratezza del match >85%.

Portare questa disciplina in produzione richiede un'architettura a 3 livelli: raccolta dei segnali (raw event stream), stitching dell'identità (graph engine), unificazione del profilo (CDP layer). A ogni livello si bilanciano privacy compliance (TCF 2.2, KVKK consent) e performance (tradeoff tra risoluzione real-time e batch).

Hash Matching: Il Nucleo dell'Identità Deterministica

L'hash matching è il metodo più affidabile di identity resolution: prendi l'email o il numero di telefono dell'utente, lo hassi con SHA256, e lo confronti con gli hash presenti in sistemi diversi. L'accuratezza è prossima al 100% perché il rischio di collisione è trascurabile — lo stesso hash significa la stessa email. Ma ci sono 3 condizioni critiche: (1) devi aver raccolto le PII dell'utente (form, login), (2) devi avere il consenso (GDPR 6(1)(a) o interesse legittimo), (3) lo standard di hashing deve essere coerente tra i sistemi (lowercase + trim + encoding UTF-8).

Nei nostri progetti CDP & retention engineering, Roibase utilizza questa pipeline:

-- Standardizzazione dell'email hash in BigQuery
CREATE OR REPLACE FUNCTION `project.dataset.hash_email`(email STRING)
RETURNS STRING AS (
  TO_HEX(SHA256(LOWER(TRIM(email))))
);

-- Arricchimento della tabella eventi con email hash
SELECT
  event_timestamp,
  user_pseudo_id,
  `project.dataset.hash_email`(user_properties.email) AS email_hash,
  device.category,
  traffic_source.medium
FROM `analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260601' AND '20260630'
  AND user_properties.email IS NOT NULL;

Se scrivi questo hash in una CDP come Segment o mParticle, essa unificherà gli eventi provenienti da dispositivi diversi sotto lo stesso email_hash. Scenario di esempio: un utente si iscrive alla newsletter da desktop lunedì (raccogli l'email), naviga anonimo da mobile mercoledì, accede e acquista da desktop giovedì. Senza email hash vedresti 3 user_id diversi; con hash matching, 1 profilo, 3 sessioni, percorso netto.

Tradeoff: L'hash matching funziona solo per utenti autenticati. Su siti e-commerce il tasso di login è dell'8-12%, quindi il 88-92% del traffico rimane anonimo. In questo segmento entrano in gioco i metodi probabilistici.

Probabilistic Linking: Abbinare i Segnali Statisticamente

La risoluzione dell'identità probabilistica utilizza la combinazione di segnali diversi per calcolare un punteggio "probabilmente la stessa persona". Combini indirizzo IP + user-agent + timezone + pattern di comportamento della sessione e accetti il match con una confidence threshold >80%. L'accuratezza non è alta quanto quella deterministica (falsi positivi nel 5-10%), ma copre il traffico anonimo.

La logica dell'algoritmo: ogni segnale porta un "weight". Se l'indirizzo IP è stabile su una rete home/ufficio, +0.3; se la combinazione user-agent + timezone è rara, +0.25; se il pattern di comportamento della sessione (ordine delle pagine, scroll depth, timing) si sovrappone al 90% con un profilo precedente, +0.4. Se il punteggio totale >0.8, colleghi le due sessioni allo stesso nodo di identità. Questo non avviene in real-time — un job batch ricalcola il grafo 1-2 volte al giorno.

La pipeline probabilistica che Roibase utilizza nel vertical gaming è la seguente:

-- Creazione della fingerprint (semplificata)
WITH fingerprints AS (
  SELECT
    user_pseudo_id,
    event_date,
    NET.IP_TO_STRING(NET.SAFE_IP_FROM_STRING(user_first_touch_timestamp)) AS ip_prefix,
    device.operating_system,
    device.browser,
    geo.country,
    ARRAY_AGG(page_location ORDER BY event_timestamp LIMIT 5) AS page_sequence
  FROM `analytics_123456789.events_*`
  WHERE _TABLE_SUFFIX = FORMAT_DATE('%Y%m%d', CURRENT_DATE())
  GROUP BY 1,2,3,4,5,6
)
SELECT
  a.user_pseudo_id AS user_a,
  b.user_pseudo_id AS user_b,
  -- Similarità Jaccard sulla sequenza di pagine
  (SELECT COUNT(*) FROM UNNEST(a.page_sequence) AS p WHERE p IN UNNEST(b.page_sequence)) 
    / (ARRAY_LENGTH(a.page_sequence) + ARRAY_LENGTH(b.page_sequence)) AS similarity_score
FROM fingerprints a
JOIN fingerprints b
  ON a.ip_prefix = b.ip_prefix
  AND a.operating_system = b.operating_system
  AND a.user_pseudo_id != b.user_pseudo_id
WHERE similarity_score > 0.75;

Questa query abbina utenti con la stessa combinazione IP + OS dove la sequenza di pagine è simile al 75%. In produzione scrivi questo punteggio in un graph database (Neo4j o BigQuery graph table) mantenendolo come edge weight.

Rischio: Le combinazioni di IP condiviso (caffetteria, ufficio) o user-agent generico (iPhone 15 + Safari) possono creare falsi positivi elevati. Per questo motivo la risoluzione a livello household viene gestita in un livello separato.

Household Identity: Distinguere Persone Diverse Sulla Stessa Rete

L'household clustering affronta il problema di distinguere utenti diversi che condividono lo stesso IP/rete di dispositivi. Su una rete domestica, madre, padre e figlio usano lo stesso Wi-Fi; il matching probabilistico potrebbe unirli in un unico profilo. Per evitarlo, osservi i segnali di behavioral divergence: preferenza di categoria di prodotto, timing della sessione (mattino 10 vs notte 23), velocità di scroll, pattern di digitazione sulla tastiera (biometrica ma sensibile da prospettiva GDPR).

Il modello sviluppato da Roibase nel settore telecomunicazioni funziona così:

IP-level clustering: Raccogli tutte le sessioni provenienti dallo stesso IP sotto un unico "household node".
Behavioral segmentation: Trasforma ogni sessione in un feature vector (product_category, avg_session_duration, bounce_rate, hour_of_day).
K-means clustering: Crea 2-3 cluster all'interno dell'household — ogni cluster è una "sub-identity".
Validation: Quando arriva un email hash, confermi la sub-identity o la ri-distribuisci.

Struttura di tabella di esempio:

household_id	sub_identity	feature_vector	last_seen	email_hash
hh_abc123	sub_1	fashion, 18min, 0900-1200	2026-07-02	hash_x
hh_abc123	sub_2	gaming, 45min, 2100-2400	2026-07-02	NULL

Con questa struttura mantieni 2 persone nella stessa famiglia su profili separati. Quando arriva un email hash (es. il figlio accede), sub_2 si conferma, mentre sub_1 rimane probabilistica.

Tradeoff: L'algoritmo di clustering ha un costo computazionale elevato — riprocessare ogni giorno tutti gli household è pesante. Eseguiamo il job batch in 4-6 ore — non real-time, i profili si aggiornano in T+1 giorni.

Architettura Identity Graph in Produzione

Unire i 3 metodi sopra in un'architettura produttiva significa questi livelli:

1. Event ingestion layer (sGTM): Tramite Google Tag Manager lato server si raccoglie lo stream di raw event — GA4, Segment, Klaviyo, Conversion API server-side. Ogni evento porta user_pseudo_id + session_id + client_id. Se presenti email/telefono, aggiungi l'hash.

2. Identity stitching engine (BigQuery + dbt): Job batch giornaliero:

Deterministic matching (confronti email_hash)
Probabilistic scoring (similarità IP + UA + behavior)
Household clustering (K-means o DBSCAN)

Output: tabella identity_graph (nodo = identità unica, edge = confidence score).

3. Profile unification (CDP): Per ogni nodo nel grafo crei un profilo unificato — tutti i touchpoint, attributi, segmenti convergono. Questo profilo si sincronizza con piattaforme di attivazione come Klaviyo o Braze.

4. Real-time lookup: Quando arriva un nuovo evento, interroghi il grafo — se esiste un match, lo aggiungi al profilo esistente; altrimenti apri un nodo nuovo (domani il job batch cercherà di unificarlo).

Nel stack Shopify Plus di Roibase, il costo mensile GCP per questa architettura è ~$800 (BigQuery + Cloud Functions + sGTM container). Per 50M event/mese, il runtime batch è 4-5 ore. ROI: accuratezza dell'attribuzione aumenta del 18%, il calcolo del CAC diventa stabile del 22% in più (perché distingui le 3 sessioni dello stesso utente).

Privacy, Consenso e Conformità KVKK

L'identity resolution si fonda su GDPR 6(1)(f) "interesse legittimo" o 6(1)(a) "consenso esplicito". In Turchia, KVKK richiede consenso esplicito — devi dichiarare all'utente: "Unificheremo i vostri dati personali dai comportamenti su dispositivi diversi". Lo gestisci tramite una Consent Management Platform (CMP): TCF 2.2 con purpose 2 (device identification) e purpose 7 (cross-device linking).

L'hashing è "pseudonimizzazione" secondo GDPR 4(5), non anonimizzazione completa — rimane dato personale. Le tabelle con hash richiedono encryption at rest + access control. Nei progetti Roibase, i dataset BigQuery sono cifrati con customer-managed encryption key (CMEK), l'accesso è ristretto da IAM policy + VPC Service Controls.

Retention policy: Conserva l'identity graph secondo KVKK art. 7 finché l'obiettivo del trattamento persiste. In e-commerce tipicamente 2 anni — dopo l'ultimo acquisto di 24 mesi, il profilo riceve flag inattivo; se l'utente non ritorna in 30 giorni, il profilo viene cancellato (right to erasure).

Cosa Fare Adesso

Costruire l'identity resolution da zero è un progetto di data engineering di 8-12 settimane. Se non hai una CDP, prima devi mettere in piedi l'architettura first-party data — raccolta eventi server-side, BigQuery warehouse, pipeline di trasformazione dbt. Su questa infrastruttura aggiungi il motore di identity stitching. Se hai uno stack esistente, testa il modulo probabilistic matching in pilota su 1-2 segmenti (es. clienti ad alto valore), misura accuratezza e false positive, calibra la confidence threshold. Prima di lanciare in produzione, allinea il flow di consenso e la policy di retention con il team legale. L'identity resolution è il fondamento per tutti gli altri livelli del data marketing (attribuzione, segmentazione, LTV modeling) — se questo non è solido, tutte le metriche soprastanti poggiano su basi sbagliate.