Eine Consent-Architektur, die projektübergreifend funktioniert

Webanwendungen binden häufig externe Dienste wie Analytics, Karten, Videos oder Terminbuchungen ein. Damit entstehen zusätzliche Datenflüsse und die Frage, unter welchen Bedingungen diese Dienste geladen werden dürfen.

Viele Consent-Lösungen werden als eigenständiges System nachträglich in eine Website integriert. Dadurch entstehen zusätzliche Abhängigkeiten: Konfiguration und Oberfläche liegen ausserhalb der eigentlichen Anwendung, externe Scripts werden Teil des technischen Ladewegs und die Kontrolle über einzelne Integrationen verteilt sich auf mehrere Systeme.

Für unsere Projekte wollten wir Consent deshalb direkt in die Anwendungsarchitektur integrieren.

Daraus entstand eine eigenständige Consent-Engine, die heute als gemeinsamer technischer Baustein eingesetzt wird.

Das Consent-System trennt die zentrale Funktionslogik bewusst von den projektspezifischen Daten und der sichtbaren Oberfläche.

Dadurch kann dieselbe technische Grundlage in unterschiedlich aufgebauten Anwendungen eingesetzt werden, ohne Consent-State, Versionierung oder Script-Gating für jedes Projekt neu implementieren zu müssen.

Eine zentrale Anforderung bestand darin, zustimmungspflichtige Dienste vor einer Einwilligung nicht lediglich zu deaktivieren. Sie sollen gar nicht erst geladen werden.

Dafür greifen mehrere Mechanismen ineinander.

Damit deklarierte Speicherwerte und die tatsächliche Implementierung nicht unabhängig voneinander gepflegt werden, verwendet die Engine eine zentrale Registry. Für jeden über die Consent-Infrastruktur verwalteten Speicherwert werden technische Eigenschaften festgelegt.

Sprachabhängige Angaben wie Zweck und Beschreibung werden getrennt davon gepflegt.

Versucht Anwendungscode, über die Consent-Infrastruktur einen nicht registrierten Wert zu schreiben, wird der Vorgang abgelehnt. Damit ist die Registry nicht nur Dokumentation, sondern Teil der technischen Kontrolle.

Jede Consent-Konfiguration besitzt eine Version.

Bei einem weiteren Besuch vergleicht die Engine die gespeicherte Version mit dem aktuell eingesetzten Stand. Ändert sich die Konfiguration entsprechend, kann die bestehende Auswahl verworfen und eine neue Entscheidung eingeholt werden.

Damit lässt sich beispielsweise ein neu hinzugekommener Dienst über eine neue Consent-Version abbilden, ohne für jede Website eine eigene Migrationslogik zu entwickeln.

Eine Einwilligung kann jederzeit über die Consent-Einstellungen angepasst werden. Wird eine zuvor akzeptierte Kategorie wieder abgewählt, wird nicht nur der gespeicherte Consent-Zustand geändert.

Der Neuaufbau ist relevant, weil bereits ausgeführte Drittanbieter-Scripts nicht allein durch das Entfernen ihres Script-Elements zuverlässig rückgängig gemacht werden können.

Nach dem Widerruf soll der Zustand deshalb dem eines Besuchers entsprechen, der die betreffende Kategorie nicht freigegeben hat.

Zwischen Consent-Engine und Konfiguration steht eine definierte Schnittstelle. Die Engine benötigt bestimmte Informationen, ist aber nicht daran gebunden, wo diese gespeichert werden.

Dadurch sind unterschiedliche Modelle möglich.

Cookie-Namen, Kennungen, Kategorienzuordnung und Speicherdauern sind sprachneutral. Alles, was Besucher lesen, kann dagegen pro Sprache gepflegt werden.

Ein Speicherwert wird dadurch technisch einmal definiert und anschliessend für jede benötigte Sprache beschrieben.

Im Referenzprojekt Woop Art sind Deutsch und Englisch vollständig gepflegt. Der Webauftritt von Woop Technology verwendet dieselbe Engine mit zusätzlichen Sprachen.

Die Engine stellt eine wiederverwendbare Standard-Oberfläche bereit, schreibt deren Verwendung aber nicht vor.

Die Consent-Logik bleibt dabei unverändert.

So kann die Darstellung an das Designsystem des jeweiligen Projekts angepasst werden, ohne zentrale Funktionen wie Versionierung, Registry oder Widerruf neu implementieren zu müssen.

Neben dem Consent-Zustand im Browser kann jede ausdrücklich gespeicherte Entscheidung serverseitig protokolliert werden.

IPv4-Adressen werden nach dem zweiten Block gekürzt, IPv6-Adressen nach dem dritten Segment.

Der dafür vorgesehene Endpunkt akzeptiert nur Anfragen von der eigenen Herkunft und liegt auf einem festen Pfad, damit er auch auf Infrastruktur-Ebene gezielt eingeschränkt werden kann.

Die Entscheidung des Besuchers wird zuerst im Consent-Zustand der Anwendung wirksam. Schlägt die zusätzliche serverseitige Speicherung fehl, bleibt die Website weiterhin nutzbar.

Der Fehler wird serverseitig protokolliert, statt technische Details im Browser offenzulegen. Damit hängt die Funktionsfähigkeit des Consent-Systems nicht davon ab, ob die zusätzliche Protokollierung in jedem Moment verfügbar ist.

Die Consent-Konfiguration und die zentrale Engine sind Bestandteil der eigenen Anwendung. Für das Consent-System selbst ist deshalb kein externer CMP-Anbieter erforderlich.

Zustimmungsabhängige Dienste bleiben davon getrennt und werden erst geladen, wenn die erforderliche Einwilligung vorliegt.

Die Consent-Engine liegt als eigenes Package vor und wird über die private Paketverwaltung von Woop Technology bereitgestellt. Versionen und Änderungen können damit wie bei anderen technischen Abhängigkeiten nachvollziehbar verwaltet werden.

Ein neues Projekt ergänzt im Wesentlichen vier projektspezifische Bereiche.

Eine eigene Consent-Architektur ist nicht für jedes Projekt notwendig. Für eine einfache Website mit wenigen externen Diensten kann eine etablierte Consent-Plattform die schnellere und wirtschaftlichere Lösung sein.

In diesen Fällen reduziert eine gemeinsame Engine projektspezifische Implementierungen und ermöglicht es, zentrale Funktionen an einer Stelle weiterzuentwickeln.

Der zentrale Consent-Zustand steht auch dem Anwendungscode zur Verfügung.

Dadurch lassen sich auch Zwei-Klick-Lösungen umsetzen. Anstelle eines noch nicht freigegebenen Drittanbieters kann zunächst eine lokale Komponente angezeigt werden, die über den externen Dienst informiert und diesen erst nach einer entsprechenden Entscheidung lädt.

Consent bleibt damit nicht auf Banner und Einstellungsdialog beschränkt, sondern kann direkt in den Ablauf einer Anwendung integriert werden.

Eine externe Consent-Plattform bringt einen zusätzlichen Anbieter, eigene Scripts, eigene Konfiguration und üblicherweise eine weitere technische Abhängigkeit mit sich. Die eigene Engine wird dagegen gemeinsam mit den bestehenden Anwendungen und innerhalb der vorgesehenen Infrastruktur betrieben.

Das bedeutet nicht, dass externe Consent-Plattformen grundsätzlich ungeeignet sind. Die Entscheidung hängt vom Umfang und den Anforderungen des jeweiligen Projekts ab.

Für die Verwaltung der Einwilligungen selbst ist kein weiterer CMP-Anbieter erforderlich. Die entsprechenden Consent-Daten können damit dort verarbeitet werden, wo auch die Anwendung betrieben wird.

Welche weiteren externen Dienste ein konkretes Projekt verwendet und welche Daten dabei übertragen werden, wird unabhängig davon projektspezifisch definiert und dokumentiert.

Die Consent-Engine wird heute als wiederverwendbarer Bestandteil unterschiedlicher Webanwendungen eingesetzt. Zentrale Funktionen werden einmal gepflegt, während Daten, Integrationen, Sprachen und Oberfläche projektspezifisch bleiben.