Qué hacer si recibes una queja sobre tu banner de cookies

Todos los artículos

Mide antes de responder. Graba lo que hace tu web en cada recorrido de consentimiento, con un perfil limpio, y luego contrasta la queja punto por punto con esa prueba: acepta lo que se sostiene, rebate lo que no con la petición o la cookie que lo desmiente, y haz una contrapropuesta cuando la solución que piden sea errónea. La causa no suele estar en la lista.

La consola no es una prueba. Lo que se envía, sí.

Cuando llega una queja, el instinto es tirar de una lista de verificación de cumplimiento. Es la referencia correcta para saber lo que debe hacer un banner, y los reguladores y los grandes proveedores de consentimiento lo explican bien. Pero responden a una pregunta distinta de la que tienes delante: no cómo es un banner que cumple, sino qué le hizo tu web a la persona que se quejó.

Así que lo primero es una grabación, no una revisión de ajustes. Cuatro recorridos con un perfil limpio: primera carga sin hacer clic en nada, aceptar, rechazar y una visita posterior con la elección guardada. Apunta las cookies y los dominios de proveedores que produce cada uno. Diez minutos, y lo único de todo esto que tendrá peso después.

El contenedor en el que trabajamos tenía una auditoría que indicaba que todas las etiquetas estaban configuradas para el consentimiento, sin ninguna pendiente. Ese mismo día, un perfil limpio con el banner todavía en pantalla fijó siete cookies y llamó a seis dominios de proveedores. Ninguna de las dos afirmaciones era falsa. Respondían a preguntas distintas.

¿Suele ser acertada una queja sobre un banner de cookies?

Una queja llega como una lista numerada y es tentador recorrerla como si fuera un veredicto. Léela como un conjunto de afirmaciones, cada una verdadera o falsa, y cada una comprobable en la grabación que acabas de hacer.

En el conjunto de webs del que sale este artículo, la lista tenía ocho puntos numerados. Tres eran incorrectos: la afirmación de que ninguna etiqueta fijaba un estado denegado por defecto era falsa, porque los valores por defecto ya eran correctos y lo eran desde hacía tiempo; tres de las etiquetas señaladas como no bloqueadas en realidad ya lo estaban; y un punto señalaba directamente la etiqueta equivocada. Cuatro eran correctos y se aceptaron sin discusión. Uno acertaba con el problema y se equivocaba con la solución, y necesitaba una contrapropuesta en lugar de un sí o un no.

El reparto importa más que cada punto por separado. Aceptar algo falso hace tanto daño como negar algo cierto: te compromete a un cambio que no arregla nada y debilita todas las demás afirmaciones de la respuesta. Los dos casos piden el mismo tratamiento: pruebas adjuntas a la respuesta.

Revisar así una lista de hallazgos tiene su propio procedimiento, y es el mismo tanto si la lista llega con una queja como con una auditoría: cómo saber si una etiqueta señalada fija cookies de verdad antes del consentimiento.

La causa no suele estar en la lista

Quien se queja informa de lo que se ve desde fuera: cookies presentes, proveedores llamados, un banner que no frenó ni lo uno ni lo otro. Lo que las cargó es lo que te toca averiguar a ti.

Casi todo se explica por dos lugares, y ninguno aparece en una auditoría del gestor de etiquetas. El primero es una etiqueta de proveedor que carga a otros proveedores. Aquí, la etiqueta de una plataforma de marketing cargaba dos píxeles publicitarios propios, así que bloquear esa única etiqueta detuvo los tres, lo que daba la vuelta a una conclusión anterior según la cual el contenedor por sí solo no podía resolver la queja. Compruébalo primero: explicamos la versión que más se nota en por qué el píxel de Facebook se sigue cargando aunque tus etiquetas estén bloqueadas.

El segundo es el head de tu propia web. Los scripts pegados en la plantilla cargan antes de que el contenedor pueda opinar, y ningún ajuste de consentimiento llega hasta ellos, por cómo está construido y no por un error de configuración. Aquí quedaban tres cuando terminó el trabajo en el contenedor, y hizo falta un desarrollador, no acceso al gestor de etiquetas.

¿Cómo se redacta una respuesta defendible a una queja?

El orden importa: cada paso decide lo que puede afirmar el siguiente.

1. Graba los cuatro recorridos de consentimiento antes de escribir nada

   Ventana privada, paneles de red y de almacenamiento abiertos, en una página que no hayas visitado. Captura la primera carga sin hacer clic en nada, luego aceptar, luego rechazar y luego una visita posterior con la elección guardada. Guarda las cookies y los dominios de proveedores de cada una.

2. Contrasta la queja punto por punto con esa grabación

   Marca cada punto numerado como correcto, incorrecto o parcialmente correcto, con la petición o la cookie concreta que lo decide. No respondas desde la consola del gestor de etiquetas: muestra lo que está configurado, y una queja trata de lo que pasó.

3. Busca la causa que no está en la lista

   Los puntos que te han enviado describen lo que se veía desde fuera. Averigua por separado qué está cargando esas cookies: si una etiqueta de proveedor está cargando otras y qué hay escrito directamente en el head de tu propia web.

4. Reparte los arreglos según quién se encarga

   Clasifica cada problema confirmado en tres grupos: se arregla en el contenedor, solo en el código de la web o solo en el portal de un proveedor. Tienen responsables y plazos distintos, y una respuesta que promete arreglar en el contenedor un script del head de la web no aguantará la siguiente réplica.

5. Vuelve a comprobar los cuatro recorridos, no la vista de auditoría

   Repite el paso uno con la versión publicada y compara las grabaciones. Confirma que no te está engañando un archivo de contenedor en caché. Se sirve con una caché corta, y nuestra primera comprobación aquí estaba leyendo la versión anterior sin ninguna señal de ello. Mira la versión del archivo que te están sirviendo antes de dar por bueno un fallo.

6. Responde con la medición, no con promesas

   Explica qué mediste, qué encontraste, qué se corrigió y qué queda pendiente, con fecha y responsable. Los puntos que discutes van con la prueba adjunta, no con una negativa sin más.

Dos cosas que conviene tener antes de que llegue una

Una grabación de referencia, hecha cuando todo va bien, convierte todo lo anterior en una comparación en lugar de una investigación: probar un banner de cookies antes de publicarlo es el mismo procedimiento en un momento más tranquilo. Y el registro del consentimiento. Un banner demuestra lo que se ofreció, no lo que eligió nadie, y el artículo 7.1 del RGPD te pide que puedas demostrar que un visitante dio su consentimiento. Solo el registro responde a eso.

Nuestra posición en esto

Desarrollamos una plataforma de consentimiento, así que tenlo en cuenta al leer esto. Tomamos lo que la página envía en realidad como la fuente de verdad porque es también donde se nota el daño en la medición. Las decisiones de consentimiento ocultan a la analítica parte de tus sesiones, y cuánta depende de tu región, tu audiencia y el diseño de tu banner. La tasa de consentimiento de tu CMP es la forma más rápida de calcularlo, y comparar las sesiones de GA4 con los registros de peticiones de tu servidor o tu CDN es la comprobación independiente. Una configuración correcta no devuelve a tus informes a los visitantes que rechazaron. Hace que lo que sí registras coincida con lo que eligieron los visitantes.

La versión incómoda es que un banner puede estar bien elegido, bien instalado y aun así tener fugas, porque la mayor parte de lo que se escapa nunca estuvo al alcance de la herramienta de consentimiento. Ese hueco existe en todos los rangos de precio, incluido el nuestro.