Topeltbänneri probleem

Paljud rakendused on osaliselt natiivsed ja osaliselt veebipõhised. Mäng näitab oma poodi, uudiseid või abilehti WebView's; utiliitrakendus renderdab artikleid oma veebisaidilt; hübriidrakendus pakib suurema osa oma liidesest veebisisu sisse. Mõlemal poolel on oma nõusolekumehhanism: natiivrakendus kasutab rakendusesisest CMP-d või SDK-d ja veebilehed laadivad veebi-CMP. Kui need pole ühendatud, küsitakse kasutajalt kaks korda, ühes kohas tehtud valikuid ignoreeritakse teises ja reklaamipäringud WebView seest lähevad välja valede signaalidega.

See juhend käsitleb, kuidas panna natiivne ja veebi nõusolek kokku sobima, nii et kasutajad vastavad ühe korra ja iga reklaamipäring kannab sama otsust.

Kus kumbki pool nõusolekut hoiab

Natiivne

IAB TCF määrab, kuidas rakendusesisene CMP nõusolekut salvestab: iOS-is NSUserDefaults'is ja Androidis SharedPreferences'is, kasutades standardseid võtmeid nagu IABTCF_TCString, IABTCF_gdprApplies ja IABTCF_PurposeConsents. Reklaami-SDK-d loevad neid võtmeid otse. IAB GPP defineerib sarnased võtmed prefiksiga IABGPP_, näiteks IABGPP_HDR_GppString.

Veeb

Veebi-CMP salvestab oma otsuse tavaliselt esimese osapoole küpsistesse või kohalikku salvestusruumi saidi domeeni jaoks ning avab selle JavaScripti funktsioonide __tcfapi ja __gpp kaudu. Lehel olevad reklaamimärgendid kutsuvad neid funktsioone, mitte natiivset salvestust.

Lünk

WebView'del on oma küpsiste ja salvestuse ruum, mis on eraldi seadme brauserist ja eraldi rakenduse natiivsetest eelistustest. iOS-is unustab mittepüsivat andmesalve kasutav WKWebView kõik, kui see suletakse. Midagi ei liigu kahe poole vahel, kui sa seda ei ehita.

Vali üks tõe allikas

Esimene otsus on, kumb pool nõusolekut omab. Enamiku rakenduste puhul on vastus natiivne CMP, sest:

• See käivitub esimesena, enne mis tahes WebView avamist.
• Natiivsed reklaami-SDK-d, mis tavaliselt teenivad suurema osa tulust, loevad natiivset salvestust.
• iOS-is saab seda koordineerida App Tracking Transparency küsimisega.

Veebi esikoht võib olla mõistlik hübriidrakenduste puhul, mille kogu liides on veebisisu, kuid siis pead otsuse natiivsetele SDK-dele tagasi natiivsesse salvestusse kirjutama.

Natiivse nõusoleku andmine WebView'le

Kui natiivne on tõe allikas, peab WebView nägema sama otsust. Levinud mustrid:

1. Süsti sisse __tcfapi implementatsioon. Enne lehe skriptide käivitumist süsti väikese skripti, mis defineerib __tcfapi (ja vajadusel __gpp) ning vastab kutsetele TC-stringi ja natiivsest salvestusest loetud väärtustega. Lehel olevad reklaamimärgendid saavad natiivse otsuse standardse API kaudu.
2. Suru veebibänner alla. Seadista veebi-CMP jääma peidetuks, kui leht laaditakse sinu rakenduse sees, näiteks päringuparameetri või sinu kontrollitava kohandatud user agent'i märgi alusel. Vastasel juhul näeb kasutaja teist bännerit.
3. Anna string edasi laadimisel. Mõned veebi-CMP-d saavad lähtestamisel vastu võtta olemasoleva nõusolekustringi ja selle omaks võtta. Toetatud meetodeid vaata oma veebi-CMP dokumentatsioonist.

Olenemata mustrist veendu, et süstitud väärtused uuenevad, kui kasutaja muudab oma valikut natiivsete seadete ekraanil, mitte ainult rakenduse järgmisel käivitamisel.

Veebinõusoleku tagasi andmine natiivsele poolele

Kui kasutajad saavad nõusolekut WebView sees muuta, näiteks privaatsusseadete lehe kaudu, peab rakendus sellest teada saama. Kasuta JavaScripti silda: sõnumikäsitlejat iOS-is või JavaScripti liidest Androidis. Veebipool kuulab käsuga __tcfapi('addEventListener', ...) ja saadab uue stringi natiivsele koodile, mis kirjutab standardsed võtmed. Valideeri WebView'st tulev sisend enne kirjutamist; võta vastu ainult sõnumeid oma sisust.

Reklaamid WebView'des

WebView's renderdatud reklaamid on veebireklaamid. Nad loevad nõusolekut lehelt, mitte natiivsest salvestusest, kui reklaami-SDK ei paku viisi kahe sidumiseks. Näiteks Google'i Mobile Ads SDK pakub API-d WebView'de registreerimiseks, et nende sees olevad reklaamid saaksid kasutada rakenduse signaale; kontrolli oma SDK jaoks praegust dokumentatsiooni. Igal juhul veendu testiga, et WebView'st tulevad reklaamipäringud kannavad sama TC- või GPP-stringi mis natiivsed reklaamipäringud.

Testimise kontrollnimekiri

• Värske install: üks nõusolekuküsimine, mitte kaks.
• Lükka natiivses CMP-s kõik tagasi, ava WebView, uuri reklaamipäringuid: string peaks tagasilükkamist kajastama.
• Muuda nõusolekut natiivsetes seadetes, naase avatud WebView'sse: leht peaks nägema uut otsust.
• Kui veebiseaded on olemas, muuda nõusolekut seal ja veendu, et natiivsed võtmed uuenevad.
• Sulge rakendus sundkorras ja käivita uuesti: otsused säilivad mõlemal poolel.
• Testi nii iOS-is kui ka Androidis, kuna WebView salvestus käitub kummaski erinevalt.

Peamised järeldused

• Natiivne ja WebView nõusolek elavad eraldi salvestustes ning ei sünkroniseeru vaikimisi.
• Vali üks tõe allikas; enamiku rakenduste puhul on see natiivne CMP.
• Ava natiivne nõusolek veebisisule süstitud __tcfapi või __gpp kaudu ja peida veebibänner.
• Kasuta JavaScripti silda, et saata veebimuudatused tagasi natiivsesse salvestusse.
• Veendu, et WebView'st tulevad reklaamipäringud kannavad sama nõusolekustringi mis natiivsed.