Guia d'integració del consentiment de galetes per a la gravació de sessions amb Microsoft Clarity per al 2026
Microsoft Clarity es va llançar el 2020 com una alternativa gratuïta i sense quota a Hotjar i Smartlook per a la gravació de sessions, mapes de calor i anàlisi d'interaccions. Cinc anys després, ocupa una quota significativa dels llocs de mercat mitjà i petites empreses arreu del món, en part perquè és realment útil i en part perquè la instal·lació és una sola línia de JavaScript que la majoria d'operadors enganxen sense pensar-hi gaire més. Des del punt de vista de la privadesa, aquesta facilitat d'instal·lació és precisament el problema. Clarity enregistra moviments del ratolí, comportament de desplaçament, clics, pulsacions de teclat, interaccions amb formularis i instantànies completes del DOM de la pàgina — la càrrega de comportament més densa de qualsevol eina d'analítica àmpliament desplegada — i envia-ho tot als servidors de Microsoft en el moment en què es carrega l'script. Per a qualsevol desplegament que afecti trànsit de la EU, el UK, l'EEA, el Brasil o Califòrnia, la instal·lació per defecte no és conforme, i els reguladors més actius en l'aplicació de l'enregistrament de sessions — el CNIL, el Garante italià, el UK ICO — han deixat clar que l'anàlisi s'aplica independentment del nivell de preus o del proveïdor de l'eina. Aquesta guia repassa què enregistra Clarity, com funciona el límit de consentiment i el patró d'integració que supera l'auditoria.
Què enregistra realment Clarity
El Clarity SDK (carregat des de www.clarity.ms/tag/{project_id}) inicialitza un objecte global clarity i identifica els visitants amb una galeta propietat de Microsoft anomenada _clck, juntament amb una galeta de sessió _clsk. A partir d'aquell moment, l'script captura un flux de comportament molt dens:
- Entrada de ratolí i tàctil — cada moviment, clic, toc, desplaçament i gest s'enregistra amb marca de temps i coordenades.
- Interaccions amb formularis — esdeveniments de focus, difuminat i entrada a cada camp de formulari, més el text dels camps no sensibles si no s'ha configurat l'emmascarament.
- Instantànies del DOM — instantànies periòdiques completes del DOM de la pàgina perquè la reproducció de la sessió pugui reconstruir l'estat visual exacte en qualsevol moment.
- Esdeveniments personalitzats — qualsevol esdeveniment que l'aplicació emet explícitament mitjançant les crides a clarity("event", "name").
- Dades de rendiment i errors — errors de JavaScript, fallades de xarxa i temps de mesura de les core web vitals.
- Dades d'identificador — la galeta propietat de Clarity més la geolocalització derivada de la IP i l'empremta de l'agent d'usuari.
La combinació — especialment les instantànies del DOM i la captura de camps de formulari — fa que Clarity sigui funcionalment equivalent a una gravació en vídeo de la sessió del visitant. La classificació regulatòria sota el GDPR és clara: es tracta del tractament de dades personals, les galetes no són essencials, les dades creuen fronteres cap a la infraestructura nord-americana de Microsoft i la base legal requerida és el consentiment. Les directrius de la CNIL del 2024 sobre l'enregistrament de sessions no deixa cap ambigüitat en aquest punt i esmenta explícitament les eines de la categoria de Clarity.
El risc de les dades sensibles
Les eines d'enregistrament de sessions tenen un risc de privadesa específic que altres eines d'analítica no tenen: poden capturar dades personals sensibles de manera accidental. Un usuari que escrigui un número de targeta de crèdit, una condició de salut, una afiliació religiosa o un identificador nacional en qualsevol camp de formulari és enregistrat per Clarity si el camp no està emmascarat explícitament. Sota el GDPR, això és el tractament de dades personals sensibles de l'Article 9, que requereix consentiment explícit d'adhesió voluntària i rarament queda cobert per una decisió general de consentiment de màrqueting.
Clarity admet una configuració d'emmascarament de contingut que amaga camps específics de l'enregistrament, però el comportament per defecte captura-ho tot. L'enfocament defensable en una auditoria és emmascara de manera agressiva — suposeu que cada camp de formulari és sensible fins que es demostri el contrari — i documenteu les decisions d'emmascarament explícitament.
Controls de privadesa natius de Clarity
Microsoft ha invertit en els controls de privadesa de Clarity durant els últims dos anys. La plataforma ara exposa diversos primitius que una integració CMP pot aprofitar.
L'atribut de màscara
Afegir data-clarity-mask="true" a un element del DOM amaga el seu contingut de l'enregistrament de la sessió. Afegir data-clarity-unmask="true" a un element fill sobreescriu la màscara per a aquell subárbol. El valor per defecte correcte per a qualsevol camp de formulari que pugui contenir dades personals és emmascara, i després desemmascara explícitament on sigui segur.
L'API de consentiment
Clarity exposa una crida clarity("consent") que, quan s'invoca, senyala que s'ha atorgat el consentiment i que el SDK hauria de continuar. Sense aquesta crida, el SDK es pot configurar perquè s'aturi després de la càrrega inicial. Aquest és el primitiu adequat per a la integració CMP en el costat de l'activació.
Emmascarament de la IP i gestió d'identificadors
La configuració del projecte de Clarity exposa opcions per al truncament de la IP i l'emmascarament d'identificadors. Activar-les és una mesura de defensa en profunditat a sobre de la restricció del CMP; no substitueix el consentiment.
Emmascarament automàtic de contingut sensible
Les versions recents de Clarity intenten detectar automàticament camps sensibles (patrons de targetes de crèdit, camps de contrasenya, camps anomenats "ssn" o similars) i emmascara'ls per defecte. La detecció és heurística i incompleta; no hi confieu com a única línia de defensa.
Integració CMP pas a pas
L'arquitectura fiable consisteix a ajornar el Clarity SDK completament fins que es concedeixi el consentiment, i llavors activar-lo explícitament a través de l'API de consentiment.
1. Elimineu l'etiqueta per defecte de la capçalera del document
El fragment d'instal·lació de Clarity és un únic script en línia que inicialitza el SDK en carregar la pàgina. Substituïu-lo per un element d'script de marcador de posició el type del qual sigui text/plain i la data-category del qual sigui analytics o marketing en funció de com el vostre CMP categoritza les eines d'enregistrament de sessions.
2. Decidiu el mapeig de categories
L'enregistrament de sessions és una categoria disputada. La CNIL l'ha tractat de diverses maneres com a analítica (quan les dades s'utilitzen per a investigació UX interna) i com a màrqueting (quan les dades alimenten decisions de personalització o compartició externa). El mapeig conservador és el màrqueting; la posició defensable en una auditoria requereix que sigueu específics sobre com s'utilitzen realment les gravacions.
3. Configureu l'emmascarament agressiu abans de l'activació
Afegiu data-clarity-mask="true" a cada element de formulari, cada camp d'entrada i cada contenidor que pugui contenir dades personals. La política per defecte és emmascara per defecte amb excepcions d'emmascarament explícites per als elements que se sap que són segurs (títols de pàgina, etiquetes de navegació, blocs de contingut públic).
4. Activeu Clarity des del callback de consentiment
Quan el CMP activa l'esdeveniment de categoria acceptada pertinent, rescriviu l'etiqueta d'script de marcador de posició i crideu clarity("consent") per concedir al SDK permís per continuar. Els esdeveniments en cua que s'han emmagatzemat en memòria intermèdia durant el període previ al consentiment es buiden aleshores.
5. Gestioneu la revocació explícitament
Si l'usuari revoca el consentiment, el Clarity SDK no té una crida "atura l'enregistrament" neta equivalent a l'API d'activació. El patró pràctic és cridar clarity("consent", false) si és compatible amb la vostra versió del SDK, i a més esborrar les galetes de Clarity al costat del client. Per a l'eliminació completa dels enregistraments històrics, utilitzeu el flux de treball d'eliminació de dades de la interfície d'administrador de Clarity o l'API d'eliminació.
Errors comuns
Quatre errors d'integració representen la majoria de les troballes d'auditoria en els desplegaments de Clarity.
Instal·lar Clarity "només per veure què fan els visitants"
El patró més comú: un gestor de producte instal·la Clarity per investigar un problema d'UX, mai activa la restricció de consentiment, mai configura l'emmascarament i s'oblida de l'script. La superfície d'enregistrament continua acumulant-se. La solució és eliminar Clarity completament o posar-la sota la mateixa arquitectura de consentiment que qualsevol altre rastrejador.
Confiar en l'emmascarament automàtic
La detecció heurística de camps sensibles de Clarity capta els casos evidents però passa per alt els específics del domini — el textarea de "symptoms" d'un lloc de salut, el camp de "account number" d'un lloc de finances amb un nom idiosincràtic. Emmascara explícitament; no us recolzeu en la detecció automàtica.
Tractar l'enregistrament de sessions com a analítica
La CNIL ha deixat clar que la categoria d'enregistrament de sessions és més propera al màrqueting que a l'analítica de primera part des d'una perspectiva de consentiment. Restringir Clarity sota un consentiment exclusivament d'analítica és defensable només si les gravacions s'utilitzen exclusivament per a investigació UX interna i mai es comparteixen fora de l'organització.
Oblidar les càrregues útils dels esdeveniments personalitzats
El codi de l'aplicació que crida clarity("event", "name", customProperties) pot filtrar dades personals al flux de Clarity a través de la càrrega útil de customProperties. Auditeu cada lloc de crida i eviteu passar identificadors d'usuari, adreces de correu electrònic o qualsevol dada personal en les propietats d'esdeveniments.
Llista de verificació d'auditoria
Sis preguntes concretes a respondre per a qualsevol desplegament de Clarity que afecti trànsit de la EU, el UK, el Brasil o Califòrnia.
- Clarity espera el consentiment? Obriu la pàgina en una finestra privada i confirmeu que no es disparen sol·licituds a clarity.ms abans d'acceptar el bàner.
- L'emmascarament és agressiu? Confirmeu que cada camp de formulari i cada contenidor amb contingut potencialment personal té aplicat data-clarity-mask.
- El mapeig de categories està documentat? Confirmeu que hi ha un registre escrit de si Clarity està restringida sota analítica o màrqueting, amb el raonament.
- L'API de consentiment està connectada? Confirmeu que el callback del CMP crida clarity("consent") en la concessió i l'equivalent en la revocació.
- Els esdeveniments personalitzats es troben auditoriats? Confirmeu que les crides a clarity("event", ...) no passen dades d'identificació ni sensibles en les càrregues útils de les seves propietats.
- L'eliminació és automatitzada? Confirmeu que les sol·licituds DSAR activen el flux de treball d'eliminació de Clarity, no un tiquet de suport manual.
On encaixa Clarity en una arquitectura de consentiment primerenc
L'enregistrament de sessions és la superfície de seguiment del comportament amb la densitat d'informació més alta en desplegaments habituals, i Clarity és l'eina que l'ha democratitzat de manera més agressiva. El nivell de preus gratuït i la instal·lació sense friccions la converteixen en el camí de menor resistència per a qualsevol equip que vulgui visibilitat sobre el comportament d'UX. Aquesta mateixa instal·lació sense friccions és el que fa que Clarity sigui l'eina d'analítica més habitualment mal configurada en les auditories del 2026. L'arquitectura correcta tracta Clarity com qualsevol altre rastrejador identificador: restringiu-la darrere del consentiment explícit, emmascara els camps de formulari de manera agressiva per defecte, documenteu el mapeig de categories i connecteu l'API de consentiment perquè els primitius propis del SDK facin complir el que el CMP ha registrat. Fet correctament, el valor de la recerca UX per al qual es va adquirir l'eina es preserva mentre l'exposició regulatòria cau a una fracció del que porta una instal·lació per defecte.