Panduan Integrasi Persetujuan Kuki Optimizely Web Experimentation: Ujian A/B di Bawah GDPR pada 2026
Optimizely menempati kedudukan yang pelik dalam perbincangan persetujuan. Orang yang waras yang melihat alat eksperimen mungkin beranggapan ini adalah kategori risiko rendah – ujian adalah tentang warna butang mana yang mendapat lebih banyak klik, bukan tentang siapa pelawat itu. Namun realiti di bawah rangka kerja yang ditetapkan oleh GDPR dan dikuatkuasakan secara aktif oleh EDPB sejak 2023 adalah bahawa setiap kali platform menulis pengecam berterusan dan mengikatnya dengan varian eksperimen, eksperimen itu melibatkan kategori pemprosesan yang sama persis seperti analitik atau pemasaran. SDK Optimizely Web Experimentation melakukan tepat itu: mencincang pengecam berterusan untuk menetapkan pelawat kepada varian, menulis penetapan itu ke dalam kuki pihak pertama supaya pelawat melihat varian yang sama sepanjang sesi, dan memancarkan acara tayangan dan penukaran yang dikaitkan dengan pengecam tersebut. Setiap langkah ini mencetuskan syarat persetujuan. Berita baiknya ialah Optimizely mempunyai salah satu integrasi persetujuan yang paling bijaksana dalam kategori eksperimen: atribut persetujuan khusus dan keupayaan untuk beroperasi dalam mod tanpa nama sahaja. Cabarannya ialah menggunakannya dengan sebenarnya.
Mengapa Optimizely Web Experimentation Memerlukan Persetujuan
Permulaan Optimizely lalai melakukan beberapa perkara pada lukisan pertama halaman: menetapkan kuki pihak pertama di bawah kunci optimizelyEndUserId yang mengandungi pengecam pelawat berterusan; menilai pelawat terhadap eksperimen aktif; menulis penetapan varian ke dalam kuki kedua di bawah kunci optimizelyOptOut; mencetuskan acara keputusan ke logx.optimizely.com; dan menerapkan perubahan varian pada halaman yang dilukis. Jika pengendali menyambungkan integrasi analitik – Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap, atau Optimizely Data Platform – SDK juga mencetuskan acara tayangan varian ke lapisan analitik, mengikat varian itu dengan profil analitik pelawat yang lebih luas.
Setiap aktiviti ini mencetuskan syarat persetujuan yang berasingan. Kegigihan pengecam pelawat adalah operasi penyimpanan dan akses di bawah Article 5(3) Arahan ePrivacy, yang memerlukan persetujuan terdahulu, bebas diberikan, khusus, berinformasi, dan tidak samar-samar di EEA, UK, dan semua bidang kuasa yang telah menggunakan standard yang sama. Mengikat penetapan varian eksperimen kepada pengecam itu sepanjang sesi adalah pemprosesan data peribadi di bawah GDPR, kerana kombinasi pengecam, alamat IP, dan tayangan varian sudah mencukupi untuk mengenal pasti individu dan mencirikan interaksi mereka dengan program eksperimen. Pengembangan data varian merentas alat – contohnya apabila Optimizely menyebarkan varian kepada Google Analytics – menambah syarat analitik ke dalam rantaian. Garis panduan EDPB 2023 menyatakan secara eksplisit bahawa eksperimen yang melibatkan pengenalan berterusan tertakluk kepada peraturan persetujuan yang sama seperti analitik. CNIL adalah pihak berkuasa yang paling lantang mengenai perkara ini, tetapi bukan satu-satunya.
Apa yang Ditulis Optimizely Sebelum Persetujuan – Apa yang Perlu Disekat
Coretan Optimizely standard memasang JavaScript SDK terus ke kepala halaman dan memulainya serta-merta semasa pemuatan. Ini adalah cara mula cepat yang didokumenkan dan punca kegagalan pematuhan yang paling biasa. SDK dijalankan sebelum sepanduk kuki dirender: kuki optimizelyEndUserId ditulis dalam milisaat, penetapan varian dibuat, dan acara keputusan dicetuskan – tanpa mengira apa yang pelawat kemudiannya putuskan. Setiap pihak berkuasa kawal selia Eropah yang menilai corak ini sampai kepada kesimpulan yang sama: kuki yang ditetapkan sebelum persetujuan adalah menyalahi undang-undang; penetapan varian yang ditangkap sebelum persetujuan adalah pemprosesan menyalahi undang-undang; dan penerbit bertanggungjawab.
Integrasi yang mematuhi peraturan mesti menghalang Optimizely daripada menulis pengecam berterusan ke kuki dan mencetuskan acara keputusan sehingga kategori persetujuan yang berkaitan diberikan. Optimizely menyokong dua corak untuk tujuan ini. Yang pertama ialah atribut persetujuan khusus: menghantar OPTIMIZELY_OPT_OUT=true sebagai rentetan pertanyaan atau menetapkan kuki optimizely.opt_out sebelum permulaan SDK menetapkan SDK ke dalam mod pilih keluar – tiada pengecam ditulis, tiada acara dicetuskan. Yang kedua ialah mod tanpa nama sahaja yang disokong dalam konfigurasi SDK: SDK beroperasi dalam mod tanpa sesi, menetapkan varian berdasarkan pengecam tempatan sesi sahaja tanpa pengenalan berterusan merentas lawatan. Mod tanpa nama membolehkan program eksperimen beroperasi di bawah asas kepentingan sah untuk keputusan rendering, menangguhkan pengenalan berterusan sehingga persetujuan diberikan.
Kuki dan Penyimpanan yang Ditulis oleh Optimizely
SDK Optimizely Web Experimentation menulis pengecam berikut semasa permulaan – semua ini bukan wajib dan memerlukan persetujuan: optimizelyEndUserId, pengecam pelawat berterusan dengan tempoh tamat tempoh berbilang tahun; penanda optimizelyOptOut yang menjejaki status pilih keluar; optimizelyDomainTestCookie untuk eksperimen merentas subdomain; dan kuki ruang nama tambahan jika pengendali telah mendayakan pengenalan merentas domain. Penarikan persetujuan mesti melakukan kedua-dua kuki tamat tempoh dan menetapkan SDK ke mod pilih keluar melalui optimizely.push({ type: 'user', attributes: { opt_out: true } }), menghentikan pengumpulan acara selanjutnya.
Memetakan Optimizely kepada Rangka Kerja Persetujuan
Optimizely tidak melaksanakan IAB TCF atau IAB Global Privacy Platform secara asli – ia adalah platform eksperimen pihak pertama, bukan vendor adtech. Namun ia mendedahkan API pilih keluar asli, menyokong integrasi Consent Mode yang didokumenkan melalui Optimizely Data Platform, dan menghormati CMP penerbit melalui atribut OPTIMIZELY_OPT_OUT. Corak yang bertahan daripada semakan kawal selia menganggap setiap ciri Optimizely sebagai syarat yang berbeza yang dikaitkan dengan isyarat CMP tertentu.
- Eksperimen tanpa nama boleh beroperasi di bawah asas kepentingan sah dengan pengecam tempatan sesi. Ini sesuai untuk keputusan rendering yang tidak memerlukan pengenalan berterusan merentas lawatan dan tidak menyebarkan kepada analitik hiliran. Mod ini dikaitkan dengan kategori yang ketat diperlukan atau berfungsi.
- Eksperimen berterusan dengan pengecam stabil dikaitkan dengan tujuan analitik. Dalam istilah TCF ini dipetakan kepada Tujuan 8 digabungkan dengan Tujuan 1. Dalam Consent Mode ia dipetakan kepada analytics_storage.
- Integrasi merentas alat (acara tayangan varian yang disebarkan kepada Google Analytics, Amplitude, atau Optimizely Data Platform) mewarisi syarat analitik daripada alat penerima dan tidak harus dicetuskan jika syarat alat tersebut belum diberikan.
- Pemperibadian dan penyasaran berasaskan audiens yang dibina atas eksperimen mencetuskan syarat pemasaran apabila beralih daripada pengukuran eksperimen kepada penyasaran peringkat pengguna.
Corak Integrasi yang Berfungsi
Penempatan rujukan mempunyai empat bahagian: CMP yang menerbitkan acara perubahan persetujuan masa nyata; bootstrap tertunda yang memulakan SDK Optimizely dengan pilih keluar didayakan atau mod tanpa nama aktif; pendengar persetujuan yang menukar SDK daripada pilih keluar kepada pengenalan berterusan apabila syarat analitik dibuka; dan laluan penarikan yang mengembalikan SDK ke mod pilih keluar, menamatkan tempoh kuki optimizely melalui document.cookie, dan menyebarkan penarikan kepada integrasi analitik hiliran.
Pelaksanaan Web dengan Bootstrap Tertunda
Di web, corak yang paling bersih ialah memuatkan coretan Optimizely dengan window.optimizelyOptOut = true yang ditetapkan sebelum permulaan SDK. Langgan acara perubahan persetujuan CMP. Apabila kategori analitik beralih kepada true, panggil window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) dan biarkan SDK memulakan secara normal. Apabila syarat ditarik balik, kembalikan atribut pilih keluar kepada true, tamatkan tempoh kuki optimizelyEndUserId, dan sebarkan perubahan kepada platform analitik yang disepadu melalui API persetujuan masing-masing.
Eksperimen Bahagian Pelayan melalui Decision Service
Optimizely juga menyokong eksperimen bahagian pelayan melalui Decision Service API. Keputusan bahagian pelayan tidak dikecualikan daripada persetujuan – asas undang-undang mengikuti data. Namun pelaksanaan bahagian pelayan membolehkan penerbit mempunyai kawalan penuh ke atas pengecam mana yang disebarkan. Corak yang berfungsi ialah menghantar pengecam sesi sementara kepada Decision Service apabila syarat analitik ditutup, dan hanya beralih kepada pengecam berterusan apabila syarat dibuka. Penetapan varian yang dikembalikan oleh Decision Service masih boleh diterapkan pada halaman yang dirender – yang berubah hanyalah sama ada ia dikaitkan dengan rekod pelawat yang stabil.
Mengesahkan Integrasi dan Jejak Audit
Langkah pengesahan adalah apa yang diperiksa oleh pihak berkuasa kawal selia, dan apa yang paling kerap dilangkau oleh penerbit dalam alat eksperimen. Penempatan Optimizely yang disepadukan dengan betul mesti lulus empat ujian secara berurutan. Pertama, sesi penyemak imbas yang bersih dengan sepanduk dipaparkan tetapi tiada pilihan dibuat harus menunjukkan sifar trafik kepada logx.optimizely.com melebihi pengambilan fail SDK, dan sifar kuki optimizely dalam document.cookie. Kedua, menolak analitik mesti mengekalkan keadaan tersebut: tiada pengecam berterusan, tiada acara keputusan, tiada penetapan varian yang dikaitkan dengan rekod stabil. Ketiga, menerima analitik harus menghasilkan kuki optimizelyEndUserId yang dijangka dan trafik acara keputusan, dengan penetapan varian yang diterapkan dengan betul. Keempat, penarikan persetujuan harus serta-merta menghentikan acara keputusan selanjutnya, menamatkan tempoh kuki, dan menyebarkan pilih keluar kepada integrasi analitik hiliran.
Jangkaan jejak audit di bawah garis panduan sepanduk kuki EDPB 2023 dan keutamaan pasukan petugas yang dikemas kini 2026 adalah bahawa penerbit dapat membuktikan pelawat memberikan persetujuan yang sah pada masa tayangan untuk tayangan eksperimen tertentu dalam projek Optimizely. Corak standard ialah menetapkan versi persetujuan dan cap masa sebagai atribut tersuai dalam profil pelawat Optimizely melalui API atribut SDK, supaya setiap tayangan boleh dijejak kepada entri log persetujuan tertentu. Penempatan yang dipagari dengan betul, digabungkan dengan mod tanpa nama untuk keputusan rendering pra-persetujuan dan laluan penarikan yang menyebarkan ke hilir, mengubah Optimizely daripada hutang lapisan eksperimen tersembunyi kepada bahagian yang boleh dipertahankan tumpukan produk dan pertumbuhan penerbit.