Težava z dvojno pasico

Številne aplikacije so deloma nativne in deloma spletne. Igra svojo trgovino, novice ali strani s pomočjo prikaže v WebViewu; aplikacija za pripomočke prikazuje članke s svojega spletnega mesta; hibridna aplikacija večino vmesnika zavije v spletno vsebino. Vsaka stran ima svoj mehanizem privolitve: nativna aplikacija uporablja CMP ali SDK v aplikaciji, spletne strani pa nalagajo spletni CMP. Če nista povezana, je uporabnik vprašan dvakrat, izbire, opravljene na enem mestu, se na drugem prezrejo, zahteve za oglase iz WebViewa pa odidejo z napačnimi signali.

Ta vodnik obravnava, kako doseči, da se nativna in spletna privolitev ujemata, tako da uporabniki odgovorijo enkrat in vsaka zahteva za oglas nosi isto odločitev.

Kje posamezna stran shranjuje privolitev

Nativno

IAB TCF določa, kako CMP v aplikaciji shranjuje privolitev: v NSUserDefaults na iOS in SharedPreferences na Androidu, s standardnimi ključi, kot so IABTCF_TCString, IABTCF_gdprApplies in IABTCF_PurposeConsents. Oglasni SDK-ji te ključe berejo neposredno. IAB GPP definira podobne ključe s predpono IABGPP_, kot je IABGPP_HDR_GppString.

Splet

Spletni CMP svojo odločitev običajno shrani v piškotke prve osebe ali lokalno shrambo za domeno spletnega mesta in jo izpostavi prek funkcij JavaScript __tcfapi in __gpp. Oglasne oznake na strani kličejo te funkcije, ne nativne shrambe.

Vrzel

WebViewi imajo lasten prostor za piškotke in shrambo, ločen od brskalnika v napravi in ločen od nativnih nastavitev aplikacije. Na iOS WKWebView, ki uporablja nepersistentno shrambo podatkov, ob zaprtju pozabi vse. Med obema stranema nič ne teče, razen če to zgradite.

Izberite en vir resnice

Prva odločitev je, katera stran je lastnik privolitve. Za večino aplikacij je odgovor nativni CMP, ker:

• Se zažene prvi, preden se odpre kateri koli WebView.
• Nativni oglasni SDK-ji, ki običajno ustvarijo večino prihodkov, berejo nativno shrambo.
• Na iOS ga je mogoče uskladiti s pozivom App Tracking Transparency.

Pristop „najprej splet“ je lahko smiseln za hibridne aplikacije, katerih celoten vmesnik je spletna vsebina, vendar morate odločitev nato zapisati nazaj v nativno shrambo za nativne SDK-je.

Posredovanje nativne privolitve v WebView

Ko je vir resnice nativni, mora WebView videti isto odločitev. Pogosti vzorci:

1. Vstavite implementacijo __tcfapi. Preden se izvedejo skripte strani, vstavite majhno skripto, ki definira __tcfapi (in po potrebi __gpp) in na klice odgovarja s TC stringom ter vrednostmi, prebranimi iz nativne shrambe. Oglasne oznake na strani nato prek standardnega API-ja dobijo nativno odločitev.
2. Zatrite spletno pasico. Spletni CMP nastavite tako, da ostane skrit, ko se stran naloži znotraj vaše aplikacije, na primer na podlagi parametra poizvedbe ali žetona po meri v user agentu, ki ga nadzirate. Sicer uporabnik vidi drugo pasico.
3. Posredujte string ob nalaganju. Nekateri spletni CMP-ji lahko ob inicializaciji sprejmejo obstoječi string privolitve in ga prevzamejo. Za podprte metode preverite dokumentacijo svojega spletnega CMP-ja.

Ne glede na vzorec poskrbite, da se vstavljene vrednosti posodobijo, ko uporabnik spremeni izbiro na nativnem zaslonu nastavitev, ne šele ob naslednjem zagonu aplikacije.

Posredovanje spletne privolitve nazaj v nativno

Če lahko uporabniki privolitev spremenijo znotraj WebViewa, na primer prek strani z nastavitvami zasebnosti, mora aplikacija to izvedeti. Uporabite most JavaScript: message handler na iOS ali vmesnik JavaScript na Androidu. Spletna stran posluša z __tcfapi('addEventListener', ...) in nov string pošlje nativni kodi, ki zapiše standardne ključe. Vnos iz WebViewa preverite, preden ga zapišete; sprejemajte samo sporočila iz lastne vsebine.

Oglasi znotraj WebViewov

Oglasi, prikazani v WebViewu, so spletni oglasi. Privolitev berejo s strani, ne iz nativne shrambe, razen če oglasni SDK ne ponuja načina za povezavo obeh. Googlov Mobile Ads SDK na primer ponuja API za registracijo WebViewov, da lahko oglasi v njih uporabljajo signale iz aplikacije; preverite trenutno dokumentacijo za svoj SDK. V vsakem primeru s testom potrdite, da zahteve za oglase iz WebViewa nosijo isti TC ali GPP string kot nativne zahteve za oglase.

Kontrolni seznam za preizkušanje

• Sveža namestitev: en poziv za privolitev, ne dva.
• Zavrnite vse v nativnem CMP-ju, odprite WebView, preglejte zahteve za oglase: string naj odraža zavrnitev.
• Spremenite privolitev v nativnih nastavitvah, vrnite se v odprt WebView: stran naj vidi novo odločitev.
• Če obstajajo spletne nastavitve, tam spremenite privolitev in potrdite, da se nativni ključi posodobijo.
• Ugasnite in znova zaženite aplikacijo: odločitve ostanejo na obeh straneh.
• Preizkusite na iOS in Androidu, ker se shramba WebViewa na vsakem obnaša drugače.

Ključne ugotovitve

• Nativna privolitev in privolitev v WebViewu živita v ločenih shrambah in se privzeto ne sinhronizirata.
• Izberite en vir resnice; za večino aplikacij je to nativni CMP.
• Nativno privolitev izpostavite spletni vsebini prek vstavljenega __tcfapi ali __gpp in skrijte spletno pasico.
• Za pošiljanje spletnih sprememb nazaj v nativno shrambo uporabite most JavaScript.
• Preverite, da zahteve za oglase iz WebViewov nosijo isti string privolitve kot nativne.