Dos tareas distintas

Cuando un visitante toma una decisión de consentimiento, tienen que ocurrir dos cosas separadas. Primero, el navegador debe recordar la elección para que el banner no reaparezca en cada página y las etiquetas sepan qué pueden hacer. Segundo, puede que necesites demostrar más tarde que la elección se hizo, qué se le mostró al visitante y cuándo. Estas tareas suelen resolverse con mecanismos de almacenamiento distintos, y confundirlas causa problemas reales: banners que siguen reapareciendo, elecciones que desaparecen en algunos navegadores o ningún registro que mostrar cuando alguien lo pide.

Esta comparación examina las tres opciones habituales — cookies first-party, almacenamiento del navegador como localStorage y registros de consentimiento del lado del servidor — y dónde encaja cada una.

Opción 1: cookies first-party

Las cookies son el hogar tradicional del estado de consentimiento. Los CMP de TCF suelen guardar la cadena de consentimiento en una cookie first-party, y muchos almacenan en una también sus propios datos de preferencias.

Ventajas

• Legible por el servidor. La cookie se envía con cada solicitud, así que el código del servidor, la lógica de borde y el etiquetado del lado del servidor pueden leer la elección sin esperar a JavaScript.
• Compartible entre subdominios. Una cookie establecida en tu dominio registrable puede cubrir los subdominios www, blog y shop.
• Ampliamente esperada. Muchas integraciones de ad tech buscan el consentimiento en las cookies.

Desventajas

• Límites de tamaño. Los navegadores limitan el tamaño de una cookie a unos 4 KB, y una cadena TCF con muchos proveedores más otros valores puede acercarse a ese límite.
• Sobrecarga en las solicitudes. Cada solicitud a tu dominio lleva la cookie, incluidas las de imágenes y scripts.
• Límites de duración en algunos navegadores. La Intelligent Tracking Prevention de Safari limita a un máximo de siete días la duración de las cookies creadas mediante JavaScript. Las cookies que establece tu propio servidor en una respuesta HTTP suelen recibir un trato más generoso, aunque hay excepciones.

Opción 2: localStorage y otros almacenamientos del navegador

Algunos CMP guardan preferencias detalladas en localStorage, a veces junto a una cookie más pequeña.

Ventajas

• Más espacio. Varios megabytes por origen, suficiente para elecciones detalladas a nivel de proveedor.
• Sin sobrecarga en las solicitudes. No se envía nada al servidor automáticamente.

Desventajas

• Invisible para el servidor. El código del servidor y la lógica de borde no pueden leerlo, así que cualquier decisión del lado del servidor tiene que esperar al navegador.
• Ligado a un único origen. El almacenamiento en www.example.com no está disponible en shop.example.com, por lo que un visitante puede volver a ver el banner en cada subdominio.
• Sujeto a eliminación. Safari puede borrar el almacenamiento escribible por scripts, incluido localStorage, de los sitios con los que el usuario no ha interactuado durante siete días de uso del navegador, y los modos de navegación privada suelen borrarlo al terminar la sesión.

Opción 3: registros de consentimiento del lado del servidor

Un registro del lado del servidor es una entrada que guardas tú o tu proveedor de CMP cada vez que se toma una decisión. Suele contener un identificador seudónimo, la marca de tiempo, las elecciones, la versión del banner o de la política mostrada y un contexto como la región.

Ventajas

• Prueba duradera. Sobrevive al borrado de cookies y a las restricciones de los navegadores, lo que lo convierte en la herramienta adecuada para demostrar que se obtuvo el consentimiento.
• Auditable. Puedes elaborar informes sobre las elecciones a lo largo del tiempo y responder preguntas sobre eventos concretos.
• Potencial multidispositivo. Para lectores con sesión iniciada, un registro del servidor puede sincronizar las elecciones entre dispositivos, si se lo explicas.

Desventajas

• No sustituye al estado local. Las etiquetas del navegador siguen necesitando una señal local rápida; consultar a un servidor en cada visualización de página para buscar el consentimiento añade latencia.
• Es en sí mismo un dato personal. Los registros necesitan un periodo de conservación, controles de acceso y un lugar en tu aviso de privacidad.
• Dependencia de un identificador. Los visitantes anónimos solo pueden asociarse a un registro mediante un identificador guardado en su dispositivo, lo que te devuelve al almacenamiento local.

Resumen comparativo

• Mejor para recordar la elección en la web: cookies first-party, idealmente establecidas por tu servidor con una duración estable.
• Mejor para datos de preferencias detallados en el navegador: localStorage, junto con una cookie que el servidor pueda leer.
• Mejor para demostrar la elección: registros del lado del servidor.
• Peor opción única: depender solo de localStorage, lo que deja al servidor a ciegas y hace frágil la elección en algunos navegadores.

Un enfoque combinado práctico

1. Guarda la señal local de referencia — por ejemplo la cadena TCF y un registro compacto de preferencias — en una cookie first-party limitada a tu dominio registrable.
2. Usa localStorage solo para datos complementarios que no necesiten llegar al servidor.
3. Escribe un registro del lado del servidor por cada elección, incluida la versión del banner y de la política mostradas.
4. Si una elección guardada desaparece, vuelve a mostrar el banner en lugar de suponer una respuesta anterior.
5. Define un periodo de nueva solicitud para las elecciones guardadas y regístralo en tu política.

Guardar la propia elección de consentimiento del visitante suele considerarse necesario para prestar el servicio que el visitante pidió — recordar su decisión — pero consulta las orientaciones aplicables en tus principales mercados.

Conclusiones clave

• Recordar una elección y demostrar una elección son tareas distintas que necesitan almacenamientos distintos.
• Las cookies son legibles por el servidor y compartibles entre subdominios, pero están limitadas en tamaño y, en Safari, en duración cuando las establece un script.
• localStorage ofrece espacio, pero es invisible para el servidor y los navegadores pueden borrarlo.
• Los registros del lado del servidor son la capa de prueba, no un sustituto de la señal local.
• Combina una cookie first-party establecida por el servidor, almacenamiento opcional del navegador y registros del servidor.