DPDP-अनुपालक लीड कैप्चर: आपकी QR कोड सहमति स्क्रीन में क्या कहना ज़रूरी है

भारत का Digital Personal Data Protection एक्ट यह तय करता है कि वैध सहमति किसे माना जाए इसके लिए एक खास, टेस्ट करने योग्य मानक तय करता है: यह मुक्त, विशिष्ट, सूचित, बिना शर्त, और स्पष्ट होनी चाहिए, एक साफ सकारात्मक कार्रवाई के ज़रिए दी गई। एक पहले से टिक किया गया चेकबॉक्स, एक असंबंधित परमिशन के साथ बंडल की गई सहमति, या किसी के सेवा का इस्तेमाल जारी रखने से सिर्फ माना गई सहमति, ये सभी उस मानक पर खरे नहीं उतरते। एक बिज़नेस के लिए जो QR कोड के ज़रिए फोन नंबर और ईमेल कैप्चर कर रहा है — अक्सर नए पर्सनल डेटा का सबसे बड़ा चालू सोर्स जो एक छोटा या मिड-साइज़ बिज़नेस इकट्ठा करता है — सहमति स्क्रीन पर इसे सही करना इसे ठीक करने की सबसे सस्ती जगह है, एक शिकायत या एक ऑडिट इसे महंगा बनाने से बहुत पहले।

SMLLR का Lead Capture Gate जानबूझकर दो चीज़ों को अलग रखता है जिन्हें बहुत से लीड-कैप्चर फॉर्म मिला देते हैं: एक अनिवार्य कॉन्टैक्ट फील्ड जो QR कोड के रीडायरेक्ट को अनलॉक करने के लिए ज़रूरी है, और उसके नीचे एक पूरी तरह अलग, डिफ़ॉल्ट रूप से अनचेक्ड मार्केटिंग-सहमति चेकबॉक्स। कॉन्टैक्ट फील्ड मार्केट किए जाने की सहमति नहीं है — यह जारी रखने के लिए एक फंक्शनल ज़रूरत है, बिल्कुल वैसे ही जैसे फोन अनलॉक करने के लिए पासवर्ड टाइप करना। असली मार्केटिंग आउटरीच की सहमति दूसरा, वैकल्पिक तत्व है, और यही वह है जिसे DPDP के नियम असल में गवर्न करते हैं। दोनों को मिला देना — "उन्होंने हमें अपना नंबर दिया" को "उन्होंने मार्केट किए जाने पर सहमति दी" के जैसा मानना — ठीक वैसी ही बंडल की गई, गैर-विशिष्ट सहमति है जिसे पकड़ने के लिए यह एक्ट बना है।

एक पहले से चेक की गई सहमति बॉक्स DPDP के तहत अमान्य सहमति मानी जाती है चाहे इसे कितनी भी साफ तरह से लेबल किया गया हो, क्योंकि यह "साफ सकारात्मक कार्रवाई" को हटा देती है जो कानून मांगता है — किसी को सक्रिय रूप से ऑप्ट इन करना होता है, निष्क्रिय रूप से ऑप्ट आउट करने में असफल नहीं होना होता। Lead Capture Gate पर SMLLR का मार्केटिंग-सहमति चेकबॉक्स हर एक स्कैन पर अनटिक्ड शुरू होता है, इसे अलग तरह से कॉन्फ़िगर करने का कोई तरीका नहीं है, और रीडायरेक्ट बिल्कुल एक जैसा फायर होता है चाहे यह चेक किया गया हो या नहीं — इसलिए ऐसा कोई परिदृश्य कभी नहीं होता जहां एक बिज़नेस सब्सक्राइबर काउंट बढ़ाने के लिए असली डेस्टिनेशन को एक ज़बरदस्ती के ऑप्ट-इन के पीछे गेट करने के लिए ललचाए।

"विशिष्ट" सहमति का मतलब है कि एक व्यक्ति अपने डेटा के एक खास इस्तेमाल पर सहमत हो रहा है, किसी अस्पष्ट कैच-ऑल पर नहीं। SMLLR प्रति उद्देश्य सहमति रिकॉर्ड करता है — आज ईमेल मार्केटिंग और ऐड टारगेटिंग, हर एक का अपना नामित ग्रांट, न कि एक सामान्य "मैं सहमत हूं" टॉगल। एक लीड जो ईमेल-मार्केटिंग सहमति देती है लेकिन कभी ऐड-टारगेटिंग रिक्वेस्ट नहीं देखती वह सिर्फ ईमेल कैंपेन के लिए योग्य है; कहीं एक बॉक्स टिक करने भर से वे अपने आप एक Meta Sync ऑडियंस सिंक के लिए योग्य नहीं बन जाते। यही उद्देश्य-स्तरीय ग्रैन्युलैरिटी है जो एक बिज़नेस को किसी भी इंडिविजुअल लीड के लिए ईमानदारी से जवाब देने देती है कि "इस व्यक्ति ने असल में किस बात पर सहमति दी", सिर्फ "क्या उन्होंने किसी चीज़ पर सहमति दी" नहीं।

सहमति को सही तरीके से कैप्चर करने से परे, DPDP-केंद्रित प्रैक्टिस का मतलब है यह साबित कर पाना कि क्या कैप्चर हुआ और कब। SMLLR के गेट के ज़रिए हर सहमति ग्रांट अपनी खुद की अपेंड-ओनली एंट्री के तौर पर स्टोर होती है — उस पल व्यक्ति को दिखाई गई एग्जैक्ट वर्डिंग, एक टाइमस्टैंप, और IP एड्रेस — और इसे बाद में कभी एडिट नहीं किया जाता। अगर एक लीड बाद में सहमति वापस लेता है, वह पुराने ग्रांट को सुपरसीड करने वाली एक नई एंट्री के तौर पर रिकॉर्ड होती है, ओरिजिनल ग्रांट की चुपचाप डिलीशन नहीं। यह इसलिए मायने रखता है क्योंकि DPDP के तहत "सूचित" सहमति का मतलब है कि व्यक्ति ने असल में खास वर्डिंग देखी हो, ऐसी वर्डिंग नहीं जिसे चुपचाप बाद में बदल दिया गया और पहले के वर्जन के तहत कैप्चर की गई सहमति पर रेट्रोएक्टिव रूप से लागू कर दिया गया।

जिन बिज़नेस के पास SMLLR अपनाने से पहले ही एक ग्राहक लिस्ट थी — किसी पिछले सिस्टम से, एक ऑफलाइन रजिस्टर से, या एक पूरी तरह अलग टूल से — वे सिर्फ इसलिए अपने आप अनुपालक नहीं हो जाते क्योंकि उस लिस्ट पर मौजूद लोग असली, मौजूदा ग्राहक हैं। CSV इम्पोर्ट एक बिज़नेस को साफ तौर पर यह अटेस्ट करने देता है कि किसी दिए गए बैच के लिए पहले से मौजूद सहमति असल में मौजूद है, उस अटेस्टेशन को बिज़नेस की अपनी जवाबदेही पर टाइमस्टैंप और IP-स्टैंप करते हुए, न कि हर इम्पोर्ट किए गए कॉन्टैक्ट को डिफ़ॉल्ट रूप से शून्य सहमति मान लेना चाहे पहले से जो भी परमिशन मौजूद रही हो। वह अटेस्टेशन एक बिज़नेस फैसला है जिसके साथ असली जवाबदेही जुड़ी है — यह DPDP की ज़रूरतों को बायपास करने का तरीका नहीं है, यह उस सहमति को सटीक रूप से रिकॉर्ड करने का तरीका है जो एक बिज़नेस को भरोसा है कि उसके पास पहले से वैध रूप से मौजूद है।

2026 तक, DPDP एक्ट के कंसेंट-मैनेजर फ्रेमवर्क के लिए रजिस्ट्रेशन नवंबर में खुलता है, एक्ट के मूल प्रावधान — सहमति की ज़रूरतें, प्राइवेसी नोटिस दायित्व, और सुरक्षा सुरक्षोपाय — मई 2027 में पूरी तरह प्रभावी होंगे। यह टाइमलाइन इंतज़ार करने की वजह नहीं है: वैध सहमति की परिभाषा नई या अस्पष्ट नहीं है, और शुरू से डिफ़ॉल्ट रूप से अनचेक्ड, उद्देश्य-विशिष्ट, ऑडिट करने योग्य सहमति के इर्द-गिर्द एक लीड-कैप्चर फ्लो बनाने में कोई अतिरिक्त लागत नहीं है इसकी तुलना में कि पहले इसे गलत तरीके से बनाया जाए और बाद में इसे रेट्रोफिट करना पड़े।