Choose another country or region to see content specific to your location.

Datenschutz auf dem Vormarsch - Wie funktioniert eine CMP?

Datenschutz auf dem Vormarsch: Teil 2 – Wie funktoniert eine CMP?

Im ersten Teil dieser Serie “Einführung und Risikoanalyse“, haben Sie einen Überblick darüber erhalten, welche Datenschutzregularien es gibt, welche Anforderungen Sie zur DSGVO-konformen Datenerhebung erfüllen müssen und welche Konsequenzen sich daraus ergeben.

In diesem Teil wenden wir uns der Frage zu, wie eine CMP technisch gesehen funktioniert.

Vielleicht haben Sie sich auch schon einmal gefragt, warum Ihnen auf einer Website immer wieder das Consent-Banner angezeigt wird, obwohl Sie Ihre Entscheidung doch bereits kundgetan haben? Nun, das kann unterschiedliche Ursachen haben.

Von den Sonderfällen einmal abgesehen, ist die wahrscheinlichste jedoch, dass Sie die Website mit unterschiedlichen Geräten bzw. Browsern besuchen. Denn wie bei den meisten Webanalyse-Systemen auch, kann die CMP einen Nutzer über verschiedene Browser oder Geräte nicht wiedererkennen. Schauen wir uns gemeinsam einmal an, wie die CMP funktioniert.

Benutzer sind Browser-Instanzen

Wenn also ein Nutzer die Seite einer Website besucht, wird bei korrekter Implementierung der CMP dieselbige involviert.

Im Klartext heißt das: besucht der Nutzer die Website zum ersten Mal oder der zum wiederholten Male, ohne bislang eine explizite Entscheidung getroffen zu haben, wird das entsprechende Consent-Banner angezeigt.

Hat der Nutzer bei einem seiner vorigen Besuche bereits eine explizite Entscheidung getroffen, wird diese berücksichtigt und die Technologien ausgespielt, denen der Nutzer zugestimmt hat.

Data Privacy Regulations Browser Instance CMP Datenschutz auf dem Vormarsch: Teil 2 - Wie funktoniert eine CMP?

Wie unterscheidet nun die CMP den Nutzer und woher weiß die CMP, welcher Technologie der Nutzer zugestimmt hat?

Zunächst werfen wir einen Blick darauf, wie die CMP einen Nutzer identifiziert. Dabei betrachten wir die CMPs von Usercentricsund OneTrust.

Usercentrics

Sobald eine Webseite im Browser aufgerufen wird, in der Usercentrics implementiert ist, wird eine sogenannte controllerId erzeugt und in der Local Storage des Browsers gespeichert.

Dabei spielt es zunächst keine Rolle, ob der Nutzer der Verwendung von Technologien explizit zustimmt oder nicht – die controllerId dient lediglich dem Zweck der Wiedererkennung des Nutzers respektive der Browser-Instanz.

Im Kontext dieser controllerId, werden jedoch auch die explizite Zustimmung oder Ablehnung von Technologien durch den Nutzer gespeichert.

Data Privacy Regulations CMP Usercentrics ControllerID Datenschutz auf dem Vormarsch: Teil 2 - Wie funktoniert eine CMP?

Der wesentliche Vorteil, die controllerId sowie die explizite Zustimmung/Ablehnung im Local Storage zu speichern, liegt primär darin, dass dieser – anders als Cookies – nicht ohne weiteres automatisch gelöscht werden kann.

OneTrust

Ruft ein Nutzer nun eine Webseite im Browser auf, in welcher OneTrust implementiert ist, wird eine sogenannte consentId generiert. Diese wird dann jedoch – anders als bei Usercentrics – nicht in der Local Storage des Browsers gespeichert, sondern vielmehr als Cookie.

Ähnlich wie bei Usercentrics ist es auch hier nicht von Bedeutung, ob der Nutzer der Verwendung von Technologien explizit zustimmt oder nicht, denn die consentId dient ebenfalls der Wiedererkennung des Nutzers bzw. der Browser-Instanz.

Im Kontext dieser consentId werden zudem die explizite Zustimmung zu bzw. Ablehnung von Kategorien durch den Nutzer gespeichert.

Data Privacy Regulations CMP OneTrust consentId Datenschutz auf dem Vormarsch: Teil 2 - Wie funktoniert eine CMP?

Diese Daten in einem Cookie zu speichern, birgt da Risiko, dass diese beim Löschen von Cookies (z. B. über das Browser-Einstellungen) logischerweise mit gelöscht werden und der Nutzer sodann wieder mit dem Consent-Banner konfrontiert wird.

Zum zweiten oder wiederholten Mal die Website besuchen

Sobald nun der Nutzer die Website zum zweiten oder wiederholten Male besucht, liest die CMP die gespeicherten Informationen hinsichtlich der gegebenen oder verweigerten Zustimmung aus und stellt diese Informationen dann in der Datenschicht des Browsers zur Verfügung.

Diese Informationen können dann von der entsprechenden Technologie genutzt werden, um ein Tag auszuspielen oder eben auch nicht. Somit stellen Sie sicher, dass die consent-pflichtigen Tags tatsächlich nur dann ausgespielt werden, wenn der Nutzer auch wirklich seine Zustimmung gegeben hat.

Verwendung der durch die CMP bereitgestellten Daten

Schauen wir uns nun einmal an, wie wir von der CMP zur Verfügung gestellten Informationen mit dem Google Tag Manager nutzen können.

In erster Linie stellt die CMP bei Initialisierung die von Nutzer gegebenen Zustimmungen im DataLayer des GTM zur Verfügung. Wie dies geschieht, hängt in erster Linie von der verwendeten CMP ab.

So stellt beispielsweise die CMP von Usercentrics die Zustimmung zu jeder konfigurierten Technologie granular im DataLayer zur Verfügung:

Usercentrics liefert detaillierte Informationen: Für jede Technologie wird angegeben, ob der Nutzer zugestimmt hat oder nicht.

Die CMP von OneTrust hingegen, fasst mehrere Technologien in Kategorien zusammen und schreibt somit lediglich die Kategorie-Nummer in den DataLayer, zu welcher auch eine Zustimmung vorhanden ist:

OneTrust stellt Informationen über die Zustimmung zur Verfügung, indem es Kategorien anzeigt, in denen die Zustimmung der Nutzer organisiert und gespeichert ist.

Beide Ansätze haben ihre Vor- und Nachteile, auf die ich jedoch zu einem späteren Zeitpunkt näher eingehen möchte.

Die im DataLayer vorhandenen Informationen können nun in eine Datenschichtvariable übergeben werden und in den Triggern zu den jeweiligen Tags entsprechend verwendet werden.

Wollen Sie also beispielsweise den Trigger zum Ausspielen des Google-Analytics-Tags anpassen, würden Sie den Trigger nur dann auslösen, wenn im DataLayer folgende Inhalte zu finden wären: Bei der Verwendung von

  1. Usercentrics der Wert “Google Analytics: true” bzw.
  2. OneTrust der Wert “C0002” in “OnetrustActiveGroups”.

Mögliche Probleme

Die geschilderte Vorgehensweise kann jedoch auch zu sogenannten Race Conditions führen.

Eine Race Condition ist eine unerwünschte Situation, die auftritt, wenn der GTM versucht, zwei oder mehr Trigger gleichzeitig auszulösen, diese aber aufgrund von Ereignisreihenfolge bzw. fehlender Daten im Data Layer fehlschlagen.

Daher muss sichergestellt werden, dass die bereitgestellten Informationen und Ereignisse in der richtigen Reihenfolge ausgeführt werden können. Ein probates Mittel beim GTM ist beispielsweise der Einsatz von Trigger-Gruppen.

Brauchen Sie Hilfe?

Wenn Sie sich nicht sicher sind, ob bei Ihnen eine Race Condition vorliegt, oder wenn Sie mit der Durchführung eines CMP nicht vertraut sind, können Sie sich gerne an e-CENS wenden – wir sind für Sie da.

Demnächst

Der nächste Teil der Serie wird sich damit befassen, wie die Lücken ausgeglichen werden können, die durch die fehlende Zustimmung entstanden sind…

Picture of Holger Tempel

Holger Tempel

Holger is among the first Google Analytics partners worldwide since early 2005. Holger is considered one of the leading experts on digital analytics and is a renowned trainer who can simplify complex ideas into real-world practical examples with actionable insights.

Related resources