Ikki banner muammosi

Koʻplab ilovalar qisman native, qisman veb. Oʻyin doʻkonini, yangiliklarni yoki yordam sahifalarini WebView-da koʻrsatadi; yordamchi ilova oʻz veb-saytidagi maqolalarni aks ettiradi; gibrid ilova interfeysining katta qismini veb-kontent bilan oʻraydi. Har bir tomonning oʻz rozilik mexanizmi bor: native ilova ilova ichidagi CMP yoki SDK-dan, veb sahifalar esa veb CMP-dan foydalanadi. Ular ulanmasa, foydalanuvchidan ikki marta soʻraladi, bir joyda qilingan tanlovlar boshqasida eʼtiborsiz qoldiriladi va WebView ichidan reklama soʻrovlari notoʻgʻri signallar bilan ketadi.

Ushbu qoʻllanma native va veb rozilikni qanday moslashtirishni qamrab oladi, shunda foydalanuvchilar bir marta javob beradi va har bir reklama soʻrovi bir xil qarorni olib yuradi.

Har bir tomon rozilikni qayerda saqlaydi

Native

IAB TCF ilova ichidagi CMP rozilikni qanday saqlashini belgilaydi: iOS-da NSUserDefaults, Android-da SharedPreferences ichida, IABTCF_TCString, IABTCF_gdprApplies va IABTCF_PurposeConsents kabi standart kalitlar bilan. Reklama SDK-lari bu kalitlarni bevosita oʻqiydi. IAB GPP IABGPP_HDR_GppString kabi IABGPP_ prefiksli shunga oʻxshash kalitlarni belgilaydi.

Veb

Veb CMP odatda qarorini sayt domeni uchun birinchi tomon cookie-larida yoki mahalliy xotirada saqlaydi va uni __tcfapi hamda __gpp JavaScript funksiyalari orqali taqdim etadi. Sahifadagi reklama teglari native xotirani emas, shu funksiyalarni chaqiradi.

Boʻshliq

WebView-larning qurilma brauzeridan va ilovaning native sozlamalaridan alohida oʻz cookie va xotira maydoni bor. iOS-da doimiy boʻlmagan maʼlumotlar omboridan foydalanadigan WKWebView yopilganda hamma narsani unutadi. Siz koʻprik qurmaguningizcha ikki tomon oʻrtasida hech narsa oqmaydi.

Yagona haqiqat manbaini tanlang

Birinchi qaror — rozilik qaysi tomonga tegishli ekani. Aksariyat ilovalar uchun javob — native CMP, chunki:

• U har qanday WebView ochilishidan oldin birinchi ishlaydi.
• Odatda daromadning katta qismini keltiradigan native reklama SDK-lari native xotirani oʻqiydi.
• iOS-da uni App Tracking Transparency soʻrovi bilan muvofiqlashtirish mumkin.

Butun interfeysi veb-kontentdan iborat gibrid ilovalar uchun avval veb yondashuvi mantiqli boʻlishi mumkin, lekin u holda native SDK-lar uchun qarorni native xotiraga qaytarib yozishingiz kerak.

Native rozilikni WebView-ga uzatish

Native haqiqat manbai boʻlganda, WebView bir xil qarorni koʻrishi kerak. Keng tarqalgan andozalar:

1. __tcfapi implementatsiyasini kiriting. Sahifa skriptlari ishlashidan oldin __tcfapi (kerak boʻlsa __gpp) ni aniqlaydigan va chaqiruvlarga native xotiradan oʻqilgan TC string va qiymatlar bilan javob beradigan kichik skript kiriting. Sahifadagi reklama teglari native qarorni standart API orqali oladi.
2. Veb bannerni bostiring. Veb CMP-ni sahifa ilovangiz ichida yuklanganda, masalan, soʻrov parametri yoki oʻzingiz nazorat qiladigan maxsus user agent belgisiga qarab, yashirin qoladigan qilib sozlang. Aks holda foydalanuvchi ikkinchi bannerni koʻradi.
3. Satrni yuklashda uzating. Baʼzi veb CMP-lar ishga tushirish vaqtida mavjud rozilik satrini qabul qilib, uni oʻzlashtirishi mumkin. Qoʻllab-quvvatlanadigan usullar uchun veb CMP-ingiz hujjatlarini tekshiring.

Qaysi andozadan foydalanishingizdan qatʼi nazar, foydalanuvchi tanlovni native sozlamalar ekranida oʻzgartirganda kiritilgan qiymatlar faqat ilovaning keyingi ochilishida emas, darhol yangilanishiga ishonch hosil qiling.

Veb rozilikni native tomonga qaytarish

Agar foydalanuvchilar rozilikni WebView ichida, masalan, maxfiylik sozlamalari sahifasi orqali oʻzgartira olsa, ilova bu haqda bilishi kerak. JavaScript koʻprigidan foydalaning: iOS-da xabar ishlovchisi, Android-da JavaScript interfeysi. Veb tomon __tcfapi('addEventListener', ...) bilan tinglaydi va yangi satrni standart kalitlarni yozadigan native kodga yuboradi. Yozishdan oldin WebView-dan kelgan kirishni tekshiring; faqat oʻz kontentingizdan kelgan xabarlarni qabul qiling.

WebView-lar ichidagi reklamalar

WebView-da koʻrsatiladigan reklamalar veb reklamalardir. Reklama SDK-si ikkalasini bogʻlash usulini taqdim etmasa, ular rozilikni native xotiradan emas, sahifadan oʻqiydi. Masalan, Googleʼning Mobile Ads SDK-si WebView-lar ichidagi reklamalar ilovadan signallardan foydalanishi uchun WebView-larni roʻyxatdan oʻtkazadigan API taklif qiladi; SDK-ingiz uchun joriy hujjatlarni tekshiring. Har qanday holatda, WebView-dan kelgan reklama soʻrovlari native reklama soʻrovlari bilan bir xil TC yoki GPP satrini olib yurishini sinov bilan tasdiqlang.

Sinov nazorat roʻyxati

• Yangi oʻrnatish: ikkita emas, bitta rozilik soʻrovi.
• Native CMP-da hammasini rad eting, WebView oching, reklama soʻrovlarini tekshiring: satr rad etishni aks ettirishi kerak.
• Native sozlamalarda rozilikni oʻzgartiring, ochiq WebView-ga qayting: sahifa yangi qarorni koʻrishi kerak.
• Agar veb sozlamalar mavjud boʻlsa, rozilikni u yerda oʻzgartiring va native kalitlar yangilanishini tasdiqlang.
• Ilovani yoping va qayta ishga tushiring: qarorlar ikkala tomonda saqlanib qoladi.
• WebView xotirasi har birida turlicha ishlagani uchun iOS va Android-da sinang.

Asosiy xulosalar

• Native va WebView roziligi alohida omborlarda yashaydi va standart boʻyicha sinxronlanmaydi.
• Yagona haqiqat manbaini tanlang; aksariyat ilovalar uchun bu native CMP.
• Native rozilikni veb-kontentga kiritilgan __tcfapi yoki __gpp orqali taqdim eting va veb bannerni yashiring.
• Veb oʻzgarishlarini native xotiraga qaytarish uchun JavaScript koʻprigidan foydalaning.
• WebView-lardan kelgan reklama soʻrovlari native soʻrovlar bilan bir xil rozilik satrini olib yurishini tekshiring.