Bakit kailangan ng Optimizely Web Experimentation ng pahintulot

Ang isang default na Optimizely initialization ay gumagawa ng ilang bagay sa unang paint ng pahina. Nagtatakda ito ng first-party na cookie sa ilalim ng optimizelyEndUserId na naglalaman ng persistent na identifier ng bisita, sinusuri ang bisita laban sa mga aktibong eksperimento, isinusulat ang mga pagtatalaga ng variant sa isang pangalawang cookie sa ilalim ng mga marker ng namespace ng optimizelyOptOut, nagpapalabas ng kaganapan ng desisyon sa logx.optimizely.com, at inilalapat ang mga pagbabago ng variant sa render na pahina. Kapag nakakonekta ang operator ng integrasyon ng analytics — Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap, o ang Optimizely Data Platform — nagpapalabas din ang SDK ng mga kaganapan ng variant-exposure sa analytics layer, na pagkatapos ay nagtatali ng variant sa mas malawak na analytics profile ng bisita.

Bawat isa sa mga aktibidad na iyon ay nagpapalitaw ng hiwalay na pintuan ng pahintulot. Ang pagpapanatili ng identifier ng bisita ay isang operasyon ng pag-iimbak at pag-access sa ilalim ng Article 5(3) ng ePrivacy Directive na nangangailangan ng naunang, kusang-loob, tiyak, impormatibo at hindi malabong pahintulot sa EEA, UK, at anumang hurisdiksyon na nag-import ng parehong pamantayan. Ang pagtali ng mga pagtatalaga ng eksperimentong variant sa identifier na iyon sa mga session ay pagpoproseso ng personal na data sa ilalim ng GDPR dahil ang kombinasyon ng identifier, IP address, at variant exposure ay sapat para matukoy ang isang indibidwal at makilala ang kanilang pakikipag-ugnayan sa programa ng eksperimento. Ang cross-tool na pagpapalaganap ng data ng variant — halimbawa, ang Optimizely ay inilalantad ang pagtatalaga ng variant sa Google Analytics — ay nagdaragdag ng analytics gate sa kadena. Ang gabay ng EDPB noong 2023 ay malinaw na nagsabi na ang eksperimento na gumagamit ng persistent na pagkakakilanlan ay napapailalim sa parehong mga patakaran ng pahintulot tulad ng analytics; ang CNIL ang pinakamaingay na regulator sa puntong ito ngunit hindi nag-iisa.

Ano ang isinusulat ng Optimizely bago ang pahintulot — at ano ang dapat sugpuin

Ang karaniwang snippet ng Optimizely ay nag-i-install ng JavaScript SDK nang direkta sa head ng pahina at agad na nagpapasimula sa pag-load. Iyon ang dokumentadong quickstart at ang pinagmulan ng pinakakaraniwang pagkabigo sa pagsunod: ang SDK ay tumatakbo bago ma-render ang banner ng cookie, ang cookie na optimizelyEndUserId ay isinusulat sa loob ng mga millisecond, ang pagtatalaga ng variant ay ginagawa, at ang kaganapan ng desisyon ay pinapalabas anuman ang mapagpasyahan ng bisita sa bandang huli. Bawat regulador ng Europa na nagpasya sa pattern na ito ay nagpasya sa parehong paraan: ang mga cookie na itinakda bago ang pahintulot ay labag sa batas, ang pagtatalaga ng variant na nakuha bago ang pahintulot ay labag sa batas na pagpoproseso, at tinatanggap ng publisher ang pananagutan.

Ang isang sumusunod na integrasyon ay dapat na pigilan ang Optimizely mula sa pagsulat ng persistent na identifier at pagpapalabas ng mga kaganapan ng desisyon hanggang sa ibigay ang kaugnay na kategorya ng pahintulot. Sinusuportahan ng Optimizely ang dalawang pattern para dito. Ang una ay ang dedikadong katangian ng pahintulot — ipasa ang OPTIMIZELY_OPT_OUT=true bilang query string o itakda ang cookie na optimizely.opt_out bago ang SDK initialization — na naglalagay sa SDK sa opt-out mode kung saan walang identifier ang isinusulat at walang kaganapan ang pinapalabas. Ang pangalawa ay ang anonymous-only na mode na sinusuportahan sa SDK configuration, kung saan ang SDK ay tumatakbo sa isang walang-session na mode na nagtatalaga ng mga variant batay sa session-local na pagkakakilanlan lamang, nang walang persistent na pagkakakilanlan sa mga pagbisita. Pinapahintulutan ng anonymous mode ang programa ng eksperimento na tumakbo sa ilalim ng batayan ng legitimate interest para sa desisyon ng pag-render habang ipinagpaliban ang persistent na pagkakakilanlan hanggang sa maibigay ang pahintulot.

Ang mga cookie at storage na isinusulat ng Optimizely

Ang Optimizely Web Experimentation SDK ay nagsusulat ng mga sumusunod na identifier sa initialization, lahat ay hindi mahahalagang at nangangailangan ng pahintulot: optimizelyEndUserId na may multi-year na expiry na naglalaman ng persistent na identifier ng bisita, mga marker ng optimizelyOptOut na nagsusubaybay ng estado ng opt-out, optimizelyDomainTestCookie para sa cross-subdomain na eksperimento, at karagdagang mga namespace cookie kapag pinagana ng operator ang cross-domain na pagkakakilanlan. Ang pag-withdraw ng pahintulot ay dapat samakatuwid ay mag-expire ng mga cookie at ilagay ang SDK sa opt-out mode sa pamamagitan ng optimizely.push({ type: 'user', attributes: { opt_out: true } }) upang ihinto ang karagdagang koleksyon ng kaganapan.

Pagmamapa ng Optimizely sa mga balangkas ng pahintulot

Ang Optimizely ay hindi natively nagpapatupad ng IAB TCF o ng IAB Global Privacy Platform — ito ay isang first-party na platform ng eksperimento, hindi isang vendor ng ad-tech — ngunit naglalantad ito ng isang native na opt-out API, sumusuporta sa isang dokumentadong Consent Mode integration sa pamamagitan ng Optimizely Data Platform, at iginagalang ang CMP ng publisher sa pamamagitan ng katangian ng OPTIMIZELY_OPT_OUT. Ang pattern na nakakaligtas sa pagsusuri ng regulator ay tinatrato ang bawat kakayahan ng Optimizely bilang isang hiwalay na pintuan na nakatali sa isang tiyak na signal ng CMP.

• Ang Anonymous na eksperimento ay maaaring tumakbo sa ilalim ng batayan ng legitimate interest na may session-local na pagkakakilanlan, na angkop para sa mga desisyon sa pag-render na hindi nangangailangan ng persistent na pagkakakilanlan sa mga pagbisita at hindi nagpapakalat sa downstream na analytics. Ang mode na ito ay nakatali sa strictly-necessary o functional na kategorya.
• Ang Persistent na eksperimento na may matatag na identifier ay nakatali sa layuning analytics. Sa mga terminong TCF ito ay nagmamapa sa layunin 8 na pinagsama sa layunin 1; para sa Consent Mode ito ay nagmamapa sa analytics_storage.
• Ang Cross-tool na integrasyon — mga kaganapan ng variant exposure na ipinagkalat sa Google Analytics, Amplitude, o ang Optimizely Data Platform — ay nagmamana ng analytics gate mula sa tumatanggap na kasangkapan at hindi dapat mag-fire kung hindi ibinigay ang pintuan ng kasangkapan na iyon.
• Ang Personalisasyon at audience-based na pag-target na itinayo sa ibabaw ng eksperimento ay nagpapalitaw ng marketing gate dahil ito ay lumagpas mula sa eksperimentong sukat patungo sa pag-target sa antas ng gumagamit.

Ang pattern ng integrasyon na gumagana

Ang reference deployment ay may apat na bahagi: isang CMP na naglalantad ng real-time na kaganapan ng pagbabago ng pahintulot, isang deferred bootstrap na nagpapasimula ng Optimizely SDK na may opt-out na pinagana o aktibong anonymous mode, isang listener ng pahintulot na nagbabalik ng SDK mula sa opt-out at nagsisimula ng persistent na pagkakakilanlan kapag bumukas ang analytics gate, at isang withdrawal path na naglalagay ng SDK pabalik sa opt-out mode, nag-e-expire ng mga cookie ng optimizely sa pamamagitan ng document.cookie, at nagpapakalat ng pag-withdraw sa anumang downstream na integrasyon ng analytics.

Implementasyon sa web na may deferred bootstrap

Sa web ang pinaka-malinis na pattern ay ang i-load ang Optimizely snippet na may window.optimizelyOptOut = true na itinakda bago ang SDK initialization. Mag-subscribe sa kaganapan ng pagbabago ng pahintulot ng CMP. Kapag ang kategorya ng analytics ay lumipat sa true, tawagan ang window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) at hayaang mag-initialize ang SDK nang normal. Kapag ang gate ay nag-withdraw, itulak pabalik ang katangian ng opt-out sa true, i-expire ang cookie na optimizelyEndUserId, at ipalaganap ang pagbabago sa anumang integrated na platform ng analytics sa pamamagitan ng kanilang kani-kanilang consent API.

Server-side na eksperimento sa pamamagitan ng Decision Service

Sinusuportahan din ng Optimizely ang server-side na eksperimento sa pamamagitan ng Decision Service API. Ang mga desisyon sa server-side ay hindi exempted mula sa pahintulot — ang legal na batayan ay sumusunod sa data — ngunit ang server-side na pagpapatupad ay nagbibigay sa publisher ng ganap na kontrol sa kung aling mga identifier ang ipinagpapakalat. Ang pattern na gumagana ay ang magpasa ng isang ephemeral na session identifier sa Decision Service kapag ang analytics gate ay sarado, at lumipat sa persistent na identifier lamang kapag ang gate ay bukas. Ang mga pagtatalaga ng variant na ibinalik ng Decision Service ay maaari pa ring ilapat sa render na pahina; ang nagbabago ay kung sila ay nakatali sa isang matatag na rekord ng bisita.

Pag-validate ng integrasyon at ng audit trail

Ang hakbang sa pag-validate ay kung ano ang sinusuri ng mga regulator at kung ano ang pinaka-madalas na nilalaktawan ng mga publisher sa mga kasangkapan ng eksperimento. Ang isang tamang integrated na deployment ng Optimizely ay dapat pumasa sa apat na pagsubok nang sunud-sunod. Una, ang isang malinis na session ng browser na may ipinakitang banner ngunit walang pagpili na ginawa ay dapat gumaawa ng zero na mga kahilingan sa logx.optimizely.com lampas sa SDK file fetch at zero na mga cookie ng optimizely sa document.cookie. Pangalawa, ang pagtanggi sa analytics ay dapat panatilihin ang estado na iyon — walang persistent na identifier, walang kaganapan ng desisyon, walang pagtatalaga ng variant na nakatali sa isang matatag na rekord. Pangatlo, ang pagtanggap ng analytics ay dapat gumawa ng inaasahang cookie ng optimizelyEndUserId at trapiko ng kaganapan ng desisyon, na may tamang pagtatalaga ng variant na inilapat. Pang-apat, ang pag-withdraw ng pahintulot ay dapat agad na itigil ang karagdagang mga kaganapan ng desisyon, mag-expire ng mga cookie, at ipalaganap ang opt-out sa anumang downstream na integrasyon ng analytics.

Ang inaasahan sa audit trail sa ilalim ng mga alituntunin ng EDPB na cookie banner noong 2023 at ang mga na-renew na priyoridad ng task force ng 2026 ay ang publisher ay maaaring patunayan, para sa anumang tiyak na eksperimentong exposure sa proyekto ng Optimizely, na ang bisita ay nagbigay ng wastong pahintulot sa sandali ng exposure. Ang karaniwang pattern ay ang itakda ang bersyon ng pahintulot at timestamp bilang isang custom na katangian sa profile ng bisita ng Optimizely sa pamamagitan ng attribute API ng SDK upang ang anumang indibidwal na exposure ay masusubaybayan pabalik sa isang tiyak na entry sa log ng pahintulot. Ang isang tamang naka-gate na deployment, kasama ang anonymous-mode na paghawak para sa mga desisyon sa pag-render bago ang pahintulot at isang withdrawal path na nagpapakalat sa downstream, ay kung ano ang nagbabago ng Optimizely mula sa isang nakatagong pananagutan sa antas ng eksperimento patungo sa isang mapagtatanggol na bahagi ng produkto at growth stack ng publisher.