Banners que empujan: cuando el diseño te mete en problemas- Post 1 — Serie 2 (Cookies/CMP/UX)

Posted on by Leocadio Marrero Trujillo

Banners que empujan: cuando el diseño te mete en problemas

Subtítulo: cómo detectar en 10 minutos si tu banner “invita a aceptar” y qué evidencia guardar para poder defenderlo.

 

Hay banners que “cumplen” en apariencia: tienen primera capa, segunda capa, lista de proveedores, enlace a política… y aun así el usuario no elige, cede. No siempre por mala fe: muchas veces por diseño. Aceptar es fácil. Rechazar es un laberinto.

Este post va de algo muy simple:

Si aceptar cuesta 1 clic y rechazar cuesta 5, no estás pidiendo un consentimiento: estás empujando una decisión.

Y cuando el banner empuja, tu cumplimiento se vuelve frágil. Porque el día que alguien lo revisa con ojos de auditoría o inspección, lo que importa no es cómo se ve: importa si deja elegir y si lo que se elige se respeta.

1) El problema real no es el banner: es la fricción

En la práctica, el consentimiento se juega en tres cosas:

  1. Equivalencia
    Rechazar debe ser tan fácil como aceptar: misma visibilidad, mismo esfuerzo.
  2. Claridad
    El usuario entiende qué está aceptando: sin frases vagas, sin confundir finalidades.
  3. Efecto real
    Lo que el usuario elige se cumple: en red, no solo en pantalla.

La mayoría de banners falla en el punto 1. Y cuando falla ahí, suele arrastrar los otros dos.

2) Señales claras de un “banner que empuja”

Si reconoces dos o más de estas señales, estás en zona de riesgo:

A) Aceptar destaca y rechazar se esconde

Botón grande y llamativo para aceptar, mientras que rechazar aparece como enlace pequeño o texto con poco contraste.

B) Rechazar solo existe en segunda capa

En la primera capa solo hay “Aceptar” y “Configurar”, y el “Rechazar todo” se esconde dentro.

C) Cerrar (“X”) equivale a aceptar (o dispara cookies igual)

Cerrar no debería activar nada opcional. Si lo hace, hay consentimiento por omisión.

D) Mensajes emocionales o culpabilizadores

“Ayúdanos a mejorar”, “sin cookies no podemos…”: esto empuja, no informa.

E) Rechazar parece “romper” la web

Amenazas de pérdida de funcionalidades que no están justificadas (o son exageradas) para forzar aceptación.

 

3) Prueba rápida en 10 minutos

Aquí es donde pasamos de opinión a evidencia.

Test 1 — “Clics y tiempo” (2 minutos)

Haz dos recorridos y anota:

  • Ruta A (Aceptar): nº de clics + segundos
  • Ruta B (Rechazar): nº de clics + segundos

Regla práctica: si rechazar cuesta claramente más, hay un problema de equivalencia.

Objetivo razonable: Aceptar y Rechazar en 1 clic en primera capa cuando se pide consentimiento.

Test 2 — “Móvil manda” (3 minutos)

Repite lo anterior en móvil (o vista responsive).
Muchos banners “pasan” en desktop y se vuelven tramposos en móvil por espacio y jerarquía visual.

Regla: lo que es fácil en desktop debe ser igual de fácil en móvil.

Test 3 — “¿Rechazar se respeta?” (5 minutos)

Esta es la prueba que cierra discusiones.

  1. Abre la web en modo incógnito.
  2. Sin interactuar con el banner, abre DevTools → Network y recarga.
  3. Guarda evidencia en 3 escenarios:
    • Pre (antes de elegir)
    • Accept (tras aceptar)
    • Reject (tras rechazar)

Puedes exportar HAR o, si no quieres llegar a ese nivel, capturar los dominios que aparecen en Network.

Qué buscas:

  • Si en Reject siguen apareciendo llamadas a terceros que deberían estar bloqueados → el banner “dice” una cosa y “hace” otra.
  • Si en Pre ya hay llamadas a terceros no necesarios antes de elegir → el banner es cosmético.

 

4) Evidencia mínima que debes guardar

No guardes “un pantallazo del banner” y listo. Guarda un mini expediente simple, repetible y ordenado.

Capturas (5)

  1. Primera capa (desktop)
  2. Primera capa (móvil)
  3. Segunda capa (si existe)
  4. Estado “rechazado” visible
  5. Lista de finalidades / proveedores (si aplica)

Pruebas de red

  • HAR (o captura de dominios) Pre / Accept / Reject

Control de cambios

  • Versión/fecha del banner o CMP
  • Qué cambió (1–3 líneas)

Con esto pasas de “yo creo que cumplo” a “yo lo puedo demostrar”.

5) Mini semáforo (diagnóstico rápido)

  • 🟢 Verde: aceptar y rechazar son equivalentes y el tráfico cambia de verdad.
  • 🟠 Ámbar: rechazar existe, pero está escondido o exige demasiados pasos.
  • 🔴 Rojo: se activan terceros antes de decidir o rechazar no bloquea.

6) Qué corregir primero

Orden de remediación que funciona:

  1. Igualar botones (misma prominencia).
  2. Rechazar en primera capa cuando el banner pide consentimiento.
  3. Asegurar efecto real (bloqueo pre-consent y coherencia en Reject).
  4. Reducir ruido: finalidades claras en lenguaje humano.
  5. Versionar y probar cada cambio de GTM/CMP (sin evidencia no hay cierre).

Cierre

Un banner no se “cumple”. Se opera: diseño, configuración, evidencia y control de cambios.

Si tu banner empuja, tarde o temprano se nota. Y cuando se nota, lo único que te sostiene es lo que puedas probar.

Siguiente post (Post 2):
“Rechazar debe ser tan fácil como aceptar: cómo se rompe en producción (GTM/CMP) y cómo dejar evidencia”

Bibliografía y recursos

Leocadio Marrero Trujillo