El banner de cookies es una de las pocas piezas de una web que consigue el pleno: molesta al visitante, baja la conversión y encima, en la mayoría de casos, tampoco cumple. Casi siempre es un plugin instalado deprisa y configurado por defecto. Antes de tocar el diseño conviene saber qué exige exactamente la normativa andorrana, que no es la que casi todo el mundo cree, y qué margen real te deja para no espantar a quien acaba de entrar. La implementación que enseñamos va en Laravel, uno de los stacks con los que trabajamos, pero el bloqueo de scripts y la prueba del consentimiento se montan igual en WordPress, Next.js o lo que tengas.
En Andorra no hay una ley de cookies, hay una ley de consentimiento
Esto descoloca a quien viene de España esperando encontrar una norma equivalente a la de comunicaciones electrónicas. No existe.
Lo que hay es el Reglament del 28 de setembre del 2022 d'aplicació de la Llei 29/2021, qualificada de protecció de dades personals, y su artículo 8 apartado 2 lo dice sin rodeos:
"Les característiques i les condicions establertes als articles 7 i 8 de la Llei 29/2021 [...] són el marc legal per redactar polítiques de privacitat de pàgines web i polítiques informatives de rastrejadors web."
Es decir: los rastreadores web se rigen por las reglas generales de consentimiento, no por una ley aparte. Y esas reglas, en el mismo artículo, son bastante más exigentes de lo que la mayoría de banners cumple. Puedes leer el texto consolidado en el Portal Jurídic.
Tres de esas reglas condicionan el diseño entero.
Rechazar tiene que costar lo mismo que aceptar
El artículo 8.1.a exige que el consentimiento sea libre, entendiendo por libre que el usuario haya tenido una elección real y no condicionada a sufrir un perjuicio si no la otorga. Y el 8.1.e añade que solo es válido el consentimiento que se puede revocar o denegar de forma gratuita y sin efectos negativos.
En la práctica eso significa que los tres botones (configurar, rechazar todo, aceptar todo) van en la misma fila y con el mismo tamaño. El patrón de esconder "rechazar" detrás de dos clics, o de pintarlo en gris claro sobre blanco mientras "aceptar" va en color de marca, es exactamente lo que la norma describe como elección condicionada.
Si vas a jugarte algo aquí, el consejo es aplanar el contraste entre ambos botones. Con un sistema basado en variables CSS eso es cambiar una línea, no rehacer el componente.
El artículo 8.1.d cierra la puerta al consentimiento tácito
Literal: "El consentiment no pot ser implícit o tàcit", y "el silenci o la inacció de l'interessat no es poden considerar eines vàlides per atorgar el consentiment".
Traducido a código: todas las categorías opcionales nacen desactivadas y solo se activan con un clic. Nada de "si continúas navegando, aceptas". Nada de casillas premarcadas. Y nada de activar analítica mientras el usuario decide.
Esa última es la que más se incumple, y es la que convierte un banner correcto en decorativo.
Un banner sin bloqueo de scripts es decorativo
Instalar un banner y dar el cumplimiento por hecho es lo que hace la mayoría, y es comprensible: el banner aparece, el visitante pulsa, la pantalla se va. Nada en esa secuencia avisa de que los scripts que se querían controlar ya se habían cargado antes de que el visitante llegara a pulsar.
Un componente de consentimiento guarda una elección y avisa de que ha cambiado. Eso es todo lo que puede hacer. Si tu aplicación carga el script de analítica en el <head> pase lo que pase, el banner no está protegiendo nada: está documentando por escrito que sabías que había que pedir permiso y lo pediste después de recogerlo.
La parte que tiene que escribir tu aplicación es la puerta:
const prefs = JSON.parse(localStorage.getItem('cookie-preferences') || '{}');
if (prefs.analytics) {
// solo aquí se inyecta el script de analítica
}
window.addEventListener('wirecookies-saved', (e) => {
if (e.detail.marketing) { /* activar píxeles */ }
});
Son diez líneas y son las diez que separan cumplir de aparentar.
Andie recomienda
El artículo 8.1.g del reglamento obliga a parar el tratamiento si alguien retira el consentimiento. Eso implica que la puerta no puede comprobarse solo al cargar la página: hay que escuchar también el evento de cambio, porque un usuario puede desactivar la analítica sin recargar. Si solo lees el valor al arrancar, un rechazo posterior no surte efecto hasta la siguiente visita.
El banner que no bloquea convierte mejor y además es el que cumple
Lo habitual es vivir esto como un conflicto: cumplir cuesta conversión, así que se busca el banner más agresivo que el asesor legal deje pasar. Con la norma andorrana delante, esa tensión resulta ser falsa, y el diseño que menos molesta es también el que aguanta una inspección.
Un muro de cookies no cumple el 8.1.a, porque condiciona el acceso a otorgar consentimiento. Y además es lo que más rebote genera: el visitante llega desde una búsqueda, se encuentra una pantalla que le tapa el contenido y se vuelve atrás.
La alternativa correcta es también la que convierte: una franja inferior que no tapa nada, sin capa oscura, con la página navegable mientras el usuario decide. Si no decide, no se guarda nada y nada opcional se activa. Legalmente impecable y sin fricción.
Hay dos detalles más que afectan a métricas reales. El banner aparece con un pequeño retardo, del orden de 800 milisegundos, para que no entre en el primer pintado y no cuente como desplazamiento de diseño. Y una vez elegido no vuelve a aparecer nunca, porque la elección persiste. Un banner que reaparece en cada visita es de los pocos elementos capaces de hundir una conversión por sí solo.
Poder retirar el consentimiento no es una cortesía
El artículo 8.1.c es literal y muy concreto: "Els mecanismes posats a disposició de l'interessat per part del responsable de retirar el consentiment han de ser tan intuïtius i accessibles com els que facilita per obtenir el consentiment."
O sea que si pediste permiso con un banner visible, retirarlo tiene que ser igual de visible. Enterrarlo en un párrafo de la política de privacidad no cumple.
La solución es un botón flotante discreto que persiste después de la elección y reabre el mismo panel de preferencias. Ocupa poco, no molesta, y es la pieza que convierte el banner en un mecanismo bidireccional en vez de una puerta de un solo sentido.
Si tienes otro botón flotante en la esquina, ponlos en esquinas distintas. Parece obvio y es el choque más habitual.
Dónde se guarda la elección cambia lo que puedes hacer con ella
Hay una decisión que casi nadie toma conscientemente y que condiciona lo que podrás hacer después: guardar el consentimiento en una cookie o en localStorage. Parece intercambiable y no lo es, porque una cookie viaja en cada petición y localStorage no sale nunca del navegador.
A favor: el componente que gestiona el consentimiento de cookies no pone ninguna cookie, no viaja en cada petición y no es en sí mismo un tratamiento que haya que consentir.
En contra: el servidor no puede leerlo. No puedes decidir en PHP si incrustar o no el script de analítica; la decisión es siempre en cliente. Y localStorage es por origen, así que un subdominio distinto pide consentimiento por separado.
Para una web normal, el intercambio compensa. Si tu caso necesita decidir en servidor, necesitas una cookie y sabiendo que esa cookie es técnica y no requiere consentimiento previo.
La prueba del consentimiento la pone tu aplicación
El banner resuelve pedir el consentimiento y respetarlo. Lo que no resuelve, y casi ningún proyecto lo contempla hasta que le preguntan, es demostrar meses después que aquel visitante concreto aceptó aquello concreto en aquella fecha.
Guardar la elección en el navegador resuelve el comportamiento, no la responsabilidad proactiva que exige el artículo 5.3 de la Llei 29/2021. Si la Agència Andorrana de Protecció de Dades pregunta cuándo consintió un usuario concreto y a qué versión de la política, el navegador de esa persona no es una respuesta.
Si tu exposición lo justifica, lo que hay que añadir es un registro en servidor con fecha, categorías aceptadas y versión de la política. Es una tabla y un endpoint, y se engancha al mismo evento de guardado. Si tu web es informativa y no cargas más que lo estrictamente necesario, probablemente no lo necesites.
La misma lógica vale para la caducidad. Una elección guardada no caduca sola; si quieres renovarla cada cierto tiempo, hay que añadir una marca temporal y comprobarla.
Qué hay en el mercado y en qué se diferencia
Las plataformas de gestión de consentimiento hacen cosas que un componente no hace, y conviene saber cuáles.
Cookiebot y OneTrust escanean tu sitio periódicamente, detectan qué cookies y qué terceros carga, generan la declaración y mantienen un registro de consentimientos en servidor con su prueba. Para una empresa con muchos dominios y muchos terceros, eso es trabajo real que se externaliza. El compromiso: coste recurrente por dominio, un script externo que se carga en todas tus páginas y que por tanto es un tercero más en tu ruta crítica, y una estética que es la suya.
Axeptio cuida más la experiencia y el mismo intercambio se mantiene: script externo y suscripción.
La diferencia de enfoque de resolverlo dentro de tu propia aplicación es que no sale nada de la página. No hay petición a un tercero para decidir si puedes hacer peticiones a terceros, no hay coste por dominio y el aspecto es el de tu producto porque comparte las mismas variables CSS que el resto de tu interfaz. A cambio, el bloqueo de scripts y el registro de la prueba los escribes tú, que son las diez líneas y la tabla de más arriba.
Y si no trabajas con Laravel
Los criterios no dependen del lenguaje y sirven para juzgar cualquier solución:
- Que las categorías opcionales nazcan desactivadas. Si vienen premarcadas, el consentimiento no es válido.
- Que aceptar y rechazar tengan el mismo peso visual y el mismo número de clics.
- Que exista una forma visible y permanente de cambiar de opinión.
- Que el banner no bloquee la página. Ni por normativa ni por conversión.
- Y que tú controles el bloqueo de los scripts. Si la herramienta no te da un evento y un valor legible, no puedes cumplir aunque el banner sea perfecto.
Dónde está el código
El paquete está en Packagist, el código en GitHub y la documentación del paquete recoge todas las opciones. Es MIT y no hace ninguna petición de red: no rastrea nada por su cuenta.
Si además necesitas los textos, tenemos un generador de política de privacidad y un generador de aviso legal para Andorra.
El cumplimiento en materia de datos es una de las cosas que más caro sale arreglar tarde. Lo tratamos en partner digital, y si nos cuentas tu caso te decimos qué te falta.
