Guida all'integrazione del consenso per i cookie di registrazione delle sessioni di Microsoft Clarity per il 2026
Microsoft Clarity è stato lanciato nel 2020 come alternativa gratuita senza quota a Hotjar e Smartlook per la registrazione delle sessioni, le mappe di calore e l'analisi delle interazioni. Cinque anni dopo, è presente su una quota significativa di siti web di medie e piccole imprese in tutto il mondo, in parte perché è genuinamente utile e in parte perché l'installazione consiste in una sola riga di JavaScript che la maggior parte degli operatori incolla senza pensarci oltre. Dal punto di vista della privacy, questa facilità di installazione è esattamente il problema. Clarity registra i movimenti del mouse, il comportamento di scorrimento, i clic, i tasti premuti, le interazioni con i moduli e gli snapshot completi del DOM della pagina — il payload comportamentale più denso di qualsiasi strumento di analisi comunemente distribuito — e inoltra tutto ai server di Microsoft nel momento in cui lo script viene caricato. Per qualsiasi distribuzione che tocchi il traffico di EU, UK, EEA, Brasile o California, l'installazione predefinita non è conforme, e le autorità di regolamentazione più attive nell'applicazione della registrazione delle sessioni — il CNIL, il Garante italiano, l'UK ICO — hanno dichiarato esplicitamente che l'analisi si applica indipendentemente dal livello di prezzo o dal fornitore dello strumento. Questa guida illustra cosa registra Clarity, come funziona il confine del consenso e il modello di integrazione che supera il controllo.
Cosa registra effettivamente Clarity
Clarity SDK (caricato da www.clarity.ms/tag/{project_id}) inizializza un oggetto clarity globale e identifica i visitatori con un cookie di proprietà di Microsoft chiamato _clck, insieme a un cookie di sessione _clsk. Da quel momento, lo script cattura un denso flusso comportamentale:
- Input mouse e tocco — ogni movimento, clic, tocco, scorrimento e gesto viene registrato con timestamp e coordinate.
- Interazioni con i moduli — eventi di focus, blur e input su ogni campo del modulo, più il testo dei campi non sensibili se il mascheramento non è configurato.
- Snapshot DOM — snapshot completi periodici del DOM della pagina in modo che la riproduzione della sessione possa ricostruire l'esatto stato visivo in qualsiasi momento.
- Eventi personalizzati — qualsiasi evento che l'applicazione emette esplicitamente tramite chiamate clarity("event", "name").
- Dati sulle prestazioni e sugli errori — errori JavaScript, guasti di rete e tempi di core web vitals.
- Dati identificativi — il cookie di proprietà di Clarity più la geolocalizzazione derivata dall'IP e il fingerprinting dello user agent.
La combinazione — in particolare gli snapshot DOM e la cattura dei campi del modulo — rende Clarity funzionalmente equivalente a una registrazione video della sessione del visitatore. La classificazione normativa ai sensi del GDPR è semplice: si tratta di elaborazione di dati personali, i cookie non sono essenziali, i dati attraversano i confini verso l'infrastruttura statunitense di Microsoft e la base giuridica richiesta è il consenso. Le linee guida 2024 del CNIL sulla registrazione delle sessioni sono inequivocabili su questo punto e nominano esplicitamente gli strumenti nella categoria di Clarity.
Il rischio dei dati sensibili
Gli strumenti di registrazione delle sessioni presentano un rischio specifico per la privacy che altri strumenti di analisi non hanno: possono catturare accidentalmente dati personali sensibili. Un utente che digita un numero di carta di credito, una condizione di salute, un'affiliazione religiosa o un identificativo nazionale in qualsiasi campo di un modulo viene registrato da Clarity se il campo non è esplicitamente mascherato. Ai sensi del GDPR, si tratta di elaborazione di dati personali sensibili ai sensi dell'Article 9, che richiede un consenso esplicito opt-in e raramente è coperta da una decisione generale di consenso al marketing.
Clarity supporta una configurazione di mascheramento dei contenuti che nasconde campi specifici dalla registrazione, ma il comportamento predefinito cattura tutto. L'approccio difendibile in sede di audit è mascherare in modo aggressivo — presupporre che ogni campo del modulo sia sensibile finché non si dimostra il contrario — e documentare esplicitamente le decisioni di mascheramento.
Controlli nativi della privacy di Clarity
Microsoft ha investito nei controlli sulla privacy di Clarity negli ultimi due anni. La piattaforma espone ora diverse primitive che un'integrazione CMP può sfruttare.
L'attributo mask
Aggiungere data-clarity-mask="true" a un elemento DOM nasconde il suo contenuto dalla registrazione della sessione. Aggiungere data-clarity-unmask="true" a un elemento figlio sovrascrive la maschera per quel sottoalbero. Il valore predefinito corretto per qualsiasi campo del modulo che potrebbe contenere dati personali è mascherare, poi de-mascherare esplicitamente dove è sicuro farlo.
L'API di consenso
Clarity espone una chiamata clarity("consent") che, quando invocata, segnala che il consenso è stato concesso e che l'SDK può procedere. Senza questa chiamata, l'SDK può essere configurato per fermarsi dopo il caricamento iniziale. Questa è la primitiva corretta per l'integrazione CMP sul lato di attivazione.
Mascheramento IP e gestione degli identificatori
Le impostazioni del progetto Clarity espongono opzioni per il troncamento dell'IP e il mascheramento degli identificatori. L'abilitazione di queste opzioni è una misura di difesa in profondità in aggiunta al gating del CMP; non sostituisce il consenso.
Mascheramento automatico dei contenuti sensibili
Le versioni recenti di Clarity tentano di rilevare automaticamente i campi sensibili (pattern di carte di credito, campi password, campi denominati “ssn” o simili) e mascherarli per impostazione predefinita. Il rilevamento è euristico e incompleto; non fare affidamento su di esso come unica linea di difesa.
Integrazione CMP passo dopo passo
L'architettura affidabile consiste nel differire completamente Clarity SDK fino alla concessione del consenso, quindi attivarlo esplicitamente tramite l'API di consenso.
1. Rimuovere il tag predefinito dall'intestazione del documento
Il frammento di installazione di Clarity è un singolo script inline che inizializza l'SDK al caricamento della pagina. Sostituirlo con un elemento script segnaposto il cui type è text/plain e il cui data-category è analytics o marketing a seconda di come il CMP categorizza gli strumenti di registrazione delle sessioni.
2. Decidere la mappatura delle categorie
La registrazione delle sessioni è una categoria contestata. Il CNIL l'ha trattata in vari modi come analisi (quando i dati vengono utilizzati per la ricerca UX interna) e come marketing (quando i dati alimentano decisioni di personalizzazione o condivisione esterna). La mappatura conservativa è il marketing; la posizione difendibile in sede di audit richiede di essere specifici su come vengono effettivamente utilizzate le registrazioni.
3. Configurare il mascheramento aggressivo prima dell'attivazione
Aggiungere data-clarity-mask="true" a ogni elemento del modulo, ogni campo di input, ogni contenitore che potrebbe contenere dati personali. La policy predefinita è mask-by-default con eccezioni di unmask esplicite per gli elementi noti per essere sicuri (titoli di pagina, etichette di navigazione, blocchi di contenuto pubblici).
4. Attivare Clarity dalla callback di consenso
Quando il CMP attiva l'evento di categoria-accettata rilevante, riscrivere il tag dello script segnaposto e chiamare clarity("consent") per concedere all'SDK il permesso di procedere. Gli eventi in coda che erano stati bufferizzati durante il periodo pre-consenso verranno quindi svuotati.
5. Gestire esplicitamente la revoca
Se l'utente revoca il consenso, Clarity SDK non dispone di una chiamata pulita di arresto della registrazione equivalente all'API di attivazione. Il pattern pratico consiste nel chiamare clarity("consent", false) se supportato nella versione SDK in uso, e nell'eliminare inoltre i cookie di Clarity sul lato client. Per l'eliminazione completa delle registrazioni storiche, utilizzare il flusso di lavoro di eliminazione dati dell'interfaccia utente di amministrazione di Clarity o l'API di eliminazione.
Insidie comuni
Quattro errori di integrazione rappresentano la maggioranza dei risultati degli audit sulle distribuzioni di Clarity.
Installazione di Clarity solo per vedere cosa fanno i visitatori
Il pattern più comune: un product manager installa Clarity per ricercare un problema UX, non abilita mai il gating del consenso, non configura mai il mascheramento e dimentica lo script. La superficie di registrazione continua ad accumularsi. La bonifica consiste nel rimuovere completamente Clarity o nel portarlo sotto la stessa architettura di consenso di ogni altro tracker.
Affidarsi al mascheramento automatico
Il rilevamento euristico dei campi sensibili di Clarity cattura i casi ovvi ma manca quelli specifici del dominio — la textarea dei sintomi di un sito sanitario, il campo del numero di conto di un sito finanziario con un nome idiosincratico. Mascherare esplicitamente; non fare affidamento sul rilevamento.
Trattare la registrazione delle sessioni come analisi
Il CNIL ha dichiarato esplicitamente che la categoria di registrazione delle sessioni è più vicina al marketing che all'analisi di prima parte dal punto di vista del consenso. Il gating di Clarity sotto il consenso solo per l'analisi è difendibile solo se le registrazioni vengono utilizzate esclusivamente per la ricerca UX interna e non vengono mai condivise al di fuori dell'organizzazione.
Dimenticare i payload degli eventi personalizzati
Il codice applicativo che chiama clarity("event", "name", customProperties) può far trapelare dati personali nel flusso di Clarity attraverso il payload customProperties. Verificare ogni sito di chiamata ed evitare di passare identificatori utente, indirizzi email o qualsiasi dato personale nelle proprietà degli eventi.
Elenco di controllo per l'audit
Sei domande concrete a cui rispondere per qualsiasi distribuzione di Clarity che tocchi il traffico di EU, UK, Brasile o California.
- Clarity attende il consenso? Aprire la pagina in una finestra privata e confermare che nessuna richiesta clarity.ms viene attivata prima che il banner venga accettato.
- Il mascheramento è aggressivo? Confermare che ogni campo del modulo e ogni contenitore con contenuto potenzialmente personale abbia data-clarity-mask applicato.
- La mappatura delle categorie è documentata? Confermare che esista un registro scritto che indichi se Clarity è sottoposto a gate sotto analytics o marketing, con la motivazione.
- L'API di consenso è collegata? Confermare che la callback del CMP chiami clarity("consent") alla concessione e l'equivalente alla revoca.
- Gli eventi personalizzati sono verificati? Confermare che le chiamate clarity("event", ...) non passino dati identificativi o sensibili nei payload delle proprietà.
- L'eliminazione è automatizzata? Confermare che le richieste DSAR attivino il flusso di lavoro di eliminazione di Clarity, non un ticket di supporto manuale.
Dove si colloca Clarity in uno stack consent-first
La registrazione delle sessioni è la superficie di tracciamento comportamentale con la più alta densità di informazioni nel deployment comune, e Clarity è lo strumento che l'ha democratizzata in modo più aggressivo. Il livello di prezzo gratuito e l'installazione senza attrito lo rendono la via di minore resistenza per qualsiasi team che desideri visibilità sul comportamento UX. Quella stessa installazione senza attrito è ciò che rende Clarity lo strumento di analisi più comunemente configurato in modo errato negli audit del 2026. L'architettura corretta tratta Clarity come qualsiasi altro tracker identificativo: lo mette dietro un consenso esplicito, maschera i campi del modulo in modo aggressivo per impostazione predefinita, documenta la mappatura delle categorie e collega l'API di consenso in modo che le primitive proprie dell'SDK facciano rispettare ciò che il CMP ha registrato. Fatto correttamente, il valore della ricerca UX per cui lo strumento è stato acquistato viene preservato mentre l'esposizione normativa scende a una frazione di ciò che porta un'installazione predefinita.