Guia d'integració del consentiment de galetes d'Optimizely Web Experimentation: proves A/B sota el GDPR el 2026
Optimizely ocupa una posició estranya respecte a la conversa sobre el consentiment. Una persona raonable que examini les eines d'experimentació podria assumir que és una categoria de baix risc — la prova tracta sobre quin color de botó genera més clics, no sobre qui és el visitant. La realitat, sota el marc que el GDPR va establir i que l'EDPB ha estat reforçant activament des del 2023, és que l'experimentació implica exactament les mateixes categories de processament que l'analítica o el màrqueting sempre que la plataforma escriu un identificador persistent i hi vincula les variants experimentals. L'Optimizely Web Experimentation SDK fa precisament això: assigna un visitant a una variant fent hash d'un identificador persistent, escriu l'assignació a una galeta de primera part perquè el visitant vegi la mateixa variant entre sessions, i emet esdeveniments d'exposició i conversió vinculats a aquest identificador. Cadascun d'aquests passos activa una porta de consentiment. La bona notícia és que Optimizely inclou una de les integracions de consentiment més reflexives de la categoria d'experimentació, inclòs un atribut de consentiment dedicat i la capacitat d'operar en mode només anònim. La feina consisteix a utilitzar-ho realment.
Per què Optimizely Web Experimentation requereix consentiment
Una inicialització predeterminada d'Optimizely fa diverses coses en el primer renderitzat de la pàgina. Estableix una galeta de primera part sota optimizelyEndUserId que conté l'identificador persistent del visitant, avalua el visitant contra els experiments actius, escriu les assignacions de variants a una segona galeta sota els marcadors d'espai de noms optimizelyOptOut, envia un esdeveniment de decisió a logx.optimizely.com i aplica els canvis de variant a la pàgina renderitzada. Quan l'operador ha connectat una integració d'analítica — Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap o l'Optimizely Data Platform — el SDK també envia esdeveniments d'exposició de variant a la capa analítica, que després vincula la variant al perfil analític més ampli del visitant.
Cadascuna d'aquestes activitats activa una porta de consentiment separada. Persistir l'identificador del visitant és una operació d'emmagatzematge i accés sota l'Article 5(3) de la Directiva ePrivacy que requereix consentiment previ, lliurement donat, específic, informat i inequívoc a l'EEA, el Regne Unit i qualsevol jurisdicció que hagi importat el mateix estàndard. Vincular les assignacions de variants experimentals a aquest identificador entre sessions és un processament de dades personals sota el GDPR perquè la combinació d'identificador, adreça IP i exposició de variant és suficient per distingir un individu i caracteritzar la seva interacció amb el programa d'experimentació. La propagació entre eines de les dades de variants — Optimizely exposant l'assignació de variant a Google Analytics, per exemple — afegeix la porta analítica a la cadena. La guia de l'EDPB del 2023 ha estat explícita que l'experimentació que implica identificació persistent està subjecta a les mateixes regles de consentiment que l'analítica; el CNIL ha estat el regulador més vocal en aquest punt però no és l'únic.
Què escriu Optimizely abans del consentiment — i el que s'ha de suprimir
El fragment estàndard d'Optimizely instal·la el JavaScript SDK directament a l'encapçalament de la pàgina i s'inicialitza immediatament en carregar-se. Això és el quickstart documentat i la font del fracàs de compliment més comú: el SDK s'executa abans que el bàner de galetes s'hagi renderitzat, la galeta optimizelyEndUserId s'escriu en qüestió de mil·lisegons, es fa l'assignació de variant i l'esdeveniment de decisió s'envia independentment del que el visitant decideixi més tard. Tot regulador europeu que s'ha pronunciat sobre aquest patró ha fallat de la mateixa manera: les galetes establertes abans del consentiment són il·legals, l'assignació de variant capturada abans del consentiment és un processament il·legal, i l'editor porta la responsabilitat.
Una integració conforme ha de, per tant, impedir que Optimizely escrigui l'identificador persistent i enviï esdeveniments de decisió fins que s'hagi concedit la categoria de consentiment pertinent. Optimizely suporta dos patrons per a això. El primer és l'atribut de consentiment dedicat — passar OPTIMIZELY_OPT_OUT=true com a cadena de consulta o establir la galeta optimizely.opt_out abans de la inicialització del SDK — que posa el SDK en mode d'exclusió voluntària on no s'escriu cap identificador i no s'envien esdeveniments. El segon és el mode només anònim suportat a la configuració del SDK, on el SDK s'executa en un mode sense sessió que assigna variants basant-se únicament en la identificació local de sessió, sense identificació persistent entre visites. El mode anònim permet que el programa d'experimentació s'executi sota una base d'interès legítim per a la decisió de renderitzat mentre es difereix la identificació persistent fins que es concedeixi el consentiment.
Les galetes i l'emmagatzematge que escriu Optimizely
L'Optimizely Web Experimentation SDK escriu els identificadors següents en la inicialització, tots els quals són no essencials i requereixen consentiment: optimizelyEndUserId amb una caducitat de diversos anys que conté l'identificador persistent del visitant, marcadors optimizelyOptOut que fan el seguiment de l'estat d'exclusió voluntària, optimizelyDomainTestCookie per a l'experimentació entre subdominis, i galetes d'espai de noms addicionals quan l'operador ha habilitat la identificació entre dominis. Per tant, retirar el consentiment ha de tant caducar les galetes com posar el SDK en mode d'exclusió voluntària mitjançant optimizely.push({ type: 'user', attributes: { opt_out: true } }) per aturar la col·lecció d'esdeveniments posterior.
Mapejar Optimizely als marcs de consentiment
Optimizely no implementa nativament el IAB TCF o el IAB Global Privacy Platform — és una plataforma d'experimentació de primera part, no un proveïdor de tecnologia publicitària — però sí que exposa una API d'exclusió voluntària nativa, suporta una integració de Consent Mode documentada a través de l'Optimizely Data Platform i respecta el CMP de l'editor a través de l'atribut OPTIMIZELY_OPT_OUT. El patró que supera la revisió d'un regulador tracta cada capacitat d'Optimizely com una porta separada vinculada a un senyal CMP específic.
- L'experimentació anònima pot executar-se sota una base d'interès legítim amb identificació local de sessió, que és adequada per a decisions de renderitzat que no requereixen identificació persistent entre visites i que no es propaguen a l'analítica posterior. Aquest mode s'enllaça a la categoria estrictament necessària o funcional.
- L'experimentació persistent amb un identificador estable s'enllaça al propòsit analític. En termes TCF, això s'assigna al propòsit 8 combinat amb el propòsit 1; per a Consent Mode, s'assigna a analytics_storage.
- La integració entre eines — esdeveniments d'exposició de variant propagats a Google Analytics, Amplitude o l'Optimizely Data Platform — hereta la porta analítica de l'eina receptora i no s'ha d'enviar si la porta d'aquesta eina no ha estat concedida.
- La personalització i la segmentació basada en audiència construïdes sobre l'experimentació activen la porta de màrqueting perquè creuen des del mesurament experimental cap a la segmentació a nivell d'usuari.
El patró d'integració que funciona
El desplegament de referència té quatre parts: un CMP que exposa un esdeveniment de canvi de consentiment en temps real, un arrencada diferida que inicialitza el SDK d'Optimizely amb l'exclusió voluntària habilitada o el mode anònim actiu, un escoltador de consentiment que canvia el SDK fora de l'exclusió voluntària i inicia la identificació persistent quan s'obre la porta analítica, i un camí de retirada que torna el SDK al mode d'exclusió voluntària, caduca les galetes optimizely mitjançant document.cookie i propaga la retirada a qualsevol integració analítica posterior.
Implementació web amb l'arrencada diferida
A la web, el patró més net és carregar el fragment d'Optimizely amb window.optimizelyOptOut = true establert abans de la inicialització del SDK. Subscriviu-vos a l'esdeveniment de canvi de consentiment del CMP. Quan la categoria analítica fa la transició a true, crideu window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) i deixeu que el SDK s'inicialitzi normalment. Quan la porta es retira, torneu a posar l'atribut d'exclusió voluntària a true, caduceu la galeta optimizelyEndUserId i propageu el canvi a qualsevol plataforma analítica integrada a través de les seves respectives API de consentiment.
Experimentació del costat del servidor a través del Decision Service
Optimizely també suporta l'experimentació del costat del servidor a través de la Decision Service API. Les decisions del costat del servidor no estan exemptes del consentiment — la base legal segueix les dades — però l'execució del costat del servidor dóna a l'editor control total sobre quins identificadors es propaguen. El patró que funciona és passar un identificador de sessió efímer al Decision Service quan la porta analítica està tancada, i canviar a l'identificador persistent només quan la porta estigui oberta. Les assignacions de variants retornades pel Decision Service encara es poden aplicar a la pàgina renderitzada; el que canvia és si estan vinculades a un registre de visitant estable.
Validar la integració i el rastre d'auditoria
El pas de validació és el que comproven els reguladors i el que els editors sovint ometen en les eines d'experimentació. Un desplegament d'Optimizely correctament integrat ha de superar quatre proves en seqüència. Primer, una sessió de navegador neta amb el bàner mostrat però sense cap elecció feta ha de produir zero sol·licituds a logx.optimizely.com més enllà de la descàrrega del fitxer SDK i zero galetes optimizely a document.cookie. Segon, declinar l'analítica ha de mantenir aquest estat — sense identificador persistent, sense esdeveniment de decisió, sense assignació de variant vinculada a un registre estable. Tercer, acceptar l'analítica ha de produir la galeta optimizelyEndUserId esperada i el trànsit d'esdeveniments de decisió, amb l'assignació de variant correctament aplicada. Quart, retirar el consentiment ha d'aturar immediatament els esdeveniments de decisió posteriors, caducar les galetes i propagar l'exclusió voluntària a qualsevol integració analítica posterior.
L'expectativa de rastre d'auditoria sota les directrius de bàner de galetes de l'EDPB del 2023 i les prioritats renovades del grup de treball del 2026 és que l'editor pugui demostrar, per a qualsevol exposició experimental específica al projecte d'Optimizely, que el visitant havia donat un consentiment vàlid en el moment de l'exposició. El patró estàndard és establir la versió del consentiment i la marca de temps com a atribut personalitzat al perfil de visitant d'Optimizely a través de l'attribute API del SDK perquè qualsevol exposició individual sigui rastreable fins a una entrada específica del registre de consentiment. Un desplegament correctament tancat, combinat amb el maneig del mode anònim per a les decisions de renderitzat prèvies al consentiment i un camí de retirada que es propaga a l'ordre inferior, és el que converteix Optimizely d'una responsabilitat oculta a la capa d'experimentació en una part defensable del producte i la pila de creixement d'un editor.