सहमति कहाँ सहेजें: कुकीज़, localStorage और सर्वर-साइड रिकॉर्ड की तुलना
दो अलग काम
जब कोई विज़िटर सहमति का चुनाव करता है, तो दो अलग चीज़ें होनी चाहिए। पहली, ब्राउज़र को चुनाव याद रखना होता है ताकि बैनर हर पेज पर दोबारा न आए और टैग जान सकें कि उन्हें क्या करने की अनुमति है। दूसरी, आपको बाद में साबित करना पड़ सकता है कि चुनाव किया गया था, विज़िटर को क्या दिखाया गया था, और कब। इन कामों को अक्सर अलग स्टोरेज तंत्र संभालते हैं, और इन्हें आपस में उलझाने से वास्तविक समस्याएँ होती हैं: बार-बार लौटते बैनर, कुछ ब्राउज़रों पर गायब हो जाते चुनाव, या किसी के पूछने पर दिखाने के लिए कोई रिकॉर्ड न होना।
यह तुलना तीन आम विकल्पों को देखती है — फ़र्स्ट-पार्टी कुकीज़, localStorage जैसा ब्राउज़र स्टोरेज, और सर्वर-साइड सहमति रिकॉर्ड — और यह कि हर एक कहाँ उपयुक्त बैठता है।
विकल्प 1: फ़र्स्ट-पार्टी कुकीज़
कुकीज़ सहमति स्थिति का पारंपरिक घर हैं। TCF CMP आमतौर पर सहमति स्ट्रिंग को फ़र्स्ट-पार्टी कुकी में सहेजते हैं, और कई CMP अपना प्रेफ़रेंस डेटा भी उसी में रखते हैं।
ताक़तें
- सर्वर द्वारा पढ़ने योग्य। कुकी हर अनुरोध के साथ भेजी जाती है, इसलिए सर्वर-साइड कोड, एज लॉजिक और सर्वर-साइड टैगिंग JavaScript की प्रतीक्षा किए बिना चुनाव पढ़ सकते हैं।
- सबडोमेन में साझा करने योग्य। आपके रजिस्टर करने योग्य डोमेन पर सेट की गई कुकी www, blog और shop सबडोमेन को कवर कर सकती है।
- व्यापक रूप से अपेक्षित। कई ऐड टेक इंटीग्रेशन सहमति को कुकीज़ में खोजते हैं।
कमज़ोरियाँ
- आकार की सीमाएँ। ब्राउज़र कुकी का आकार लगभग 4 KB पर सीमित करते हैं, और कई वेंडरों वाली TCF स्ट्रिंग अन्य मानों के साथ इसके क़रीब पहुँच सकती है।
- अनुरोध का अतिरिक्त भार। आपके डोमेन पर हर अनुरोध कुकी साथ ले जाता है, इमेज और स्क्रिप्ट अनुरोधों सहित।
- कुछ ब्राउज़रों में अवधि की सीमाएँ। Safari की Intelligent Tracking Prevention JavaScript से बनी कुकीज़ की अधिकतम अवधि सात दिन तक सीमित करती है। HTTP रिस्पॉन्स में आपके अपने सर्वर द्वारा सेट की गई कुकीज़ के साथ आमतौर पर अधिक उदारता बरती जाती है, हालाँकि अपवाद हैं।
विकल्प 2: localStorage और अन्य ब्राउज़र स्टोरेज
कुछ CMP विस्तृत प्राथमिकताएँ localStorage में सहेजते हैं, कभी-कभी एक छोटी कुकी के साथ।
ताक़तें
- अधिक जगह। प्रति ऑरिजिन कई मेगाबाइट, वेंडर-स्तर के विस्तृत चुनावों के लिए पर्याप्त।
- अनुरोध का अतिरिक्त भार नहीं। सर्वर को अपने आप कुछ नहीं भेजा जाता।
कमज़ोरियाँ
- सर्वर को अदृश्य। सर्वर-साइड कोड और एज लॉजिक इसे पढ़ नहीं सकते, इसलिए कोई भी सर्वर-साइड निर्णय ब्राउज़र की प्रतीक्षा करेगा।
- एक ऑरिजिन से बँधा। www.example.com पर स्टोरेज shop.example.com पर उपलब्ध नहीं है, इसलिए विज़िटर को हर सबडोमेन पर बैनर फिर दिख सकता है।
- हटाए जाने के अधीन। Safari उन साइटों के लिए localStorage सहित स्क्रिप्ट द्वारा लिखने योग्य स्टोरेज हटा सकता है जिनसे उपयोगकर्ता ने ब्राउज़र उपयोग के सात दिनों तक इंटरैक्ट नहीं किया, और प्राइवेट ब्राउज़िंग मोड आमतौर पर सत्र समाप्त होने पर उसे साफ़ कर देते हैं।
विकल्प 3: सर्वर-साइड सहमति रिकॉर्ड
सर्वर-साइड रिकॉर्ड वह प्रविष्टि है जिसे आप या आपका CMP प्रदाता हर चुनाव के समय सहेजता है। इसमें आमतौर पर एक छद्मनामित आइडेंटिफ़ायर, टाइमस्टैम्प, चुनाव, दिखाया गया बैनर या नीति संस्करण, और क्षेत्र जैसा संदर्भ होता है।
ताक़तें
- टिकाऊ प्रमाण। यह कुकी साफ़ करने और ब्राउज़र प्रतिबंधों के बाद भी बचा रहता है, जिससे यह साबित करने के लिए सही साधन बनता है कि सहमति प्राप्त की गई थी।
- ऑडिट योग्य। आप समय के साथ चुनावों पर रिपोर्ट कर सकते हैं और विशिष्ट घटनाओं के बारे में प्रश्नों का उत्तर दे सकते हैं।
- क्रॉस-डिवाइस की संभावना। लॉग-इन पाठकों के लिए, सर्वर रिकॉर्ड डिवाइसों के बीच चुनाव सिंक कर सकता है, बशर्ते आप उन्हें यह समझाएँ।
कमज़ोरियाँ
- स्थानीय स्थिति का विकल्प नहीं। ब्राउज़र में टैग को अब भी तेज़, स्थानीय सिग्नल चाहिए; सहमति देखने के लिए हर पेज व्यू पर सर्वर को कॉल करना विलंबता जोड़ता है।
- यह स्वयं व्यक्तिगत डेटा है। रिकॉर्ड को प्रतिधारण अवधि, एक्सेस नियंत्रण और आपके प्राइवेसी नोटिस में स्थान चाहिए।
- आइडेंटिफ़ायर पर निर्भरता। अनाम विज़िटरों को रिकॉर्ड से केवल उनके डिवाइस पर सहेजे गए आइडेंटिफ़ायर के ज़रिए जोड़ा जा सकता है, जो आपको फिर लोकल स्टोरेज पर ले आता है।
आमने-सामने सारांश
- वेब पर चुनाव याद रखने के लिए सबसे अच्छा: फ़र्स्ट-पार्टी कुकीज़, आदर्श रूप से आपके सर्वर द्वारा स्थिर अवधि के साथ सेट की गई।
- ब्राउज़र में विस्तृत प्राथमिकता डेटा के लिए सबसे अच्छा: localStorage, ऐसी कुकी के साथ जिसे सर्वर पढ़ सके।
- चुनाव साबित करने के लिए सबसे अच्छा: सर्वर-साइड रिकॉर्ड।
- अकेले सबसे बुरा विकल्प: केवल localStorage पर निर्भर रहना, जो सर्वर को अंधा छोड़ देता है और कुछ ब्राउज़रों पर चुनाव को नाज़ुक बनाता है।
एक व्यावहारिक संयुक्त दृष्टिकोण
- प्रामाणिक स्थानीय सिग्नल — उदाहरण के लिए TCF स्ट्रिंग और एक संक्षिप्त प्रेफ़रेंस रिकॉर्ड — को अपने रजिस्टर करने योग्य डोमेन तक सीमित फ़र्स्ट-पार्टी कुकी में सहेजें।
- localStorage का उपयोग केवल उस पूरक डेटा के लिए करें जिसे सर्वर तक पहुँचाना ज़रूरी नहीं।
- हर चुनाव के लिए एक सर्वर-साइड रिकॉर्ड लिखें, जिसमें दिखाए गए बैनर और नीति का संस्करण शामिल हो।
- अगर सहेजा गया चुनाव ग़ायब हो जाए, तो पिछला उत्तर मान लेने की जगह बैनर फिर दिखाएँ।
- सहेजे गए चुनावों के लिए पुनः-प्रॉम्प्ट अवधि तय करें और उसे अपनी नीति में दर्ज करें।
विज़िटर के सहमति चुनाव को स्वयं सहेजना आमतौर पर उस सेवा को देने के लिए आवश्यक माना जाता है जो विज़िटर ने माँगी है — उनके निर्णय को याद रखना — लेकिन अपने मुख्य बाज़ारों में लागू मार्गदर्शन जाँच लें।
मुख्य बातें
- चुनाव याद रखना और चुनाव साबित करना अलग काम हैं जिन्हें अलग स्टोरेज चाहिए।
- कुकीज़ सर्वर द्वारा पढ़ने योग्य और सबडोमेन में साझा करने योग्य हैं, लेकिन आकार में सीमित हैं और Safari में स्क्रिप्ट से सेट होने पर अवधि में भी।
- localStorage जगह देता है लेकिन सर्वर को अदृश्य है और ब्राउज़र उसे साफ़ कर सकते हैं।
- सर्वर-साइड रिकॉर्ड प्रमाण की परत हैं, स्थानीय सिग्नल का विकल्प नहीं।
- सर्वर द्वारा सेट की गई फ़र्स्ट-पार्टी कुकी, वैकल्पिक ब्राउज़र स्टोरेज और सर्वर रिकॉर्ड को मिलाएँ।