இரட்டை-பேனர் சிக்கல்

பல செயலிகள் ஒரு பகுதி நேட்டிவ், ஒரு பகுதி வலை. ஒரு விளையாட்டு தனது கடை, செய்தி அல்லது உதவிப் பக்கங்களை WebView-இல் காட்டுகிறது; ஒரு பயன்பாட்டுச் செயலி தனது இணையதளத்திலிருந்து கட்டுரைகளைக் காட்டுகிறது; ஒரு கலப்பினச் செயலி தனது இடைமுகத்தின் பெரும்பகுதியை வலை உள்ளடக்கத்தில் சுற்றி வைக்கிறது. ஒவ்வொரு பக்கத்துக்கும் அதன் சொந்த ஒப்புதல் வழிமுறை உண்டு: நேட்டிவ் செயலி செயலிக்குள் உள்ள CMP அல்லது SDK-ஐப் பயன்படுத்துகிறது; வலைப் பக்கங்கள் வலை CMP-ஐ ஏற்றுகின்றன. அவை இணைக்கப்படாவிட்டால், பயனரிடம் இருமுறை கேட்கப்படுகிறது, ஓரிடத்தில் செய்த தேர்வுகள் மற்றொன்றில் புறக்கணிக்கப்படுகின்றன, WebView-க்குள்ளிருந்து செல்லும் விளம்பரக் கோரிக்கைகள் தவறான சமிக்ஞைகளுடன் செல்கின்றன.

நேட்டிவ், வலை ஒப்புதலை எவ்வாறு ஒத்திசைக்கச் செய்வது என்பதை இந்த வழிகாட்டி விளக்குகிறது; பயனர்கள் ஒருமுறை பதிலளிக்க, ஒவ்வொரு விளம்பரக் கோரிக்கையும் அதே முடிவைக் கொண்டு செல்ல.

ஒவ்வொரு பக்கமும் ஒப்புதலை எங்கே சேமிக்கிறது

நேட்டிவ்

செயலிக்குள் உள்ள CMP ஒப்புதலை எவ்வாறு சேமிக்கிறது என்பதை IAB TCF வரையறுக்கிறது: 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 அதே முடிவைப் பார்க்க வேண்டும். பொதுவான முறைகள்:

1. ஒரு __tcfapi செயலாக்கத்தை உட்செலுத்துங்கள். பக்கத்தின் ஸ்கிரிப்ட்கள் இயங்குவதற்கு முன், __tcfapi-ஐ (தேவைப்பட்டால் __gpp-ஐயும்) வரையறுத்து, நேட்டிவ் சேமிப்பிலிருந்து படித்த TC string மற்றும் மதிப்புகளுடன் அழைப்புகளுக்குப் பதிலளிக்கும் சிறிய ஸ்கிரிப்ட்டை உட்செலுத்துங்கள். பக்கத்தில் உள்ள விளம்பர டேக்கள் தரநிலை API வழியாக நேட்டிவ் முடிவைப் பெறும்.
2. வலை பேனரை அடக்குங்கள். பக்கம் உங்கள் செயலிக்குள் ஏற்றப்படும்போது வலை CMP மறைந்திருக்கும்படி கட்டமைக்கவும், எ.கா. வினவல் அளவுரு அல்லது உங்கள் கட்டுப்பாட்டிலுள்ள தனிப்பயன் user agent டோக்கன் அடிப்படையில். இல்லையெனில் பயனர் இரண்டாவது பேனரைப் பார்ப்பார்.
3. ஏற்றும்போது 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-ஐக் கொண்டுள்ளனவா எனச் சரிபாருங்கள்.