Guía de integración do consentimento de cookies de Optimizely Web Experimentation: probas A/B baixo o GDPR en 2026

Optimizely ocupa unha posición estraña en relación coa conversa sobre o consentimento. Unha persoa razoable que examine ferramentas de experimentación podería asumir que se trata dunha categoría de baixo risco — a proba trata sobre que cor de botón xera máis clics, non sobre quen é o visitante. A realidade, baixo o marco que o GDPR estableceu e que o EDPB vén reforzando activamente desde 2023, é que a experimentación implica exactamente as mesmas categorías de procesamento que a análise ou o marketing cada vez que a plataforma escribe un identificador persistente e vincula variantes experimentais a el. O SDK de Optimizely Web Experimentation fai precisamente iso: asigna un visitante a unha variante mediante o hash dun identificador persistente, escribe a asignación nunha cookie de primeira parte para que o visitante vexa a mesma variante entre sesións, e emite eventos de exposición e conversión vinculados a ese identificador. Cada un deses pasos activa unha porta de consentimento. A boa noticia é que Optimizely inclúe unha das integracións de consentimento máis reflexivas da categoría de experimentación, incluído un atributo de consentimento dedicado e a capacidade de operar en modo só anónimo. O traballo está en realmente utilizalo.

Por que Optimizely Web Experimentation require consentimento

Unha inicialización predeterminada de Optimizely fai varias cousas no primeiro renderizado da páxina. Establece unha cookie de primeira parte baixo optimizelyEndUserId que contén o identificador persistente do visitante, avalía o visitante fronte aos experimentos activos, escribe as asignacións de variantes nunha segunda cookie baixo os marcadores do espazo de nomes optimizelyOptOut, dispara un evento de decisión a logx.optimizely.com e aplica os cambios de variante á páxina renderizada. Cando o operador conectou unha integración de análise — Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap ou a Optimizely Data Platform — o SDK tamén dispara eventos de exposición de variantes na capa de análise, que logo vincula a variante co perfil de análise máis amplo do visitante.

Cada unha desas actividades activa unha porta de consentimento separada. Persistir o identificador do visitante é unha operación de almacenamento e acceso baixo o Article 5(3) da Directiva ePrivacy que require consentimento previo, libremente outorgado, específico, informado e inequívoco na EEA, o Reino Unido e calquera xurisdición que adoptara o mesmo estándar. Vincular as asignacións de variantes experimentais a ese identificador entre sesións é un procesamento de datos persoais baixo o GDPR porque a combinación de identificador, enderezo IP e exposición de variante é suficiente para identificar un individuo e caracterizar a súa interacción co programa de experimentación. A propagación entre ferramentas dos datos de variante — Optimizely expondo a asignación de variante a Google Analytics, por exemplo — engade a porta de análise á cadea. A guía do EDPB de 2023 foi explícita en que a experimentación que implica identificación persistente está suxeita ás mesmas regras de consentimento que a análise; o CNIL foi o regulador máis vocal neste punto, pero non é o único.

Que escribe Optimizely antes do consentimento — e o que debe suprimirse

O fragmento estándar de Optimizely instala o SDK de JavaScript directamente no encabezado da páxina e inicialízase inmediatamente ao cargar. Ese é o inicio rápido documentado e a fonte do fallo de cumprimento máis común: o SDK execútase antes de que se renderizara o banner de cookies, a cookie optimizelyEndUserId escríbese en cuestión de milisegundos, realízase a asignación de variante e o evento de decisión dispárase independentemente do que o visitante decida máis tarde. Cada regulador europeo que se pronunciou sobre este patrón pronunciouse da mesma forma: as cookies establecidas antes do consentimento son ilegais, a asignación de variante capturada antes do consentimento é un procesamento ilegal e o editor leva a responsabilidade.

Unha integración conforme debe polo tanto impedir que Optimizely escriba o identificador persistente e dispare eventos de decisión ata que se concedeu a categoría de consentimento pertinente. Optimizely admite dous patróns para iso. O primeiro é o atributo de consentimento dedicado — pase OPTIMIZELY_OPT_OUT=true como cadea de consulta ou estableza a cookie optimizely.opt_out antes da inicialización do SDK — o que pon o SDK en modo de exclusión voluntaria onde non se escribe ningún identificador e non se disparan eventos. O segundo é o modo só anónimo admitido na configuración do SDK, onde o SDK funciona nun modo sen sesión que asigna variantes baseándose unicamente na identificación local de sesión, sen identificación persistente entre visitas. O modo anónimo permite que o programa de experimentación funcione baixo unha base de interese lexítimo para a decisión de renderizado, diferindo a identificación persistente ata que se conceda o consentimento.

As cookies e o almacenamento que escribe Optimizely

O SDK de Optimizely Web Experimentation escribe os seguintes identificadores na inicialización, todos os cales son non esenciais e requiren consentimento: optimizelyEndUserId cunha vencemento de varios anos que contén o identificador persistente do visitante, marcadores optimizelyOptOut que rastrexan o estado de exclusión voluntaria, optimizelyDomainTestCookie para a experimentación entre subdominios e cookies de espazo de nomes adicionais cando o operador habilitou a identificación entre dominios. Por tanto, retirar o consentimento debe tanto vencer as cookies como poñer o SDK en modo de exclusión voluntaria mediante optimizely.push({ type: 'user', attributes: { opt_out: true } }) para deter a recollida adicional de eventos.

Mapear Optimizely en marcos de consentimento

Optimizely non implementa de forma nativa IAB TCF nin a IAB Global Privacy Platform — é unha plataforma de experimentación de primeira parte, non un provedor de tecnoloxía publicitaria — pero si expón unha API de exclusión voluntaria nativa, admite unha integración de Consent Mode documentada a través da Optimizely Data Platform e respecta o CMP do editor a través do atributo OPTIMIZELY_OPT_OUT. O patrón que supera a revisión dun regulador trata cada capacidade de Optimizely como unha porta separada vinculada a un sinal CMP específico.

O patrón de integración que funciona

O despregamento de referencia ten catro partes: un CMP que expón un evento de cambio de consentimento en tempo real, un arranque diferido que inicializa o SDK de Optimizely con exclusión voluntaria habilitada ou modo anónimo activo, un escoitador de consentimento que cambia o SDK fóra da exclusión voluntaria e inicia a identificación persistente cando se abre a porta de análise, e un camiño de retirada que devolve o SDK ao modo de exclusión voluntaria, vence as cookies optimizely mediante document.cookie e propaga a retirada a calquera integración de análise posterior.

Implementación web co arranque diferido

Na web o patrón máis limpo é cargar o fragmento de Optimizely con window.optimizelyOptOut = true establecido antes da inicialización do SDK. Subscríbase ao evento de cambio de consentimento do CMP. Cando a categoría de análise pase a true, chame a window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) e deixe que o SDK se inicialice normalmente. Cando a porta se retire, volva empurrar o atributo de exclusión voluntaria a true, venza a cookie optimizelyEndUserId e propague o cambio a calquera plataforma de análise integrada a través das súas respectivas API de consentimento.

Experimentación do lado do servidor mediante o Decision Service

Optimizely tamén admite a experimentación do lado do servidor mediante a Decision Service API. As decisións do lado do servidor non están exentas do consentimento — a base xurídica segue os datos — pero a execución do lado do servidor dá ao editor control total sobre que identificadores se propagan. O patrón que funciona é pasar un identificador de sesión efémero ao Decision Service cando a porta de análise está pechada, e cambiar ao identificador persistente só cando a porta está aberta. As asignacións de variantes devoltas polo Decision Service aínda se poden aplicar á páxina renderizada; o que cambia é se están vinculadas a un rexistro de visitante estable.

Validar a integración e o rastro de auditoría

O paso de validación é o que comprueban os reguladores e o que os editores omiten con máis frecuencia nas ferramentas de experimentación. Un despregamento de Optimizely correctamente integrado debe superar catro probas en secuencia. En primeiro lugar, unha sesión de navegador limpa co banner mostrado pero sen ningunha elección realizada debe producir cero solicitudes a logx.optimizely.com máis aló da descarga do arquivo SDK e cero cookies optimizely en document.cookie. En segundo lugar, rexeitar a análise debe manter ese estado — sen identificador persistente, sen evento de decisión, sen asignación de variante vinculada a un rexistro estable. En terceiro lugar, aceptar a análise debe producir a cookie optimizelyEndUserId esperada e o tráfico de eventos de decisión con a asignación de variante correctamente aplicada. En cuarto lugar, retirar o consentimento debe deter inmediatamente os eventos de decisión adicionais, vencer as cookies e propagar a exclusión voluntaria a calquera integración de análise posterior.

A expectativa de rastro de auditoría baixo as directrices de banner de cookies do EDPB de 2023 e as renovadas prioridades do grupo de traballo de 2026 é que o editor poida demostrar, para calquera exposición experimental específica no proxecto de Optimizely, que o visitante dera un consentimento válido no momento da exposición. O patrón estándar é establecer a versión do consentimento e a marca de tempo como un atributo personalizado no perfil de visitante de Optimizely a través da attribute API do SDK para que calquera exposición individual sexa rastreable ata unha entrada específica do rexistro de consentimento. Un despregamento correctamente delimitado, combinado co manexo do modo anónimo para as decisións de renderizado previas ao consentimento e un camiño de retirada que se propaga augas abaixo, é o que converte a Optimizely dunha responsabilidade oculta ao nivel de capa de experimentación nunha parte defendible do produto e a pila de crecemento dun editor.

← Blog Ler todo →