Problemet med doble bannere

Mange apper er delvis native og delvis web. Et spill viser butikken, nyheter eller hjelpesider i en WebView; en utility-app gjengir artikler fra nettstedet sitt; en hybridapp pakker mesteparten av grensesnittet inn i webinnhold. Hver side har sin egen samtykkemekanisme: den native appen bruker en in-app CMP eller SDK, og nettsidene laster en web-CMP. Med mindre de er koblet sammen, blir brukeren spurt to ganger, valg gjort ett sted ignoreres det andre, og annonseforespørsler fra WebView-en går ut med feil signaler.

Denne veiledningen viser hvordan du får native og web-samtykke til å stemme overens, slik at brukerne svarer én gang og hver annonseforespørsel bærer den samme beslutningen.

Hvor hver side lagrer samtykke

Native

IAB TCF spesifiserer hvordan en in-app CMP lagrer samtykke: i NSUserDefaults på iOS og SharedPreferences på Android, med standardnøkler som IABTCF_TCString, IABTCF_gdprApplies og IABTCF_PurposeConsents. Annonse-SDK-er leser disse nøklene direkte. IAB GPP definerer lignende nøkler med prefikset IABGPP_, som IABGPP_HDR_GppString.

Web

En web-CMP lagrer vanligvis beslutningen sin i førsteparts informasjonskapsler eller lokal lagring for nettstedets domene, og eksponerer den gjennom JavaScript-funksjonene __tcfapi og __gpp. Annonsetagger på siden kaller disse funksjonene, ikke den native lagringen.

Gapet

WebViews har sitt eget rom for informasjonskapsler og lagring, adskilt fra enhetens nettleser og fra appens native preferanser. På iOS glemmer en WKWebView med et ikke-vedvarende datalager alt når den lukkes. Ingenting flyter mellom de to sidene med mindre du bygger det.

Velg én sannhetskilde

Den første beslutningen er hvilken side som eier samtykket. For de fleste apper er svaret den native CMP-en, fordi:

• den kjører først, før noen WebView åpnes.
• native annonse-SDK-er, som vanligvis tjener mesteparten av inntektene, leser den native lagringen.
• den på iOS kan koordineres med App Tracking Transparency-forespørselen.

Web først kan gi mening for hybridapper der hele grensesnittet er webinnhold, men da må du skrive beslutningen tilbake til den native lagringen for native SDK-er.

Å sende native samtykke inn i WebView-en

Med native som sannhetskilde må WebView-en se den samme beslutningen. Vanlige mønstre:

1. Injiser en __tcfapi-implementering. Injiser, før sidens skript kjører, et lite skript som definerer __tcfapi (og __gpp ved behov) og besvarer kall med TC-strengen og verdier lest fra den native lagringen. Annonsetagger på siden får da den native beslutningen gjennom standard-API-et.
2. Undertrykk webbanneret. Konfigurer web-CMP-en til å forbli skjult når siden lastes inne i appen din, for eksempel basert på en spørringsparameter eller et user agent-token du selv kontrollerer. Ellers ser brukeren et nytt banner.
3. Send strengen med ved innlasting. Noen web-CMP-er kan ta imot en eksisterende samtykkestreng ved initialisering og overta den. Sjekk web-CMP-ens dokumentasjon for støttede metoder.

Uansett hvilket mønster du bruker, sørg for at de injiserte verdiene oppdateres når brukeren endrer valget sitt på den native innstillingsskjermen, og ikke først ved neste oppstart av appen.

Å sende websamtykke tilbake til native

Hvis brukere kan endre samtykke inne i WebView-en, for eksempel gjennom en side for personverninnstillinger, må appen få vite det. Bruk en JavaScript-bridge: en message handler på iOS eller et JavaScript-grensesnitt på Android. Webdelen lytter med __tcfapi('addEventListener', ...) og sender den nye strengen til native kode, som skriver standardnøklene. Valider input fra WebView-en før du skriver det; godta bare meldinger fra ditt eget innhold.

Annonser inne i WebViews

Annonser som gjengis i en WebView er webannonser. De leser samtykke fra siden, ikke fra den native lagringen, med mindre annonse-SDK-en gir en måte å koble de to sammen. Googles Mobile Ads SDK tilbyr for eksempel et API for å registrere WebViews slik at annonser i dem kan bruke signaler fra appen; sjekk gjeldende dokumentasjon for SDK-en din. Bekreft uansett med en test at annonseforespørsler fra WebView-en bærer den samme TC- eller GPP-strengen som native annonseforespørsler.

Testsjekkliste

• Fersk installasjon: én samtykkeforespørsel, ikke to.
• Avvis alle i den native CMP-en, åpne en WebView, inspiser annonseforespørsler: strengen bør gjenspeile avvisningen.
• Endre samtykke i de native innstillingene, gå tilbake til en åpen WebView: siden bør se den nye beslutningen.
• Hvis det finnes webinnstillinger, endre samtykke der og bekreft at de native nøklene oppdateres.
• Avslutt og start appen på nytt: beslutninger består på begge sider.
• Test på både iOS og Android, siden WebView-lagring oppfører seg ulikt på hver.

Viktigste poenger

• Native og WebView-samtykke bor i separate lagre og synkroniseres ikke som standard.
• Velg én sannhetskilde; for de fleste apper er det den native CMP-en.
• Eksponer native samtykke for webinnhold gjennom en injisert __tcfapi eller __gpp, og skjul webbanneret.
• Bruk en JavaScript-bridge for å sende webendringer tilbake til den native lagringen.
• Sjekk at annonseforespørsler fra WebViews bærer den samme samtykkestrengen som native forespørsler.