Het dubbele-bannerprobleem

Veel apps zijn deels native en deels web. Een game toont zijn winkel, nieuws of helppagina's in een WebView; een utility-app rendert artikelen van zijn website; een hybride app verpakt het grootste deel van zijn interface in webinhoud. Elke kant heeft een eigen toestemmingsmechanisme: de native app gebruikt een in-app CMP of SDK en de webpagina's laden een web-CMP. Zolang ze niet verbonden zijn, wordt de gebruiker twee keer gevraagd, worden keuzes op de ene plek op de andere genegeerd en gaan advertentieverzoeken vanuit de WebView met de verkeerde signalen de deur uit.

Deze gids behandelt hoe je native en web-toestemming op één lijn brengt, zodat gebruikers één keer antwoorden en elk advertentieverzoek dezelfde beslissing draagt.

Waar elke kant toestemming opslaat

Native

De IAB TCF legt vast hoe een in-app CMP toestemming opslaat: in NSUserDefaults op iOS en SharedPreferences op Android, met standaardsleutels zoals IABTCF_TCString, IABTCF_gdprApplies en IABTCF_PurposeConsents. Advertentie-SDK's lezen deze sleutels rechtstreeks. De IAB GPP definieert vergelijkbare sleutels met het voorvoegsel IABGPP_, zoals IABGPP_HDR_GppString.

Web

Een web-CMP slaat zijn beslissing doorgaans op in first-party cookies of lokale opslag voor het domein van de site, en stelt die beschikbaar via de JavaScript-functies __tcfapi en __gpp. Advertentietags op de pagina roepen die functies aan, niet de native opslag.

De kloof

WebViews hebben hun eigen cookie- en opslagruimte, gescheiden van de browser van het apparaat en van de native voorkeuren van de app. Op iOS vergeet een WKWebView met een niet-persistente gegevensopslag alles zodra hij sluit. Er stroomt niets tussen de twee kanten tenzij je het zelf bouwt.

Kies één bron van waarheid

De eerste beslissing is welke kant eigenaar is van toestemming. Voor de meeste apps is het antwoord de native CMP, omdat:

• die als eerste draait, voordat een WebView wordt geopend.
• native advertentie-SDK's, die meestal het grootste deel van de inkomsten opleveren, de native opslag lezen.
• die op iOS kan worden afgestemd met de prompt van App Tracking Transparency.

Web eerst kan zinvol zijn voor hybride apps waarvan de hele interface uit webinhoud bestaat, maar dan moet je de beslissing terugschrijven naar de native opslag voor native SDK's.

Native toestemming doorgeven aan de WebView

Met native als bron van waarheid moet de WebView dezelfde beslissing zien. Gangbare patronen:

1. Een __tcfapi-implementatie injecteren. Injecteer, voordat de scripts van de pagina draaien, een klein script dat __tcfapi (en zo nodig __gpp) definieert en aanroepen beantwoordt met de TC string en waarden uit de native opslag. Advertentietags op de pagina krijgen de native beslissing dan via de standaard-API.
2. De webbanner onderdrukken. Configureer de web-CMP zo dat hij verborgen blijft wanneer de pagina in je app wordt geladen, bijvoorbeeld op basis van een queryparameter of een user-agenttoken dat je zelf beheert. Anders ziet de gebruiker een tweede banner.
3. De string bij het laden doorgeven. Sommige web-CMP's kunnen bij initialisatie een bestaande toestemmingsstring accepteren en overnemen. Raadpleeg de documentatie van je web-CMP voor ondersteunde methoden.

Welk patroon je ook gebruikt, zorg dat de geïnjecteerde waarden worden bijgewerkt wanneer de gebruiker zijn keuze wijzigt in het native instellingenscherm, en niet pas bij de volgende start van de app.

Webtoestemming terugsturen naar native

Als gebruikers toestemming binnen de WebView kunnen wijzigen, bijvoorbeeld via een privacyinstellingenpagina, moet de app dat te weten komen. Gebruik een JavaScript-bridge: een message handler op iOS of een JavaScript-interface op Android. De webkant luistert met __tcfapi('addEventListener', ...) en stuurt de nieuwe string naar de native code, die de standaardsleutels schrijft. Valideer invoer uit de WebView voordat je die wegschrijft; accepteer alleen berichten van je eigen inhoud.

Advertenties in WebViews

Advertenties die in een WebView worden gerenderd, zijn webadvertenties. Ze lezen toestemming van de pagina, niet uit de native opslag, tenzij de advertentie-SDK een manier biedt om de twee te koppelen. De Mobile Ads SDK van Google biedt bijvoorbeeld een API om WebViews te registreren zodat advertenties daarin signalen van de app kunnen gebruiken; raadpleeg de actuele documentatie van je SDK. Bevestig in elk geval met een test dat advertentieverzoeken vanuit de WebView dezelfde TC- of GPP-string dragen als native advertentieverzoeken.

Testchecklist

• Verse installatie: één toestemmingsprompt, niet twee.
• Weiger alles in de native CMP, open een WebView, inspecteer advertentieverzoeken: de string moet de weigering weerspiegelen.
• Wijzig toestemming in de native instellingen, keer terug naar een geopende WebView: de pagina moet de nieuwe beslissing zien.
• Als er webinstellingen zijn, wijzig daar toestemming en bevestig dat de native sleutels worden bijgewerkt.
• Sluit de app geforceerd af en start opnieuw: beslissingen blijven aan beide kanten behouden.
• Test op zowel iOS als Android, omdat WebView-opslag op elk platform anders werkt.

Belangrijkste punten

• Native en WebView-toestemming leven in aparte opslag en synchroniseren standaard niet.
• Kies één bron van waarheid; voor de meeste apps is dat de native CMP.
• Stel native toestemming beschikbaar aan webinhoud via een geïnjecteerde __tcfapi of __gpp en verberg de webbanner.
• Gebruik een JavaScript-bridge om webwijzigingen terug te sturen naar de native opslag.
• Controleer dat advertentieverzoeken uit WebViews dezelfde toestemmingsstring dragen als native verzoeken.