Problemet med dubbla bannrar

Många appar är delvis nativa och delvis webbaserade. Ett spel visar sin butik, sina nyheter eller hjälpsidor i en WebView; en verktygsapp renderar artiklar från sin webbplats; en hybridapp lindar in större delen av sitt gränssnitt i webbinnehåll. Varje sida har sin egen samtyckesmekanism: den nativa appen använder en CMP eller SDK i appen, och webbsidorna laddar en webb-CMP. Om de inte är kopplade till varandra tillfrågas användaren två gånger, val som görs på ett ställe ignoreras på det andra, och annonsförfrågningar inifrån WebView skickas med fel signaler.

Den här guiden går igenom hur du får nativt och webbaserat samtycke att stämma överens, så att användare svarar en gång och varje annonsförfrågan bär samma beslut.

Var varje sida lagrar samtycke

Nativt

IAB TCF anger hur en CMP i appen lagrar samtycke: i NSUserDefaults på iOS och SharedPreferences på Android, med standardnycklar som IABTCF_TCString, IABTCF_gdprApplies och IABTCF_PurposeConsents. Annons-SDK:er läser dessa nycklar direkt. IAB GPP definierar liknande nycklar med prefixet IABGPP_, till exempel IABGPP_HDR_GppString.

Webb

En webb-CMP lagrar vanligtvis sitt beslut i förstapartscookies eller lokal lagring för webbplatsens domän och exponerar det via JavaScript-funktionerna __tcfapi och __gpp. Annonstaggar på sidan anropar de funktionerna, inte nativ lagring.

Gapet

WebViews har sitt eget utrymme för cookies och lagring, skilt från enhetens webbläsare och skilt från appens nativa inställningar. På iOS glömmer en WKWebView som använder ett icke-beständigt datalager allt när den stängs. Ingenting flödar mellan de två sidorna om du inte bygger det.

Välj en enda sanningskälla

Det första beslutet är vilken sida som äger samtycket. För de flesta appar är svaret den nativa CMP:n, eftersom:

• Den körs först, innan någon WebView öppnas.
• Nativa annons-SDK:er, som vanligtvis tjänar de flesta intäkterna, läser nativ lagring.
• På iOS kan den samordnas med App Tracking Transparency-frågan.

Webb först kan vara rimligt för hybridappar vars hela gränssnitt är webbinnehåll, men då måste du skriva tillbaka beslutet till nativ lagring för nativa SDK:er.

Skicka nativt samtycke in i WebView

Med nativt som sanningskälla måste WebView se samma beslut. Vanliga mönster:

1. Injicera en __tcfapi-implementation. Innan sidans skript körs, injicera ett litet skript som definierar __tcfapi (och __gpp vid behov) och svarar på anrop med TC-strängen och värden som lästs från nativ lagring. Annonstaggar på sidan får då det nativa beslutet via standard-API:t.
2. Tysta webbbannern. Konfigurera webb-CMP:n att förbli dold när sidan laddas inuti din app, till exempel baserat på en frågeparameter eller en egen user agent-token som du styr. Annars ser användaren en andra banner.
3. Skicka strängen vid laddning. Vissa webb-CMP:er kan ta emot en befintlig samtyckessträng vid initiering och anta den. Kontrollera din webb-CMP:s dokumentation för metoder som stöds.

Oavsett vilket mönster du använder, se till att de injicerade värdena uppdateras när användaren ändrar sitt val på den nativa inställningsskärmen, inte bara vid nästa appstart.

Skicka webbsamtycke tillbaka till nativt

Om användare kan ändra samtycke inuti WebView, till exempel via en sida för integritetsinställningar, måste appen få veta det. Använd en JavaScript-brygga: en meddelandehanterare på iOS eller ett JavaScript-gränssnitt på Android. Webbsidan lyssnar med __tcfapi('addEventListener', ...) och skickar den nya strängen till nativ kod, som skriver standardnycklarna. Validera indata från WebView innan du skriver; acceptera bara meddelanden från ditt eget innehåll.

Annonser i WebViews

Annonser som renderas i en WebView är webbannonser. De läser samtycke från sidan, inte från nativ lagring, om inte annons-SDK:n erbjuder ett sätt att länka de två. Googles Mobile Ads SDK erbjuder till exempel ett API för att registrera WebViews så att annonser i dem kan använda signaler från appen; kontrollera aktuell dokumentation för din SDK. Bekräfta i alla fall med ett test att annonsförfrågningar från WebView bär samma TC- eller GPP-sträng som nativa annonsförfrågningar.

Checklista för testning

• Nyinstallation: en samtyckesfråga, inte två.
• Avvisa allt i den nativa CMP:n, öppna en WebView, granska annonsförfrågningar: strängen ska spegla avvisandet.
• Ändra samtycke i nativa inställningar, återvänd till en öppen WebView: sidan ska se det nya beslutet.
• Om webbinställningar finns, ändra samtycke där och bekräfta att de nativa nycklarna uppdateras.
• Avsluta och starta om appen: besluten kvarstår på båda sidor.
• Testa på både iOS och Android, eftersom WebView-lagring beter sig olika på respektive plattform.

Viktiga slutsatser

• Nativt och WebView-samtycke finns i separata lager och synkroniseras inte som standard.
• Välj en sanningskälla; för de flesta appar är det den nativa CMP:n.
• Exponera nativt samtycke för webbinnehåll via en injicerad __tcfapi eller __gpp och dölj webbbannern.
• Använd en JavaScript-brygga för att skicka webbändringar tillbaka till nativ lagring.
• Kontrollera att annonsförfrågningar från WebViews bär samma samtyckessträng som nativa.