सहमति हमेशा के लिए नहीं होती

जब कोई विज़िटर अपनी पसंद चुन ले, तो आपको उसे याद रखना चाहिए ताकि हर पेज पर उसे परेशान न किया जाए। लेकिन स्टोर की गई पसंद अनिश्चित काल तक नहीं चलती। परिस्थितियाँ बदलती हैं, टूल जुड़ते हैं, और बहुत पहले लिया गया निर्णय शायद अब वह न दर्शाए जो विज़िटर आज चुनता। यह चेकलिस्ट आपको समाप्ति और दोबारा पूछने के समझदार नियम तय करने में मदद करती है।

नियम क्या कहते हैं (और क्या नहीं)

GDPR सहमति के लिए कोई निश्चित समाप्ति तिथि तय नहीं करता। व्यवहार में नियामकों के मार्गदर्शन इस कमी को भरते हैं। उदाहरण के लिए, फ़्रांस का CNIL सलाह देता है कि दोबारा पूछने से पहले विज़िटर की पसंद को लगभग छह महीने तक रखा जाए, और कहता है कि ट्रैकिंग कुकी का अपना जीवनकाल 13 महीने से अधिक नहीं होना चाहिए। अन्य प्राधिकरणों ने सटीक संख्याएँ तय नहीं की हैं। अपनी ऑडियंस से संबंधित प्राधिकरण को देखें और जो अवधि चुनें उसे दस्तावेज़ित करें।

चेकलिस्ट 1: डिफ़ॉल्ट जीवनकाल तय करें

• सहमति का जीवनकाल चुनें और उसे लिख लें। छह से बारह महीने एक आम दायरा है; जहाँ आपका नियामक सुझाए, वहाँ छोटा सिरा चुनें।
• सिर्फ़ पसंद नहीं, पसंद चुने जाने की तारीख भी स्टोर करें।
• सहमति रिकॉर्ड रखने वाली कुकी या स्टोरेज एंट्री पर भी वही जीवनकाल तर्क लागू करें।
• सुनिश्चित करें कि स्टोर की गई पसंद सर्वर साइड पर या आपके लॉजिक में समाप्त हो, सिर्फ़ ब्राउज़र में नहीं।

चेकलिस्ट 2: दोबारा पूछने के ट्रिगर तय करें

स्टोर की गई पसंद की उम्र चाहे जो हो, विज़िटर से फिर पूछें जब:

• आप कोई नया उद्देश्य जोड़ते हैं। डेटा का कोई नया उपयोग पहले की पसंद में कभी कवर नहीं हुआ था।
• आप कोई नया वेंडर या पार्टनर जोड़ते हैं जो डेटा को ऐसे तरीके से प्रोसेस करता है जो पहले उजागर नहीं किया गया था।
• आपकी प्राइवेसी या कुकी नीति में महत्वपूर्ण बदलाव होता है।
• बैनर का संस्करण बदलता है इस तरह कि उपलब्ध विकल्प बदल जाते हैं।
• स्टोर की गई पसंद गायब, भ्रष्ट या अपठनीय है।

इसे एक सहमति संस्करण संख्या से जोड़ें जिसे आप ऊपर की कोई भी बात होने पर बढ़ाते हैं। पुराने संस्करण वाली स्टोर की गई पसंद बैनर को ट्रिगर करती है।

चेकलिस्ट 3: विज़िटर अनुभव की रक्षा करें

• एक ही सेशन के भीतर टाइमर के आधार पर दोबारा न पूछें।
• जिस विज़िटर ने अस्वीकार किया, उसे सिर्फ़ थकाने के लिए दोबारा न पूछें; वास्तविक ट्रिगर न होने पर अस्वीकृति का पूरी अवधि तक सम्मान करें।
• फ़ुटर में एक स्थायी लिंक रखें ताकि विज़िटर समाप्ति का इंतज़ार किए बिना किसी भी समय अपना मन बदल सकें।
• सहमति वापस लेना उतना ही आसान बनाएँ जितना उसे देना।

चेकलिस्ट 4: विशेष मामलों को संभालें

• साफ़ की गई कुकी। बैनर फिर दिखेगा। यह अपेक्षित है; इसे फ़िंगरप्रिंटिंग से टालने की कोशिश न करें।
• कई डोमेन या सबडोमेन। तय करें कि पसंद उनके बीच साझा होगी या नहीं और व्यवहार को एकसमान रखें।
• ऐप्स। पसंद और उसकी तारीख को ऐप स्टोरेज में स्टोर करें, और डेटा उपयोग जोड़ने वाले SDK अपडेट के बाद दोबारा पूछें।
• क्षेत्र बदलना। यदि कोई विज़िटर दूसरे क्षेत्राधिकार में चला जाए, तो जाँचें कि क्या आपके नियम अलग तरह से लागू होने चाहिए।

चेकलिस्ट 5: प्रमाण रखें

• हर सहमति के लिए टाइमस्टैम्प, बैनर संस्करण और पसंद रिकॉर्ड करें।
• एक परिवर्तन लॉग रखें कि आपने जीवनकाल या संस्करण संख्या कब और क्यों बदली।
• अपनी कुकी इन्वेंटरी के साथ हर तिमाही सेटिंग की समीक्षा करें।

FlexyConsent कहाँ फ़िट होता है

FlexyConsent IAB Europe और IAB Canada द्वारा प्रमाणित है, IAB TCF 2.4 और Google Consent Mode v2 को सपोर्ट करता है, और EU, EEA, UK, अमेरिकी राज्य, कनाडा और क्यूबेक जैसे क्षेत्रों को कवर करता है। आप जो भी प्लेटफ़ॉर्म इस्तेमाल करें, जाँचें कि वह पसंद को कैसे स्टोर करता है और नया प्रॉम्प्ट किससे ट्रिगर होता है, और उसे ऊपर लिखे अपने नियमों से मिलाएँ।

मुख्य बातें

• सहमति समाप्त होनी चाहिए; कोई एक कानूनी संख्या नहीं है, इसलिए एक अवधि चुनें, उसे लिखें और अपने नियामक का मार्गदर्शन देखें।
• उद्देश्य, वेंडर, नीतियाँ या बैनर विकल्प बदलने पर, सहमति संस्करण संख्या का उपयोग करके, दोबारा पूछें।
• वास्तविक ट्रिगर के बिना उन विज़िटर को परेशान न करें जिन्होंने अस्वीकार किया।
• सहमति बदलने या वापस लेने का हमेशा उपलब्ध तरीका रखें।
• टाइमस्टैम्प, संस्करण और पसंद रिकॉर्ड करें, और हर तिमाही नियमों की समीक्षा करें।