Guía de Integración del Consentimiento de Cookies para Mapas de Calor y Grabaciones de Sesiones de Hotjar: Manual 2026 para Editores
Hotjar ocupa un lugar único en la pila de herramientas. No es una plataforma de análisis web como Google Analytics, ni una plataforma de análisis de productos como Amplitude o Mixpanel, ni tampoco un gestor de etiquetas. Es una herramienta de investigación de experiencia de usuario que existe específicamente para registrar lo que hacen los usuarios individuales en una página — adónde mueven el ratón, qué clican, dónde hacen scroll, dónde vacilan y, en el caso de las grabaciones de sesión, exactamente lo que escribieron y vieron renderizado en pantalla. Esa granularidad es el producto. También es la razón por la que los reguladores han identificado la reproducción de sesiones como una de las categorías de mayor riesgo en el procesamiento de comportamiento, y por qué un despliegue descuidado de Hotjar es una de las formas más fáciles para un sitio web que de otra manera cumple la normativa de salir del cumplimiento. La CNIL, el Garante y el EDPB han publicado orientaciones dirigidas específicamente al comportamiento de reproducción de sesiones, y el grupo de trabajo del EDPB sobre banners de cookies de 2026 lo trata como una categoría prioritaria. La buena noticia es que Hotjar es una de las herramientas mejor diseñadas de esta categoría para despliegues con prioridad en el consentimiento — siempre que el editor use realmente los controles que existen.
Por qué Hotjar requiere consentimiento explícito
El perfil de recopilación de Hotjar es lo que activa las obligaciones de consentimiento en todos los marcos relevantes. En una inicialización predeterminada, el script de seguimiento de Hotjar escribe al menos tres cookies de primera parte — _hjSessionUser_{siteId}, _hjSession_{siteId} y una serie de cookies de supresión y de fuente entrante — en el navegador en cuestión de milisegundos tras la carga de la página. El script comienza entonces a transmitir un registro continuo de coordenadas del cursor, coordenadas de clic, posición de desplazamiento, tamaño del viewport y, cuando la grabación de sesión está activada, el DOM completo renderizado comparado con una línea base.
Bajo el artículo 5(3) de la Directiva ePrivacy, cada una de esas cookies es una operación de almacenamiento y acceso que requiere consentimiento previo, libre, específico, informado e inequívoco en el EEE, el Reino Unido, Suiza y cualquier jurisdicción que haya adoptado el mismo estándar. Bajo el GDPR, el flujo de comportamiento constituye un tratamiento de datos personales porque la combinación del rastro del cursor, la dirección IP, la huella digital del dispositivo y el identificador de sesión es suficiente para singularizar a un individuo. Bajo el CCPA y el CPRA, la misma recopilación cuenta como una venta o compartición a menos que el editor tenga el contrato de proveedor de servicios pertinente con Hotjar — que Hotjar ofrece a través de su DPA conforme al CCPA, pero que solo entra en vigor cuando la integración está configurada correctamente. Bajo la guía del EDPB sobre reproducción de sesiones, el listón es aún más alto: la reproducción debe estar vinculada a un propósito de investigación UX específico y legítimo, el período de retención debe ser el mínimo necesario, y el interesado debe ser informado no solo de que existen grabaciones sino de que su propia sesión puede ser reproducida por un analista.
Qué recopila Hotjar antes del consentimiento — y lo que debe suprimirse
El error de implementación más común es el que viene con el propio inicio rápido de Hotjar: pegar el script de seguimiento directamente en el <head> de la página. Eso funciona, pero carga Hotjar antes de que el banner de cookies se haya siquiera renderizado, lo que significa que las cookies se establecen y la grabación de comportamiento comienza en la primera visualización de la página — independientemente de lo que el usuario decida después. Todos los reguladores de la UE que han fallado sobre este patrón lo han hecho de la misma manera: las cookies establecidas antes del consentimiento son ilegales y el editor es responsable.
Una integración conforme debe por tanto impedir que el script de Hotjar se cargue en absoluto hasta que se haya otorgado la categoría de consentimiento pertinente. La forma más limpia de hacerlo es envolver el fragmento de Hotjar dentro de una etiqueta <script> controlada por consentimiento que el CMP inyecta solo después de que el usuario haya aceptado la categoría de análisis o investigación de productos. Si el script se carga mediante un gestor de etiquetas, el equivalente es establecer el activador en un evento de consentimiento otorgado en lugar de All Pages. La propia documentación de Hotjar recomienda ahora explícitamente este patrón, y la plataforma expone una API hj('consent', 'grant') para los casos en que el script debe estar presente pero permanecer inactivo hasta que se registre el consentimiento.
Cookies y almacenamiento que escribe Hotjar
Hotjar Tracking Code 6.x escribe los siguientes identificadores, todos los cuales no son esenciales y requieren consentimiento: _hjSessionUser_{siteId} con una caducidad de 365 días que contiene el identificador del usuario, _hjSession_{siteId} con una caducidad de 30 minutos que contiene el identificador de sesión, _hjFirstSeen, _hjIncludedInSessionSample_{siteId}, _hjAbsoluteSessionInProgress y una serie de cookies de atribución de campañas cuando las encuestas o los widgets de comentarios están activos. Las propias grabaciones de sesiones se almacenan en los servidores de Hotjar y están vinculadas al identificador de sesión — revocar el consentimiento debe por tanto también señalar una solicitud de eliminación a través de la API de Hotjar o el flujo de eliminación de usuarios en el producto.
Mapeo de Hotjar a los marcos de consentimiento
Hotjar no se integra de forma nativa con IAB TCF ni con la IAB Global Privacy Platform. No es un proveedor de tecnología publicitaria y nunca estuvo pensado para serlo. Sin embargo, se integra con Google Consent Mode v2 a través de la señal analytics_storage y expone su propia API de consentimiento nativa a la que cualquier CMP puede vincularse. El patrón que supera la revisión de un regulador trata cada capacidad de Hotjar como una puerta de consentimiento separada.
- Los mapas de calor y mapas de clics se vinculan al propósito de análisis o investigación de productos. En términos de TCF, esto es más comúnmente el propósito 8 (medir el rendimiento del contenido) combinado con el propósito 1 (almacenar y/o acceder a la información). Para Consent Mode, esto es analytics_storage.
- La grabación de sesiones debe estar detrás de una señal separada y más estricta. La grabación captura el DOM renderizado y cualquier campo sin máscara, y una adhesión explícita a nivel de preferencias — no el consentimiento analítico general — es la postura defendible bajo la guía del EDPB sobre reproducción de sesiones.
- Las encuestas y los widgets de comentarios pueden funcionar bajo la misma puerta de consentimiento que la grabación de sesión cuando recogen entrada de texto libre, o bajo la puerta de análisis cuando solo recogen datos de valoración.
- Los embudos y el seguimiento de conversiones se vinculan a la puerta de análisis; si se propaga algún identificador de usuario a un CRM o plataforma publicitaria, también se aplica la puerta de marketing.
El patrón de integración que funciona
El despliegue de referencia tiene cuatro partes: un CMP que expone un evento de cambio de consentimiento en tiempo real, un cargador de scripts diferido que solo inyecta el fragmento de Hotjar después de que se active el consentimiento de análisis, una capa de supresión de grabación de sesiones que establece la grabación en desactivado por defecto hasta que se abra una puerta separada, y una configuración de enmascaramiento de entrada que suprime de forma estricta cualquier campo que un regulador consideraría sensible incluso cuando se ha otorgado el consentimiento. El cuarto punto se pasa por alto con frecuencia: el enmascaramiento de entrada no es un sustituto del consentimiento, pero sí un sustituto de la catástrofe cuando el consentimiento se otorga para una investigación legítima y un usuario pega datos sensibles en un campo de texto libre.
Implementación web
En la web, el patrón más limpio es suscribirse al evento de cambio de consentimiento del CMP y luego inyectar condicionalmente el fragmento de Hotjar cuando el propósito analítico cambie de falso a verdadero. Use document.createElement('script') para inyectar el código de seguimiento con el atributo async establecido, y adjunte un controlador onload que llame a hj('identify', userId, properties) solo si existe un identificador de usuario validado por el servidor. Cuando se revoca el consentimiento, llame a hj('consent', 'revoke'), haga caducar todas las cookies _hj mediante document.cookie y envíe una solicitud de eliminación a través de la API de Hotjar Data para las grabaciones de sesiones anteriores del usuario. No inicialice Hotjar de forma perezosa en el mismo paso de renderizado que el banner — el script debe esperar a una concesión explícita, y la concesión debe quedar registrada con una marca de tiempo y una cadena de consentimiento antes de que el script se ejecute.
Enmascaramiento de entrada y supresión de datos sensibles
El grabador de sesiones de Hotjar se entrega con tres modos de enmascaramiento: Suppress mode, que es el predeterminado para los campos de contraseña y cualquier elemento marcado con el atributo data-hj-suppress; Whitelist mode, donde solo se graban las entradas explícitamente aceptadas; y Mask mode, donde las pulsaciones de teclas se registran como asteriscos. Bajo las reglas de categoría especial del GDPR y la definición de información personal sensible del CCPA, cualquier campo que pueda capturar información sanitaria, detalles financieros, identificadores gubernamentales, datos biométricos, geolocalización precisa o contenido de comunicaciones privadas debe usar Suppress mode independientemente del estado de consentimiento del usuario. Establecer data-hj-suppress a nivel de formulario en lugar de a nivel de campo es el patrón más seguro — suprime todo el formulario incluso si un desarrollador añade posteriormente un nuevo campo que olvida marcar individualmente.
Aplicaciones de página única y cambios de ruta
Para las SPA (React, Vue, Angular, Svelte), el fragmento de Hotjar se vincula por defecto solo a la carga inicial de la página. Para rastrear transiciones de página virtuales, el bootstrap debe llamar a hj('stateChange', newPath) en cada cambio de ruta. Esta llamada respeta el estado de consentimiento que Hotjar mantiene en ese momento, por lo que la lógica de control del CMP no necesita duplicarse — pero el cambio de ruta no debe por sí mismo desencadenar una nueva carga de script si el consentimiento se ha revocado entre visualizaciones de página.
Validación de la integración
El paso de validación es lo que verifican los reguladores y lo que los editores omiten con mayor frecuencia. Un despliegue de Hotjar correctamente integrado debe pasar cuatro pruebas en orden. En primer lugar, una nueva sesión de navegador con el banner mostrado pero sin ninguna elección realizada debe producir cero solicitudes a static.hotjar.com, script.hotjar.com o vars.hotjar.com, y cero cookies _hj en document.cookie. En segundo lugar, rechazar el análisis debe mantener ese estado — sin carga de script, sin grabación, sin cookies. En tercer lugar, aceptar el análisis debe producir una carga de script y las cookies esperadas _hjSessionUser y _hjSession con atributos SameSite correctos, y una grabación de mapa de calor debe aparecer en el panel de Hotjar en cinco minutos. En cuarto lugar, revocar el consentimiento a posteriori debe detener inmediatamente la grabación adicional, hacer caducar las cookies y activar una solicitud de eliminación — una limpieza tardía es una infracción.
El rastro de auditoría importa por separado. Los reguladores esperan que el editor pueda demostrar, para cualquier grabación en la cuenta de Hotjar, que el usuario que la generó había dado un consentimiento válido en el momento de la captura. El patrón estándar es incrustar la versión del consentimiento y la marca de tiempo como atributo personalizado en el registro de usuario de Hotjar mediante hj('identify', userId, { consent_version: 'v3', consent_ts: ts }). Eso hace que cualquier grabación específica sea rastreable hasta una entrada específica del registro de consentimiento, que es el estándar que ha fijado el EDPB y el estándar que los editores deben adoptar independientemente de dónde operen. Un despliegue correctamente controlado, combinado con un enmascaramiento de entrada que suprime por defecto y una ruta de eliminación que se activa al revocar, es lo que hace de Hotjar una parte defendible de una pila de investigación en lugar de una obligación de cumplimiento.