Por qué Optimizely Web Experimentation requiere consentimiento

Una inicialización predeterminada de Optimizely hace varias cosas en el primer renderizado de la página. Establece una cookie de primera parte bajo optimizelyEndUserId que contiene el identificador persistente del visitante, evalúa al visitante contra los experimentos activos, escribe las asignaciones de variantes en una segunda cookie bajo los marcadores del espacio de nombres optimizelyOptOut, dispara un evento de decisión a logx.optimizely.com y aplica los cambios de variante a la página renderizada. Cuando el operador ha conectado una integración de análisis — Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap o la Optimizely Data Platform — el SDK también dispara eventos de exposición de variantes en la capa de análisis, que luego vincula la variante con el perfil de análisis más amplio del visitante.

Cada una de esas actividades activa una puerta de consentimiento separada. Persistir el identificador del visitante es una operación de almacenamiento y acceso bajo el Article 5(3) de la Directiva ePrivacy que requiere consentimiento previo, libremente otorgado, específico, informado e inequívoco en el EEA, el Reino Unido y cualquier jurisdicción que haya adoptado el mismo estándar. Vincular las asignaciones de variantes experimentales a ese identificador entre sesiones es un procesamiento de datos personales bajo el GDPR porque la combinación de identificador, dirección IP y exposición de variante es suficiente para identificar a un individuo y caracterizar su interacción con el programa de experimentación. La propagación entre herramientas de los datos de variantes — Optimizely exponiendo la asignación de variante a Google Analytics, por ejemplo — añade la puerta de análisis a la cadena. La guía del EDPB de 2023 ha sido explícita en que la experimentación que involucra identificación persistente está sujeta a las mismas reglas de consentimiento que el análisis; el CNIL ha sido el regulador más vocal en este punto, pero no es el único.

Qué escribe Optimizely antes del consentimiento — y qué debe suprimirse

El fragmento estándar de Optimizely instala el JavaScript SDK directamente en el encabezado de la página y se inicializa inmediatamente al cargar. Ese es el inicio rápido documentado y la fuente del fallo de cumplimiento más común: el SDK se ejecuta antes de que se haya renderizado el banner de cookies, la cookie optimizelyEndUserId se escribe en cuestión de milisegundos, se realiza la asignación de variante y el evento de decisión se dispara independientemente de lo que el visitante decida más tarde. Todos los reguladores europeos que se han pronunciado sobre este patrón han fallado de la misma manera: las cookies establecidas antes del consentimiento son ilegales, la asignación de variante capturada antes del consentimiento es un procesamiento ilegal y el editor lleva la responsabilidad.

Una integración conforme debe por tanto impedir que Optimizely escriba el identificador persistente y dispare eventos de decisión hasta que se haya concedido la categoría de consentimiento pertinente. Optimizely admite dos patrones para esto. El primero es el atributo de consentimiento dedicado — pase OPTIMIZELY_OPT_OUT=true como una cadena de consulta o establezca la cookie optimizely.opt_out antes de la inicialización del SDK — lo que pone el SDK en modo de exclusión voluntaria donde no se escribe ningún identificador y no se disparan eventos. El segundo es el modo solo anónimo admitido en la configuración del SDK, donde el SDK funciona en un modo sin sesión que asigna variantes basándose únicamente en la identificación local de sesión, sin identificación persistente entre visitas. El modo anónimo permite que el programa de experimentación funcione bajo una base de interés legítimo para la decisión de renderizado, aplazando la identificación persistente hasta que se conceda el consentimiento.

Las cookies y el almacenamiento que escribe Optimizely

El Optimizely Web Experimentation SDK escribe los siguientes identificadores en la inicialización, todos los cuales son no esenciales y requieren consentimiento: optimizelyEndUserId con un vencimiento de varios años que contiene el identificador persistente del visitante, marcadores optimizelyOptOut que rastrean el estado de exclusión voluntaria, optimizelyDomainTestCookie para la experimentación entre subdominios, y cookies de espacio de nombres adicionales cuando el operador ha habilitado la identificación entre dominios. Por tanto, retirar el consentimiento debe tanto vencer las cookies como poner el SDK en modo de exclusión voluntaria mediante optimizely.push({ type: 'user', attributes: { opt_out: true } }) para detener la recopilación adicional de eventos.

Mapear Optimizely a marcos de consentimiento

Optimizely no implementa de forma nativa IAB TCF ni la IAB Global Privacy Platform — es una plataforma de experimentación de primera parte, no un proveedor de tecnología publicitaria — pero sí expone una API de exclusión voluntaria nativa, admite una integración de Consent Mode documentada a través de la Optimizely Data Platform y respeta el CMP del editor a través del atributo OPTIMIZELY_OPT_OUT. El patrón que supera la revisión de un regulador trata cada capacidad de Optimizely como una puerta separada vinculada a una señal CMP específica.

• La experimentación anónima puede ejecutarse bajo una base de interés legítimo con identificación local de sesión, lo que es apropiado para decisiones de renderizado que no requieren identificación persistente entre visitas y que no se propagan a análisis posteriores. Este modo se vincula a la categoría estrictamente necesaria o funcional.
• La experimentación persistente con un identificador estable se vincula al propósito analítico. En términos de TCF, esto se asigna al propósito 8 combinado con el propósito 1; para Consent Mode, esto se asigna a analytics_storage.
• La integración entre herramientas — eventos de exposición de variantes propagados a Google Analytics, Amplitude o la Optimizely Data Platform — hereda la puerta de análisis de la herramienta receptora y no debe dispararse si la puerta de esa herramienta no ha sido concedida.
• La personalización y la orientación basada en audiencias construidas sobre la experimentación activan la puerta de marketing porque cruzan de la medición experimental a la orientación a nivel de usuario.

El patrón de integración que funciona

El despliegue de referencia tiene cuatro partes: un CMP que expone un evento de cambio de consentimiento en tiempo real, un arranque diferido que inicializa el SDK de Optimizely con la exclusión voluntaria habilitada o el modo anónimo activo, un oyente de consentimiento que cambia el SDK fuera de la exclusión voluntaria e inicia la identificación persistente cuando se abre la puerta de análisis, y una ruta de retirada que devuelve el SDK al modo de exclusión voluntaria, vence las cookies optimizely mediante document.cookie y propaga la retirada a cualquier integración de análisis posterior.

Implementación web con el arranque diferido

En la web, el patrón más limpio es cargar el fragmento de Optimizely con window.optimizelyOptOut = true establecido antes de la inicialización del SDK. Suscríbase al evento de cambio de consentimiento del CMP. Cuando la categoría de análisis pase a true, llame a window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) y deje que el SDK se inicialice normalmente. Cuando la puerta se retire, vuelva a empujar el atributo de exclusión voluntaria a true, venza la cookie optimizelyEndUserId y propague el cambio a cualquier plataforma de análisis integrada a través de sus respectivas API de consentimiento.

Experimentación en el lado del servidor mediante el Decision Service

Optimizely también admite la experimentación en el lado del servidor mediante la Decision Service API. Las decisiones del lado del servidor no están exentas del consentimiento — la base jurídica sigue los datos — pero la ejecución en el lado del servidor da al editor control total sobre qué identificadores se propagan. El patrón que funciona es pasar un identificador de sesión efímero al Decision Service cuando la puerta de análisis está cerrada, y cambiar al identificador persistente solo cuando la puerta está abierta. Las asignaciones de variantes devueltas por el Decision Service aún se pueden aplicar a la página renderizada; lo que cambia es si están vinculadas a un registro de visitante estable.

Validar la integración y el rastro de auditoría

El paso de validación es lo que comprueban los reguladores y lo que los editores omiten con más frecuencia en las herramientas de experimentación. Un despliegue de Optimizely correctamente integrado debe pasar cuatro pruebas en secuencia. En primer lugar, una sesión de navegador limpia con el banner mostrado pero sin ninguna elección realizada debe producir cero solicitudes a logx.optimizely.com más allá de la descarga del archivo SDK y cero cookies optimizely en document.cookie. En segundo lugar, rechazar el análisis debe mantener ese estado — sin identificador persistente, sin evento de decisión, sin asignación de variante vinculada a un registro estable. En tercer lugar, aceptar el análisis debe producir la cookie optimizelyEndUserId esperada y el tráfico de eventos de decisión, con la asignación de variante correctamente aplicada. En cuarto lugar, retirar el consentimiento debe detener inmediatamente los eventos de decisión adicionales, vencer las cookies y propagar la exclusión voluntaria a cualquier integración de análisis posterior.

La expectativa de rastro de auditoría bajo las directrices de banner de cookies del EDPB de 2023 y las renovadas prioridades del grupo de trabajo de 2026 es que el editor pueda demostrar, para cualquier exposición experimental específica en el proyecto de Optimizely, que el visitante había otorgado un consentimiento válido en el momento de la exposición. El patrón estándar es establecer la versión del consentimiento y la marca de tiempo como un atributo personalizado en el perfil de visitante de Optimizely a través de la attribute API del SDK para que cualquier exposición individual sea rastreable hasta una entrada específica del registro de consentimiento. Un despliegue correctamente delimitado, combinado con el manejo del modo anónimo para las decisiones de renderizado previas al consentimiento y una ruta de retirada que se propaga aguas abajo, es lo que convierte a Optimizely de una responsabilidad oculta a nivel de capa de experimentación en una parte defendible del producto y la pila de crecimiento de un editor.