Kombinieren von nativen und Webinhalten in einer App
In vielen Fällen besteht eine mobile App aus einem nativen Teil (z. B. geschrieben in Java oder Kotlin oder C++ usw.) und einem Web-Teil (normalerweise durch Einfügen einer Webansicht in die App). Um die Benutzererfahrung zu optimieren, gibt es einige Empfehlungen und Implementierungsstrategien, die Sie verwenden können.
Core-Setup
Im Allgemeinen empfehlen wir die Verwendung unseres SDK für iOS or Android um das CMP in Ihre App zu integrieren (nativer Teil). Die CMP wird normalerweise beim Start der App ausgelöst, zeigt die Einwilligungsebene an und lässt den Benutzer seine Auswahl treffen. Sobald der Benutzer die Auswahl getroffen hat, entfernt das SDK die Einwilligungsebene und die App wird fortgesetzt.
In Fällen, in denen die App eine Webansicht enthält, muss der Inhalt in dieser Webansicht (z. B. eine Webseite, die Werbung enthält) auch wissen, ob eine Einwilligung erteilt wurde und ob möglicherweise Unterstützung für APIs wie IAB TCF oder IAB GPP erforderlich ist. Daher sollte die Webseite, die innerhalb der Webansicht geladen wird, auch den CMP-Code enthalten (HTML-Implementierung des Codes).
Austausch von Einwilligungsinformationen
Bei der oben genannten Kernkonfiguration besteht das Problem darin, dass ein Benutzer zweimal gefragt wird: Einmal beim App-Start und einmal bei jedem Öffnen einer (neuen) Webansicht. Um dies zu vermeiden, können die Einwilligungsinformationen zwischen SDK und Webview ausgetauscht werden. Dazu werden die Zustimmungsdaten aus dem SDK exportiert und an die URL angehängt, die in der Webansicht geladen wird.
Beispiel:
consentData = CMPStorageConsentManager.exportCMPData(this);
myWebView.loadURL("https://mywebsite.com/....#cmpimport=" + consentData);(Für beide SDKs existiert eine Exportfunktion, obiges Beispiel ist den iOS-Beispielen entnommen)
Sobald die Webansicht geladen ist, wird der CMP-Code in der Webansicht ausgeführt und findet den Hash (#cmpimport=.....) in der URL. Die CMP wird diese Einwilligungsdaten automatisch importieren und keine Daten mehr aus Cookies oder lokalem Speicher verwenden. Da die Zustimmungsdaten in die CMP importiert wurden, sollte die Zustimmungsschicht normalerweise nicht (wieder) erscheinen, da die Zustimmung des Benutzers bereits vorhanden ist.
Bitte beachten Sie, dass Zustimmungsinformationen nur vom SDK an die Webansicht weitergegeben werden können und nicht in die entgegengesetzte Richtung.
Feintuning
Als letzten Schritt gibt es vielleicht noch ein Feintuning, das Sie gerne machen würden.
Einerseits sollte der CMP-Code, der in die Webansicht integriert ist, nicht das Symbol für das Einstellungszentrum anzeigen (normalerweise auf der linken unteren Seite des Browserfensters, damit Besucher ihre Auswahl aktualisieren können). Um das Symbol zu deaktivieren, gehen Sie bitte zu Menü > Rechtliche Einstellungen > DSGVO/CCPA/... > Symbol Einstellungen anzeigen.
Andererseits auch mit der #cmpimport=... auf der URL kann es immer noch Fälle geben, in denen die CMP entscheidet, die Einwilligungsebene in der Webansicht anzuzeigen. Um dies zu vermeiden, empfehlen wir, a hinzuzufügen clientseitige Konfiguration Variable auf alle Seiten, die in der Webansicht angezeigt werden:
<script>
window.cmp_noscreen = true;
</script>
... your CMP-Code ...Dadurch wird verhindert, dass die Einwilligungsebene angezeigt wird.
FAQ
Kann ich dasselbe CMP im SDK und in der Webansicht verwenden?
Ja. Für das System spielt es keine Rolle, ob im SDK, Ihrer Webansicht und/oder Ihrer normalen Website derselbe CMP oder ein anderer CMP verwendet wird. Sie können dieselbe CMP oder verschiedene CMPs in allen Umgebungen verwenden und alle CMPs können die Zustimmungsdaten voneinander importieren.
Da die App jedoch in den meisten Fällen unterschiedliche Anforderungen in Bezug auf Verhalten und Design hat, ist es in der Regel besser, App-CMPs und Web-CMPs zu trennen. Gleiches gilt für Designs: Generell kann in allen Umgebungen das gleiche Design verwendet werden, aber in vielen Fällen ist es sinnvoll, ein separates Design für die App-Umgebung zu haben.
Empfehlung: Wenn Sie unterschiedliche CMPs in Ihrer App und auf Ihrer Website verwenden, empfehlen wir, dasselbe CMP, das im nativen Teil Ihrer App verwendet wird, auch in den Webansichten Ihrer App zu verwenden.
Was sind die Vor- und Nachteile der Verwendung desselben/eines anderen CMP?
Hier sind einige Vorteile der Verwendung desselben CMP in all Ihren Umgebungen:
- einfachere Verwaltung von Anbieterlisten, Zwecken und Cookies, da alle Umgebungen dieselbe Konfiguration verwenden
- keine Reibung, wenn Einwilligungsdaten von einer Umgebung in eine andere übertragen werden
Dies sind die Nachteile der Verwendung desselben CMP in all Ihren Umgebungen:
- Die Anbieterliste ist möglicherweise länger als bei einer Trennung der CMPs (da eine kombinierte Anbieterliste alle Anbieter aus allen Umgebungen enthalten muss).
- keine Möglichkeit, bestimmte allgemeine Einstellungen zu unterscheiden (z. B. allgemeine Einstellungen wie Datenschutz-URL, AGB-URL oder rechtliche Einstellungen wie Unterstützung für DSGVO, CCPA und andere)
- komplizierter, wenn verschiedene Designs verwendet werden sollen (die Verwendung von Targetings kann erforderlich sein)
Was passiert, wenn zwei verschiedene CMPs verwendet werden?
Falls die im nativen Teil der App verwendete CMP eine andere CMP ist als die in der Webansicht, werden die Einwilligungsinformationen aus dem nativen SDK in die Webansicht-CMP importiert. In Fällen, in denen es einen Unterschied zwischen der Zweckliste und/oder der Anbieterliste der beiden CMPs gibt, behandelt die importierende CMP (diejenige in der Webansicht) alle fehlenden Zwecke und Anbieter als „keine Zustimmung“ / „abgemeldet“. Um dies zu veranschaulichen, gehen wir von folgendem Aufbau aus:
CMP im nativen Teil der App:
Zwecke: A, B, C
Anbieter: 1, 2, 3
CMP in der Webansicht:
Zwecke: C, D, E
Anbieter: 3, 4, 5
Falls der Benutzer akzeptiert im nativen Teil lautet das Ergebnis:
CMP im nativen Teil der App:
Zwecke: A=akzeptiert, B=akzeptiert, C=akzeptiert
Verkäufer: 1=akzeptiert, 2 =akzeptiert, 3 =akzeptiert
CMP in der Webansicht:
Zwecke: C=akzeptiert, D=abgelehnt, E=abgelehnt
Verkäufer: 3=akzeptiert, 4 =abgelehnt, 5 =abgelehnt
Falls der Benutzer Ausschuss im nativen Teil lautet das Ergebnis:
CMP im nativen Teil der App:
Zwecke: A=abgelehnt, B=abgelehnt, C=abgelehnt
Verkäufer: 1=abgelehnt, 2 =abgelehnt, 3 =abgelehnt
CMP in der Webansicht:
Zwecke: C=abgelehnt, D=abgelehnt, E=abgelehnt
Verkäufer: 3=abgelehnt, 4 =abgelehnt, 5 =abgelehnt
Bitte beachten Sie dass sein Verhalten unabhängig von der Zweckzuweisung des Verkäufers ist. Das bedeutet, dass das Ergebnis das gleiche wie oben beschrieben ist, auch wenn alle Lieferanten Zweck C zugeordnet sind.
Bitte beachten Sie dass sein Verhalten auch unabhängig von den verwendeten Rechtsgrundlagen des jeweiligen Anbieters/Zwecks und unabhängig von der Gerichtsbarkeit ist, in der sich der Benutzer befindet.
