Optimizely Web Experimentation cookie-samtykkevejledning: A/B-test under GDPR i 2026
Optimizely befinder sig i en mærkelig position i samtykkedebatten. En fornuftig person, der ser på eksperimenteringsværktøjer, vil måske antage, at det er en lavrisikokategori — testen handler om, hvilken knapfarve der driver flest klik, ikke om hvem besøgende er. Virkeligheden er, under det rammesæt som GDPR etablerede, og som EDPB aktivt har styrket siden 2023, at eksperimentering engagerer præcis de samme behandlingskategorier som analyse eller marketing, når platformen skriver et persistent identifikator og knytter eksperimentelle varianter til det. Optimizely Web Experimentation SDK gør præcis dette: den tildeler en besøgende til en variant ved at hashe et persistent identifikator, skriver tildelingen til en førstepartscookie, så den besøgende ser den samme variant på tværs af sessioner, og udsender eksponerings- og konverteringshændelser knyttet til dette identifikator. Hvert af disse trin aktiverer en samtykkeport. Den gode nyhed er, at Optimizely leveres med en af de mere gennemtænkte samtykkeintegrationer i eksperimenteringskategorien, herunder en dedikeret samtykkeattribut og mulighed for at operere i kun-anonym tilstand. Arbejdet ligger i rent faktisk at bruge det.
Hvorfor Optimizely Web Experimentation kræver samtykke
En standard Optimizely-initialisering gør flere ting ved sidens første maling. Den sætter en førstepartscookie under optimizelyEndUserId indeholdende det persistente besøgende-identifikator, evaluerer den besøgende mod de aktive eksperimenter, skriver varianttildelingerne til en anden cookie under optimizelyOptOut-navnerumsmarkørerne, affyrer en beslutningshændelse til logx.optimizely.com og anvender variantændringerne på den gengivne side. Når operatøren har tilsluttet en analyseintegration — Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap eller Optimizely Data Platform — affyrer SDK'en også varianteksponeringsbegivenheder ind i analyselaget, som derefter knytter varianten til den besøgendes bredere analyseprofil.
Hver af disse aktiviteter aktiverer en separat samtykkeport. Persistering af besøgende-identifikatoren er en lagrings-og-adgangsoperation under Article 5(3) i ePrivacy-direktivet, der kræver forudgående, frit givet, specifikt, informeret og utvetydigt samtykke i EEA, UK og enhver jurisdiktion, der har importeret den samme standard. Binding af eksperimentelle varianttildelinger til dette identifikator på tværs af sessioner er behandling af personoplysninger under GDPR, fordi kombinationen af identifikator, IP-adresse og varianteksponering er tilstrækkelig til at udpege et individ og karakterisere dets interaktion med eksperimentprogrammet. Tværgående formidling af variantdata — Optimizely eksponerer f.eks. varianttildelingen til Google Analytics — tilføjer analyseportalen til kæden. EDPB's vejledning fra 2023 har udtrykkeligt angivet, at eksperimentering, der involverer persistent identifikation, er underlagt de samme samtykkeregler som analyse; CNIL har været den mest højtråbende tilsynsmyndighed på dette punkt, men er ikke alene.
Hvad Optimizely skriver før samtykke — og hvad der skal undertrykkes
Standard Optimizely-uddrag installerer JavaScript SDK direkte i sidens head og initialiseres straks ved indlæsning. Det er den dokumenterede hurtigstart og kilden til den mest almindelige overholdelsesfejl: SDK'en kører, inden cookiebanneret er gengivet, optimizelyEndUserId-cookien skrives inden for millisekunder, varianttildelingen foretages, og beslutningshændelsen affyres uanset, hvad den besøgende beslutter senere. Alle europæiske tilsynsmyndigheder, der har taget stilling til dette mønster, har truffet afgørelse på samme måde: cookies indstillet før samtykke er ulovlige, varianttildelingen, der er indhentet før samtykke, er ulovlig behandling, og udgiveren bærer ansvaret.
En kompatibel integration skal derfor forhindre Optimizely i at skrive det persistente identifikator og affyre beslutningshændelser, indtil den relevante samtykkekategori er givet. Optimizely understøtter to mønstre til dette. Det første er den dedikerede samtykkeattribut — send OPTIMIZELY_OPT_OUT=true som en forespørgselstreng eller indstil optimizely.opt_out-cookien før SDK-initialisering — hvilket sætter SDK'en i frameldelstilstand, hvor der ikke skrives noget identifikator og ingen hændelser affyres. Det andet er den kun-anonyme tilstand, der understøttes i SDK-konfigurationen, hvor SDK'en kører i en sessionsfri tilstand, der tildeler varianter udelukkende baseret på sessionslokal identifikation uden persistent identifikation på tværs af besøg. Den anonyme tilstand gør det muligt for eksperimentprogrammet at køre under et legitimt interessegrundlag for gengivelsesbeslutningen, mens persistent identifikation udskydes, indtil samtykke gives.
De cookies og lagring, som Optimizely skriver
Optimizely Web Experimentation SDK skriver følgende identifikatorer ved initialisering, som alle er ikke-væsentlige og kræver samtykke: optimizelyEndUserId med et flerårig udløb indeholdende det persistente besøgende-identifikator, optimizelyOptOut-markører, der sporer frameldingstilstand, optimizelyDomainTestCookie til eksperimentering på tværs af underdomæner, og yderligere navnerumsscookies, når operatøren har aktiveret identifikation på tværs af domæner. Tilbagetrækning af samtykke skal derfor både udløbe cookies og sætte SDK'en i frameldingstilstand via optimizely.push({ type: 'user', attributes: { opt_out: true } }) for at stoppe yderligere hændelsesindsamling.
Kortlægning af Optimizely til samtykkerammer
Optimizely implementerer ikke nativt IAB TCF eller IAB Global Privacy Platform — det er en førstepartseksperimenteringsplatform, ikke en adtech-leverandør — men det eksponerer en native frameldelses-API, understøtter en dokumenteret Consent Mode-integration via Optimizely Data Platform og respekterer udgiverens CMP via OPTIMIZELY_OPT_OUT-attributten. Det mønster, der overlever en tilsynsmyndigheds gennemgang, behandler hver Optimizely-kapacitet som en separat port bundet til et specifikt CMP-signal.
- Anonym eksperimentering kan køre under et legitimt interessegrundlag med sessionslokal identifikation, hvilket er passende for gengivelsesbeslutninger, der ikke kræver persistent identifikation på tværs af besøg og ikke udbredes til nedstrømsanalyse. Denne tilstand er bundet til den strengt nødvendige eller funktionelle kategori.
- Persistent eksperimentering med et stabilt identifikator er bundet til analyseformålet. I TCF-termer svarer dette til formål 8 kombineret med formål 1; for Consent Mode svarer dette til analytics_storage.
- Tværgående integration — varianteksponeringsbegivenheder udbredt til Google Analytics, Amplitude eller Optimizely Data Platform — arver analyseportalen fra det modtagende værktøj og må ikke affyres, hvis dette værktøjs port ikke er givet.
- Personalisering og målgruppebaseret målretning bygget oven på eksperimentering aktiverer marketingportalen, fordi den krydser fra eksperimentel måling til målretning på brugerniveau.
Det integrationsmønster, der virker
Referenceimplementeringen har fire dele: en CMP, der eksponerer en realtids samtykkehændelse, en udskudt bootstrap, der initialiserer Optimizely SDK med frameldning aktiveret eller anonym tilstand aktiv, en samtykkelytter, der skifter SDK ud af frameldning og starter persistent identifikation, når analyseportalen åbnes, og en tilbagetrækningssti, der sætter SDK tilbage til frameldingstilstand, udløber optimizely-cookies via document.cookie og udbreder tilbagetrækningen til eventuelle nedstrømsanalyseintegrationer.
Webimplementering med den udskudte bootstrap
På nettet er det reneste mønster at indlæse Optimizely-uddrag med window.optimizelyOptOut = true sat før SDK-initialisering. Abonner på CMP'ens samtykkehændelse. Når analysekategorien overgår til true, kald window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) og lad SDK'en initialisere normalt. Når porten trækkes tilbage, skub frameldelseattributten tilbage til true, udløb optimizelyEndUserId-cookien og udspred ændringen til eventuelle integrerede analyseplatforme via deres respektive samtykke-API'er.
Serverside-eksperimentering via Decision Service
Optimizely understøtter også serverside-eksperimentering via Decision Service API. Serverside-beslutninger er ikke fritaget for samtykke — det juridiske grundlag følger dataene — men serverside-udførelse giver udgiveren fuld kontrol over, hvilke identifikatorer der udbredes. Det mønster, der virker, er at sende et kortvarigt sessionsidentifikator til Decision Service, når analyseportalen er lukket, og skifte til det persistente identifikator kun når portalen er åben. Varianttildelingerne returneret af Decision Service kan stadig anvendes på den gengivne side; hvad der ændrer sig, er om de er knyttet til en stabil besøgendepost.
Validering af integrationen og revisionssporet
Valideringstrinnet er det, tilsynsmyndigheder kontrollerer, og det udgivere oftest springer over på eksperimenteringsværktøjer. En korrekt integreret Optimizely-implementering skal bestå fire tests i rækkefølge. For det første skal en ren browsersession med banneret vist, men ingen valg truffet, producere nul forespørgsler til logx.optimizely.com ud over SDK-filhentning og nul optimizely-cookies i document.cookie. For det andet skal afvisning af analyse bevare den tilstand — intet persistent identifikator, ingen beslutningshændelse, ingen varianttildeling knyttet til en stabil post. For det tredje skal accept af analyse producere den forventede optimizelyEndUserId-cookie og beslutningshændelsestrafik med varianttildelingen korrekt anvendt. For det fjerde skal tilbagetrækning af samtykke straks stoppe yderligere beslutningshændelser, udløbe cookies og udbrede frameldeingen til eventuelle nedstrømsanalyseintegrationer.
Revisionsforventningen under EDPB's cookiebanner-retningslinjer fra 2023 og de fornyede prioriteter for 2026-taskforcen er, at udgiveren kan bevise, for enhver specifik eksperimentel eksponering i Optimizely-projektet, at den besøgende havde givet gyldigt samtykke på eksponeringstidspunktet. Standardmønsteret er at indstille samtykkeversionen og tidsstemplet som en brugerdefineret attribut på Optimizely-besøgendeprofilen via SDK'ens attribute API, så enhver individuel eksponering er sporbar tilbage til en specifik samtykkelogpost. En korrekt afgrænset implementering, parret med anonym-tilstand-håndtering for præ-samtykke-gengivelsesbeslutninger og en tilbagetrækningssti, der udbredes nedstrøms, er det, der forvandler Optimizely fra en skjult eksperimenteringslag-forpligtelse til en forsvarlig del af en udgivers produkt- og vækststak.