เหตุใด Optimizely Web Experimentation จึงต้องการความยินยอม

การเริ่มต้น Optimizely ตามค่าเริ่มต้นทำหลายอย่างในการแสดงผลครั้งแรกของหน้า: ตั้งค่าคุกกี้ฝ่ายแรกภายใต้คีย์ optimizelyEndUserId ที่มีตัวระบุผู้เยี่ยมชมถาวร; ประเมินผู้เยี่ยมชมเทียบกับการทดลองที่ใช้งานอยู่; เขียนการกำหนดตัวแปรลงในคุกกี้ที่สองภายใต้คีย์ optimizelyOptOut; ส่งเหตุการณ์การตัดสินใจไปยัง logx.optimizely.com; และใช้การเปลี่ยนแปลงตัวแปรกับหน้าที่แสดงผล หากผู้ดำเนินการเชื่อมต่อการรวมการวิเคราะห์ เช่น Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap หรือ Optimizely Data Platform SDK จะส่งเหตุการณ์การแสดงผลตัวแปรไปยังชั้นการวิเคราะห์ด้วย โดยเชื่อมโยงตัวแปรกับโปรไฟล์การวิเคราะห์ที่กว้างขึ้นของผู้เยี่ยมชม

แต่ละกิจกรรมเหล่านี้เรียกใช้ข้อกำหนดความยินยอมแยกกัน ความคงอยู่ของตัวระบุผู้เยี่ยมชมเป็นการดำเนินการจัดเก็บและเข้าถึงภายใต้ Article 5(3) ของ Directive ePrivacy ที่ต้องการความยินยอมล่วงหน้า ให้โดยเสรี เฉพาะเจาะจง มีข้อมูล และชัดเจนใน EEA, UK และทุกเขตอำนาจที่นำมาตรฐานเดียวกันมาใช้ การผูกมัดการกำหนดตัวแปรทดลองกับตัวระบุนั้นตลอดเซสชันเป็นการประมวลผลข้อมูลส่วนบุคคลภายใต้ GDPR เพราะการรวมกันของตัวระบุ ที่อยู่ IP และการแสดงผลตัวแปรเพียงพอต่อการระบุตัวบุคคลและอธิบายลักษณะการโต้ตอบกับโปรแกรมทดลอง การเผยแพร่ข้อมูลตัวแปรระหว่างเครื่องมือ เช่น เมื่อ Optimizely ส่งตัวแปรไปยัง Google Analytics จะเพิ่มเกตการวิเคราะห์เข้าไปในห่วงโซ่ แนวทางของ EDPB ปี 2023 ระบุอย่างชัดเจนว่าการทดลองที่เกี่ยวข้องกับการระบุตัวตนถาวรอยู่ภายใต้กฎความยินยอมเดียวกับการวิเคราะห์ CNIL เป็นหน่วยงานกำกับดูแลที่พูดออกมาดังที่สุดในประเด็นนี้ แต่ไม่ใช่เพียงแห่งเดียว

สิ่งที่ Optimizely เขียนก่อนได้รับความยินยอม สิ่งที่ต้องระงับ

ส่วนของ Optimizely มาตรฐานติดตั้ง JavaScript SDK โดยตรงในส่วน head ของหน้าและเริ่มต้นทันทีเมื่อโหลด นี่คือ quickstart ที่มีเอกสารและสาเหตุที่พบบ่อยที่สุดของความล้มเหลวด้านการปฏิบัติตาม SDK จะทำงานก่อนที่แบนเนอร์คุกกี้จะแสดงผล: คุกกี้ optimizelyEndUserId ถูกเขียนภายในมิลลิวินาที การกำหนดตัวแปรเกิดขึ้น และเหตุการณ์การตัดสินใจถูกส่ง โดยไม่คำนึงถึงสิ่งที่ผู้เยี่ยมชมตัดสินใจในภายหลัง หน่วยงานกำกับดูแลของยุโรปทุกแห่งที่ประเมินรูปแบบนี้ได้ข้อสรุปเดียวกัน: คุกกี้ที่ตั้งค่าก่อนความยินยอมเป็นสิ่งผิดกฎหมาย การกำหนดตัวแปรที่จับก่อนความยินยอมเป็นการประมวลผลที่ผิดกฎหมาย และผู้เผยแพร่เป็นผู้รับผิดชอบ

การรวมที่ปฏิบัติตามต้องป้องกันไม่ให้ Optimizely เขียนตัวระบุถาวรลงในคุกกี้และส่งเหตุการณ์การตัดสินใจจนกว่าจะได้รับหมวดหมู่ความยินยอมที่เกี่ยวข้อง Optimizely รองรับสองรูปแบบสำหรับสิ่งนี้ อันแรกคือแอตทริบิวต์ความยินยอมเฉพาะ: การส่ง OPTIMIZELY_OPT_OUT=true เป็น query string หรือตั้งค่าคุกกี้ optimizely.opt_out ก่อนการเริ่มต้น SDK ตั้งค่า SDK เป็นโหมดไม่ยินยอม ไม่มีตัวระบุถูกเขียน ไม่มีเหตุการณ์ถูกส่ง อันที่สองคือโหมดไม่ระบุตัวตนเท่านั้น ที่รองรับในการกำหนดค่า SDK: SDK ทำงานในโหมดไม่มีเซสชัน โดยกำหนดตัวแปรตามตัวระบุในเซสชันเท่านั้นโดยไม่มีการระบุตัวตนถาวรข้ามการเยี่ยมชม โหมดไม่ระบุตัวตนช่วยให้โปรแกรมทดลองทำงานภายใต้ฐานประโยชน์อันชอบธรรมสำหรับการตัดสินใจแสดงผล โดยเลื่อนการระบุตัวตนถาวรออกไปจนกว่าจะได้รับความยินยอม

คุกกี้และพื้นที่จัดเก็บที่ Optimizely เขียน

SDK ของ Optimizely Web Experimentation เขียนตัวระบุต่อไปนี้ในการเริ่มต้น ทั้งหมดเป็นส่วนที่ไม่จำเป็นและต้องการความยินยอม: optimizelyEndUserId ตัวระบุผู้เยี่ยมชมถาวรที่มีวันหมดอายุหลายปี; เครื่องหมาย optimizelyOptOut ที่ติดตามสถานะการไม่ยินยอม; optimizelyDomainTestCookie สำหรับการทดลองข้ามซับโดเมน; และคุกกี้ namespace เพิ่มเติมหากผู้ดำเนินการเปิดใช้งานการระบุตัวตนข้ามโดเมน การเพิกถอนความยินยอมต้องทำทั้งการหมดอายุของคุกกี้และตั้งค่า SDK เป็นโหมดไม่ยินยอมผ่าน optimizely.push({ type: 'user', attributes: { opt_out: true } }) เพื่อหยุดการรวบรวมเหตุการณ์เพิ่มเติม

การแมป Optimizely กับ Consent Framework

Optimizely ไม่ได้ใช้งาน IAB TCF หรือ IAB Global Privacy Platform โดยกำเนิด เป็นแพลตฟอร์มทดลองฝ่ายแรก ไม่ใช่ผู้จำหน่าย adtech แต่เปิดเผย API สำหรับการไม่ยินยอมโดยกำเนิด รองรับการรวม Consent Mode ที่มีเอกสารผ่าน Optimizely Data Platform และเคารพ CMP ของผู้เผยแพร่ผ่านแอตทริบิวต์ OPTIMIZELY_OPT_OUT รูปแบบที่ผ่านการตรวจสอบด้านกฎระเบียบปฏิบัติต่อฟีเจอร์ Optimizely แต่ละอย่างเป็นเกตแยกที่เชื่อมโยงกับสัญญาณ CMP เฉพาะ

• การทดลองแบบไม่ระบุตัวตน สามารถทำงานภายใต้ฐานประโยชน์อันชอบธรรมด้วยตัวระบุในเซสชัน เหมาะสำหรับการตัดสินใจแสดงผลที่ไม่ต้องการการระบุตัวตนถาวรข้ามการเยี่ยมชมและไม่เผยแพร่ไปยังการวิเคราะห์ดาวน์สตรีม โหมดนี้เชื่อมโยงกับหมวดหมู่ที่จำเป็นอย่างเคร่งครัดหรือเพื่อการทำงาน
• การทดลองถาวรที่มีตัวระบุเสถียร เชื่อมโยงกับวัตถุประสงค์การวิเคราะห์ ในคำศัพท์ TCF จะแมปกับ Purpose 8 รวมกับ Purpose 1 ใน Consent Mode แมปกับ analytics_storage
• การรวมข้ามเครื่องมือ (เหตุการณ์การแสดงผลตัวแปรที่เผยแพร่ไปยัง Google Analytics, Amplitude หรือ Optimizely Data Platform) รับสืบทอดเกตการวิเคราะห์จากเครื่องมือที่รับและไม่ควรส่งหากเกตของเครื่องมือนั้นยังไม่ได้รับอนุมัติ
• การปรับแต่งและการกำหนดเป้าหมายตามกลุ่มผู้ชม ที่สร้างบนการทดลองจะเรียกใช้เกตการตลาดเมื่อเปลี่ยนจากการวัดผลทดลองไปยังการกำหนดเป้าหมายระดับผู้ใช้

รูปแบบการรวมที่ใช้งานได้

การติดตั้งอ้างอิงมีสี่ส่วน: CMP ที่เผยแพร่เหตุการณ์การเปลี่ยนแปลงความยินยอมแบบเรียลไทม์; bootstrap ที่ล่าช้าที่เริ่มต้น SDK ของ Optimizely โดยเปิดใช้งานการไม่ยินยอมหรือโหมดไม่ระบุตัวตนที่ใช้งานอยู่; ผู้ฟังความยินยอมที่สลับ SDK จากการไม่ยินยอมไปยังการระบุตัวตนถาวรเมื่อเกตการวิเคราะห์เปิด; และเส้นทางการเพิกถอนที่ส่ง SDK กลับไปยังโหมดไม่ยินยอม ทำให้คุกกี้ optimizely หมดอายุผ่าน document.cookie และเผยแพร่การเพิกถอนไปยังการรวมการวิเคราะห์ดาวน์สตรีม

การใช้งานเว็บด้วย Bootstrap ที่ล่าช้า

บนเว็บ รูปแบบที่สะอาดที่สุดคือโหลดส่วนของ Optimizely ด้วย window.optimizelyOptOut = true ที่ตั้งค่าก่อนการเริ่มต้น SDK สมัครรับเหตุการณ์การเปลี่ยนแปลงความยินยอมของ CMP เมื่อหมวดหมู่การวิเคราะห์เปลี่ยนเป็น true ให้เรียก window.optimizely.push({ type: 'user', attributes: { opt_out: false } }) และให้ SDK เริ่มต้นตามปกติ เมื่อเกตถูกเพิกถอน ให้เปลี่ยนแอตทริบิวต์การไม่ยินยอมกลับเป็น true ทำให้คุกกี้ optimizelyEndUserId หมดอายุ และเผยแพร่การเปลี่ยนแปลงไปยังแพลตฟอร์มการวิเคราะห์ที่รวมไว้ผ่าน API ความยินยอมตามลำดับ

การทดลองฝั่งเซิร์ฟเวอร์ผ่าน Decision Service

Optimizely ยังรองรับการทดลองฝั่งเซิร์ฟเวอร์ผ่าน Decision Service API การตัดสินใจฝั่งเซิร์ฟเวอร์ไม่ได้รับการยกเว้นจากความยินยอม ฐานทางกฎหมายตามข้อมูล แต่การดำเนินการฝั่งเซิร์ฟเวอร์ช่วยให้ผู้เผยแพร่มีการควบคุมเต็มที่ว่าตัวระบุใดถูกเผยแพร่ รูปแบบที่ใช้งานได้คือการส่งตัวระบุเซสชันชั่วคราวไปยัง Decision Service เมื่อเกตการวิเคราะห์ปิด และเปลี่ยนเป็นตัวระบุถาวรเมื่อเกตเปิดเท่านั้น การกำหนดตัวแปรที่ส่งคืนโดย Decision Service ยังคงสามารถใช้กับหน้าที่แสดงผลได้ สิ่งที่เปลี่ยนคือว่าเชื่อมโยงกับบันทึกผู้เยี่ยมชมที่เสถียรหรือไม่

การตรวจสอบการรวมและเส้นทางการตรวจสอบ

ขั้นตอนการตรวจสอบคือสิ่งที่หน่วยงานกำกับดูแลตรวจสอบ และสิ่งที่ผู้เผยแพร่มักข้ามในเครื่องมือทดลอง การติดตั้ง Optimizely ที่รวมอย่างถูกต้องต้องผ่านการทดสอบสี่รายการตามลำดับ ประการแรก เซสชันเบราว์เซอร์ที่สะอาดที่มีแบนเนอร์ปรากฏแต่ไม่มีการเลือก ต้องแสดงการรับส่งข้อมูลเป็นศูนย์ไปยัง logx.optimizely.com เกินกว่าการดึงไฟล์ SDK และคุกกี้ optimizely เป็นศูนย์ใน document.cookie ประการที่สอง การปฏิเสธการวิเคราะห์ต้องคงสถานะนั้น: ไม่มีตัวระบุถาวร ไม่มีเหตุการณ์การตัดสินใจ ไม่มีการกำหนดตัวแปรที่เชื่อมโยงกับบันทึกที่เสถียร ประการที่สาม การยอมรับการวิเคราะห์ควรสร้างคุกกี้ optimizelyEndUserId ที่คาดหวังและการรับส่งข้อมูลเหตุการณ์การตัดสินใจ โดยการกำหนดตัวแปรถูกใช้อย่างถูกต้อง ประการที่สี่ การเพิกถอนความยินยอมควรหยุดเหตุการณ์การตัดสินใจเพิ่มเติมทันที ทำให้คุกกี้หมดอายุ และเผยแพร่การไม่ยินยอมไปยังการรวมการวิเคราะห์ดาวน์สตรีม

ความคาดหวังของเส้นทางการตรวจสอบภายใต้แนวทางแบนเนอร์คุกกี้ของ EDPB ปี 2023 และลำดับความสำคัญของคณะทำงานที่อัปเดตปี 2026 คือผู้เผยแพร่สามารถพิสูจน์ได้ว่าผู้เยี่ยมชมให้ความยินยอมที่ถูกต้องในขณะที่แสดงผลสำหรับการแสดงผลทดลองเฉพาะในโปรเจกต์ Optimizely รูปแบบมาตรฐานคือตั้งค่าเวอร์ชันความยินยอมและการประทับเวลาเป็นแอตทริบิวต์ที่กำหนดเองในโปรไฟล์ผู้เยี่ยมชมของ Optimizely ผ่าน SDK attributes API เพื่อให้การแสดงผลแต่ละครั้งสามารถติดตามกลับไปยังรายการบันทึกความยินยอมเฉพาะ การติดตั้งที่ควบคุมอย่างถูกต้อง รวมกับโหมดไม่ระบุตัวตนสำหรับการตัดสินใจแสดงผลก่อนได้รับความยินยอม และเส้นทางการเพิกถอนที่เผยแพร่ดาวน์สตรีม จะเปลี่ยน Optimizely จากหนี้สินชั้นการทดลองที่ซ่อนอยู่ให้เป็นส่วนที่สามารถปกป้องได้ของสแต็กผลิตภัณฑ์และการเติบโตของผู้เผยแพร่