Dubultā banera problēma

Daudzas lietotnes ir daļēji natīvas un daļēji tīmekļa. Spēle savu veikalu, ziņas vai palīdzības lapas rāda WebView; utilītlietotne attēlo rakstus no savas vietnes; hibrīdlietotne lielāko daļu saskarnes ietin tīmekļa saturā. Katrai pusei ir savs piekrišanas mehānisms: natīvā lietotne izmanto lietotnes CMP vai SDK, bet tīmekļa lapas ielādē tīmekļa CMP. Ja tās nav savienotas, lietotājam jautā divreiz, vienā vietā izdarītās izvēles otrā tiek ignorētas, un reklāmu pieprasījumi no WebView iekšienes tiek nosūtīti ar nepareiziem signāliem.

Šis ceļvedis aptver to, kā panākt, lai natīvā un tīmekļa piekrišana saskan, lai lietotāji atbildētu vienreiz un katrs reklāmas pieprasījums nestu to pašu lēmumu.

Kur katra puse glabā piekrišanu

Natīvā puse

IAB TCF nosaka, kā lietotnes CMP glabā piekrišanu: iOS NSUserDefaults un Android SharedPreferences, izmantojot standarta atslēgas, piemēram, IABTCF_TCString, IABTCF_gdprApplies un IABTCF_PurposeConsents. Reklāmu SDK šīs atslēgas nolasa tieši. IAB GPP definē līdzīgas atslēgas ar prefiksu IABGPP_, piemēram, IABGPP_HDR_GppString.

Tīmekļa puse

Tīmekļa CMP parasti glabā savu lēmumu pirmās puses sīkdatnēs vai lokālajā krātuvē vietnes domēnam un atklāj to ar JavaScript funkcijām __tcfapi un __gpp. Lapas reklāmu tagi izsauc šīs funkcijas, nevis natīvo krātuvi.

Plaisa

WebView ir sava sīkdatņu un krātuves telpa, atsevišķa no ierīces pārlūka un atsevišķa no lietotnes natīvajiem iestatījumiem. iOS WKWebView, kas izmanto nepastāvīgu datu krātuvi, aizmirst visu, kad tiek aizvērts. Nekas nepārvietojas starp abām pusēm, ja jūs to neizveidojat.

Izvēlieties vienu patiesības avotu

Pirmais lēmums ir, kurai pusei pieder piekrišana. Lielākajai daļai lietotņu atbilde ir natīvais CMP, jo:

• Tas darbojas pirmais, pirms tiek atvērts jebkurš WebView.
• Natīvie reklāmu SDK, kas parasti nopelna lielāko daļu ieņēmumu, nolasa natīvo krātuvi.
• iOS to var koordinēt ar App Tracking Transparency uzvedni.

Tīmekļa prioritāte var būt saprātīga hibrīdlietotnēm, kuru visa saskarne ir tīmekļa saturs, taču tad lēmums jāieraksta atpakaļ natīvajā krātuvē natīvajiem SDK.

Natīvās piekrišanas nodošana WebView

Ja patiesības avots ir natīvais, WebView jāredz tas pats lēmums. Izplatītas shēmas:

1. Ievietojiet __tcfapi implementāciju. Pirms lapas skriptu palaišanas ievietojiet nelielu skriptu, kas definē __tcfapi (un vajadzības gadījumā __gpp) un atbild uz izsaukumiem ar TC string un vērtībām, kas nolasītas no natīvās krātuves. Lapas reklāmu tagi tad saņem natīvo lēmumu caur standarta API.
2. Apslāpējiet tīmekļa baneri. Konfigurējiet tīmekļa CMP, lai tas paliktu paslēpts, kad lapa tiek ielādēta jūsu lietotnē, piemēram, pēc vaicājuma parametra vai pielāgota user agent žetona, ko kontrolējat jūs. Pretējā gadījumā lietotājs redz otru baneri.
3. Nododiet virkni ielādes laikā. Daži tīmekļa CMP inicializācijas brīdī var pieņemt esošu piekrišanas virkni un to pārņemt. Atbalstītās metodes meklējiet sava tīmekļa CMP dokumentācijā.

Neatkarīgi no izmantotās shēmas, pārliecinieties, ka ievietotās vērtības tiek atjauninātas, kad lietotājs maina izvēli natīvo iestatījumu ekrānā, nevis tikai nākamajā lietotnes palaišanas reizē.

Tīmekļa piekrišanas nodošana atpakaļ natīvajai pusei

Ja lietotāji var mainīt piekrišanu WebView iekšienē, piemēram, caur privātuma iestatījumu lapu, lietotnei par to jāuzzina. Izmantojiet JavaScript tiltu: ziņojumu apstrādātāju iOS vai JavaScript saskarni Android. Tīmekļa puse klausās ar __tcfapi('addEventListener', ...) un nosūta jauno virkni natīvajam kodam, kas ieraksta standarta atslēgas. Pirms rakstīšanas validējiet WebView ievadi; pieņemiet tikai ziņojumus no sava satura.

Reklāmas WebView iekšienē

WebView attēlotās reklāmas ir tīmekļa reklāmas. Tās nolasa piekrišanu no lapas, nevis no natīvās krātuves, ja vien reklāmu SDK nenodrošina veidu, kā abus saistīt. Piemēram, Google Mobile Ads SDK piedāvā API WebView reģistrēšanai, lai reklāmas tajos varētu izmantot lietotnes signālus; aktuālo dokumentāciju savam SDK pārbaudiet. Jebkurā gadījumā ar testu pārliecinieties, ka reklāmu pieprasījumi no WebView nes to pašu TC vai GPP virkni kā natīvie reklāmu pieprasījumi.

Testēšanas kontrolsaraksts

• Jauna instalēšana: viena piekrišanas uzvedne, nevis divas.
• Natīvajā CMP noraidiet visu, atveriet WebView, pārbaudiet reklāmu pieprasījumus: virknei jāatspoguļo noraidījums.
• Mainiet piekrišanu natīvajos iestatījumos, atgriezieties atvērtā WebView: lapai jāredz jaunais lēmums.
• Ja pastāv tīmekļa iestatījumi, mainiet piekrišanu tur un pārliecinieties, ka natīvās atslēgas atjaunojas.
• Apturiet un atkārtoti palaidiet lietotni: lēmumi saglabājas abās pusēs.
• Pārbaudiet gan iOS, gan Android, jo WebView krātuve katrā uzvedas citādi.

Galvenie secinājumi

• Natīvā un WebView piekrišana atrodas atsevišķās krātuvēs un pēc noklusējuma nesinhronizējas.
• Izvēlieties vienu patiesības avotu; lielākajai daļai lietotņu tas ir natīvais CMP.
• Natīvo piekrišanu tīmekļa saturam atklājiet ar ievietotu __tcfapi vai __gpp un paslēpiet tīmekļa baneri.
• Izmantojiet JavaScript tiltu, lai tīmekļa izmaiņas nosūtītu atpakaļ natīvajā krātuvē.
• Pārbaudiet, vai reklāmu pieprasījumi no WebView nes to pašu piekrišanas virkni kā natīvie.