Guia de Integração de Consentimento de Cookies do Optimizely Web Experimentation: Testes A/B sob o GDPR em 2026
O Optimizely ocupa uma posição estranha nas discussões sobre consentimento. Uma pessoa razoável olhando para uma ferramenta de experimentação pode pensar que esta é uma categoria de baixo risco – os testes são sobre qual cor de botão recebe mais cliques, não sobre quem é o visitante. Mas a realidade sob o quadro estabelecido pelo GDPR e ativamente aplicado pelo EDPB desde 2023 é que toda vez que uma plataforma escreve um identificador persistente e vincula uma variante experimental a ele, o experimento envolve exatamente as mesmas categorias de processamento que análise ou marketing. O SDK do Optimizely Web Experimentation faz exatamente isso: hash de um identificador persistente para atribuir visitantes a variantes, escreve a atribuição em um cookie próprio para que os visitantes vejam a mesma variante ao longo da sessão, e emite eventos de impressão e conversão vinculados a esse identificador. Cada um desses passos aciona um requisito de consentimento. A boa notícia é que o Optimizely tem uma das integrações de consentimento mais bem pensadas na categoria de experimentação: um atributo de consentimento dedicado e a capacidade de operar apenas no modo anônimo. O desafio é realmente usá-los.
Por que o Optimizely Web Experimentation Requer Consentimento
A inicialização padrão do Optimizely faz várias coisas na primeira renderização da página: define um cookie próprio sob a chave optimizelyEndUserId contendo um identificador persistente do visitante; avalia o visitante em relação aos experimentos ativos; escreve a atribuição da variante em um segundo cookie sob a chave optimizelyOptOut; dispara um evento de decisão para logx.optimizely.com; e aplica as alterações da variante na página renderizada. Se os operadores conectarem integrações analíticas – Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap ou Optimizely Data Platform – o SDK também dispara eventos de impressão de variante para a camada analítica, vinculando a variante ao perfil analítico mais amplo do visitante.
Cada uma dessas atividades aciona um requisito de consentimento separado. A persistência do identificador do visitante é uma operação de armazenamento e acesso sob o Article 5(3) da Diretiva ePrivacy, exigindo consentimento prévio, livremente dado, específico, informado e inequívoco no EEA, UK e todas as jurisdições que adotaram os mesmos padrões. Vincular a atribuição de variante experimental a esse identificador durante a sessão é processamento de dados pessoais sob o GDPR, porque a combinação de identificador, endereço IP e impressão de variante é suficiente para identificar um indivíduo e caracterizar suas interações com o programa de experimentos. A propagação de dados de variante entre ferramentas – por exemplo, quando o Optimizely envia uma variante para o Google Analytics – adiciona um gate analítico à cadeia. As diretrizes do EDPB de 2023 afirmam explicitamente que experimentos envolvendo identificação persistente estão sujeitos às mesmas regras de consentimento que análise. O CNIL foi a autoridade mais vocal neste ponto, mas não a única.
O Que o Optimizely Escreve Antes do Consentimento – O Que Deve Ser Suprimido
O snippet padrão do Optimizely instala o JavaScript SDK diretamente no head da página e o inicializa imediatamente no carregamento. Este é o quickstart documentado e a causa mais comum de falhas de conformidade. O SDK é executado antes do banner de cookies ser renderizado: o cookie optimizelyEndUserId é escrito em milissegundos, as atribuições de variante são feitas e os eventos de decisão são disparados – independentemente do que o visitante decidir posteriormente. Toda autoridade regulatória europeia que avaliou esse padrão chegou à mesma conclusão: cookies definidos antes do consentimento são ilegais; atribuições de variante capturadas antes do consentimento são processamento ilegal; e o editor é responsável.
Uma integração conforme deve impedir que o Optimizely escreva identificadores persistentes em cookies e dispare eventos de decisão até que a categoria de consentimento relevante seja concedida. O Optimizely suporta dois padrões para isso. O primeiro é o atributo de consentimento dedicado: passar OPTIMIZELY_OPT_OUT=true como query string ou definir o cookie optimizely.opt_out antes da inicialização do SDK coloca o SDK no modo opt-out – nenhum identificador é escrito, nenhum evento é disparado. O segundo é o modo somente anônimo, suportado na configuração do SDK: o SDK opera no modo sem sessão, atribuindo variantes com base apenas em identificadores locais de sessão sem identificação persistente entre visitas. O modo anônimo permite que o programa de experimentos opere sob base de interesse legítimo para decisões de renderização, adiando a identificação persistente até que o consentimento seja concedido.
Cookies e Armazenamento Escritos pelo Optimizely
O SDK do Optimizely Web Experimentation escreve os seguintes identificadores na inicialização – todos são não essenciais e exigem consentimento: optimizelyEndUserId, um identificador persistente de visitante com prazo de expiração de vários anos; o marcador optimizelyOptOut que rastreia o status de opt-out; optimizelyDomainTestCookie para experimentos entre subdomínios; e cookies adicionais de namespace se o operador habilitou a identificação entre domínios. A revogação do consentimento deve realizar tanto a expiração dos cookies quanto a definição do SDK no modo opt-out via optimizely.push({ type: 'user', attributes: { opt_out: true } }), interrompendo a coleta de eventos subsequente.
Mapeando o Optimizely para Frameworks de Consentimento
O Optimizely não implementa nativamente o IAB TCF ou o IAB Global Privacy Platform – é uma plataforma de experimentação própria, não um fornecedor de adtech. Mas expõe uma API nativa de opt-out, suporta uma integração Consent Mode documentada via Optimizely Data Platform, e respeita o CMP do editor via atributo OPTIMIZELY_OPT_OUT. O padrão que sobrevive ao escrutínio regulatório trata cada funcionalidade do Optimizely como um gate separado vinculado a um sinal específico de CMP.
- Experimentos anônimos podem operar sob base de interesse legítimo com identificadores locais de sessão. Isso é adequado para decisões de renderização que não requerem identificação persistente entre visitas e não se propagam para análise downstream. Este modo é vinculado à categoria estritamente necessária ou funcional.
- Experimentos persistentes com identificadores estáveis são vinculados a finalidades analíticas. Na terminologia TCF isso mapeia para Finalidade 8 combinada com Finalidade 1. No Consent Mode mapeia para analytics_storage.
- Integrações entre ferramentas (eventos de impressão de variante propagados para Google Analytics, Amplitude ou Optimizely Data Platform) herdam o gate analítico da ferramenta receptora e não devem ser disparados se o gate dessa ferramenta não foi concedido.
- Personalização e targeting baseado em audiência construído sobre experimentos aciona o gate de marketing quando se move de medição experimental para targeting em nível de usuário.
Padrões de Integração que Funcionam
A implantação de referência tem quatro partes: um CMP que publica eventos de mudança de consentimento em tempo real; um bootstrap adiado que inicializa o SDK do Optimizely com opt-out habilitado ou modo anônimo ativo; um ouvinte de consentimento que muda o SDK de opt-out para identificação persistente quando o gate analítico abre; e um caminho de revogação que retorna o SDK ao modo opt-out, expira os cookies optimizely via document.cookie, e propaga a revogação para integrações analíticas downstream.
Implementação Web com Bootstrap Adiado
Na web, o padrão mais limpo é carregar o snippet do Optimizely com window.optimizelyOptOut = true definido antes da inicialização do SDK. Assine eventos de mudança de consentimento do CMP. Quando a categoria analítica transita para true, chame window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) e deixe o SDK inicializar normalmente. Quando o gate for revogado, retorne o atributo opt-out para true, expire o cookie optimizelyEndUserId, e propague a mudança para plataformas analíticas integradas via suas respectivas APIs de consentimento.
Experimentos do Lado do Servidor via Decision Service
O Optimizely também suporta experimentos do lado do servidor via API Decision Service. Decisões do lado do servidor não estão isentas de consentimento – a base legal segue os dados. Mas a execução do lado do servidor permite que os editores tenham controle total sobre quais identificadores são propagados. O padrão funcional é passar um identificador de sessão efêmero para o Decision Service quando o gate analítico está fechado, e só mudar para um identificador persistente quando o gate estiver aberto. As atribuições de variante retornadas pelo Decision Service ainda podem ser aplicadas na página renderizada – o que muda é se estão vinculadas a um registro estável de visitante.
Validando a Integração e Trilha de Auditoria
Os passos de validação são o que as autoridades regulatórias verificam, e o que os editores mais frequentemente pulam em ferramentas de experimentação. Uma implantação do Optimizely corretamente integrada deve passar em quatro testes em sequência. Primeiro, uma sessão de navegador limpa com o banner visível mas sem escolha feita deve mostrar zero tráfego para logx.optimizely.com além do fetch do arquivo SDK, e zero cookies optimizely em document.cookie. Segundo, rejeitar análise deve manter esse estado: sem identificadores persistentes, sem eventos de decisão, sem atribuições de variante vinculadas a registros estáveis. Terceiro, aceitar análise deve produzir os cookies optimizelyEndUserId esperados e tráfego de eventos de decisão, com atribuições de variante corretamente aplicadas. Quarto, a revogação do consentimento deve imediatamente parar mais eventos de decisão, expirar cookies e propagar opt-out para integrações analíticas downstream.
As expectativas de trilha de auditoria sob as diretrizes de banner de cookies do EDPB de 2023 e as prioridades atualizadas do grupo de trabalho de 2026 são que os editores podem provar que o visitante forneceu consentimento válido no momento da impressão para impressões experimentais específicas em um projeto Optimizely. O padrão padrão é definir a versão e o carimbo de tempo do consentimento como atributos personalizados no perfil de visitante do Optimizely via API de atributos do SDK, para que cada impressão possa ser rastreada até uma entrada específica de log de consentimento. Uma implantação adequadamente protegida, combinada com modo anônimo para decisões de renderização pré-consentimento e um caminho de revogação que propaga downstream, transforma o Optimizely de uma dívida oculta de camada de experimento em uma parte defensável da pilha de produto e crescimento do editor.