Problem dvostrukog bannera

Mnoge su aplikacije djelomično nativne, a djelomično web. Igra prikazuje svoju trgovinu, vijesti ili stranice pomoći u WebViewu; aplikacija-alat prikazuje članke sa svojeg web-mjesta; hibridna aplikacija veći dio sučelja pakira u web sadržaj. Svaka strana ima vlastiti mehanizam privole: nativna aplikacija koristi CMP ili SDK unutar aplikacije, a web stranice učitavaju web CMP. Ako nisu povezani, korisnik se pita dvaput, odabiri učinjeni na jednom mjestu ignoriraju se na drugom, a zahtjevi za oglase iz WebViewa izlaze s pogrešnim signalima.

Ovaj vodič opisuje kako da se nativna i web privola slažu, tako da korisnici odgovore jednom i da svaki zahtjev za oglas nosi istu odluku.

Gdje svaka strana pohranjuje privolu

Nativno

IAB TCF propisuje kako CMP unutar aplikacije pohranjuje privolu: u NSUserDefaults na iOS-u i SharedPreferences na Androidu, pomoću standardnih ključeva poput IABTCF_TCString, IABTCF_gdprApplies i IABTCF_PurposeConsents. Oglasni SDK-ovi čitaju te ključeve izravno. IAB GPP definira slične ključeve s prefiksom IABGPP_, poput IABGPP_HDR_GppString.

Web

Web CMP obično pohranjuje svoju odluku u kolačiće prve strane ili lokalnu pohranu za domenu web-mjesta i izlaže je preko JavaScript funkcija __tcfapi i __gpp. Oglasni tagovi na stranici pozivaju te funkcije, a ne nativnu pohranu.

Praznina

WebViewi imaju vlastiti prostor za kolačiće i pohranu, odvojen od preglednika na uređaju i odvojen od nativnih postavki aplikacije. Na iOS-u WKWebView koji koristi nestalnu pohranu podataka zaboravlja sve kad se zatvori. Ništa ne teče između dviju strana osim ako to ne izgradite.

Odaberite jedan izvor istine

Prva je odluka koja strana posjeduje privolu. Za većinu aplikacija odgovor je nativni CMP, jer:

• Pokreće se prvi, prije otvaranja bilo kojeg WebViewa.
• Nativni oglasni SDK-ovi, koji obično ostvaruju većinu prihoda, čitaju nativnu pohranu.
• Na iOS-u se može koordinirati s App Tracking Transparency upitom.

Pristup „prvo web“ može imati smisla za hibridne aplikacije čije je cijelo sučelje web sadržaj, ali tada morate zapisati odluku natrag u nativnu pohranu za nativne SDK-ove.

Prosljeđivanje nativne privole u WebView

Kad je nativno izvor istine, WebView mora vidjeti istu odluku. Uobičajeni obrasci:

1. Umetnite implementaciju __tcfapi. Prije nego što se skripte stranice izvrše, umetnite malu skriptu koja definira __tcfapi (i __gpp ako je potrebno) i odgovara na pozive TC stringom i vrijednostima pročitanima iz nativne pohrane. Oglasni tagovi na stranici tada dobivaju nativnu odluku preko standardnog API-ja.
2. Potisnite web banner. Podesite web CMP da ostane skriven kad se stranica učitava unutar vaše aplikacije, na primjer na temelju parametra upita ili prilagođenog tokena u user agentu koji kontrolirate. Inače korisnik vidi drugi banner.
3. Proslijedite string pri učitavanju. Neki web CMP-ovi mogu pri inicijalizaciji prihvatiti postojeći string privole i usvojiti ga. Provjerite dokumentaciju svog web CMP-a za podržane metode.

Koji god obrazac koristili, pobrinite se da se umetnute vrijednosti ažuriraju kad korisnik promijeni odabir na nativnom zaslonu postavki, a ne tek pri sljedećem pokretanju aplikacije.

Vraćanje web privole u nativno

Ako korisnici mogu promijeniti privolu unutar WebViewa, na primjer preko stranice postavki privatnosti, aplikacija mora saznati za to. Koristite JavaScript most: message handler na iOS-u ili JavaScript sučelje na Androidu. Web strana sluša pomoću __tcfapi('addEventListener', ...) i šalje novi string nativnom kodu, koji zapisuje standardne ključeve. Provjerite ulaz iz WebViewa prije zapisivanja; prihvaćajte samo poruke iz vlastitog sadržaja.

Oglasi unutar WebViewa

Oglasi prikazani u WebViewu su web oglasi. Čitaju privolu sa stranice, a ne iz nativne pohrane, osim ako oglasni SDK ne pruža način da se to dvoje poveže. Googleov Mobile Ads SDK, primjerice, nudi API za registraciju WebViewa kako bi oglasi unutar njih mogli koristiti signale iz aplikacije; provjerite aktualnu dokumentaciju za svoj SDK. U svakom slučaju, testom potvrdite da zahtjevi za oglase iz WebViewa nose isti TC ili GPP string kao nativni zahtjevi za oglase.

Kontrolni popis za testiranje

• Svježa instalacija: jedan upit za privolu, ne dva.
• Odbijte sve u nativnom CMP-u, otvorite WebView, pregledajte zahtjeve za oglase: string treba odražavati odbijanje.
• Promijenite privolu u nativnim postavkama, vratite se u otvoreni WebView: stranica treba vidjeti novu odluku.
• Ako postoje web postavke, promijenite privolu tamo i potvrdite da se nativni ključevi ažuriraju.
• Prekinite i ponovno pokrenite aplikaciju: odluke traju na obje strane.
• Testirajte i na iOS-u i na Androidu, jer se pohrana WebViewa na svakom ponaša drukčije.

Ključni zaključci

• Nativna privola i privola u WebViewu žive u odvojenim pohranama i zadano se ne sinkroniziraju.
• Odaberite jedan izvor istine; za većinu aplikacija to je nativni CMP.
• Izložite nativnu privolu web sadržaju preko umetnutog __tcfapi ili __gpp i sakrijte web banner.
• Koristite JavaScript most da pošaljete web izmjene natrag u nativnu pohranu.
• Provjerite da zahtjevi za oglase iz WebViewa nose isti string privole kao nativni.