Integreringsguide för cookie-samtycke i Optimizely Web Experimentation: A/B-testning under GDPR 2026

Optimizely intar en märklig position i samtyckediskussioner. En förnuftig person som tittar på ett experimenteringsverktyg kanske tänker att det är en lågriskategori – testerna handlar om vilken knappfärg som får flest klick, inte vem besökaren är. Men verkligheten under det ramverk som GDPR har fastställt och som EDPB aktivt tillämpat sedan 2023 är att varje gång en plattform skriver en beständig identifierare och kopplar en experimentell variant till den, involverar experimentet exakt samma behandlingskategorier som analys eller marknadsföring. Optimizely Web Experimentation SDK gör precis det: hashar en beständig identifierare för att tilldela besökare till varianter, skriver tilldelningen till en förstapartscookie så att besökare ser samma variant under hela sessionen, och sänder ut visnings- och konverteringshändelser kopplade till den identifieraren. Vart och ett av dessa steg utlöser ett samtyckeskrav. Den goda nyheten är att Optimizely har en av de mest genomtänkta samtyckesintegreringarna i experimentkategorin: ett dedikerat samtyckesattribut och möjligheten att köra i enbart anonymt läge. Utmaningen är att faktiskt använda dem.

Varför Optimizely Web Experimentation kräver samtycke

Optimizelys standardinitiering gör flera saker vid sidans första rendering: ställer in en förstapartscookie under nyckeln optimizelyEndUserId som innehåller en beständig besökaridentifierare; utvärderar besökaren mot aktiva experiment; skriver varianttilldelningen till en andra cookie under nyckeln optimizelyOptOut; skickar en beslutshändelse till logx.optimizely.com; och tillämpar variantändringar på den renderade sidan. Om operatörer kopplar analytikintegreringar – Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap eller Optimizely Data Platform – skickar SDK:n också variantvisningshändelser till analysslagret och kopplar varianten till besökarens bredare analytikprofil.

Var och en av dessa aktiviteter utlöser ett separat samtyckeskrav. Persistens av besökaridentifieraren är en lagrings- och åtkomstoperation under Article 5(3) i ePrivacy-direktivet, som kräver föregående, frivilligt givet, specifikt, informerat och otvetydigt samtycke i EEA, UK och alla jurisdiktioner som har antagit samma standarder. Att binda den experimentella varianttilldelningen till den identifieraren under sessionen är behandling av personuppgifter under GDPR, eftersom kombinationen av identifierare, IP-adress och variantvisning räcker för att identifiera en individ och karakterisera deras interaktioner med experimentprogrammet. Propagering av variantdata mellan verktyg – till exempel när Optimizely skickar en variant till Google Analytics – lägger till ett analysgrindar i kedjan. EDPB:s riktlinjer från 2023 anger uttryckligen att experiment som involverar beständig identifiering är föremål för samma samtyckesregler som analys. CNIL var den mest högljudda tillsynsmyndigheten i denna fråga, men inte den enda.

Vad Optimizely skriver innan samtycke – vad som måste undertryckas

Standard-Optimizely-snippet installerar JavaScript SDK direkt i sidans head och initierar den omedelbart vid laddning. Det är den dokumenterade snabbstarten och den vanligaste orsaken till efterlevnadsfel. SDK:n körs innan cookie-bannern renderas: optimizelyEndUserId-cookien skrivs inom millisekunder, varianttilldelningar görs och beslutshändelser skickas – oavsett vad besökaren sedan beslutar. Varje europeisk tillsynsmyndighet som har granskat detta mönster har kommit till samma slutsats: cookies satta innan samtycke är olagliga; varianttilldelningar fångade innan samtycke är olaglig behandling; och utgivaren är ansvarig.

En kompatibel integrering måste förhindra Optimizely från att skriva beständiga identifierare till cookies och skicka beslutshändelser tills den relevanta samtyckeskategorin har beviljats. Optimizely stöder två mönster för detta. Det första är det dedikerade samtyckesattributet: att skicka OPTIMIZELY_OPT_OUT=true som frågesträng eller ställa in optimizely.opt_out-cookien innan SDK-initiering ställer in SDK:n i avsägningsläge – inga identifierare skrivs, inga händelser skickas. Det andra är enbart anonymt läge, stödd i SDK-konfigurationen: SDK:n arbetar i sessionslöst läge och tilldelar varianter enbart baserat på sessionslokala identifierare utan beständig identifiering mellan besök. Anonymt läge gör det möjligt för experimentprogrammet att köra under legitimate interest-grund för renderingsbeslut och skjuta upp beständig identifiering till samtycke har beviljats.

Cookies och lagring som Optimizely skriver

Optimizely Web Experimentation SDK skriver följande identifierare vid initiering – alla är icke-nödvändiga och kräver samtycke: optimizelyEndUserId, en beständig besökaridentifierare med utgångsdatum på flera år; optimizelyOptOut-markören som spårar avsägningsstatus; optimizelyDomainTestCookie för experiment över subdomäner; och ytterligare namnrymdscookies om operatören har aktiverat domänövergripande identifiering. Återkallelse av samtycke måste utföra både utgång av cookies och ställa in SDK:n i avsägningsläge via optimizely.push({ type: 'user', attributes: { opt_out: true } }), vilket stoppar ytterligare händelseinsamling.

Mappa Optimizely till samtyckesramverk

Optimizely implementerar inte IAB TCF eller IAB Global Privacy Platform nativt – det är en förstapartsexperimenteringsplattform, inte en adtech-leverantör. Men det exponerar ett nativt opt-ut API, stöder en dokumenterad Consent Mode-integrering via Optimizely Data Platform och respekterar utgivarens CMP via attributet OPTIMIZELY_OPT_OUT. Mönstret som överlever regulatorisk granskning behandlar varje Optimizely-funktion som en separat grind kopplad till en specifik CMP-signal.

Fungerande integreringsmönster

Referensimplementationen har fyra delar: en CMP som publicerar samtyckeförändringshändelser i realtid; en fördröjd bootstrap som initierar Optimizely SDK med opt-ut aktiverat eller anonymt läge aktivt; en samtyckeslyssnare som växlar SDK:n från opt-ut till beständig identifiering när analysgrindar öppnas; och en återkallelsestig som returnerar SDK:n till avsägningsläge, låter optimizely-cookies löpa ut via document.cookie och propagerar återkallelsen till nedströms analytikintegreringar.

Webbimplementering med fördröjd bootstrap

På webben är det renaste mönstret att ladda Optimizely-snippet med window.optimizelyOptOut = true ställt in innan SDK-initiering. Prenumerera på CMP samtyckeförändringshändelser. När analytikkategorin övergår till true, anropa window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) och låt SDK:n initiera normalt. När grindar återkallas, återställ opt-ut-attributet till true, låt optimizelyEndUserId-cookien löpa ut och propagera ändringen till integrerade analytikplattformar via deras respektive samtyckes-API:er.

Server-side experiment via Decision Service

Optimizely stöder också server-side experiment via Decision Service API. Server-side beslut är inte undantagna från samtycke – den rättsliga grunden följer data. Men server-side exekvering gör det möjligt för utgivare att ha full kontroll över vilka identifierare som propageras. Det fungerande mönstret är att skicka en efemär sessionsidentifierare till Decision Service när analygrindar är stängd, och bara byta till en beständig identifierare när grindar är öppen. Varianttilldelningar som Decision Service returnerar kan fortfarande tillämpas på den renderade sidan – vad som förändras är om de är kopplade till en stabil besökarpost.

Validera integreringen och revisionsspår

Valideringsstegen är vad regulatoriska myndigheter kontrollerar, och vad utgivare oftast hoppar över i experimenteringsverktyg. En korrekt integrerad Optimizely-implementering måste klara fyra tester i följd. För det första måste en ren webbläsarsession med bannern synlig men utan gjort val visa nolltrafik till logx.optimizely.com bortom SDK-filhämtning, och noll optimizely-cookies i document.cookie. För det andra måste avsägande av analys behålla det tillståndet: inga beständiga identifierare, inga beslutshändelser, inga varianttilldelningar kopplade till stabila poster. För det tredje bör godkännande av analys producera de förväntade optimizelyEndUserId-cookies och beslutshändelsetrafik, med varianttilldelningar korrekt tillämpade. För det fjärde bör återkallelse av samtycke omedelbart stoppa ytterligare beslutshändelser, låta cookies löpa ut och propagera opt-ut till nedströms analytikintegreringar.

Revisionsspårförväntningarna under EDPB:s riktlinjer för cookie-banners från 2023 och de uppdaterade arbetsgruppsprioriteterna från 2026 är att utgivare kan bevisa att besökaren gav giltigt samtycke vid visningstillfället för specifika experimentella visningar i ett Optimizely-projekt. Standardmönstret är att ställa in samtyckesversionen och tidsstämpeln som anpassade attribut i Optimizelys besökarprofil via SDK-attribut-API, så att varje visning kan spåras tillbaka till en specifik samtyckeloggspost. En korrekt säkrad implementering, kombinerad med anonymt läge för pre-samtycke renderingsbeslut och en återkallelsestig som propagerar nedströms, omvandlar Optimizely från en dold experimentlagersskuld till en försvarbar del av utgivarens produkt- och tillväxtstapel.

← Blogg Läs allt →