Rechazar debe ser tan fácil como aceptar- Post 2 — Serie 2 (Cookies/CMP/UX)

Posted on by Leocadio Marrero Trujillo

Rechazar debe ser tan fácil como aceptar

Cómo se rompe en producción (CMP + Tag Manager) y cómo dejar evidencia que te defiende

Hay banners que “a simple vista” parecen correctos: tienen panel de configuración, listan finalidades, enlazan a la política de cookies… y, aun así, el usuario no decide: cede.

La razón casi siempre es la misma: el diseño y la configuración hacen que aceptar sea directo y rechazar sea fricción. Y cuando por fin se rechaza, a veces ni siquiera se respeta.

Este artículo va a lo práctico: cómo se rompe de verdad (normalmente por una mala integración entre CMP y Tag Manager) y cómo construir un mínimo de evidencia para poder decir, sin dudas, que “rechazar” funciona.

1) Cuatro formas comunes en las que “rechazar” falla (y pasan desapercibidas)

1. “Rechazar” cambia la pantalla, pero no cambia lo que carga la web

La CMP te muestra que has rechazado, pero el Tag Manager sigue disparando etiquetas igual.

Señal típica: el banner refleja “rechazado”, pero en el tráfico de red aparecen dominios de terceros (analítica, ads, replay, etc.).
Causa habitual: etiquetas configuradas en “All Pages” sin condición real por consentimiento.

2. Hay un script “duro” en el <head> que se salta el consentimiento

Aunque el Tag Manager esté bien condicionado, un script pegado directamente en la plantilla se carga antes.

Señal típica: antes de tocar el banner, ya hay llamadas a terceros (escenario “Pre”).
Causa habitual: scripts añadidos por plugins, CMS, widgets o desarrollos antiguos.

3. La preferencia no se conserva o no se propaga

Rechazas en una página, pero al navegar a otra el estado no se respeta (o vuelve a pedir consentimiento).

Señal típica: el sitio “olvida” la elección; aparecen tags en páginas distintas.
Causa habitual: implementación incompleta en subdominios, fallos de almacenamiento o inconsistencias en la CMP.

4. Rechazar exige varios pasos… y al final no bloquea nada

Entras a “configurar”, desmarcas, guardas, cierras… y el resultado es inconsistente.

Señal típica: fricción alta, resultado débil.
Causa habitual: mala correspondencia entre categorías de la CMP y etiquetas reales del Tag Manager.

2) La prueba que no falla: Pre / Accept / Reject

Si solo haces una cosa, que sea esta.

Paso 1 — Elige 6 páginas para muestreo

No lo hagas solo en la home. Elige páginas donde más se cuelan terceros:

  1. Home
  2. Landing de campañas (si existe)
  3. Login/registro
  4. Formulario (contacto, lead, empleo)
  5. Checkout/pricing
  6. Página con embeds (mapas, vídeo, chat)

Paso 2 — Ejecuta 3 escenarios por página

En modo incógnito (o borrando cookies antes de cada prueba):

  • Pre: sin tocar el banner, recarga y captura la red
  • Accept: aceptas, recargas y capturas
  • Reject: rechazas, recargas y capturas

Si exportas HAR, perfecto. Si no, basta con capturar la lista de dominios en Network y las cookies que se establecen.

Paso 3 — Qué debería ocurrir

  • En Pre: no deberían aparecer terceros no necesarios (cuando aplique)
  • En Accept: se activan los terceros consentidos
  • En Reject: no aparecen terceros opcionales, o desaparecen respecto a Accept

Esto es lo que convierte el debate en evidencia.

 

3) Por qué se rompe: CMP y Tag Manager “no se están hablando”

Cuando falla, casi siempre es por una de estas dos razones:

  • La CMP sí registra la elección, pero el Tag Manager no condiciona el disparo de etiquetas con esa elección.
  • O el Tag Manager está condicionado, pero hay scripts externos que se cargan igual (hardcoded).

La solución no es “cambiar el texto del banner”. La solución es alinear tres cosas:

A) CMP: categorías y vendors coherentes

  • Categorías claras (necesarias / analítica / marketing / etc.)
  • Vendors/finalidades que realmente existen en el tráfico
  • “Rechazar todo” y “Aceptar todo” accesibles (y coherentes)

B) Tag Manager: reglas de disparo basadas en consentimiento

  • Nada opcional debe dispararse por defecto en “All Pages”
  • Cada tag opcional debe depender de:
    • estado de consentimiento por categoría, o
    • señal de CMP (cookie/variable/dataLayer)

C) Evidencia post-implementación

Cada cambio en CMP o Tag Manager debería cerrarse con:

  • evidencia Pre/Accept/Reject (al menos en 2–3 páginas críticas)
  • capturas de configuración
  • export/versionado del contenedor de etiquetas

4) La tabla que ordena el caos: observado vs declarado

Cuando se discute internamente (“pero eso lo gestiona marketing”, “eso lo pone el proveedor”), esta tabla cambia el tono de la conversación.

Dominio/endpoint observadoAparece en PreAparece en RejectEstá declarado en la CMPCategoría CMPAcción
ejemplo-analytics.comSí/NoSí/NoSí/NoAnalíticaBloquear/Configurar
ejemplo-ads.comSí/NoSí/NoSí/NoMarketingBloquear/Eliminar
cdn-ejemplo.comSí/NoSí/NoSí/NoNecesariasJustificar

Tres conclusiones típicas:

  • Hay dominios observados que no están declarados (riesgo inmediato).
  • Hay vendors declarados que no aparecen (CMP sobredimensionada o mal configurada).
  • Hay “necesarias” que en realidad son opcionales (clasificación incorrecta).

5) Pack mínimo de evidencia para que “rechazar” sea defendible

Guárdalo por trimestre (o por release importante). No requiere herramienta cara, solo disciplina.

  1. Lista de 6 páginas de muestreo
  2. Evidencias Pre/Accept/Reject por página
  3. Capturas de CMP (1ª capa y 2ª capa)
  4. Versionado del Tag Manager (o registro de cambios)
  5. Tabla “observado vs declarado” con acciones y fechas

En auditoría, esto vale más que 10 páginas de argumentación.

6) Checklist rápida (para pegar en tu procedimiento)

  • Rechazar y aceptar están al mismo nivel (mismo esfuerzo)
  • Rechazar se respeta tras recargar
  • Pre no dispara opcionales (cuando aplique)
  • Reject elimina opcionales frente a Accept
  • No hay scripts hardcoded que se salten la CMP
  • El Tag Manager condiciona firing por consentimiento
  • CMP vendors/finalidades coherentes con el tráfico
  • Evidencia guardada (HAR o dominios)
  • Control de cambios (CMP/Tag Manager)
  • Tabla “observado vs declarado” actualizada

Cierre

Un “rechazar” que no funciona es peor que no tener banner: te deja con una falsa sensación de control y sin defensa cuando alguien mira el tráfico real.

El estándar que perseguimos en GRCx3 es sencillo: lo que declaras coincide con lo que ejecutas.

Siguiente post (Post 3)

Vendors fantasma y terceros silenciosos

Cómo detectar lo que tu CMP declara, lo que tu web ejecuta… y lo que nadie ve (CDN, fonts, embeds, conversion APIs)

Bibliografía y recursos (selección breve)

Leocadio Marrero Trujillo