Kaksoisbannerin ongelma

Monet sovellukset ovat osittain natiiveja ja osittain verkkopohjaisia. Peli näyttää kauppansa, uutisensa tai ohjesivunsa WebViewissä; apuohjelmasovellus renderöi artikkeleita verkkosivustoltaan; hybridisovellus käärii suurimman osan käyttöliittymästään verkkosisältöön. Kummallakin puolella on oma suostumusmekanisminsa: natiivisovellus käyttää sovelluksen sisäistä CMP:tä tai SDK:ta, ja verkkosivut lataavat verkko-CMP:n. Ellei niitä yhdistetä, käyttäjältä kysytään kahdesti, toisaalla tehdyt valinnat jätetään huomiotta toisaalla ja mainospyynnöt WebViewn sisältä lähtevät väärillä signaaleilla.

Tämä opas käsittelee, miten natiivi ja verkon suostumus saadaan täsmäämään, jotta käyttäjät vastaavat kerran ja jokainen mainospyyntö kantaa saman päätöksen.

Missä kumpikin puoli säilyttää suostumuksen

Natiivi

IAB TCF määrittelee, miten sovelluksen sisäinen CMP tallentaa suostumuksen: iOS:llä NSUserDefaultsiin ja Androidilla SharedPreferencesiin, käyttäen vakioavaimia kuten IABTCF_TCString, IABTCF_gdprApplies ja IABTCF_PurposeConsents. Mainos-SDK:t lukevat nämä avaimet suoraan. IAB GPP määrittelee vastaavat avaimet etuliitteellä IABGPP_, kuten IABGPP_HDR_GppString.

Verkko

Verkko-CMP tallentaa päätöksensä tyypillisesti ensimmäisen osapuolen evästeisiin tai paikalliseen tallennustilaan sivuston verkkotunnukselle ja tarjoaa sen JavaScript-funktioiden __tcfapi ja __gpp kautta. Sivun mainostagit kutsuvat näitä funktioita, eivät natiivia tallennustilaa.

Aukko

WebVieweillä on oma eväste- ja tallennustilansa, erillään laitteen selaimesta ja erillään sovelluksen natiiviasetuksista. iOS:llä WKWebView, joka käyttää ei-pysyvää tietovarastoa, unohtaa kaiken sulkeutuessaan. Mikään ei liiku näiden kahden puolen välillä, ellet rakenna sitä.

Valitse yksi totuuden lähde

Ensimmäinen päätös on, kumpi puoli omistaa suostumuksen. Useimmille sovelluksille vastaus on natiivi CMP, koska:

• Se suoritetaan ensimmäisenä, ennen kuin mitään WebViewtä avataan.
• Natiivit mainos-SDK:t, jotka yleensä ansaitsevat suurimman osan tuloista, lukevat natiivia tallennustilaa.
• iOS:llä se voidaan koordinoida App Tracking Transparency -kehotteen kanssa.

Verkko ensin voi olla järkevää hybridisovelluksille, joiden koko käyttöliittymä on verkkosisältöä, mutta silloin päätös on kirjoitettava takaisin natiiviin tallennustilaan natiiveja SDK:ita varten.

Natiivin suostumuksen välittäminen WebViewlle

Kun natiivi on totuuden lähde, WebViewn on nähtävä sama päätös. Yleisiä malleja:

1. Injektoi __tcfapi-toteutus. Ennen sivun skriptien suoritusta injektoi pieni skripti, joka määrittelee __tcfapi:n (ja tarvittaessa __gpp:n) ja vastaa kutsuihin TC-merkkijonolla ja natiivista tallennustilasta luetuilla arvoilla. Sivun mainostagit saavat natiivin päätöksen vakiorajapinnan kautta.
2. Hiljennä verkkobanneri. Määritä verkko-CMP pysymään piilossa, kun sivu ladataan sovelluksesi sisällä, esimerkiksi kyselyparametrin tai hallitsemasi mukautetun user agent -tunnisteen perusteella. Muuten käyttäjä näkee toisen bannerin.
3. Välitä merkkijono latauksessa. Jotkin verkko-CMP:t voivat ottaa alustuksessa vastaan olemassa olevan suostumusmerkkijonon ja omaksua sen. Tarkista tuetut menetelmät verkko-CMP:si dokumentaatiosta.

Mitä mallia käytätkin, varmista, että injektoidut arvot päivittyvät, kun käyttäjä muuttaa valintaansa natiivissa asetusnäytössä, eikä vain sovelluksen seuraavalla käynnistyksellä.

Verkon suostumuksen välittäminen takaisin natiiville

Jos käyttäjät voivat muuttaa suostumusta WebViewn sisällä, esimerkiksi tietosuoja-asetussivun kautta, sovelluksen on saatava siitä tieto. Käytä JavaScript-siltaa: viestinkäsittelijää iOS:llä tai JavaScript-rajapintaa Androidilla. Verkkopuoli kuuntelee komennolla __tcfapi('addEventListener', ...) ja lähettää uuden merkkijonon natiivikoodille, joka kirjoittaa vakioavaimet. Validoi WebViewn syöte ennen kirjoittamista; hyväksy viestejä vain omalta sisällöltäsi.

Mainokset WebVieweissä

WebViewssä renderöidyt mainokset ovat verkkomainoksia. Ne lukevat suostumuksen sivulta, eivät natiivista tallennustilasta, ellei mainos-SDK tarjoa tapaa linkittää näitä kahta. Esimerkiksi Googlen Mobile Ads SDK tarjoaa rajapinnan WebViewien rekisteröintiin, jotta niiden sisällä olevat mainokset voivat käyttää sovelluksen signaaleja; tarkista SDK:si ajantasainen dokumentaatio. Varmista joka tapauksessa testillä, että WebViewn mainospyynnöt kantavat saman TC- tai GPP-merkkijonon kuin natiivit mainospyynnöt.

Testauksen tarkistuslista

• Uusi asennus: yksi suostumuskehote, ei kaksi.
• Hylkää kaikki natiivissa CMP:ssä, avaa WebView, tarkista mainospyynnöt: merkkijonon tulisi heijastaa hylkäystä.
• Muuta suostumusta natiiviasetuksissa, palaa avoimeen WebViewhin: sivun pitäisi nähdä uusi päätös.
• Jos verkkoasetukset ovat olemassa, muuta suostumusta siellä ja varmista, että natiivit avaimet päivittyvät.
• Sulje sovellus pakolla ja käynnistä uudelleen: päätökset säilyvät molemmilla puolilla.
• Testaa sekä iOS:llä että Androidilla, koska WebViewn tallennustila toimii kummallakin eri tavoin.

Keskeiset opit

• Natiivi ja WebView-suostumus elävät erillisissä tallennustiloissa eivätkä synkronoidu oletuksena.
• Valitse yksi totuuden lähde; useimmille sovelluksille se on natiivi CMP.
• Tarjoa natiivi suostumus verkkosisällölle injektoidun __tcfapi:n tai __gpp:n kautta ja piilota verkkobanneri.
• Käytä JavaScript-siltaa välittämään verkon muutokset takaisin natiiviin tallennustilaan.
• Tarkista, että WebViewn mainospyynnöt kantavat saman suostumusmerkkijonon kuin natiivit.