Matricúlate
Cómo probar que al rechazar desaparecen terceros, cómo evitar la “carga diferida” tramposa y qué evidencia guardar
Hay un momento en el que el discurso sobre cookies se acaba y empieza la realidad: el instante en que alguien pulsa “Rechazar”.
Ahí se ve si el banner sirve para algo o si solo cumple una función decorativa. Porque una cosa es que la interfaz diga “preferencias guardadas” y otra, muy distinta, que el sitio deje realmente de cargar terceros, deje de almacenar identificadores opcionales y respete esa decisión al navegar, recargar o cambiar de página. La CNIL lleva años insistiendo en que rechazar debe ser tan fácil como aceptar, y en 2024 volvió a actuar frente a patrones oscuros en banners que empujaban a aceptar. (cnil.fr)
Este artículo va a ese punto exacto: cómo comprobar que el modo rechazo funciona de verdad, cómo detectar trampas frecuentes —sobre todo la llamada “carga diferida” que muchos equipos confunden con cumplimiento— y qué evidencias merece la pena guardar para poder defender el resultado sin improvisaciones. La idea no es hacer una tesis, sino dejar un método que pueda repetir cualquier equipo web con cierta disciplina. (ICO)
1) Qué significa, en la práctica, que “rechazar” funcione
Que “rechazar” funcione no significa solo que desaparezca el banner o que se escriba una cookie de preferencias. Significa tres cosas muy concretas.
La primera: que, tras rechazar, no se activen tecnologías opcionales —cookies u otros mecanismos de storage/access— que dependan del consentimiento. El ICO resume la regla básica de forma muy directa: debes informar, explicar qué hacen esas tecnologías y obtener consentimiento cuando no caen en una excepción. Eso incluye no solo cookies en sentido estricto, sino tecnologías equivalentes de almacenamiento o acceso. (ICO)
La segunda: que esa negativa se mantenga. No sirve de nada un “rechazar” que funciona en la página de inicio pero se deshace al pasar a otra sección, al abrir el checkout, al cargar un embed o al aterrizar en una landing con un contenedor distinto. El problema real suele estar menos en el banner y más en la integración entre CMP, Tag Manager, scripts hardcoded y servicios externos. Ese es justamente el tipo de análisis repetible que el EDPB quiso facilitar con su herramienta de auditoría web. (edpb.europa.eu)
La tercera: que lo que ocurre en red sea coherente con lo que promete tu interfaz. La AEPD, en su guía sobre cookies analíticas externas, se mueve precisamente en ese terreno: roles, configuración real del servicio, condiciones de uso y pruebas que permitan sostener que lo implementado coincide con lo declarado. (Agencia Española de Protección de Datos)
2) El error más extendido: confundir “no disparar inmediatamente” con “no tratar”
Muchas implementaciones fallan por una idea equivocada: si el tercero no se carga “nada más entrar”, ya estamos bien. No siempre.
Hay sitios que, tras pulsar “Rechazar”, no lanzan etiquetas de forma instantánea, pero dejan preparado el terreno para activarlas en cuanto ocurre un evento posterior: scroll, clic, cambio de página, apertura de un chat, visualización de un vídeo, incluso simple permanencia en pantalla. A eso me refiero aquí con carga diferida tramposa: no desaparece el tratamiento, solo se desplaza unos segundos o unos eventos más adelante.
Desde el punto de vista de auditoría, esto es crítico porque en una revisión superficial el sitio puede “parecer limpio”, pero en cuanto amplías la prueba aparecen solicitudes a terceros, creación de identificadores o activación de embeds que deberían seguir bloqueados. Si el usuario rechazó, el estándar práctico no es “espera cinco segundos y carga igual”; el estándar es que el rechazo tenga efecto real y persistente sobre aquello que depende del consentimiento. La CNIL y el ICO, cada uno en su marco, empujan a esa lectura material del control, no a una lectura cosmética. (cnil.fr)
3) Las cinco formas en las que el “modo rechazo” suele romperse
3.1. Rechazar cambia la pantalla, pero no el tráfico
Es el caso más evidente. La CMP guarda el estado de rechazo, pero los dominios de analítica, publicidad, replay o widgets siguen apareciendo en Network. Suele deberse a etiquetas disparadas por reglas genéricas —por ejemplo, “All Pages”— o a una mala lectura de la señal de consentimiento en el Tag Manager. (edpb.europa.eu)
3.2. El script ya estaba cargado antes del banner
Aquí el problema no es el banner ni el contenedor, sino un script pegado directamente en la plantilla, en el CMS o en un plugin. Aunque el banner diga “rechazado”, ese script ya hizo la llamada. En auditoría, esto se detecta muy rápido en el escenario Pre. (edpb.europa.eu)
3.3. El rechazo se pierde al navegar
El usuario rechaza en una página, pero al abrir otra sección aparecen terceros distintos, se rearma un vendor list o se ejecuta un embed que estaba fuera del alcance inicial de la CMP. Esto pasa mucho con subdominios, landings aisladas, microsites, áreas privadas y entornos híbridos web/app. (ICO)
3.4. La carga se retrasa para parecer limpia
No ocurre nada al segundo 1, pero sí al segundo 10 o cuando haces scroll. En apariencia el sitio “respeta” el rechazo; en realidad solo retrasa el firing para pasar pruebas superficiales. Es el patrón clásico de carga diferida tramposa. No hace falta mala intención: a veces basta con un disparador mal configurado por evento o visibilidad. (edpb.europa.eu)
3.5. El embed o widget se cuela por otra puerta
Vídeos, mapas, chats, reseñas, iframes, botones sociales o conversion APIs pueden seguir activándose aunque la capa principal de consent esté bien. Son “zonas laterales” del stack que nadie incluye en el test básico y que luego rompen la coherencia del rechazo. (ICO)
4) Cómo se prueba de verdad: protocolo simple, pero serio
La mejor forma de verificar el modo rechazo es dejar de discutir “sensaciones” y montar una pequeña rutina de prueba. No hace falta un laboratorio; hace falta método.
Paso 1 — Selecciona páginas de muestreo con sentido
No te quedes en la home. Elige páginas donde el riesgo de activación de terceros sea real: inicio, landing de campaña, página con mapa o vídeo, formulario, login/registro, checkout o pricing, y una página con chat o widget si existe. Esta lógica de seleccionar escenarios relevantes en lugar de mirar solo una URL es coherente con la idea de auditoría repetible que promueve el EDPB. (edpb.europa.eu)
Paso 2 — Ejecuta tres escenarios por página
Hazlo en incógnito o borrando estado previo:
Pre: entras y no tocas el banner.
Accept: aceptas y recargas.
Reject: rechazas y recargas.
Aquí ya puedes extraer HAR o, como mínimo, guardar capturas de la pestaña Network con los dominios observados. El objetivo no es acumular archivos, sino comparar comportamientos. (edpb.europa.eu)
Paso 3 — Añade una cuarta capa de prueba: eventos y tiempo
Esta es la parte que suele faltar y que detecta la carga diferida tramposa. En el escenario Reject, además de recargar:
espera 10–15 segundos;
haz scroll;
abre o intenta abrir el chat;
reproduce el vídeo o expande el mapa;
navega a otra página del flujo.
Si en cualquiera de esos momentos aparecen terceros opcionales que deberían seguir bloqueados, el modo rechazo no está bien resuelto. El problema no es solo de UX, es de coherencia material. (ICO)
5) Qué deberías ver en cada escenario
En “Pre”
Si no concurre una excepción clara, no deberían activarse terceros opcionales. Si aparecen antes de cualquier decisión, estás ante un problema prioritario. La guía del ICO sobre storage and access technologies y la orientación de la AEPD sobre cookies lo dejan bastante claro: el punto de partida general es consentimiento para tecnologías no exentas. (ICO)
En “Accept”
Deben activarse los servicios consentidos y hacerlo de forma coherente con lo declarado en la CMP. Este escenario te sirve como “foto positiva” de referencia.
En “Reject”
Aquí está la prueba clave: frente a Accept, deberían desaparecer o quedar bloqueados los terceros opcionales. Y esa situación debe mantenerse al recargar, navegar, esperar y disparar eventos habituales de uso.
Si la diferencia entre Accept y Reject es mínima o inexistente, el rechazo no está operando realmente. (cnil.fr)
6) Ejemplos claros de “carga diferida” que engañan
Ejemplo 1 — El chat que no carga al entrar, pero sí al segundo scroll
Una web de soporte parece limpia en Reject durante los primeros segundos. Pero en cuanto haces scroll hasta el footer, aparece el widget de chat, se conecta con un tercero y empieza a intercambiar identificadores de sesión.
Lectura correcta: no respetó el rechazo; solo retrasó la conexión hasta un evento. Remedio: condicionar el widget por consentimiento o cargarlo solo tras acción expresa del usuario si la funcionalidad no es necesaria en ese punto.
Ejemplo 2 — El vídeo embebido que se “despierta” al hacer clic en play
Aquí el clic del usuario sí puede ser una frontera útil, pero solo si el diseño lo explica con honestidad y no confunde ese clic con una aceptación general de tracking. La solución razonable suele ser click-to-load con placeholder y texto claro: “al reproducir, se cargará contenido de un tercero”. Remedio: dejar claro el tercero, su función y evitar que se active antes. Lección: no todo clic es consentimiento global; a veces es solo activación puntual de un contenido.
Ejemplo 3 — La landing con otro contenedor
Home y páginas internas pasan el test, pero una landing montada por marketing usa un contenedor distinto y dispara analítica/ads aunque el usuario había rechazado. Remedio: unificar gobierno de contenedores y someter todas las plantillas al mismo test. Lección: el modo rechazo se rompe mucho más por organización que por técnica.
7) La tabla que deberías mantener: “aparece / desaparece / persiste”
Para ordenar resultados y no depender de memoria, esta tabla es especialmente útil:
Dominio / terceroPreAcceptRejectReject + scroll/esperaReject + navegaciónDecisiónanalitica-x.comSí/NoSí/NoSí/NoSí/NoSí/NoBloquear / revisarads-y.comSí/NoSí/NoSí/NoSí/NoSí/NoEliminar / condicionarchat-z.comSí/NoSí/NoSí/NoSí/NoSí/NoCargar por acciónmapa-w.comSí/NoSí/NoSí/NoSí/NoSí/NoPlaceholder / click-to-load
Con una sola vista puedes ver si el rechazo está limpio de entrada pero se rompe por evento, por tiempo o por cambio de página.
8) Qué evidencia merece la pena guardar
No hace falta guardar absolutamente todo. Lo importante es que el material sirva para explicar el resultado y para repetir la prueba después de un cambio.
Evidencia mínima útil
Capturas de la CMP en primera capa y estado “rechazado”.
HAR o capturas de Network en Pre / Accept / Reject.
Una prueba adicional en Reject con scroll o espera y otra con navegación.
Registro de versión del contenedor o de cambios en CMP/GTM.
Tabla resumida con los terceros que desaparecen y los que persisten.
La herramienta de auditoría web del EDPB y el enfoque compatible con recolectores de evidencia del entorno europeo son útiles precisamente para convertir estas pruebas en algo más repetible y comparable entre revisiones. (edpb.europa.eu)
9) Lecciones que conviene fijar
Primera lección: el rechazo no se verifica en la interfaz; se verifica en red. (Agencia Española de Protección de Datos)
Segunda: un sitio puede parecer limpio durante cinco segundos y estar roto a los diez. Si no pruebas tiempo, scroll, clics y navegación, solo has hecho media auditoría. (edpb.europa.eu)
Tercera: muchos fallos del modo rechazo nacen fuera del banner: en el contenedor, en scripts hardcoded, en embeds o en landings separadas. (ICO)
Cuarta: la evidencia más valiosa no es compleja; es consistente. Si cada release deja un pequeño paquete de pruebas comparables, el control sube mucho. (edpb.europa.eu)
Quinta: “rechazar” debe ser fácil, claro y efectivo. Si falla cualquiera de esas tres cosas, el problema no es solo de UX; es de cumplimiento. (cnil.fr)
Cierre
El modo rechazo de verdad no se demuestra con una buena intención ni con un botón bonito. Se demuestra cuando, tras pulsarlo, los terceros opcionales desaparecen, no reaparecen por la puerta de atrás y esa situación puede enseñarse con pruebas sencillas pero sólidas.
Ahí es donde una CMP deja de ser decoración y se convierte en control.
Siguiente post (Post 6)
“Cookies, analítica y medición ‘sin autoengaños’: cuándo puedes defender un uso exento, cuándo no, y qué evidencias deberías guardar”
Bibliografía y recursos
CNIL — Dark patterns in cookie banners: formal notices to website publishers. La CNIL recuerda que, salvo excepciones, las cookies requieren consentimiento y que rechazarlas debe ser tan fácil como aceptarlas. (cnil.fr)
CNIL — Refusing cookies should be as easy as accepting them. Acción continuada de la CNIL frente a banners que dificultan el rechazo. (cnil.fr)
AEPD — Guía de cookies analíticas externas. Orientación práctica sobre configuración, roles y condiciones en analítica prestada por terceros. (Agencia Española de Protección de Datos)
AEPD — Guía sobre el uso de las cookies. Marco general sobre cookies y tecnologías similares. (Agencia Española de Protección de Datos)
ICO — Guidance on the use of storage and access technologies. Guía actual del ICO sobre cookies y tecnologías equivalentes. (ICO)
ICO — Cookies and similar technologies. Resumen básico de obligaciones bajo PECR. (ICO)
EDPB — Website auditing tool. Herramienta oficial para preparar, ejecutar y evaluar auditorías web. (edpb.europa.eu)