Optimizely Web Experimentation कुकी सहमति एकीकरण मार्गदर्शिका: 2026 में GDPR के तहत A/B परीक्षण
Optimizely सहमति बातचीत के संदर्भ में एक अजीब स्थिति में है। प्रयोग उपकरणों को देखने वाला एक उचित व्यक्ति मान सकता है कि यह एक कम-जोखिम वाली श्रेणी है — परीक्षण इस बारे में है कि कौन सा बटन रंग अधिक क्लिक लाता है, न कि विज़िटर कौन है। वास्तविकता, GDPR द्वारा स्थापित और EDPB द्वारा 2023 से सक्रिय रूप से मज़बूत किए जा रहे ढांचे के तहत, यह है कि प्रयोग ठीक वही प्रोसेसिंग श्रेणियां संलग्न करता है जो विश्लेषण या मार्केटिंग करती हैं जब भी प्लेटफ़ॉर्म एक स्थायी पहचानकर्ता लिखता है और उससे प्रायोगिक वेरिएंट जोड़ता है। Optimizely Web Experimentation SDK ठीक यही करता है: यह एक स्थायी पहचानकर्ता को हैश करके किसी विज़िटर को एक वेरिएंट असाइन करता है, असाइनमेंट को फर्स्ट-पार्टी कुकी में लिखता है ताकि विज़िटर सत्रों में एक ही वेरिएंट देखे, और उस पहचानकर्ता से जुड़े एक्सपोज़र और रूपांतरण ईवेंट उत्सर्जित करता है। इन चरणों में से प्रत्येक एक सहमति गेट सक्रिय करता है। अच्छी खबर यह है कि Optimizely प्रयोग श्रेणी में सबसे विचारशील सहमति एकीकरणों में से एक के साथ आता है, जिसमें एक समर्पित सहमति विशेषता और केवल-अनाम मोड में काम करने की क्षमता शामिल है। काम इसे वास्तव में उपयोग करने में है।
Optimizely Web Experimentation को सहमति की आवश्यकता क्यों है
एक डिफ़ॉल्ट Optimizely प्रारंभिकीकरण पेज के पहले पेंट में कई काम करता है। यह स्थायी विज़िटर पहचानकर्ता वाली optimizelyEndUserId के अंतर्गत एक फर्स्ट-पार्टी कुकी सेट करता है, सक्रिय प्रयोगों के विरुद्ध विज़िटर का मूल्यांकन करता है, optimizelyOptOut नेमस्पेस मार्करों के अंतर्गत दूसरी कुकी में वेरिएंट असाइनमेंट लिखता है, logx.optimizely.com को एक निर्णय ईवेंट फायर करता है, और रेंडर किए गए पेज पर वेरिएंट परिवर्तन लागू करता है। जब ऑपरेटर ने कोई एनालिटिक्स एकीकरण जोड़ा हो — Google Analytics 4, Adobe Analytics, Amplitude, Mixpanel, Heap, या Optimizely Data Platform — तो SDK एनालिटिक्स परत में वेरिएंट-एक्सपोज़र ईवेंट भी फायर करता है, जो फिर वेरिएंट को विज़िटर के व्यापक एनालिटिक्स प्रोफ़ाइल से जोड़ता है।
इन गतिविधियों में से प्रत्येक एक अलग सहमति गेट सक्रिय करती है। विज़िटर पहचानकर्ता को बनाए रखना ePrivacy Directive के Article 5(3) के तहत एक स्टोरेज-एंड-एक्सेस ऑपरेशन है जिसके लिए EEA, UK और उसी मानक को अपनाने वाले किसी भी क्षेत्राधिकार में पूर्व, स्वतंत्र रूप से दी गई, विशिष्ट, सूचित और अस्पष्ट सहमति की आवश्यकता होती है। सत्रों में उस पहचानकर्ता के साथ प्रायोगिक वेरिएंट असाइनमेंट जोड़ना GDPR के तहत व्यक्तिगत डेटा की प्रोसेसिंग है क्योंकि पहचानकर्ता, IP पता, और वेरिएंट एक्सपोज़र का संयोजन एक व्यक्ति को अलग करने और प्रयोग कार्यक्रम के साथ उनकी बातचीत को चिह्नित करने के लिए पर्याप्त है। वेरिएंट डेटा का क्रॉस-टूल प्रसार — उदाहरण के लिए Optimizely Google Analytics को वेरिएंट असाइनमेंट उजागर करना — श्रृंखला में एनालिटिक्स गेट जोड़ता है। EDPB के 2023 के मार्गदर्शन ने स्पष्ट रूप से कहा है कि स्थायी पहचान में संलग्न प्रयोग एनालिटिक्स के समान सहमति नियमों के अधीन है; CNIL इस बिंदु पर सबसे मुखर नियामक रहा है लेकिन अकेला नहीं है।
Optimizely सहमति से पहले क्या लिखता है — और क्या दबाया जाना चाहिए
मानक Optimizely स्निपेट JavaScript SDK को सीधे पेज हेड में इंस्टॉल करता है और लोड पर तुरंत प्रारंभ होता है। यही दस्तावेज़ीकृत क्विकस्टार्ट है और सबसे सामान्य अनुपालन विफलता का स्रोत: SDK कुकी बैनर रेंडर होने से पहले चलता है, optimizelyEndUserId कुकी मिलीसेकंड में लिखी जाती है, वेरिएंट असाइनमेंट किया जाता है, और निर्णय ईवेंट फायर होता है चाहे विज़िटर बाद में जो भी फैसला करे। इस पैटर्न पर फैसला करने वाले प्रत्येक यूरोपीय नियामक ने एक ही तरह से फैसला किया है: सहमति से पहले सेट की गई कुकी अवैध हैं, सहमति से पहले कैप्चर किया गया वेरिएंट असाइनमेंट अवैध प्रोसेसिंग है, और प्रकाशक दायित्व वहन करता है।
इसलिए एक अनुपालन एकीकरण को Optimizely को स्थायी पहचानकर्ता लिखने से और प्रासंगिक सहमति श्रेणी दिए जाने तक निर्णय ईवेंट फायर करने से रोकना चाहिए। Optimizely इसके लिए दो पैटर्न का समर्थन करता है। पहला समर्पित सहमति विशेषता है — OPTIMIZELY_OPT_OUT=true को क्वेरी स्ट्रिंग के रूप में पास करें या SDK प्रारंभिकीकरण से पहले optimizely.opt_out कुकी सेट करें — जो SDK को ऑप्ट-आउट मोड में डालता है जहां कोई पहचानकर्ता नहीं लिखा जाता और कोई ईवेंट फायर नहीं होता। दूसरा SDK कॉन्फ़िगरेशन में समर्थित केवल-अनाम मोड है, जहां SDK एक सत्र-रहित मोड में चलता है जो केवल सत्र-स्थानीय पहचान के आधार पर वेरिएंट असाइन करता है, विज़िट में स्थायी पहचान के बिना। अनाम मोड प्रयोग कार्यक्रम को रेंडरिंग निर्णय के लिए वैध-हित के आधार पर चलाने देता है जबकि सहमति मिलने तक स्थायी पहचान स्थगित करता है।
Optimizely द्वारा लिखी जाने वाली कुकी और स्टोरेज
Optimizely Web Experimentation SDK प्रारंभिकीकरण पर निम्नलिखित पहचानकर्ता लिखता है, ये सभी गैर-आवश्यक हैं और सहमति की आवश्यकता है: स्थायी विज़िटर पहचानकर्ता वाली बहु-वर्षीय समाप्ति के साथ optimizelyEndUserId, ऑप्ट-आउट स्थिति ट्रैक करने वाले optimizelyOptOut मार्कर, क्रॉस-सबडोमेन प्रयोग के लिए optimizelyDomainTestCookie, और जब ऑपरेटर ने क्रॉस-डोमेन पहचान सक्षम की हो तो अतिरिक्त नेमस्पेस कुकी। इसलिए सहमति वापस लेने से कुकी को समाप्त करना और optimizely.push({ type: 'user', attributes: { opt_out: true } }) के माध्यम से SDK को ऑप्ट-आउट मोड में रखना दोनों आवश्यक हैं ताकि आगे के ईवेंट संग्रह को रोका जा सके।
Optimizely को सहमति ढांचों से मैप करना
Optimizely मूल रूप से IAB TCF या IAB Global Privacy Platform लागू नहीं करता — यह एक विज्ञापन-तकनीक विक्रेता नहीं, फर्स्ट-पार्टी प्रयोग प्लेटफ़ॉर्म है — लेकिन यह एक मूल ऑप्ट-आउट API उजागर करता है, Optimizely Data Platform के माध्यम से एक दस्तावेज़ीकृत Consent Mode एकीकरण का समर्थन करता है, और OPTIMIZELY_OPT_OUT विशेषता के माध्यम से प्रकाशक के CMP का सम्मान करता है। नियामक की समीक्षा से जीवित रहने वाला पैटर्न प्रत्येक Optimizely क्षमता को एक विशिष्ट CMP सिग्नल से बंधे एक अलग गेट के रूप में मानता है।
- अनाम प्रयोग सत्र-स्थानीय पहचान के साथ वैध-हित के आधार पर चलाया जा सकता है, जो रेंडरिंग निर्णयों के लिए उपयुक्त है जिनके लिए विज़िट में स्थायी पहचान की आवश्यकता नहीं है और जो डाउनस्ट्रीम एनालिटिक्स में प्रचारित नहीं होते। यह मोड सख्त-आवश्यक या कार्यात्मक श्रेणी से जुड़ा होता है।
- स्थिर पहचानकर्ता के साथ स्थायी प्रयोग एनालिटिक्स उद्देश्य से जुड़ा होता है। TCF शब्दों में यह उद्देश्य 1 के साथ मिलकर उद्देश्य 8 पर मैप होता है; Consent Mode के लिए यह analytics_storage पर मैप होता है।
- क्रॉस-टूल एकीकरण — Google Analytics, Amplitude, या Optimizely Data Platform को प्रचारित वेरिएंट एक्सपोज़र ईवेंट — प्राप्त उपकरण से एनालिटिक्स गेट विरासत में लेते हैं और उस उपकरण का गेट प्रदान न होने पर फायर नहीं होना चाहिए।
- प्रयोग के ऊपर निर्मित वैयक्तिकरण और ऑडियंस-आधारित लक्ष्यीकरण मार्केटिंग गेट को सक्रिय करता है क्योंकि यह प्रायोगिक मापन से उपयोगकर्ता-स्तरीय लक्ष्यीकरण में जाता है।
वह एकीकरण पैटर्न जो काम करता है
संदर्भ तैनाती के चार भाग हैं: एक CMP जो रियल-टाइम सहमति परिवर्तन ईवेंट उजागर करता है, एक विलंबित बूटस्ट्रैप जो Optimizely SDK को ऑप्ट-आउट सक्षम या अनाम मोड सक्रिय के साथ प्रारंभ करता है, एक सहमति श्रोता जो SDK को ऑप्ट-आउट से बाहर कर देता है और एनालिटिक्स गेट खुलने पर स्थायी पहचान शुरू करता है, और एक वापसी पथ जो SDK को ऑप्ट-आउट मोड में वापस डालता है, document.cookie के माध्यम से optimizely कुकी की समय-सीमा समाप्त करता है, और किसी भी डाउनस्ट्रीम एनालिटिक्स एकीकरण में वापसी प्रचारित करता है।
विलंबित बूटस्ट्रैप के साथ वेब कार्यान्वयन
वेब पर सबसे स्वच्छ पैटर्न SDK प्रारंभिकीकरण से पहले window.optimizelyOptOut = true सेट के साथ Optimizely स्निपेट लोड करना है। 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 तैनाती को क्रम में चार परीक्षण पास करने होंगे। पहला, बैनर दिखाए गए लेकिन कोई विकल्प न चुने जाने वाले स्वच्छ ब्राउज़र सत्र में SDK फ़ाइल फेच से परे logx.optimizely.com के लिए शून्य अनुरोध और document.cookie में शून्य optimizely कुकी होनी चाहिए। दूसरा, एनालिटिक्स अस्वीकार करने से वह स्थिति बनाए रखनी चाहिए — कोई स्थायी पहचानकर्ता नहीं, कोई निर्णय ईवेंट नहीं, कोई वेरिएंट असाइनमेंट स्थिर रिकॉर्ड से नहीं जुड़ा। तीसरा, एनालिटिक्स स्वीकार करने से अपेक्षित optimizelyEndUserId कुकी और निर्णय-ईवेंट ट्रैफ़िक उत्पन्न होनी चाहिए, वेरिएंट असाइनमेंट सही ढंग से लागू के साथ। चौथा, सहमति वापस लेने से तुरंत आगे के निर्णय ईवेंट रोकने चाहिए, कुकी की समय-सीमा समाप्त करनी चाहिए, और किसी भी डाउनस्ट्रीम एनालिटिक्स एकीकरण में ऑप्ट-आउट प्रचारित करना चाहिए।
EDPB के 2023 के कुकी बैनर दिशानिर्देशों और नवीनीकृत 2026 टास्क फोर्स प्राथमिकताओं के तहत ऑडिट-ट्रेल अपेक्षा यह है कि प्रकाशक Optimizely परियोजना में किसी भी विशिष्ट प्रायोगिक एक्सपोज़र के लिए साबित कर सके कि एक्सपोज़र के समय विज़िटर ने वैध सहमति दी थी। मानक पैटर्न SDK की attribute API के माध्यम से Optimizely विज़िटर प्रोफ़ाइल पर सहमति संस्करण और टाइमस्टैम्प को एक कस्टम विशेषता के रूप में सेट करना है ताकि कोई भी व्यक्तिगत एक्सपोज़र किसी विशिष्ट सहमति लॉग प्रविष्टि तक ट्रेस करने योग्य हो। एक सही ढंग से गेट की गई तैनाती, सहमति-पूर्व रेंडरिंग निर्णयों के लिए अनाम-मोड हैंडलिंग और डाउनस्ट्रीम प्रचारित होने वाले वापसी पथ के साथ, वही है जो Optimizely को एक छिपी हुई प्रयोग-स्तर देनदारी से प्रकाशक के उत्पाद और विकास स्टैक के एक रक्षाओं भाग में बदलती है।