Problemi i dyfishtë i banerit

Shumë aplikacione janë pjesërisht nativë dhe pjesërisht uebi. Një lojë e shfaq dyqanin, lajmet ose faqet e ndihmës në një WebView; një aplikacion shërbimi shfaq artikuj nga sajti i tij; një aplikacion hibrid e mbështjell pjesën më të madhe të ndërfaqes në përmbajtje uebi. Secila anë ka mekanizmin e vet të pëlqimit: aplikacioni nativ përdor një CMP ose SDK brenda aplikacionit, dhe faqet e uebit ngarkojnë një CMP uebi. Nëse nuk janë të lidhura, përdoruesi pyetet dy herë, zgjedhjet e bëra në një vend shpërfillen në tjetrin, dhe kërkesat për reklama nga brenda WebView dalin me sinjale të gabuara.

Ky udhëzues shpjegon si t'i bëni pëlqimin nativ dhe atë të uebit të përputhen, që përdoruesit të përgjigjen vetëm një herë dhe çdo kërkesë për reklamë të mbajë të njëjtin vendim.

Ku e ruan pëlqimin secila anë

Nativ

IAB TCF përcakton si e ruan pëlqimin një CMP brenda aplikacionit: në NSUserDefaults në iOS dhe në SharedPreferences në Android, me çelësa standardë si IABTCF_TCString, IABTCF_gdprApplies dhe IABTCF_PurposeConsents. SDK-të e reklamave i lexojnë drejtpërdrejt këta çelësa. IAB GPP përcakton çelësa të ngjashëm me parashtesën IABGPP_, si IABGPP_HDR_GppString.

Uebi

Një CMP uebi zakonisht e ruan vendimin e vet në cookie first-party ose në ruajtjen lokale për domenin e sajtit, dhe e ekspozon përmes funksioneve JavaScript __tcfapi dhe __gpp. Etiketat e reklamave në faqe i thërrasin ato funksione, jo ruajtjen native.

Boshllëku

WebView-t kanë hapësirën e tyre të cookie-ve dhe të ruajtjes, të ndarë nga shfletuesi i pajisjes dhe nga preferencat native të aplikacionit. Në iOS, një WKWebView që përdor një depo të dhënash jo të përhershme harron gjithçka kur mbyllet. Asgjë nuk rrjedh mes dy anëve nëse nuk e ndërtoni vetë.

Zgjidhni një burim të vetëm të së vërtetës

Vendimi i parë është cila anë e zotëron pëlqimin. Për shumicën e aplikacioneve përgjigjja është CMP-ja native, sepse:

• Ekzekutohet e para, para se të hapet çfarëdo WebView.
• SDK-të e reklamave native, që zakonisht sjellin pjesën më të madhe të të ardhurave, e lexojnë ruajtjen native.
• Në iOS, mund të koordinohet me kërkesën App Tracking Transparency.

Qasja me uebin në radhë të parë mund të ketë kuptim për aplikacionet hibride ndërfaqja e plotë e të cilave është përmbajtje uebi, por atëherë duhet ta shkruani vendimin prapa në ruajtjen native për SDK-të native.

Kalimi i pëlqimit nativ te WebView

Me nativen si burim të së vërtetës, WebView duhet të shohë të njëjtin vendim. Modele të zakonshme:

1. Injektoni një zbatim të __tcfapi. Para se të ekzekutohen skriptet e faqes, injektoni një skript të vogël që përcakton __tcfapi (dhe __gpp nëse duhet) dhe u përgjigjet thirrjeve me TC string dhe vlerat e lexuara nga ruajtja native. Etiketat e reklamave në faqe e marrin atëherë vendimin nativ përmes API-t standard.
2. Shtypni banerin e uebit. Konfiguroni CMP-në e uebit që të qëndrojë e fshehur kur faqja ngarkohet brenda aplikacionit tuaj, për shembull sipas një parametri kërkese ose një shenje të personalizuar user agent që e kontrolloni ju. Përndryshe përdoruesi sheh një baner të dytë.
3. Kalojeni vargun gjatë ngarkimit. Disa CMP uebi mund të pranojnë një varg pëlqimi ekzistues gjatë inicializimit dhe ta adoptojnë. Shihni dokumentacionin e CMP-së suaj të uebit për metodat e mbështetura.

Cilido model që përdorni, sigurohuni që vlerat e injektuara përditësohen kur përdoruesi e ndryshon zgjedhjen e tij në ekranin e cilësimeve native, jo vetëm në nisjen e radhës së aplikacionit.

Kalimi i pëlqimit të uebit prapa te nativi

Nëse përdoruesit mund ta ndryshojnë pëlqimin brenda WebView, për shembull përmes një faqeje cilësimesh privatësie, aplikacioni duhet ta marrë vesh. Përdorni një urë JavaScript: një trajtues mesazhesh në iOS ose një ndërfaqe JavaScript në Android. Ana e uebit dëgjon me __tcfapi('addEventListener', ...) dhe e dërgon vargun e ri te kodi nativ, që shkruan çelësat standardë. Vlerësoni të dhënat nga WebView para se t'i shkruani; pranoni vetëm mesazhe nga përmbajtja juaj.

Reklamat brenda WebView

Reklamat e shfaqura në një WebView janë reklama uebi. Ato e lexojnë pëlqimin nga faqja, jo nga ruajtja native, përveç nëse SDK i reklamave ofron mënyrë për t'i lidhur. Mobile Ads SDK i Google, për shembull, ofron një API për regjistrimin e WebView-ve që reklamat brenda tyre të mund të përdorin sinjale nga aplikacioni; shihni dokumentacionin aktual për SDK-në tuaj. Në çdo rast, konfirmoni me një test që kërkesat për reklama nga WebView mbajnë të njëjtin TC string ose GPP string si kërkesat native.

Lista e kontrollit të testimit

• Instalim i ri: një kërkesë e vetme pëlqimi, jo dy.
• Refuzoni gjithçka në CMP-në native, hapni një WebView, inspektoni kërkesat për reklama: vargu duhet ta pasqyrojë refuzimin.
• Ndryshoni pëlqimin në cilësimet native, kthehuni te një WebView i hapur: faqja duhet ta shohë vendimin e ri.
• Nëse ekzistojnë cilësime uebi, ndryshoni pëlqimin atje dhe konfirmoni që çelësat native përditësohen.
• Mbylleni me forcë aplikacionin dhe rinisni: vendimet mbeten në të dyja anët.
• Testoni si në iOS ashtu edhe në Android, pasi ruajtja e WebView sillet ndryshe në secilin.

Pikat kryesore

• Pëlqimi nativ dhe ai i WebView jetojnë në depo të ndara dhe nuk sinkronizohen si parazgjedhje.
• Zgjidhni një burim të vetëm të së vërtetës; për shumicën e aplikacioneve është CMP-ja native.
• Ekspozojeni pëlqimin nativ te përmbajtja e uebit përmes një __tcfapi ose __gpp të injektuar dhe fshihni banerin e uebit.
• Përdorni një urë JavaScript për t'i dërguar ndryshimet e uebit prapa në ruajtjen native.
• Kontrolloni që kërkesat për reklama nga WebView mbajnë të njëjtin varg pëlqimi si ato native.