WebView में सहमति: नेटिव और वेब सहमति को सिंक में रखना
डबल-बैनर की समस्या
कई ऐप आंशिक रूप से नेटिव और आंशिक रूप से वेब होते हैं। कोई गेम अपना स्टोर, समाचार या सहायता पेज WebView में दिखाता है; कोई यूटिलिटी ऐप अपनी वेबसाइट से लेख रेंडर करता है; कोई हाइब्रिड ऐप अपना अधिकांश इंटरफ़ेस वेब सामग्री में लपेटता है। हर पक्ष का अपना सहमति तंत्र होता है: नेटिव ऐप इन-ऐप CMP या SDK का उपयोग करता है, और वेब पेज वेब CMP लोड करते हैं। जब तक वे जुड़े न हों, उपयोगकर्ता से दो बार पूछा जाता है, एक जगह किए गए विकल्प दूसरी जगह अनदेखे रह जाते हैं, और WebView के अंदर से जाने वाले विज्ञापन अनुरोध गलत संकेतों के साथ निकलते हैं।
यह गाइड बताती है कि नेटिव और वेब सहमति को कैसे सहमत कराएँ, ताकि उपयोगकर्ता एक बार उत्तर दें और हर विज्ञापन अनुरोध में वही निर्णय जाए।
हर पक्ष सहमति कहाँ संग्रहीत करता है
नेटिव
IAB TCF निर्दिष्ट करता है कि इन-ऐप CMP सहमति कैसे संग्रहीत करता है: iOS पर NSUserDefaults में और Android पर SharedPreferences में, IABTCF_TCString, IABTCF_gdprApplies और IABTCF_PurposeConsents जैसी मानक कुंजियों का उपयोग करते हुए। विज्ञापन SDK इन कुंजियों को सीधे पढ़ते हैं। IAB GPP IABGPP_ उपसर्ग वाली समान कुंजियाँ परिभाषित करता है, जैसे IABGPP_HDR_GppString।
वेब
वेब CMP आमतौर पर अपना निर्णय साइट के डोमेन के फ़र्स्ट-पार्टी कुकी या लोकल स्टोरेज में संग्रहीत करता है, और उसे __tcfapi तथा __gpp JavaScript फ़ंक्शन के माध्यम से उपलब्ध कराता है। पेज के विज्ञापन टैग इन्हीं फ़ंक्शन को कॉल करते हैं, नेटिव स्टोरेज को नहीं।
अंतराल
WebView का अपना कुकी और स्टोरेज स्थान होता है, जो डिवाइस ब्राउज़र से अलग और ऐप की नेटिव प्राथमिकताओं से अलग है। iOS पर, गैर-स्थायी डेटा स्टोर वाला WKWebView बंद होने पर सब कुछ भूल जाता है। जब तक आप न बनाएँ, दोनों पक्षों के बीच कुछ नहीं बहता।
सत्य का एक स्रोत चुनें
पहला निर्णय यह है कि सहमति का मालिक कौन-सा पक्ष है। अधिकांश ऐप के लिए उत्तर नेटिव CMP है, क्योंकि:
- वह पहले चलता है, किसी भी WebView के खुलने से पहले।
- नेटिव विज्ञापन SDK, जो आमतौर पर अधिकांश राजस्व कमाते हैं, नेटिव स्टोरेज पढ़ते हैं।
- iOS पर इसे App Tracking Transparency प्रॉम्प्ट के साथ समन्वित किया जा सकता है।
उन हाइब्रिड ऐप के लिए वेब-फ़र्स्ट समझदारी हो सकती है जिनका पूरा इंटरफ़ेस वेब सामग्री है, लेकिन तब नेटिव SDK के लिए आपको निर्णय को वापस नेटिव स्टोरेज में लिखना होगा।
नेटिव सहमति को WebView में पहुँचाना
नेटिव को सत्य का स्रोत मानने पर WebView को वही निर्णय दिखना चाहिए। आम पैटर्न:
__tcfapiकार्यान्वयन इंजेक्ट करें। पेज की स्क्रिप्ट चलने से पहले एक छोटी स्क्रिप्ट इंजेक्ट करें जो__tcfapi(और ज़रूरत हो तो__gpp) को परिभाषित करे और नेटिव स्टोरेज से पढ़े TC string और मानों के साथ कॉल का उत्तर दे। तब पेज के विज्ञापन टैग मानक API के माध्यम से नेटिव निर्णय पा लेते हैं।- वेब बैनर दबाएँ। वेब CMP को इस तरह कॉन्फ़िगर करें कि जब पेज आपके ऐप के अंदर लोड हो तो वह छिपा रहे, उदाहरण के लिए क्वेरी पैरामीटर या आपके नियंत्रण वाले कस्टम यूज़र एजेंट टोकन के आधार पर। अन्यथा उपयोगकर्ता को दूसरा बैनर दिखता है।
- लोड पर string पास करें। कुछ वेब CMP आरंभ पर मौजूदा सहमति string स्वीकार करके उसे अपना सकते हैं। समर्थित तरीकों के लिए अपने वेब CMP के दस्तावेज़ देखें।
जो भी पैटर्न उपयोग करें, सुनिश्चित करें कि जब उपयोगकर्ता नेटिव सेटिंग्स स्क्रीन में अपना विकल्प बदले तो इंजेक्ट किए गए मान अपडेट हों, केवल अगले ऐप लॉन्च पर नहीं।
वेब सहमति को नेटिव तक वापस पहुँचाना
यदि उपयोगकर्ता WebView के अंदर सहमति बदल सकते हैं, उदाहरण के लिए गोपनीयता सेटिंग्स पेज के माध्यम से, तो ऐप को इसकी जानकारी होनी चाहिए। JavaScript ब्रिज का उपयोग करें: iOS पर मैसेज हैंडलर या Android पर JavaScript इंटरफ़ेस। वेब पक्ष __tcfapi('addEventListener', ...) से सुनता है और नई string नेटिव कोड को भेजता है, जो मानक कुंजियाँ लिखता है। लिखने से पहले WebView से आए इनपुट को मान्य करें; केवल अपनी ही सामग्री के संदेश स्वीकार करें।
WebView के अंदर विज्ञापन
WebView में रेंडर किए गए विज्ञापन वेब विज्ञापन हैं। वे सहमति पेज से पढ़ते हैं, नेटिव स्टोरेज से नहीं, जब तक विज्ञापन SDK दोनों को जोड़ने का तरीका न दे। उदाहरण के लिए Google का Mobile Ads SDK WebView को पंजीकृत करने का API देता है ताकि उनके अंदर के विज्ञापन ऐप के संकेतों का उपयोग कर सकें; अपने SDK के वर्तमान दस्तावेज़ देखें। हर स्थिति में परीक्षण से पुष्टि करें कि WebView से जाने वाले विज्ञापन अनुरोधों में नेटिव विज्ञापन अनुरोधों जैसी ही TC या GPP string हो।
परीक्षण चेकलिस्ट
- नया इंस्टॉल: एक सहमति प्रॉम्प्ट, दो नहीं।
- नेटिव CMP में सभी अस्वीकार करें, WebView खोलें, विज्ञापन अनुरोध देखें: string में अस्वीकृति दिखनी चाहिए।
- नेटिव सेटिंग्स में सहमति बदलें, खुले WebView पर लौटें: पेज को नया निर्णय दिखना चाहिए।
- यदि वेब सेटिंग्स मौजूद हैं, तो वहाँ सहमति बदलें और पुष्टि करें कि नेटिव कुंजियाँ अपडेट होती हैं।
- ऐप को बंद करके फिर शुरू करें: निर्णय दोनों पक्षों पर बने रहें।
- iOS और Android दोनों पर परीक्षण करें, क्योंकि WebView स्टोरेज का व्यवहार दोनों पर अलग है।
मुख्य बातें
- नेटिव और WebView की सहमति अलग स्टोर में रहती है और डिफ़ॉल्ट रूप से सिंक नहीं होती।
- सत्य का एक स्रोत चुनें; अधिकांश ऐप के लिए यह नेटिव CMP है।
- इंजेक्ट किए गए
__tcfapiया__gppसे नेटिव सहमति को वेब सामग्री के लिए उपलब्ध कराएँ और वेब बैनर छिपाएँ। - वेब बदलावों को वापस नेटिव स्टोरेज में भेजने के लिए JavaScript ब्रिज का उपयोग करें।
- जाँचें कि WebView से जाने वाले विज्ञापन अनुरोधों में नेटिव जैसी ही सहमति string हो।