O que Clarity rexistra realmente

O SDK de Clarity (cargado desde www.clarity.ms/tag/{project_id}) inicializa un obxecto global clarity e identifica os visitantes cun cookie de Microsoft chamado _clck, xunto cun cookie de sesión _clsk. Desde ese momento, o script captura un fluxo de comportamento denso:

• Entrada de rato e táctil — cada movemento, clic, toque, desprazamento e xesto rexístrase con marca de tempo e coordenadas.
• Interaccións con formularios — eventos de foco, desenfoque e entrada en cada campo do formulario, máis o texto dos campos non sensibles se non está configurado o enmascaramento.
• Instantáneas do DOM — instantáneas completas periódicas do DOM da páxina para que a reprodución da sesión poida reconstruír o estado visual exacto en calquera momento.
• Eventos personalizados — calquera evento que a aplicación emite explicitamente mediante chamadas clarity("event", "name").
• Datos de rendemento e erros — erros de JavaScript, fallos de rede e temporizacións dos indicadores web esenciais.
• Datos identificadores — o cookie de Clarity máis a xeolocalización derivada da IP e a pegada dixital do axente de usuario.

A combinación — especialmente as instantáneas do DOM e a captura dos campos do formulario — fai que Clarity sexa funcionalmente equivalente a unha gravación en vídeo da sesión do visitante. A clasificación regulatoria segundo o GDPR é sinxela: trátase do tratamento de datos persoais, as cookies non son esenciais, os datos cruzan fronteiras cara á infraestrutura estadounidense de Microsoft e a base xurídica necesaria é o consentimento. As directrices de 2024 da CNIL sobre a gravación de sesións son inequívocas neste punto e nomea explicitamente as ferramentas da categoría de Clarity.

O risco dos datos sensibles

As ferramentas de gravación de sesión teñen un risco de privacidade específico que outras ferramentas de análise non teñen: poden capturar datos persoais sensibles accidentalmente. Un usuario que escribe un número de tarxeta de crédito, un estado de saúde, unha afiliación relixiosa ou un identificador nacional en calquera campo do formulario é rexistrado por Clarity se o campo non está explicitamente enmascarado. En virtude do GDPR, trátase do tratamento de datos persoais sensibles do Article 9, que require un consentimento opt-in explícito e raramente está cuberto por unha decisión xeral de consentimento de marketing.

Clarity admite unha configuración de enmascaramento de contido que oculta campos específicos da gravación, pero o comportamento predeterminado captura todo. O enfoque defendible na auditoría é enmascarar de forma agresiva — supoñer que cada campo do formulario é sensible ata que se demostre o contrario — e documentar as decisións de enmascaramento explicitamente.

Controis de privacidade nativos de Clarity

Microsoft investiu nos controis de privacidade de Clarity nos últimos dous anos. A plataforma agora expón varios primitivos que unha integración CMP pode aproveitar.

O atributo mask

Engadir data-clarity-mask="true" a un elemento DOM oculta o seu contido da gravación de sesión. Engadir data-clarity-unmask="true" a un elemento fillo anula a máscara para esa subárbore. O valor predeterminado correcto para calquera campo de formulario que poida conter datos persoais é enmascarar, despois desenmascarar explicitamente onde sexa seguro.

A API de consentimento

Clarity expón unha chamada clarity("consent") que, cando se invoca, sinala que se concedeu o consentimento e que o SDK debe continuar. Sen esta chamada, o SDK pódese configurar para que se deteña despois da carga inicial. Este é o primitivo correcto para a integración CMP no lado da activación.

Enmascaramento de IP e xestión de identificadores

A configuración do proxecto de Clarity expón opcións para o truncamento de IP e o enmascaramento de identificadores. Activar estas opcións é unha medida de defensa en profundidade ademais do filtrado CMP; non substitúe o consentimento.

Enmascaramento automático de contido sensible

As versións recentes de Clarity intentan detectar automaticamente os campos sensibles (patróns de tarxeta de crédito, campos de contrasinal, campos denominados "ssn" ou similares) e enmascaralos de forma predeterminada. A detección é heurística e incompleta; non confíes nela como única liña de defensa.

Integración CMP paso a paso

A arquitectura fiable é diferir o SDK de Clarity por completo ata que se conceda o consentimento e, a continuación, activalo explicitamente mediante a API de consentimento.

1. Eliminar a etiqueta predeterminada da cabeceira do documento

O fragmento de instalación de Clarity é un script en liña único que inicializa o SDK ao cargar a páxina. Substituílo por un elemento script de marcador de posición cuxo type sexa text/plain e cuxo data-category sexa analytics ou marketing dependendo de como o teu CMP categorice as ferramentas de gravación de sesión.

2. Decidir o mapeamento de categorías

A gravación de sesión é unha categoría controvertida. A CNIL traitouna de diferentes xeitos como análise (cando os datos se usan para a investigación interna de UX) e como marketing (cando os datos alimentan decisións de personalización ou compartición externa). O mapeamento conservador é o marketing; a posición defendible na auditoría require que sexas específico sobre como se usan realmente as gravacións.

3. Configurar o enmascaramento agresivo antes da activación

Engadir data-clarity-mask="true" a cada elemento do formulario, cada campo de entrada, cada contedor que poida conter datos persoais. A política predeterminada é a máscara predeterminada con excepcións explícitas de desenmascaramento para os elementos que se saben seguros (títulos de páxina, etiquetas de navegación, bloques de contido público).

4. Activar Clarity desde a devolución de chamada de consentimento

Cando o CMP activa o evento de categoría aceptada relevante, reescriba a etiqueta do script de marcador de posición e chame a clarity("consent") para conceder ao SDK permiso para continuar. Os eventos en cola que se almacenaron en búfer durante o período previo ao consentimento vaciararanse entón.

5. Xestionar a revogación de forma explícita

Se o usuario revoga o consentimento, o SDK de Clarity non ten unha chamada limpa "deter a gravación" equivalente á API de activación. O patrón práctico é chamar a clarity("consent", false) se é compatible coa súa versión do SDK e, ademais, borrar as cookies de Clarity no lado do cliente. Para a eliminación completa das gravacións históricas, use o fluxo de traballo de eliminación de datos da interface de administración de Clarity ou a API de eliminación.

Erros comúns

Catro erros de integración representan a maioría das conclusións das auditorías nos despregamentos de Clarity.

Instalar Clarity "só para ver o que fan os visitantes"

O patrón máis común: un xestor de produto instala Clarity para investigar un problema de UX, nunca activa o filtrado de consentimento, nunca configura o enmascaramento e esquece o script. A superficie de gravación segue acumulándose. A solución é eliminar Clarity por completo ou traelo baixo a mesma arquitectura de consentimento que calquera outro rastreador.

Confiar no enmascaramento automático

A detección heurística de campos sensibles de Clarity capta os casos obvios pero pasa por alto os específicos do dominio — a área de texto "síntomas" dun sitio de saúde, o campo de "número de conta" dun sitio financeiro cun nome idiosincrático. Enmascara explicitamente; non confíes na detección.

Tratar a gravación de sesión como análise

A CNIL foi explícita en que a categoría de gravación de sesión está máis próxima ao marketing que á análise propia desde o punto de vista do consentimento. Filtrar Clarity baixo un consentimento só de análise só é defendible se as gravacións se usan exclusivamente para a investigación interna de UX e nunca se comparten fóra da organización.

Esquecer as cargas de eventos personalizados

O código de aplicación que chama a clarity("event", "name", customProperties) pode filtrar datos persoais ao fluxo de Clarity a través da carga de customProperties. Audita cada sitio de chamada e evita pasar identificadores de usuario, enderezos de correo electrónico ou calquera dato persoal nas propiedades do evento.

Lista de verificación de auditoría

Seis preguntas concretas que responder para calquera despregamento de Clarity que toque tráfico EU, UK, brasileiro ou de California.

• Clarity espera o consentimento? Abre a páxina nunha xanela privada e confirma que non se disparan solicitudes de clarity.ms antes de aceptar o banner.
• O enmascaramento é agresivo? Confirma que cada campo do formulario e cada contedor con contido potencialmente persoal ten aplicado data-clarity-mask.
• Está documentado o mapeamento de categorías? Confirma que existe un rexistro escrito de se Clarity está filtrado baixo análise ou marketing, co razoamento.
• Está conectada a API de consentimento? Confirma que a devolución de chamada do CMP chama a clarity("consent") ao conceder e o equivalente ao revogar.
• Están auditados os eventos personalizados? Confirma que as chamadas clarity("event", ...) non pasan datos identificativos ou sensibles nas súas cargas de propiedades.
• Está automatizada a eliminación? Confirma que as solicitudes DSAR activan o fluxo de traballo de eliminación de Clarity, non un ticket de soporte manual.

Onde encaixa Clarity nunha pila de consentimento primeiro

A gravación de sesión é a superficie de seguimento de comportamento de maior densidade de información nos despregamentos comúns, e Clarity é a ferramenta que a democratizou de forma máis agresiva. O nivel de prezos gratuíto e a instalación sen fricciones convérteno no camiño de menor resistencia para calquera equipo que desexe visibilidade sobre o comportamento de UX. Esa mesma instalación sen fricciones é o que fai de Clarity a ferramenta de análise máis comunmente mal configurada nas auditorías de 2026. A arquitectura correcta trata a Clarity como calquera outro rastreador identificador: filtralo detrás do consentimento explícito, enmascarar os campos do formulario de forma agresiva por defecto, documentar o mapeamento de categorías e conectar a API de consentimento para que os propios primitivos do SDK apliquen o que rexistrou o CMP. Feito correctamente, o valor da investigación de UX para o que se comprou a ferramenta consérvase mentres que a exposición regulatoria cae a unha fracción do que implica unha instalación predeterminada.