Qué pasa cuando alguien retira su consentimiento de cookies

Todos los artículos

La recogida se detiene para las categorías que revocó, y las cookies que ya están en su dispositivo en general siguen donde estaban. Después deberían pasar tres cosas. El registro suma un evento de retirada en lugar de perder la concesión original. Sale una señal de denegación hacia todas las herramientas que la aceptan. Y cada herramienta reinicia la identidad antes de que se desactive la captura.

La respuesta que da todo el mundo habla de archivos de cookies

Si buscas esta pregunta, te responden otra más estrecha: si la retirada borra las cookies que ya están en el dispositivo. La respuesta es que no, y el razonamiento es correcto. Un script solo puede tocar las cookies de su propio dominio, así que nada de tu web puede alcanzar una cookie que otra empresa puso en el suyo. Es una regla de seguridad del navegador, no un fallo de tu herramienta de consentimiento. Las cookies propias como _ga son la excepción: están en tu propio dominio, así que tu web puede borrarlas. Lo que hace una plataforma de consentimiento es bloquear los scripts que leen y escriben esas cookies.

Esa respuesta es correcta, y es la parte más pequeña de la transición. Borrar un archivo después protege muy poco: el momento que importa es cuando los datos se mueven, es decir, cuando se instala una cookie y cuando se lee. El bloqueo detiene las dos cosas. Borrar archivos, no.

Hay una excepción real. Con ads_data_redaction activado y ad_storage denegado, Google oculta los identificadores de clic en los pings que sigue enviando, como documenta la guía de Google sobre 'consent mode'. Es la única palanca de todo el sistema que elimina algo de lo que se envía, y es un ajuste de Google, no algo que haga tu banner.

Lo que casi nadie deja por escrito es qué debe hacer tu sistema de medición en ese momento. Ahí es donde falla la retirada, y falla sin hacer ruido: el banner se cierra y todo parece en orden.

Qué debería pasar, por orden

La retirada es una secuencia, y el orden importa más que cualquier llamada concreta.

1. Registra la retirada como un evento nuevo, no como una edición

   Una retirada no es una corrección de la concesión original. Es un segundo hecho: este visitante dio su consentimiento en un momento y lo revocó en otro, y las dos cosas son ciertas. Guárdala como una fila nueva que apunte a la concesión que sustituye, en una tabla que no se pueda actualizar ni borrar. El artículo 7.3 del RGPD dice que la retirada no afecta a la licitud del tratamiento anterior, y la concesión original es tu prueba de ello. Si la sobrescribes, habrás destruido la única prueba de que la recogida anterior era lícita. Velo registra una retirada como un evento nuevo que hace referencia al anterior, y lo conserva indefinidamente incluso cuando los registros de concesión normales caducan.

2. Envía una señal de denegación, no te quedes en silencio

   El instinto es hacer que todo deje de dispararse. Con Consent Mode, eso es un error. La etiqueta debe quedarse donde está y recibir una actualización que ponga analytics_storage y las tres señales publicitarias en denied. Entonces envía un ping sin cookies que no lleva identificadores, y ese ping mantiene vivos el modelado y los informes básicos. Quitar la etiqueta del todo no envía nada, y nada no es lo mismo que un rechazo registrado. Lo uno es un visitante que dijo que no; lo otro, un visitante que no existe.

3. Avisa a cada herramienta en el idioma que entiende

   No existe una API de consentimiento única. Las etiquetas de Google leen una llamada gtag('consent', 'update', …); las de Microsoft, un push a uetq; las de Meta, una llamada fbq. Y los activadores de Google Tag Manager no ven un CustomEvent del navegador, así que una retirada que solo emite uno deja sin disparar todos los activadores de eventos personalizados. Envía también un evento con nombre a la capa de datos. Nuestro propio SDK hace pasar por una sola función que emite las cuatro todas las vías que cambian el consentimiento: un clic en el banner, una decisión guardada que se vuelve a aplicar, una señal de Global Privacy Control que fuerza la desactivación de categorías. Así, una retirada no puede salir por un camino distinto al de una concesión.

4. Reinicia la identidad antes de dejar de capturar, nunca después

   Casi todas las librerías de analítica ofrecen dos llamadas: una borra quién es el visitante y otra desactiva la captura. Casi todo el mundo las ordena así mentalmente, primero dejar de capturar y luego olvidarlo, y casi todo el mundo está escribiendo un bug. En muchas librerías, el indicador de consentimiento y la identidad comparten el mismo almacenamiento, así que el reinicio borra la exclusión que acabas de fijar. Primero el reinicio, el interruptor de captura al final.

5. Vuelve a aplicar el bloqueo y recarga la página

   El bloqueo controla lo que todavía no se ha ejecutado. Un script que ya se cargó sigue en memoria, con sus propios temporizadores, y puede volver a escribir su cookie en la siguiente interacción diga lo que diga ahora tu banner. Volver a aplicar el bloqueo detiene lo siguiente; recargar es la única garantía limpia de que no sigue ejecutándose nada del estado de consentimiento anterior. Además, vuelve a aplicar la decisión guardada desde el principio, que es el camino que sigue un visitante que regresa, así que ese caso queda probado sin coste.

¿Qué paso falla más a menudo?

Encontramos el paso cuatro en nuestro propio sistema, no en el de un cliente. Nuestro banner deniega la analítica; la rama de denegación llamaba primero a la exclusión y después al reinicio de la identidad. Leído así, parece correcto: dejar de capturar y luego olvidarlo.

En los datos aparecían dos personas: una identificada y otra anónima, que compartían un mismo identificador de dispositivo con minutos de diferencia. La causa estaba en la librería, no en el banner. En posthog-js 1.424.1, la llamada de reinicio también reinicia el estado de consentimiento guardado, así que ejecutarla después de la exclusión anulaba la exclusión, y la captura se reanudaba con un identificador anónimo nuevo y una sesión nueva. Cada visitante que retiraba su consentimiento se contaba dos veces sin que nadie se diera cuenta.

Invertir las dos llamadas lo arregló, y lo comprobamos en un navegador limpio, no en una revisión de código. Aceptas y aparece un identificador. Rechazas y el indicador de exclusión vale true, sin que salga ninguna petición al forzar un evento. Vuelves a aceptar más tarde y regresa el mismo identificador, no un tercero.

¿Qué debería poder ver el visitante?

El RGPD dice que retirar el consentimiento debe ser tan fácil como darlo. En la práctica, eso significa un control que vuelve a abrir el panel de preferencias desde cualquier página, no un enlace enterrado en un documento de políticas. La decisión debe aplicarse en la misma página en la que está el visitante.

También implica un comprobante que pueda mostrar más adelante, el mismo mecanismo que responde a cómo demuestras que un visitante dio su consentimiento. Una retirada es un registro de consentimiento como cualquier otro.

Lo último que hay que decidir es cuándo volver a preguntar. Una retirada no es un permiso para volver a mostrar el banner en la siguiente página vista; tratarla así es como un banner se convierte en una molestia. El momento tiene su propia respuesta: cuánto dura el consentimiento de cookies y cuándo tiene que volver a preguntar el banner.

¿Cómo pruebas una retirada?

Casi todos los banners se han probado a la entrada. Casi ninguno se ha probado a la salida, y por eso los bugs de retirada duran meses mientras el camino de aceptación sigue impecable. Acepta, navega por dos páginas, retira el consentimiento y fíjate en tres cosas: qué sale del navegador, si la exclusión sigue fijada un minuto después y cuántas personas cree tu analítica que era ese único navegador.

Velo hace pasar cada cambio de consentimiento, sea concesión o retirada, por un único camino que registra el evento, actualiza Consent Mode, envía el evento de la capa de datos con el que se activa tu contenedor y llama a la API de consentimiento de cada proveedor. Eso elimina la divergencia entre las dos direcciones. Lo que no elimina es la prueba: el orden en que tus propias herramientas quieren sus llamadas sigue siendo cosa tuya.