In vielen Fällen besteht eine mobile App aus einem nativen Teil (z. B. in Java, Kotlin oder C++ geschrieben) und einem Web-Teil (der in der Regel durch Einfügen einer Webview in die App realisiert wird). Um die Benutzererfahrung zu optimieren, gibt es einige Empfehlungen und Implementierungsstrategien, die du anwenden kannst.

Kernkonfiguration

Generell empfehlen wir die Verwendung unseres SDK für iOS oder Android, um die CMP in Ihre App (nativen Teil) zu integrieren. Die CMP wird in der Regel beim Start der App ausgelöst, zeigt die Einwilligungsmaske an und lässt den Nutzer seine Auswahl treffen. Sobald der Nutzer seine Auswahl getroffen hat, entfernt das SDK die Einwilligungsmaske und die App läuft weiter.

In Fällen, in denen die App eine Webview enthält, muss der Inhalt dieser Webview (z. B. eine Webseite, die Werbung enthält) ebenfalls wissen, ob eine Einwilligung erteilt wurde, und möglicherweise ist die Unterstützung von APIs wie IAB TCF oder IAB GPP erforderlich. Daher sollte die Webseite, die innerhalb der Webview geladen wird, ebenfalls den CMP-Code (HTML-Implementierung des Codes) enthalten.

Austausch von Einwilligungsinformationen

Bei der oben beschriebenen Grundkonfiguration besteht das Problem darin, dass ein Nutzer zweimal gefragt wird: einmal beim Start der App und einmal bei jedem Öffnen einer (neuen) Webansicht. Um dies zu vermeiden, können die Einwilligungsinformationen zwischen SDK und Webview ausgetauscht werden. Dies geschieht, indem die Einwilligungsdaten aus dem SDK exportiert und an die URL angehängt werden, die im Webview geladen wird.

Beispiel:

// Swift version
let consentData = cmpManager.exportCMPString()
if let url = URL(string: "https://mywebsite.com/....#cmpimport=" + consentData) {
    myWebView.load(URLRequest(url: url))
}

// Kotlin version
val consentData = cmpManager.exportCMPString()
myWebView.loadUrl("https://mywebsite.com/....#cmpimport=" + consentData)

 

Die exportCMPInfo Funktion ist für beide SDKs verfügbar, sowohl für iOS als auch für Android.

Sobald die Webansicht geladen ist, wird der CMP-Code in der Webansicht ausgeführt und findet den Hash (#cmpimport=.....) in der URL. Das CMP importiert diese Einwilligungsdaten automatisch und verwendet keine Daten aus Cookies oder dem lokalen Speicher mehr. Da die Einwilligungsdaten in das CMP importiert wurden, sollte die Einwilligungsschicht normalerweise nicht (erneut) erscheinen, da die Einwilligung des Nutzers bereits vorliegt.

Feinabstimmung

Als letzten Schritt können Sie noch einige Feinabstimmungen vornehmen, wenn Sie möchten.

Einerseits sollte der in die Webansicht integrierte CMP-Code das Symbol für das Präferenzcenter nicht anzeigen (das sich normalerweise unten links im Browserfenster befindet und es Besuchern ermöglicht, ihre Einstellungen zu aktualisieren). Um das Symbol zu deaktivieren, gehen Sie bitte zu Menü > Rechtliche Einstellungen > DSGVO/CCPA/… > Präferenzsymbol anzeigen.

Andererseits kann es trotz des #cmpimport=... in der URL immer noch Fälle geben, in denen die CMP beschließt, die Einwilligungsschicht in der Webansicht anzuzeigen. Um dies zu vermeiden, empfehlen wir, allen Seiten, die innerhalb der Webansicht angezeigt werden, eine clientseitige Konfigurationsvariable hinzuzufügen:

<script>
 window.cmp_noscreen = true;
</script>
... your CMP-Code ...

Dadurch wird verhindert, dass die Einwilligungsabfrage angezeigt wird.

FAQ

Kann ich denselben CMP im SDK und im Webview verwenden?

Ja. Für das System spielt es keine Rolle, ob im SDK, in Ihrer Webview und/oder auf Ihrer normalen Website dasselbe CMP oder ein anderes CMP verwendet wird. Sie können in allen Umgebungen dasselbe CMP oder verschiedene CMPs verwenden, und alle CMPs können die Einwilligungsdaten voneinander importieren.

Da die App jedoch in den meisten Fällen andere Anforderungen an Verhalten und Design stellt, ist es in der Regel besser, App-CMPs und Web-CMPs voneinander zu trennen. Das Gleiche gilt für das Design: Im Allgemeinen kann dasselbe Design in allen Umgebungen verwendet werden, aber in vielen Fällen ist es sinnvoll, ein separates Design für die App-Umgebung zu haben.

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 Reibungsverluste bei der Übertragung von Einwilligungsdaten von einer Umgebung in eine andere

Dies sind die Nachteile der Verwendung desselben CMP in all Ihren Umgebungen:

• Die Anbieterliste ist potenziell länger als bei getrennten CMPs (da eine kombinierte Anbieterliste alle Anbieter aus allen Umgebungen enthalten muss).
• Es besteht keine Möglichkeit, bestimmte allgemeine Einstellungen zu unterscheiden (z. B. allgemeine Einstellungen wie die URL für die Datenschutzerklärung, die URL für die AGB oder rechtliche Einstellungen wie die Unterstützung von DSGVO, CCPA und anderen).
• Komplizierter wird es, wenn unterschiedliche Designs verwendet werden sollen (möglicherweise ist eine Zielgruppenausrichtung erforderlich).

Was passiert, wenn zwei verschiedene CMPs verwendet werden?

Falls das im nativen Teil der App verwendete CMP ein anderes ist als das im Webview, werden die Einwilligungsinformationen aus dem nativen SDK in das Webview-CMP importiert. Wenn es Unterschiede zwischen der Zweck- und/oder Anbieterliste der beiden CMPs gibt, behandelt das importierende CMP (das im Webview) alle fehlenden Zwecke und Anbieter als „keine Einwilligung“ / „abgemeldet“. Um dies zu veranschaulichen, nehmen wir folgende Konfiguration an:

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 Nutzer im einheimischen Teil zustimmt, lautet das Ergebnis:

CMP im nativen Teil der App:
Zwecke: A=akzeptiert, B=akzeptiert, C=akzeptiert
Anbieter: 1=akzeptiert, 2=akzeptiert, 3=akzeptiert

CMP in der Webansicht:
Zwecke: C=akzeptiert, D=abgelehnt, E=abgelehnt
Anbieter: 3=akzeptiert, 4=abgelehnt, 5=abgelehnt

Falls der Nutzer den nativen Teil ablehnt, lautet das Ergebnis:

CMP im nativen Teil der App:
Zwecke: A=abgelehnt, B=abgelehnt, C=abgelehnt
Anbieter: 1=abgelehnt, 2=abgelehnt, 3=abgelehnt

CMP in der Webansicht:
Zwecke: C=abgelehnt, D=abgelehnt, E=abgelehnt
Anbieter: 3=abgelehnt, 4=abgelehnt, 5=abgelehnt