El bàner de galetes és una de les poques peces d'un web que aconsegueix el ple: molesta el visitant, baixa la conversió i, a sobre, en la majoria de casos tampoc no compleix. Gairebé sempre és un plugin instal·lat de pressa i configurat per defecte. Abans de tocar el disseny convé saber què exigeix exactament la normativa andorrana, que no és la que gairebé tothom es pensa, i quin marge real et deixa per no espantar qui acaba d'entrar. La implementació que ensenyem va en Laravel, un dels stacks amb què treballem, però el bloqueig d'scripts i la prova del consentiment es munten igual a WordPress, Next.js o el que tinguis.
A Andorra no hi ha una llei de galetes, hi ha una llei de consentiment
Això descol·loca qui ve d'Espanya esperant trobar una norma equivalent a la de comunicacions electròniques. No existeix.
El que hi ha és el Reglament del 28 de setembre del 2022 d'aplicació de la Llei 29/2021, qualificada de protecció de dades personals, i el seu article 8 apartat 2 ho diu sense embuts:
"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."
És a dir: els rastrejadors web es regeixen per les regles generals de consentiment, no per una llei a part. I aquestes regles, al mateix article, són bastant més exigents del que compleix la majoria de bàners. Pots llegir el text consolidat al Portal Jurídic.
Tres d'aquestes regles condicionen el disseny sencer.
Rebutjar ha de costar el mateix que acceptar
L'article 8.1.a exigeix que el consentiment sigui lliure, entenent per lliure que l'usuari hagi tingut una elecció real i no condicionada a patir un perjudici si no l'atorga. I el 8.1.e afegeix que només és vàlid el consentiment que es pot revocar o denegar de manera gratuïta i sense efectes negatius.
A la pràctica això vol dir que els tres botons (configurar, rebutjar-ho tot, acceptar-ho tot) van a la mateixa fila i amb la mateixa mida. El patró d'amagar "rebutjar" darrere de dos clics, o de pintar-lo en gris clar sobre blanc mentre "acceptar" va en color de marca, és exactament el que la norma descriu com a elecció condicionada.
Si t'hi vols jugar alguna cosa, el consell és aplanar el contrast entre tots dos botons. Amb un sistema basat en variables CSS això és canviar una línia, no refer el component.
L'article 8.1.d tanca la porta al consentiment tàcit
Literal: "El consentiment no pot ser implícit o tàcit", i "el silenci o la inacció de l'interessat no es poden considerar eines vàlides per atorgar el consentiment".
Traduït a codi: totes les categories opcionals neixen desactivades i només s'activen amb un clic. Res de "si continues navegant, acceptes". Res de caselles premarcades. I res d'activar l'analítica mentre l'usuari decideix.
Aquesta última és la que més s'incompleix, i és la que converteix un bàner correcte en decoratiu.
Un bàner sense bloqueig de scripts és decoratiu
Instal·lar un bàner i donar el compliment per fet és el que fa la majoria, i és comprensible: el bàner apareix, el visitant hi prem, la pantalla marxa. Res d'aquesta seqüència no avisa que els scripts que es volien controlar ja s'havien carregat abans que el visitant hi arribés a prémer.
Un component de consentiment desa una elecció i avisa que ha canviat. Això és tot el que pot fer. Si la teva aplicació carrega l'script d'analítica al <head> passi el que passi, el bàner no protegeix res: està documentant per escrit que sabies que calia demanar permís i el vas demanar després de recollir-lo.
La part que ha d'escriure la teva aplicació és la porta:
const prefs = JSON.parse(localStorage.getItem('cookie-preferences') || '{}');
if (prefs.analytics) {
// només aquí s'injecta l'script d'analítica
}
window.addEventListener('wirecookies-saved', (e) => {
if (e.detail.marketing) { /* activar píxels */ }
});
Són deu línies i són les deu que separen complir d'aparentar.
Andie recomana
L'article 8.1.g del reglament obliga a aturar el tractament si algú retira el consentiment. Això implica que la porta no es pot comprovar només en carregar la pàgina: cal escoltar també l'esdeveniment de canvi, perquè un usuari pot desactivar l'analítica sense recarregar. Si només llegeixes el valor en arrencar, un rebuig posterior no té efecte fins a la visita següent.
El bàner que no bloqueja converteix millor i a més és el que compleix
L'habitual és viure-ho com un conflicte: complir costa conversió, així que es busca el bàner més agressiu que l'assessor legal deixi passar. Amb la norma andorrana al davant, aquesta tensió resulta ser falsa, i el disseny que menys molesta és també el que aguanta una inspecció.
Un mur de galetes no compleix el 8.1.a, perquè condiciona l'accés a atorgar consentiment. I a més és el que més rebot genera: el visitant arriba des d'una cerca, es troba una pantalla que li tapa el contingut i se'n torna enrere.
L'alternativa correcta és també la que converteix: una franja inferior que no tapa res, sense capa fosca, amb la pàgina navegable mentre l'usuari decideix. Si no decideix, no es desa res i no s'activa res opcional. Legalment impecable i sense fricció.
Hi ha dos detalls més que afecten mètriques reals. El bàner apareix amb un petit retard, de l'ordre de 800 mil·lisegons, perquè no entri al primer pintat i no compti com a desplaçament de disseny. I un cop escollit no torna a aparèixer mai, perquè l'elecció persisteix. Un bàner que reapareix a cada visita és dels pocs elements capaços d'enfonsar una conversió tot sol.
Poder retirar el consentiment no és una cortesia
L'article 8.1.c és literal i molt concret: "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 sigui que si vas demanar permís amb un bàner visible, retirar-lo ha de ser igual de visible. Enterrar-ho en un paràgraf de la política de privacitat no compleix.
La solució és un botó flotant discret que persisteix després de l'elecció i reobre el mateix panell de preferències. Ocupa poc, no molesta, i és la peça que converteix el bàner en un mecanisme bidireccional en comptes d'una porta d'un sol sentit.
Si tens un altre botó flotant a la cantonada, posa'ls a cantonades diferents. Sembla obvi i és el xoc més habitual.
On es desa l'elecció canvia el que hi pots fer
Hi ha una decisió que gairebé ningú no pren conscientment i que condiciona el que podràs fer després: desar el consentiment en una galeta o en localStorage. Sembla intercanviable i no ho és, perquè una galeta viatja en cada petició i localStorage no surt mai del navegador.
A favor: el component que gestiona el consentiment de galetes no posa cap galeta, no viatja a cada petició i no és en si mateix un tractament que s'hagi de consentir.
En contra: el servidor no el pot llegir. No pots decidir en PHP si incrustar o no l'script d'analítica; la decisió és sempre al client. I localStorage és per origen, així que un subdomini diferent demana consentiment per separat.
Per a un web normal, l'intercanvi compensa. Si el teu cas necessita decidir al servidor, necessites una galeta i sabent que aquesta galeta és tècnica i no requereix consentiment previ.
La prova del consentiment la posa la teva aplicació
El bàner resol demanar el consentiment i respectar-lo. El que no resol, i gairebé cap projecte no ho contempla fins que li ho pregunten, és demostrar mesos després que aquell visitant concret va acceptar allò concret en aquella data.
Desar l'elecció al navegador resol el comportament, no la responsabilitat proactiva que exigeix l'article 5.3 de la Llei 29/2021. Si l'Agència Andorrana de Protecció de Dades pregunta quan va consentir un usuari concret i a quina versió de la política, el navegador d'aquella persona no és una resposta.
Si la teva exposició ho justifica, el que cal afegir és un registre al servidor amb data, categories acceptades i versió de la política. És una taula i un endpoint, i s'enganxa al mateix esdeveniment de desat. Si el teu web és informatiu i no carregues res més que l'estrictament necessari, probablement no el necessitis.
La mateixa lògica val per a la caducitat. Una elecció desada no caduca sola; si la vols renovar cada cert temps, cal afegir una marca temporal i comprovar-la.
Què hi ha al mercat i en què es diferencia
Les plataformes de gestió de consentiment fan coses que un component no fa, i convé saber quines.
Cookiebot i OneTrust escanegen el teu lloc periòdicament, detecten quines galetes i quins tercers carrega, generen la declaració i mantenen un registre de consentiments al servidor amb la seva prova. Per a una empresa amb molts dominis i molts tercers, això és feina real que s'externalitza. El compromís: cost recurrent per domini, un script extern que es carrega a totes les teves pàgines i que per tant és un tercer més a la teva ruta crítica, i una estètica que és la seva.
Axeptio cuida més l'experiència i el mateix intercanvi es manté: script extern i subscripció.
La diferència d'enfocament de resoldre-ho dins de la teva pròpia aplicació és que no surt res de la pàgina. No hi ha petició a un tercer per decidir si pots fer peticions a tercers, no hi ha cost per domini i l'aspecte és el del teu producte perquè comparteix les mateixes variables CSS que la resta de la teva interfície. A canvi, el bloqueig de scripts i el registre de la prova els escrius tu, que són les deu línies i la taula de més amunt.
I si no treballes amb Laravel
Els criteris no depenen del llenguatge i serveixen per jutjar qualsevol solució:
- Que les categories opcionals neixin desactivades. Si vénen premarcades, el consentiment no és vàlid.
- Que acceptar i rebutjar tinguin el mateix pes visual i el mateix nombre de clics.
- Que existeixi una manera visible i permanent de canviar d'opinió.
- Que el bàner no bloquegi la pàgina. Ni per normativa ni per conversió.
- I que tu controlis el bloqueig dels scripts. Si l'eina no et dona un esdeveniment i un valor llegible, no pots complir per perfecte que sigui el bàner.
On és el codi
El paquet és a Packagist, el codi a GitHub i la documentació del paquet recull totes les opcions. És MIT i no fa cap petició de xarxa: no rastreja res pel seu compte.
Si a més necessites els textos, tenim un generador de política de privacitat i un generador d'avís legal per a Andorra.
El compliment en matèria de dades és una de les coses que surt més cara d'arreglar tard. El tractem a partner digital, i si ens expliques el teu cas et diem què et falta.
