Problemet med dobbelte bannere

Mange apps er delvis native og delvis web. Et spil viser sin butik, nyheder eller hjælpesider i en WebView; en utility-app renderer artikler fra sit websted; en hybridapp pakker størstedelen af sin brugerflade ind i webindhold. Hver side har sin egen samtykkemekanisme: den native app bruger en in-app CMP eller SDK, og websiderne indlæser en web-CMP. Medmindre de er forbundet, bliver brugeren spurgt to gange, valg truffet det ene sted ignoreres det andet, og annonceforespørgsler fra WebView'en går ud med de forkerte signaler.

Denne vejledning gennemgår, hvordan du får native og web-samtykke til at stemme overens, så brugerne svarer én gang, og hver annonceforespørgsel bærer den samme beslutning.

Hvor hver side gemmer samtykke

Native

IAB TCF specificerer, hvordan en in-app CMP gemmer samtykke: i NSUserDefaults på iOS og SharedPreferences på Android, med standardnøgler som IABTCF_TCString, IABTCF_gdprApplies og IABTCF_PurposeConsents. Annonce-SDK'er læser disse nøgler direkte. IAB GPP definerer lignende nøgler med præfikset IABGPP_, såsom IABGPP_HDR_GppString.

Web

En web-CMP gemmer typisk sin beslutning i førsteparts-cookies eller lokal lagring for webstedets domæne og eksponerer den gennem JavaScript-funktionerne __tcfapi og __gpp. Annoncetags på siden kalder disse funktioner, ikke den native lagring.

Kløften

WebViews har deres eget cookie- og lagerrum, adskilt fra enhedens browser og fra appens native præferencer. På iOS glemmer en WKWebView med et ikke-vedvarende datalager alt, når den lukkes. Intet flyder mellem de to sider, medmindre du bygger det.

Vælg én sandhedskilde

Den første beslutning er, hvilken side der ejer samtykket. For de fleste apps er svaret den native CMP, fordi:

• den kører først, før nogen WebView åbnes.
• native annonce-SDK'er, som normalt tjener det meste af indtægterne, læser den native lagring.
• den på iOS kan koordineres med prompten fra App Tracking Transparency.

Web først kan give mening for hybridapps, hvis hele brugerflade er webindhold, men så skal du skrive beslutningen tilbage til den native lagring til native SDK'er.

Videregivelse af native samtykke til WebView'en

Med native som sandhedskilde skal WebView'en se den samme beslutning. Almindelige mønstre:

1. Injicér en __tcfapi-implementering. Injicér, før sidens scripts kører, et lille script, der definerer __tcfapi (og __gpp om nødvendigt) og besvarer kald med TC-strengen og værdier læst fra den native lagring. Annoncetags på siden får så den native beslutning gennem standard-API'et.
2. Undertryk webbanneret. Konfigurér web-CMP'en til at forblive skjult, når siden indlæses i din app, for eksempel baseret på en queryparameter eller et user agent-token, du selv kontrollerer. Ellers ser brugeren et andet banner.
3. Send strengen med ved indlæsning. Nogle web-CMP'er kan modtage en eksisterende samtykkestreng ved initialisering og overtage den. Tjek din web-CMP's dokumentation for understøttede metoder.

Uanset hvilket mønster du bruger, så sørg for, at de injicerede værdier opdateres, når brugeren ændrer sit valg på den native indstillingsskærm, og ikke først ved næste start af appen.

Videregivelse af websamtykke tilbage til native

Hvis brugere kan ændre samtykke inde i WebView'en, for eksempel via en side med privatlivsindstillinger, skal appen få det at vide. Brug en JavaScript-bridge: en message handler på iOS eller en JavaScript-grænseflade på Android. Websiden lytter med __tcfapi('addEventListener', ...) og sender den nye streng til native kode, som skriver standardnøglerne. Validér input fra WebView'en, før du skriver det; accepter kun beskeder fra dit eget indhold.

Annoncer inde i WebViews

Annoncer, der renderes i en WebView, er webannoncer. De læser samtykke fra siden, ikke fra den native lagring, medmindre annonce-SDK'et giver en måde at forbinde de to på. Googles Mobile Ads SDK tilbyder for eksempel et API til at registrere WebViews, så annoncer i dem kan bruge signaler fra appen; tjek den aktuelle dokumentation for dit SDK. Bekræft under alle omstændigheder med en test, at annonceforespørgsler fra WebView'en bærer den samme TC- eller GPP-streng som native annonceforespørgsler.

Testtjekliste

• Frisk installation: én samtykkeprompt, ikke to.
• Afvis alle i den native CMP, åbn en WebView, inspicér annonceforespørgsler: strengen bør afspejle afvisningen.
• Skift samtykke i de native indstillinger, vend tilbage til en åben WebView: siden bør se den nye beslutning.
• Hvis der findes webindstillinger, så skift samtykke dér, og bekræft, at de native nøgler opdateres.
• Dræb og genstart appen: beslutninger bevares på begge sider.
• Test på både iOS og Android, da WebView-lagring opfører sig forskelligt på hver.

Vigtigste pointer

• Native og WebView-samtykke bor i separate lagre og synkroniserer ikke som standard.
• Vælg én sandhedskilde; for de fleste apps er det den native CMP.
• Eksponer native samtykke for webindhold gennem en injiceret __tcfapi eller __gpp, og skjul webbanneret.
• Brug en JavaScript-bridge til at sende webændringer tilbage til den native lagring.
• Tjek, at annonceforespørgsler fra WebViews bærer den samme samtykkestreng som native forespørgsler.