Perché Optimizely Web Experimentation richiede il consenso

Un'inizializzazione predefinita di Optimizely esegue diverse operazioni al primo rendering della pagina. Imposta un cookie di prima parte sotto optimizelyEndUserId contenente l'identificatore persistente del visitatore, valuta il visitatore rispetto agli esperimenti attivi, scrive le assegnazioni delle varianti in un secondo cookie sotto i marcatori di spazio dei nomi optimizelyOptOut, invia un evento di decisione a logx.optimizely.com e applica le modifiche delle varianti alla pagina renderizzata. Quando l'operatore ha collegato un'integrazione analitica — Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap o l'Optimizely Data Platform — l'SDK invia anche eventi di esposizione delle varianti al livello analitico, che poi associa la variante al più ampio profilo analitico del visitatore.

Ognuna di quelle attività attiva un gate di consenso separato. La persistenza dell'identificatore del visitatore è un'operazione di archiviazione e accesso ai sensi dell'Article 5(3) della Direttiva ePrivacy che richiede un consenso previo, liberamente espresso, specifico, informato e inequivocabile nell'EEA, nel Regno Unito e in qualsiasi giurisdizione che ha adottato lo stesso standard. Il collegamento delle assegnazioni di varianti sperimentali a tale identificatore nelle sessioni costituisce un trattamento di dati personali ai sensi del GDPR, poiché la combinazione di identificatore, indirizzo IP ed esposizione alla variante è sufficiente a individuare una persona e a caratterizzare la sua interazione con il programma di sperimentazione. La propagazione cross-tool dei dati delle varianti — Optimizely che espone l'assegnazione della variante a Google Analytics, per esempio — aggiunge il gate analitico alla catena. Gli orientamenti dell'EDPB del 2023 sono stati espliciti nel sancire che la sperimentazione che comporta identificazione persistente è soggetta alle stesse regole di consenso dell'analisi; il CNIL è stato il regolatore più eloquente su questo punto ma non è l'unico.

Cosa scrive Optimizely prima del consenso — e cosa deve essere soppresso

Il frammento standard di Optimizely installa il JavaScript SDK direttamente nell'intestazione della pagina e si inizializza immediatamente al caricamento. Questo è il quickstart documentato e la fonte del più comune fallimento di conformità: l'SDK viene eseguito prima che il banner dei cookie sia stato renderizzato, il cookie optimizelyEndUserId viene scritto in pochi millisecondi, viene effettuata l'assegnazione della variante e l'evento di decisione viene inviato indipendentemente da ciò che il visitatore deciderà in seguito. Ogni autorità di regolamentazione europea che si è pronunciata su questo schema ha deciso allo stesso modo: i cookie impostati prima del consenso sono illeciti, l'assegnazione della variante acquisita prima del consenso è un trattamento illecito e l'editore ne porta la responsabilità.

Un'integrazione conforme deve pertanto impedire a Optimizely di scrivere l'identificatore persistente e di inviare eventi di decisione fino a quando la pertinente categoria di consenso non è stata concessa. Optimizely supporta due schemi a tale scopo. Il primo è l'attributo di consenso dedicato — passare OPTIMIZELY_OPT_OUT=true come stringa di query o impostare il cookie optimizely.opt_out prima dell'inizializzazione dell'SDK — che mette l'SDK in modalità opt-out in cui non viene scritto alcun identificatore e non vengono inviati eventi. Il secondo è la modalità solo anonima supportata nella configurazione dell'SDK, in cui l'SDK opera in una modalità senza sessione che assegna le varianti basandosi unicamente sull'identificazione locale alla sessione, senza identificazione persistente tra le visite. La modalità anonima consente al programma di sperimentazione di operare su base di interesse legittimo per la decisione di rendering, differendo l'identificazione persistente fino alla concessione del consenso.

I cookie e la memoria che Optimizely scrive

L'Optimizely Web Experimentation SDK scrive i seguenti identificatori all'inizializzazione, tutti non essenziali e che richiedono consenso: optimizelyEndUserId con scadenza pluriennale contenente l'identificatore persistente del visitatore, marcatori optimizelyOptOut che tracciano lo stato di opt-out, optimizelyDomainTestCookie per la sperimentazione tra sottodomini e cookie di spazio dei nomi aggiuntivi quando l'operatore ha abilitato l'identificazione tra domini. Revocare il consenso richiede quindi sia la scadenza dei cookie sia il posizionamento dell'SDK in modalità opt-out tramite optimizely.push({ type: 'user', attributes: { opt_out: true } }) per interrompere ulteriori raccolta di eventi.

Mappare Optimizely sui framework di consenso

Optimizely non implementa nativamente IAB TCF o IAB Global Privacy Platform — è una piattaforma di sperimentazione di prima parte, non un fornitore adtech — ma espone una API di opt-out nativa, supporta un'integrazione documentata di Consent Mode tramite Optimizely Data Platform e rispetta il CMP dell'editore tramite l'attributo OPTIMIZELY_OPT_OUT. Lo schema che supera la revisione di un regolatore tratta ogni capacità di Optimizely come un gate separato legato a uno specifico segnale CMP.

• La sperimentazione anonima può operare su base di interesse legittimo con identificazione locale alla sessione, che è appropriata per le decisioni di rendering che non richiedono identificazione persistente tra le visite e che non si propagano verso l'analisi a valle. Questa modalità si lega alla categoria strettamente necessaria o funzionale.
• La sperimentazione persistente con identificatore stabile si lega alla finalità analitica. In termini TCF questo si associa alla finalità 8 combinata con la finalità 1; per Consent Mode si associa a analytics_storage.
• L'integrazione cross-tool — eventi di esposizione delle varianti propagati a Google Analytics, Amplitude o Optimizely Data Platform — eredita il gate analitico dallo strumento ricevente e non deve essere attivata se il gate di quello strumento non è stato concesso.
• La personalizzazione e il targeting basato sul pubblico costruiti sulla sperimentazione attivano il gate di marketing perché si spostano dalla misurazione sperimentale al targeting a livello utente.

Lo schema di integrazione che funziona

Il deployment di riferimento ha quattro componenti: un CMP che espone un evento di modifica del consenso in tempo reale, un bootstrap differito che inizializza l'SDK di Optimizely con opt-out abilitato o modalità anonima attiva, un listener del consenso che porta l'SDK fuori dall'opt-out e avvia l'identificazione persistente quando il gate analitico si apre, e un percorso di revoca che riporta l'SDK in modalità opt-out, fa scadere i cookie optimizely tramite document.cookie e propaga la revoca a qualsiasi integrazione analitica a valle.

Implementazione web con il bootstrap differito

Sul web lo schema più pulito è caricare il frammento di Optimizely con window.optimizelyOptOut = true impostato prima dell'inizializzazione dell'SDK. Iscriversi all'evento di modifica del consenso del CMP. Quando la categoria analitica passa a true, chiamare window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) e lasciare che l'SDK si inizializzi normalmente. Quando il gate viene revocato, rimettere l'attributo di opt-out a true, far scadere il cookie optimizelyEndUserId e propagare la modifica a qualsiasi piattaforma analitica integrata tramite le rispettive API di consenso.

Sperimentazione lato server tramite il Decision Service

Optimizely supporta anche la sperimentazione lato server tramite la Decision Service API. Le decisioni lato server non sono esenti dal consenso — la base giuridica segue i dati — ma l'esecuzione lato server fornisce all'editore il pieno controllo su quali identificatori vengono propagati. Lo schema che funziona è passare un identificatore di sessione effimero al Decision Service quando il gate analitico è chiuso, e passare all'identificatore persistente solo quando il gate è aperto. Le assegnazioni delle varianti restituite dal Decision Service possono ancora essere applicate alla pagina renderizzata; ciò che cambia è se sono legate a un record di visitatore stabile.

Validare l'integrazione e la traccia di audit

Il passo di validazione è ciò che i regolatori verificano e ciò che gli editori più spesso saltano sugli strumenti di sperimentazione. Un deployment di Optimizely correttamente integrato deve superare quattro test in sequenza. In primo luogo, una sessione browser pulita con il banner visualizzato ma senza scelta effettuata deve produrre zero richieste a logx.optimizely.com oltre al recupero del file SDK e zero cookie optimizely in document.cookie. In secondo luogo, rifiutare l'analisi deve mantenere quello stato — nessun identificatore persistente, nessun evento di decisione, nessuna assegnazione di variante legata a un record stabile. In terzo luogo, accettare l'analisi deve produrre il cookie optimizelyEndUserId atteso e il traffico di eventi di decisione con l'assegnazione della variante correttamente applicata. In quarto luogo, revocare il consenso deve immediatamente interrompere ulteriori eventi di decisione, far scadere i cookie e propagare l'opt-out a qualsiasi integrazione analitica a valle.

L'aspettativa di traccia di audit ai sensi delle linee guida dell'EDPB del 2023 sui banner dei cookie e delle priorità rinnovate della task force 2026 è che l'editore possa dimostrare, per qualsiasi specifica esposizione sperimentale nel progetto Optimizely, che il visitatore aveva fornito consenso valido al momento dell'esposizione. Lo schema standard è impostare la versione del consenso e il timestamp come attributo personalizzato sul profilo del visitatore Optimizely tramite l'attribute API dell'SDK affinché qualsiasi singola esposizione sia tracciabile fino a una specifica voce del registro dei consensi. Un deployment correttamente delimitato, abbinato alla gestione della modalità anonima per le decisioni di rendering pre-consenso e a un percorso di revoca che si propaga a valle, è ciò che trasforma Optimizely da una responsabilità nascosta a livello di strato di sperimentazione in una parte difendibile del prodotto e dello stack di crescita di un editore.