Guía de integración del consentimiento de cookies para la grabación de sesiones con Microsoft Clarity para 2026
Microsoft Clarity se lanzó en 2020 como una alternativa gratuita sin cuotas a Hotjar y Smartlook para la grabación de sesiones, mapas de calor y análisis de interacciones. Cinco años después ocupa una cuota significativa de sitios de mercado medio y pequeñas empresas en todo el mundo, en parte porque es genuinamente útil y en parte porque la instalación es una sola línea de JavaScript que la mayoría de los operadores pegan sin reflexionarlo más. Desde una perspectiva de privacidad, precisamente esa facilidad de instalación es el problema. Clarity registra movimientos del ratón, comportamiento de desplazamiento, clics, pulsaciones de teclas, interacciones con formularios y capturas completas del DOM de la página — la carga de comportamiento más densa de cualquier herramienta de análisis comúnmente desplegada — y reenvía todo a los servidores de Microsoft en el momento en que se carga el script. Para cualquier implementación que afecte al tráfico de la EU, el UK, el EEA, Brasil o California, la instalación predeterminada no es conforme, y los reguladores más activos en la aplicación del registro de sesiones — el CNIL, el Garante italiano, el UK ICO — han declarado explícitamente que el análisis aplica independientemente del nivel de precios o del proveedor de la herramienta. Esta guía repasa qué registra Clarity, cómo funciona el límite de consentimiento y el patrón de integración que supera una auditoría.
Qué registra realmente Clarity
El Clarity SDK (cargado desde www.clarity.ms/tag/{project_id}) inicializa un objeto global clarity e identifica a los visitantes con una cookie de propiedad de Microsoft llamada _clck, junto con una cookie de sesión _clsk. A partir de ese momento, el script captura un flujo de comportamiento denso:
- Entrada de ratón y táctil — cada movimiento, clic, toque, desplazamiento y gesto se registra con marca de tiempo y coordenadas.
- Interacciones con formularios — eventos de enfoque, desenfoque y entrada en cada campo del formulario, más el texto de los campos no sensibles si no se ha configurado el enmascaramiento.
- Instantáneas del DOM — instantáneas periódicas completas del DOM de la página para que la reproducción de sesión pueda reconstruir el estado visual exacto en cualquier momento.
- Eventos personalizados — cualquier evento que la aplicación emite explícitamente mediante llamadas a clarity("event", "name").
- Datos de rendimiento y errores — errores de JavaScript, fallos de red y tiempos de las core web vitals.
- Datos de identificador — la cookie de propiedad de Clarity más la geolocalización derivada de la IP y la huella del agente de usuario.
La combinación — en particular las instantáneas del DOM y la captura de campos del formulario — hace que Clarity sea funcionalmente equivalente a una grabación de vídeo de la sesión del visitante. La clasificación regulatoria bajo el GDPR es clara: se trata del tratamiento de datos personales, las cookies no son esenciales, los datos cruzan fronteras hacia la infraestructura estadounidense de Microsoft y la base legal requerida es el consentimiento. La guía de la CNIL de 2024 sobre la grabación de sesiones es inequívoca en este punto y nombra explícitamente herramientas de la categoría de Clarity.
El riesgo de los datos sensibles
Las herramientas de grabación de sesiones tienen un riesgo de privacidad específico que otras herramientas de análisis no tienen: pueden capturar accidentalmente datos personales sensibles. Un usuario que escriba un número de tarjeta de crédito, una condición de salud, una afiliación religiosa o un identificador nacional en cualquier campo de formulario queda registrado por Clarity si el campo no está enmascarado explícitamente. Bajo el GDPR, esto es el tratamiento de datos personales sensibles del Article 9, que requiere un consentimiento explícito de adhesión voluntaria y rara vez está cubierto por una decisión general de consentimiento de marketing.
Clarity admite una configuración de enmascaramiento de contenido que oculta campos específicos de la grabación, pero el comportamiento predeterminado captura todo. El enfoque defendible en auditoría es enmascarar agresivamente — asuma que cada campo de formulario es sensible hasta que se demuestre lo contrario — y documentar las decisiones de enmascaramiento explícitamente.
Controles de privacidad nativos de Clarity
Microsoft ha invertido en los controles de privacidad de Clarity durante los últimos dos años. La plataforma ahora expone varios primitivos que una integración de CMP puede aprovechar.
El atributo de máscara
Añadir data-clarity-mask="true" a un elemento del DOM oculta su contenido de la grabación de sesión. Añadir data-clarity-unmask="true" a un elemento hijo anula la máscara para ese subárbol. El valor predeterminado correcto para cualquier campo de formulario que pueda contener datos personales es enmascarar y después desenmascarar explícitamente donde sea seguro.
La API de consentimiento
Clarity expone una llamada clarity("consent") que, cuando se invoca, indica que se ha otorgado el consentimiento y que el SDK debe continuar. Sin esta llamada, el SDK puede configurarse para detenerse tras la carga inicial. Este es el primitivo correcto para la integración del CMP en el lado de la activación.
Enmascaramiento de IP y gestión de identificadores
La configuración del proyecto de Clarity expone opciones para el truncamiento de IP y el enmascaramiento de identificadores. Habilitarlas es una medida de defensa en profundidad sobre la restricción del CMP; no sustituye al consentimiento.
Enmascaramiento automático de contenido sensible
Las versiones recientes de Clarity intentan detectar automáticamente los campos sensibles (patrones de tarjetas de crédito, campos de contraseña, campos denominados "ssn" o similares) y enmascararlos de forma predeterminada. La detección es heurística e incompleta; no confíe en ella como única línea de defensa.
Integración de CMP paso a paso
La arquitectura fiable consiste en aplazar completamente el Clarity SDK hasta que se otorgue el consentimiento y luego activarlo explícitamente a través de la API de consentimiento.
1. Elimine la etiqueta predeterminada del encabezado del documento
El fragmento de instalación de Clarity es un único script en línea que inicializa el SDK al cargar la página. Sustitúyalo por un elemento script de marcador de posición cuyo type sea text/plain y cuya data-category sea analytics o marketing dependiendo de cómo su CMP categorice las herramientas de grabación de sesiones.
2. Decida el mapeo de categorías
La grabación de sesiones es una categoría discutida. La CNIL la ha tratado de manera diversa como análisis (cuando los datos se utilizan para investigación UX interna) y como marketing (cuando los datos alimentan decisiones de personalización o compartición externa). El mapeo conservador es el marketing; la posición defendible en auditoría requiere ser específico sobre cómo se utilizan realmente las grabaciones.
3. Configure el enmascaramiento agresivo antes de la activación
Añada data-clarity-mask="true" a cada elemento de formulario, cada campo de entrada y cada contenedor que pueda contener datos personales. La política predeterminada es enmascarar por defecto con excepciones de desenmascaramiento explícitas para elementos conocidos como seguros (títulos de página, etiquetas de navegación, bloques de contenido público).
4. Active Clarity desde el callback de consentimiento
Cuando el CMP dispara el evento relevante de categoría aceptada, reescriba la etiqueta script de marcador de posición y llame a clarity("consent") para otorgar permiso al SDK para continuar. Los eventos en cola que se almacenaron en búfer durante el período previo al consentimiento se vaciarán entonces.
5. Gestione la revocación explícitamente
Si el usuario revoca el consentimiento, el Clarity SDK no tiene una llamada limpia de "detener la grabación" equivalente a la API de activación. El patrón práctico es llamar a clarity("consent", false) si está soportado en su versión del SDK, y además limpiar las cookies de Clarity en el lado del cliente. Para la eliminación completa de las grabaciones históricas, utilice el flujo de trabajo de eliminación de datos de la interfaz de administrador de Clarity o la API de eliminación.
Errores comunes
Cuatro errores de integración explican la mayoría de los hallazgos de auditoría en las implementaciones de Clarity.
Instalar Clarity "solo para ver qué hacen los visitantes"
El patrón más común: un gestor de producto instala Clarity para investigar un problema de UX, nunca activa la restricción de consentimiento, nunca configura el enmascaramiento y se olvida del script. La superficie de grabación sigue acumulándose. La solución es eliminar Clarity por completo o incluirla bajo la misma arquitectura de consentimiento que cualquier otro rastreador.
Confiar en el enmascaramiento automático
La detección heurística de campos sensibles de Clarity capta los casos obvios pero pasa por alto los específicos del dominio — el textarea "symptoms" de un sitio de salud, el campo "account number" de un sitio financiero con un nombre idiosincrático. Enmascare explícitamente; no se base en la detección automática.
Tratar la grabación de sesiones como análisis
La CNIL ha sido explícita en que la categoría de grabación de sesiones está más cerca del marketing que de las analíticas de primera parte desde una perspectiva de consentimiento. Condicionar Clarity a un consentimiento exclusivamente de análisis es defendible solo si las grabaciones se utilizan exclusivamente para investigación UX interna y nunca se comparten fuera de la organización.
Olvidar las cargas útiles de eventos personalizados
El código de la aplicación que llama a clarity("event", "name", customProperties) puede filtrar datos personales al flujo de Clarity a través de la carga útil de customProperties. Audite cada lugar de llamada y evite pasar identificadores de usuario, direcciones de correo electrónico o cualquier dato personal en las propiedades de eventos.
Lista de verificación de auditoría
Seis preguntas concretas que responder para cualquier implementación de Clarity que afecte al tráfico de la EU, el UK, Brasil o California.
- ¿Clarity espera el consentimiento? Abra la página en una ventana privada y confirme que no se disparan solicitudes a clarity.ms antes de que se acepte el banner.
- ¿El enmascaramiento es agresivo? Confirme que cada campo de formulario y cada contenedor con contenido potencialmente personal tiene aplicado data-clarity-mask.
- ¿El mapeo de categorías está documentado? Confirme que existe un registro escrito de si Clarity está condicionada a análisis o marketing, con el razonamiento.
- ¿La API de consentimiento está conectada? Confirme que el callback del CMP llama a clarity("consent") al otorgar y el equivalente al revocar.
- ¿Los eventos personalizados están auditados? Confirme que las llamadas a clarity("event", ...) no pasan datos identificativos ni sensibles en las cargas útiles de sus propiedades.
- ¿La eliminación está automatizada? Confirme que las solicitudes DSAR activan el flujo de trabajo de eliminación de Clarity y no un ticket de soporte manual.
Dónde encaja Clarity en una arquitectura que prioriza el consentimiento
La grabación de sesiones es la superficie de seguimiento de comportamiento con mayor densidad de información en el despliegue habitual, y Clarity es la herramienta que la ha democratizado de manera más agresiva. El nivel de precios gratuito y la instalación sin fricciones la convierten en el camino de menor resistencia para cualquier equipo que quiera visibilidad sobre el comportamiento de UX. Esa misma instalación sin fricciones es lo que hace que Clarity sea la herramienta de análisis más habitualmente mal configurada en las auditorías de 2026. La arquitectura correcta trata a Clarity como cualquier otro rastreador identificador: condiciónela a un consentimiento explícito, enmascare agresivamente los campos de formulario por defecto, documente el mapeo de categorías y conecte la API de consentimiento para que los propios primitivos del SDK apliquen lo que el CMP registró. Hecho correctamente, el valor de investigación UX para el que se adquirió la herramienta se preserva mientras la exposición regulatoria cae a una fracción de lo que conlleva una instalación predeterminada.