El banner de cookies aparece encima del hero, tapa el teléfono y el botón de pedir cita, y ofrece «Aceptar todas» en verde y «Configurar» en gris. Cumples el trámite. También estás enseñando la web por primera vez a través de un muro. El banner cookies UX conversión no es un plugin que se pega al final: es parte de la primera impresión y de cómo carga la página.
En España el consentimiento no es un checkbox escondido ni un «al navegar aceptas». Es una decisión informada, tan fácil de rechazar como de aceptar. Eso no obliga a un modal a pantalla completa ni a retrasar el contenido útil. Obliga a diseñar el momento, el copy y —sobre todo— qué scripts no se ejecutan hasta que hay respuesta.
Este artículo es el criterio que usamos en Truman en desarrollo web a medida: cumplir, no tapar el producto, y no convertir el consentimiento en un segundo de más en el LCP. Sin trucos. Sin «cumplir a medias».
Banner cookies UX conversión: el trámite no va encima del producto
El error habitual es tratar el consentimiento como una capa legal desconectada del resto de la web. Se instala un CMP, se pega el snippet y se da por cerrado. El diseño, el formulario y el INP se trabajan en otra partida. Luego el banner empuja el hero, el chat se pisa con el botón de aceptar y el LCP se mide con media página tapada.
Cumplir y convertir no son opuestos. Lo que destroza la conversión no es preguntar: es preguntar mal. Un muro a pantalla completa, un copy de 180 palabras y un «rechazar» escondido enseñan desconfianza antes de que el usuario haya leído quiénes sois. En una clínica o en una industrial, esa primera impresión pesa más que en un media.
En Truman el banner entra en el mismo sistema que el resto de la UI: tipografía, contraste, foco de teclado, y un sitio en el layout que no anula el CTA principal. La accesibilidad WCAG no se salta porque el bloque sea «legal». Un overlay sin foco atrapado y sin botón claro es un problema de producto, no de abogado.
Qué obliga la norma (y qué no obliga el plugin)
En la UE, las cookies no necesarias y las tecnologías equivalentes (píxeles, huella, almacenamiento local usado para tracking) piden consentimiento previo. Previo significa: no se cargan hasta que hay una respuesta afirmativa. Las estrictamente necesarias —sesión, seguridad, equilibrio de carga, preferencia de idioma que pide el usuario— no necesitan ese banner para existir.
| Decisión de diseño | Encaje | Por qué |
|---|---|---|
| Aceptar y rechazar al mismo nivel, un clic | Correcto | La AEPD pide paridad. Además, el usuario decide y sigue |
| Barra inferior que no tapa el CTA en desktop | Correcto | Informa sin convertir la home en un diálogo modal |
| Muro a pantalla completa hasta aceptar | Evitar | Cookie wall: fricción y, en muchos casos, riesgo legal |
| Rechazar escondido en «configurar» | Evitar | Patrón oscuro. No cumple el espíritu de la norma |
| Scripts de analítica en el HTML «por si acaso» | Incompleto | El banner pregunta; el píxel ya ha disparado |
Esto no es asesoría jurídica. Es el perímetro con el que diseñamos y desarrollamos. El texto legal, la lista de proveedores y la política de cookies los firma quien corresponda. Lo que no se improvisa en el estudio es la simetría de las acciones, el momento de carga de scripts y que el banner no anule el motivo por el que alguien ha entrado.
La carga de scripts es el consentimiento de verdad
El banner visible es la mitad. La otra mitad es el gestor de etiquetas y cómo se inyectan los terceros. Si Google Tag Manager, el píxel o el widget de chat están en el <head> sin condición, has preguntado después de haber medido. Eso no se arregla con un texto más claro.
El patrón correcto es aburrido y sólido: cookies necesarias siempre; analítica, marketing y embeds de terceros solo después del sí (o de la categoría aceptada). El CMP no es un overlay: es un interruptor de carga. Si el interruptor no corta el script, el overlay es teatro.
Ese corte también es rendimiento. Cada script que no se carga en la primera visita es menos trabajo para el hilo principal. El INP no se arregla solo con un banner más pequeño: se arregla no ejecutando lo que el usuario no ha pedido. Si te interesa el detalle de interacción, está en el artículo de Core Web Vitals e INP. Aquí el punto es de arquitectura: el consentimiento es una puerta, no una pegatina.
Si mañana bloqueas todos los scripts de marketing en staging, ¿la web sigue midiendo, vendiendo y pidiendo cita igual? Si la respuesta es no, el consentimiento no está separado del producto.
Diseño del banner: jerarquía, no teatro
Copy corto. Dos acciones visibles. Un enlace a la política. Un «configurar» para quien quiera granularidad, no como único camino al rechazo. En móvil, el bloque no puede tapar el CTA de la primera pantalla si ese CTA es el negocio —pedir cita, llamar, pedir presupuesto.
Frase de una línea, no un contrato
Aceptar y rechazar al mismo nivel
Categorías claras, no 40 proveedores
El color del botón de aceptar no tiene que ser el CTA de la marca si eso confunde las dos acciones. El CTA de la web es «Pedir cita» o «Escribirnos». El del banner es «Aceptar» y «Rechazar». Si ambos gritan igual, el usuario pulsa el más grande para quitar el estorbo. Eso no es conversión de negocio: es conversión de trámite.
El contraste y el foco importan. Un banner semitransparente sobre una foto oscura, con texto gris, no se lee. Un usuario de teclado que tabula y se pierde detrás del overlay no ha consentido: se ha quedado atrapado. Mismo criterio que en un formulario que no convierte: si el control no se entiende, la gente abandona o pulsa cualquier cosa.
Clínica y B2B: el banner no puede tapar la confianza
En Clínica Eleya la primera pantalla tiene que decir quiénes sois, qué tratamiento y cómo se pide cita. Un overlay a pantalla completa delante de eso no es «más legal»: es menos clínica. El consentimiento cabe en una barra o en un bloque anclado que deje ver el contenido. El paciente no está comparando CMPs. Está decidiendo si se fía.
En Grupo Candela la web trabaja para un comprador B2B que aterriza por capacidad, planta o un comercial que le ha mandado el enlace. El banner que tapa el teléfono o el PDF de producto convierte un contacto cualificado en un clic de «aceptar» para poder leer. Ahí el cumplimiento bien resuelto es invisible: informa, deja elegir y no interrumpe el oficio.
Criterio de implementación que pedimos (y que pedimos que nos pidan)
Lista de categorías, no un saco de «cookies». Un registro de qué script corresponde a qué categoría. Un estado persistido (y un sitio en el footer para cambiarlo). Prueba en una sesión limpia: rechazar y verificar en red que no salen las peticiones de analítica ni de ads. Prueba de teclado y de lector. Medición de LCP e INP con el banner visible y con el banner ya decidido.
Un CMP de mercado puede valer. Un snippet mal puesto no. Si el presupuesto no cubre un consentimiento bien cableado, no cubre un launch limpio. El banner «para salir del paso» se queda años. Se ve en cada visita. Y es, a menudo, el componente más feo de una web que por lo demás está bien.
El consentimiento no se diseña para que acepten. Se diseña para que elijan y la web siga siendo la web. Si el banner es el elemento más ruidoso de la home, no tienes un problema legal. Tienes un problema de producto.
Antes de dar por cerrado el consentimiento, verifica esto
- ¿Aceptar y rechazar están al mismo nivel, a un clic, sin laberinto?
- ¿En móvil el banner deja visible el CTA de negocio de la primera pantalla?
- ¿Los scripts de analítica y marketing no están en el HTML inicial?
- ¿Al rechazar, la pestaña Red no muestra píxeles ni GTM de marketing?
- ¿La preferencia se recuerda y se puede cambiar desde el footer?
- ¿El banner es usable con teclado y tiene contraste suficiente?
- ¿Chat, WhatsApp y overlay no se pisan con el bloque de cookies?
- ¿Habéis medido LCP e INP con el banner visible, no solo con él cerrado?
Preguntas frecuentes sobre cookies, consentimiento y conversión
¿Un banner de cookies baja la conversión?
Un muro a pantalla completa, un rechazo escondido o un bloque que tapa el teléfono, sí. Un aviso claro, con dos acciones al mismo nivel y scripts que no cargan hasta decidir, interrumpe menos que un chat, un popup de newsletter y tres anuncios. El daño no es preguntar: es preguntar como si la web no existiera debajo.
¿Puedo cargar Google Analytics antes de que el usuario acepte?
Si lo usas para medir personas y no es estrictamente necesario para prestar el servicio, el criterio habitual en la UE es que no. El matiz lo marca tu base jurídica y tu DPO, no el estudio. Lo que sí es técnico y no negociable: si dices que no se mide hasta el sí, el script no puede estar disparando en el head.
¿Hace falta un CMP de pago para cumplir?
No siempre. Hace falta un inventario, una puerta de carga y una UI honesta. Un CMP ayuda cuando hay muchos proveedores y hay que mantener la lista. Un CMP mal configurado cumple en la captura de pantalla y falla en la red. Elige por el cableado, no por el logo del sello.
¿El banner tiene que salir en todas las páginas?
Hasta que hay una decisión persistida, sí tiene que poder decidirse. Después, no. Si reaparece en cada URL, el consentimiento no se está guardando bien o estás midiendo mal el dominio. Eso cansa y parece un sitio roto. Arréglalo en implementación, no con un «aceptar» más grande.
