80% of Cookie Reject Buttons Don't Actually Work — Here's the Proof

Cada banner de cookies hace la misma promesa implícita: haga clic en "Rechazar" y el rastreo se detiene. El banner desaparece y usted navega en paz. Ese es el trato en el que se basa el modelo de consentimiento -- la idea de que los usuarios tienen una elección significativa y ejecutable.

Probamos esa promesa en 28.891 sitios web de la UE. En el 80,4% de ellos, la promesa está rota. El rastreo continúa después de que el usuario hace clic explícitamente en rechazar. Las cookies persisten. Los píxeles publicitarios siguen disparándose. Y en 1.642 sitios, las cookies que la acción de rechazo elimina inicialmente regresan la próxima vez que la página se carga -- un patrón que llamamos reaparición del consentimiento.

Este no es un hallazgo marginal sobre unos pocos sitios mal configurados. Apunta a un problema sistémico en el mecanismo del que cientos de millones de residentes de la UE dependen para sus derechos de privacidad.

Lo que "Rechazar" debería hacer -- legalmente

El marco legal es claro. Bajo el Artículo 5(3) de la Directiva ePrivacy, almacenar o acceder a información en el equipo terminal de un usuario requiere consentimiento previo, con una excepción estrecha para cookies estrictamente necesarias para un servicio que el usuario ha solicitado explícitamente. El Artículo 7(3) del GDPR añade que retirar el consentimiento debe ser tan fácil como darlo, y el responsable del tratamiento debe actuar sobre esa retirada.

Las Directrices 05/2020 del EDPB sobre consentimiento bajo el GDPR detallan lo que esto significa para los botones de rechazo: si un sitio web ofrece una opción "Aceptar todo", también debe ofrecer una opción igualmente prominente e igualmente accesible para rechazar. Y ese rechazo debe ser efectivo -- debe realmente prevenir el tratamiento que el consentimiento habría autorizado.

El CJEU reforzó esto en Planet49 (C-673/17): el consentimiento requiere un acto afirmativo claro, y las casillas premarcadas no constituyen consentimiento válido. El corolario lógico es que un rechazo -- un acto negativo explícito -- debe ser respetado tan definitivamente como una aceptación. Si hacer clic en "Aceptar" activa el rastreo, hacer clic en "Rechazar" debe desactivarlo. No parcialmente. No temporalmente. Completa y persistentemente.

Eso es lo que dice la ley. Nuestros datos muestran lo que realmente sucede.

Cómo probamos el flujo de rechazo

Nuestra prueba del flujo de rechazo está diseñada para ser lo más cercana posible a la experiencia de un usuario humano real haciendo clic en rechazar, con la adición de instrumentación completa. Aquí está el proceso paso a paso:

Paso 1: Sesión de navegador limpia. El escáner lanza una instancia Chromium limpia -- sin cookies, sin almacenamiento local, sin recursos en caché, sin historial de navegación. Este es un visitante genuino por primera vez sin estado de consentimiento previo. Paso 2: Navegar y registrar el estado pre-consentimiento. El escáner carga la URL objetivo y espera a que la página se estabilice. Antes de cualquier interacción, registra cada cookie presente en el navegador, cada solicitud de red realizada y cada dominio de terceros contactado. Esta es la línea base pre-consentimiento -- lo que el sitio hace antes de que el usuario tenga cualquier oportunidad de hacer una elección. Paso 3: Detectar el banner de consentimiento. Usando nuestra biblioteca de detección que cubre 45 CMP conocidos y heurísticas genéricas, el escáner identifica el mecanismo de consentimiento y localiza el botón de rechazo. Este paso usa un enfoque multicapa: primero verificando firmas de scripts CMP conocidos y sus estructuras DOM asociadas, luego recurriendo a la detección genérica de elementos de posición fija con texto relacionado con el consentimiento y etiquetas de botones como "Rechazar todo", "Declinar", "Rechazar" o traducciones equivalentes. Paso 4: Hacer clic en rechazar. El escáner hace clic en el botón de rechazo y espera a que la página se estabilice. "Estabilice" significa esperar a que las solicitudes de red pendientes se completen, las mutaciones DOM se detengan y cualquier animación o transición termine. Usamos tiempos de espera generosos para evitar falsos positivos de implementaciones CMP lentas. Paso 5: Captura post-rechazo. El escáner registra el estado completo de nuevo: todas las cookies, toda la actividad de red, todos los dominios de terceros. Esta captura se compara con la línea base pre-consentimiento para determinar qué cambió. Paso 6: Recargar y verificar reaparición. El escáner recarga la página y espera a que se estabilice de nuevo. Luego toma una captura final. Este paso es crítico: revela si la acción de rechazo es persistente (respetada a través de cargas de página) o si las cookies y el rastreo se reactivan cuando la página se carga de nuevo. Si cookies que fueron eliminadas en el paso 5 reaparecen en el paso 6, eso es reaparición del consentimiento.

Cada paso produce evidencia con marca de tiempo y archivable: inventarios completos de cookies con nombres, valores, dominios, fechas de expiración y flags; registros completos de solicitudes de red con URL, métodos, códigos de respuesta y timing; y capturas de pantalla de página completa. Esta cadena de evidencia permite que cualquier hallazgo individual sea verificado y cuestionado.

Los resultados: 80,4% de fallo

De los 28.891 sitios web donde completamos exitosamente la prueba completa del flujo de rechazo:

• 5.650 (19,6%) aprobaron. Después de hacer clic en rechazar, las cookies no esenciales fueron eliminadas, las solicitudes de rastreo cesaron y el rechazo persistió a través de recargas de página.
• 23.241 (80,4%) fallaron. El rastreo continuó de alguna forma después de que el usuario hiciera clic explícitamente en rechazar.

Los fallos no son uniformes. Caen en categorías distintas que se superponen -- un solo sitio puede exhibir múltiples modos de fallo simultáneamente.

Cookies persistentes: 10.848 sitios

En 10.848 sitios (37,5% de los probados), cookies no esenciales permanecieron en el navegador después de que el flujo de rechazo se completó. Estas son cookies clasificadas como relacionadas con analítica, marketing o rastreo que deberían haber sido eliminadas o prevenidas de establecerse después de una acción de rechazo.

Las cookies persistentes más comunes pertenecen a Google Analytics (`_ga`, `_gid`, `_gat`), Meta/Facebook (`_fbp`, `fr`) y varias plataformas publicitarias. En muchos casos, el CMP elimina exitosamente algunas cookies pero falla en atrapar todas -- sugiriendo integración incompleta entre la plataforma de gestión de consentimiento y la lista completa de scripts de terceros del sitio.

La presencia de estas cookies después del rechazo no es meramente un problema estético. Cada una es un identificador persistente que vincula la sesión actual del usuario con visitas pasadas y futuras. La cookie `_ga`, por ejemplo, es un identificador de cliente único que Google Analytics usa para construir un perfil longitudinal del comportamiento del usuario a través de sesiones. Si persiste después del rechazo, la navegación del usuario continúa siendo rastreada y agregada independientemente de su rechazo explícito.

Rastreadores persistentes: 14.547 sitios

En 14.547 sitios (50,3% de los probados), los servicios de rastreo permanecieron activos después del rechazo -- lo que significa que el navegador continuó haciendo solicitudes a dominios de rastreo conocidos incluso después de que el usuario hiciera clic en el botón de rechazo.

Este es un modo de fallo distinto de la persistencia de cookies. Un rastreador puede estar activo sin establecer una cookie: solicitudes de píxeles, llamadas de beacon y cargas de scripts todos transmiten información (como mínimo, la dirección IP del usuario, la página de referencia y datos de timing) a servidores de terceros independientemente de si se almacena una cookie. Esto a veces se llama "rastreo sin cookies" y es cada vez más común a medida que los navegadores endurecen las restricciones sobre cookies de terceros.

La brecha entre la cifra de cookies (10.848) y la cifra de rastreadores (14.547) es significativa. Significa que en aproximadamente 3.700 sitios, la acción de rechazo eliminó exitosamente cookies pero falló en prevenir que las solicitudes de rastreo continuaran. El CMP manejó la limpieza de cookies pero no bloqueó los scripts que generan el tráfico de rastreo en primer lugar. Esto apunta a un problema arquitectónico común: el CMP está configurado para gestionar cookies (eliminarlas al rechazar, prevenirlas al cargar) pero no para gestionar la ejecución de scripts.

Reaparición del consentimiento: 1.642 sitios, 4.932 cookies

La reaparición del consentimiento es el patrón más preocupante que identificamos. En 1.642 sitios, cookies que habían sido exitosamente eliminadas por la acción de rechazo reaparecieron después de recargar la página. A través de esos sitios, 4.932 cookies individuales exhibieron este comportamiento de reaparición.

La reaparición del consentimiento no es un error en un CMP o una configuración. Es un problema estructural en cómo se implementa el consentimiento a través de la pila web.

Cómo una cookie regresa después de ser eliminada. Cuando un usuario hace clic en rechazar, un CMP correctamente configurado hace dos cosas: elimina las cookies no esenciales existentes (estableciendo su expiración a una fecha pasada) y actualiza un registro de consentimiento (usualmente una cookie en sí misma o una entrada de localStorage) que indica a la lógica de bloqueo del CMP que prevenga que scripts no esenciales se ejecuten en cargas de página futuras. Si ambas funcionan, el usuario está limpio: sin cookies de rastreo, sin scripts de rastreo.

La reaparición del consentimiento ocurre cuando la eliminación tiene éxito pero el bloqueo falla. El escenario más común:

1. El CMP elimina la cookie `_ga` cuando el usuario hace clic en rechazar.

2. El CMP establece una cookie de estado de consentimiento registrando que el usuario rechazó la analítica.

3. En la siguiente carga de página, el CMP verifica su estado de consentimiento y sabe que el usuario rechazó.

4. Pero: la etiqueta de script de Google Analytics está incrustada directamente en la plantilla de la página (fuera del gestor de etiquetas) o se carga por una regla del gestor de etiquetas que no verifica el estado de consentimiento.

5. El script de GA se carga, no ve cookie `_ga` y crea una nueva.

6. La decisión de rechazo del usuario ha sido anulada.

Las variaciones de este patrón incluyen: scripts de terceros cargados mediante etiquetas `