PWA सहमति का एक किनारे का मामला क्यों हैं

एक प्रोग्रेसिव वेब ऐप एक नेटिव ऐप की तरह व्यवहार करता है — यह होम स्क्रीन पर इंस्टॉल होता है, ऑफ़लाइन चलता है, और आक्रामक रूप से कैश करता है — लेकिन यह अभी भी एक ब्राउज़र से परोसा जाता है, इसलिए कुकीज़ और वेब स्टोरेज नियम लागू होते हैं। यह संकर प्रकृति ही है जो प्रकाशकों को उलझा देती है: किसी भी वेबसाइट जैसी ही GDPR सहमति बाध्यताएँ, सर्विस वर्कर्स और स्थायी कैश के ऊपर परत बनाई गईं, जो उपयोगकर्ता के न कहने के बाद भी चुपचाप डेटा और स्क्रिप्ट को बनाए रख सकते हैं।

PWA चीज़ें कहाँ संग्रहीत करते हैं

इससे पहले कि आप भंडारण को सहमति पर आधारित कर सकें, आपको हर उस जगह को जानना होगा जहाँ एक PWA डेटा को बनाए रख सकता है:

• कुकीज़ — क्लासिक सतह, हमेशा की तरह सहमति द्वारा शासित।
• LocalStorage / IndexedDB — अक्सर ऐप स्थिति के लिए उपयोग किए जाते हैं, लेकिन एनालिटिक्स और विज्ञापन पहचानकर्ताओं के लिए भी।
• Cache Storage — सर्विस वर्कर तृतीय-पक्ष स्क्रिप्ट (एनालिटिक्स, विज्ञापन SDK) को कैश कर सकता है ताकि वे ऑफ़लाइन भी चलें।
• सर्विस वर्कर स्वयं — सत्रों के बीच बना रहता है और अगले लॉन्च पर ट्रैकिंग को फिर से पंजीकृत कर सकता है।

सहमति को इन सभी को नियंत्रित करना चाहिए, न कि केवल document.cookie को।

सहमति-पहले सर्विस वर्कर पैटर्न

मूल सिद्धांत: सर्विस वर्कर को किसी भी गैर-आवश्यक तृतीय-पक्ष संसाधन को कैश या निष्पादित करने से पहले सहमति स्थिति पढ़नी चाहिए। एक स्वच्छ पैटर्न इस तरह दिखता है:

• सहमति संकेत को कहीं संग्रहीत करें जहाँ सर्विस वर्कर इसे पढ़ सके — IndexedDB या एक कैश प्रविष्टि जिसे CMP हर पसंद पर अपडेट करता है।
• सर्विस वर्कर fetch हैंडलर में, एनालिटिक्स/विज्ञापन एंडपॉइंट को कैश करने से इनकार करें जब तक कि उस उद्देश्य के लिए सहमति मौजूद न हो।
• जब कोई उपयोगकर्ता सहमति वापस लेता है, तो सर्विस वर्कर को एक संदेश भेजें ताकि वह कैश किए गए ट्रैकिंग स्क्रिप्ट को शुद्ध करे और संबंधित IndexedDB स्टोर को साफ़ करे।

उस अंतिम चरण को छोड़ना सबसे आम PWA अनुपालन अंतराल है: बैनर कहता है “अस्वीकृत,” लेकिन एक कैश किया गया एनालिटिक्स स्क्रिप्ट अगले ऑफ़लाइन लॉन्च पर सर्विस वर्कर से चलता रहता है।

ऑफ़लाइन सहमति UX

PWA बिना नेटवर्क के लॉन्च हो सकते हैं। आपके सहमति बैनर और उपयोगकर्ता की संग्रहीत पसंद दोनों को ऑफ़लाइन काम करना चाहिए — CMP UI को स्वयं कैश करें, और कभी भी केवल इसलिए “प्रदत्त” को डिफ़ॉल्ट न करें क्योंकि सहमति सर्वर पहुँच से बाहर है। यदि आप पूर्व पसंद की पुष्टि नहीं कर सकते, तो उपयोगकर्ता को असहमत मानें और तब तक केवल आवश्यक कार्यक्षमता परोसें जब तक आप ऐसा न कर सकें।

विज्ञापन राजस्व निहितार्थ

विज्ञापन-समर्थित PWA के लिए, सहमति स्थिति को अनुरोध समय पर, ऑनलाइन या ऑफ़लाइन, आपके विज्ञापन SDK तक पहुँचना होगा। एक सही ढंग से जुड़ा PWA IAB TCF स्ट्रिंग और Consent Mode v2 संकेतों को मांग भागीदारों को बिल्कुल एक सामान्य साइट की तरह पास करता है; एक गलत कॉन्फ़िगर किया गया एक बासी “कोई सहमति नहीं” स्थिति को कैश करता है और आपके eCPM को अनिश्चित काल तक गैर-वैयक्तिकृत दरों पर ढहा देता है। सहमति की ताज़गी को एक राजस्व मीट्रिक मानें।

FlexyConsent कैसे मदद करता है

FlexyConsent चुनाव को सहमति कुकीज़ और ब्राउज़र स्टोरेज में रखता है और हर बदलाव, जिसमें वापसी भी शामिल है, की जानकारी आपके कोड को __fcapi के consentChanged इवेंट के माध्यम से देता है, जिसे आप कैश साफ़ करने से जोड़ सकते हैं।

मुख्य निष्कर्ष

• PWA को पूर्ण GDPR सहमति कर्तव्यों के साथ-साथ सर्विस-वर्कर और कैश जटिलताओं का सामना करना पड़ता है।
• कुकीज़, LocalStorage, IndexedDB और Cache Storage को सहमति पर आधारित करें — न केवल कुकीज़ को।
• वापसी पर, कैश किए गए ट्रैकिंग स्क्रिप्ट को शुद्ध करें और संग्रहीत पहचानकर्ताओं को साफ़ करें।
• सहमति स्थिति को ताज़ा और ऑफ़लाइन-सुरक्षित रखें ताकि विज्ञापन राजस्व गैर-वैयक्तिकृत दरों पर अटका न रहे।