Das Doppel-Banner-Problem

Viele Apps sind teils nativ und teils Web. Ein Spiel zeigt seinen Shop, Nachrichten oder Hilfeseiten in einer WebView; eine Utility-App rendert Artikel von ihrer Website; eine Hybrid-App verpackt den Großteil ihrer Oberfläche in Web-Inhalte. Jede Seite hat ihren eigenen Einwilligungsmechanismus: Die native App nutzt eine In-App-CMP oder ein SDK, und die Webseiten laden eine Web-CMP. Sind beide nicht verbunden, wird der Nutzer zweimal gefragt, Entscheidungen an einer Stelle werden an der anderen ignoriert, und Anzeigenanfragen aus der WebView gehen mit den falschen Signalen hinaus.

Dieser Leitfaden zeigt, wie Sie native und Web-Einwilligung in Einklang bringen, sodass Nutzer nur einmal antworten und jede Anzeigenanfrage dieselbe Entscheidung trägt.

Wo jede Seite die Einwilligung speichert

Nativ

Das IAB TCF legt fest, wie eine In-App-CMP die Einwilligung speichert: in NSUserDefaults unter iOS und SharedPreferences unter Android, mit Standardschlüsseln wie IABTCF_TCString, IABTCF_gdprApplies und IABTCF_PurposeConsents. Ad-SDKs lesen diese Schlüssel direkt. Die IAB GPP definiert ähnliche Schlüssel mit dem Präfix IABGPP_, etwa IABGPP_HDR_GppString.

Web

Eine Web-CMP speichert ihre Entscheidung typischerweise in First-Party-Cookies oder im lokalen Speicher für die Domain der Website und stellt sie über die JavaScript-Funktionen __tcfapi und __gpp bereit. Ad-Tags auf der Seite rufen diese Funktionen auf, nicht den nativen Speicher.

Die Lücke

WebViews haben einen eigenen Cookie- und Speicherbereich, getrennt vom Browser des Geräts und von den nativen Einstellungen der App. Unter iOS vergisst eine WKWebView mit einem nicht persistenten Datenspeicher beim Schließen alles. Zwischen beiden Seiten fließt nichts, solange Sie es nicht selbst bauen.

Eine einzige Wahrheitsquelle wählen

Die erste Entscheidung ist, welche Seite die Einwilligung besitzt. Für die meisten Apps lautet die Antwort die native CMP, weil:

• sie als Erste läuft, bevor irgendeine WebView geöffnet wird.
• native Ad-SDKs, die meist den Großteil des Umsatzes erzielen, den nativen Speicher lesen.
• sie sich unter iOS mit der Abfrage der App Tracking Transparency abstimmen lässt.

Web zuerst kann für Hybrid-Apps sinnvoll sein, deren gesamte Oberfläche aus Web-Inhalten besteht, doch dann müssen Sie die Entscheidung für native SDKs in den nativen Speicher zurückschreiben.

Native Einwilligung in die WebView übergeben

Mit dem nativen Speicher als Wahrheitsquelle muss die WebView dieselbe Entscheidung sehen. Gängige Muster:

1. Eine __tcfapi-Implementierung injizieren. Injizieren Sie, bevor die Skripte der Seite laufen, ein kleines Skript, das __tcfapi (und bei Bedarf __gpp) definiert und Aufrufe mit dem TC-String und den aus dem nativen Speicher gelesenen Werten beantwortet. Ad-Tags auf der Seite erhalten die native Entscheidung dann über die Standard-API.
2. Das Web-Banner unterdrücken. Konfigurieren Sie die Web-CMP so, dass sie verborgen bleibt, wenn die Seite in Ihrer App geladen wird, etwa anhand eines Query-Parameters oder eines selbst kontrollierten User-Agent-Tokens. Sonst sieht der Nutzer ein zweites Banner.
3. Den String beim Laden übergeben. Manche Web-CMPs können bei der Initialisierung einen vorhandenen Consent-String annehmen und übernehmen. Prüfen Sie in der Dokumentation Ihrer Web-CMP, welche Methoden unterstützt werden.

Welches Muster Sie auch nutzen: Achten Sie darauf, dass sich die injizierten Werte aktualisieren, wenn der Nutzer seine Auswahl im nativen Einstellungsbildschirm ändert, und nicht erst beim nächsten Start der App.

Web-Einwilligung zurück an Native geben

Können Nutzer die Einwilligung innerhalb der WebView ändern, etwa über eine Datenschutzeinstellungsseite, muss die App davon erfahren. Nutzen Sie eine JavaScript-Bridge: einen Message-Handler unter iOS oder ein JavaScript-Interface unter Android. Die Webseite lauscht mit __tcfapi('addEventListener', ...) und sendet den neuen String an den nativen Code, der die Standardschlüssel schreibt. Validieren Sie Eingaben aus der WebView, bevor Sie sie schreiben; akzeptieren Sie nur Nachrichten aus Ihren eigenen Inhalten.

Werbung in WebViews

In einer WebView gerenderte Anzeigen sind Web-Anzeigen. Sie lesen die Einwilligung von der Seite, nicht aus dem nativen Speicher, sofern das Ad-SDK keine Möglichkeit bietet, beides zu verknüpfen. Googles Mobile Ads SDK bietet zum Beispiel eine API, um WebViews zu registrieren, damit Anzeigen darin Signale der App nutzen können; prüfen Sie die aktuelle Dokumentation Ihres SDK. Bestätigen Sie in jedem Fall per Test, dass Anzeigenanfragen aus der WebView denselben TC- oder GPP-String tragen wie native Anzeigenanfragen.

Test-Checkliste

• Neuinstallation: eine Einwilligungsabfrage, nicht zwei.
• In der nativen CMP alles ablehnen, eine WebView öffnen, Anzeigenanfragen prüfen: Der String sollte die Ablehnung widerspiegeln.
• Die Einwilligung in den nativen Einstellungen ändern, zu einer geöffneten WebView zurückkehren: Die Seite sollte die neue Entscheidung sehen.
• Gibt es Web-Einstellungen, dort die Einwilligung ändern und bestätigen, dass sich die nativen Schlüssel aktualisieren.
• App beenden und neu starten: Die Entscheidungen bleiben auf beiden Seiten bestehen.
• Auf iOS und Android testen, da sich der WebView-Speicher jeweils anders verhält.

Wichtigste Erkenntnisse

• Native und WebView-Einwilligung liegen in getrennten Speichern und synchronisieren sich standardmäßig nicht.
• Wählen Sie eine Wahrheitsquelle; für die meisten Apps ist es die native CMP.
• Stellen Sie die native Einwilligung Web-Inhalten über ein injiziertes __tcfapi oder __gpp bereit und verbergen Sie das Web-Banner.
• Nutzen Sie eine JavaScript-Bridge, um Web-Änderungen in den nativen Speicher zurückzuschreiben.
• Prüfen Sie, dass Anzeigenanfragen aus WebViews denselben Consent-String tragen wie native.