LW IT Solutions logo LW IT Solutions logo LW IT Solutions
« Blog-Übersicht /Data Privacy/Tutorials / Tutorial: Konfiguration von Geolocation-Regeln in Usercentrics
Diesen Artikel in anderen Sprachen lesen:

Tutorial: Konfiguration von Geolocation-Regeln in Usercentrics

Tutorial: Konfiguration von Geolocation-Regeln in Usercentrics
Inhalt
  1. 1. Konfigurationen und Verantwortlichkeiten festlegen
  2. 2. Globale Vorgabe und regionale Regeln einrichten
  3. 3. Das passende Einbauskript verwenden
  4. 4. Auswahl und tatsächliche Datenflüsse prüfen
  5. Fragen und Antworten
  6. Quellen

Geolocation-Regeln wählen anhand einer IP-basierten Ortszuordnung eine Usercentrics-Konfiguration aus. Dafür stehen Settings IDs für einzelne Konfigurationen und eine Ruleset-ID für deren regionale Zuordnung. Die technische Auswahl ersetzt keine Prüfung, welche Datenschutzregeln für die tatsächliche Verarbeitung gelten.

Ein pauschales Profil „außerhalb EU/EWR ohne Einwilligung“ ist dafür ungeeignet. Auch außerhalb dieses Gebiets bestehen Datenschutzpflichten; die Anwendbarkeit der DSGVO hängt zudem nicht allein vom erkannten IP-Land ab. Ausgangspunkt ist eine dokumentierte Entscheidung je Verarbeitung und Region, nicht die gewünschte Bannerquote.

1. Konfigurationen und Verantwortlichkeiten festlegen

Für unterschiedliche regionale Verhaltensweisen werden die benötigten Konfigurationen mit eigenen Settings IDs angelegt. Ein einheitliches weltweites Verhalten benötigt nicht zwangsläufig zwei Profile. Eine kurze Zuordnungsliste hält Region, Settings ID, Dienste, Einwilligungsanforderungen und zuständige Freigabe fest.

Einwilligungspflichtige Dienste bleiben vor Zustimmung gesperrt. Technisch notwendige Funktionen sind gesondert zu bewerten. Die CMP muss mit den tatsächlichen Skripten und Tags verbunden sein; das Anlegen eines Dienstes im Banner blockiert nicht automatisch jede vorhandene Integration.

Ablauf mit Konfigurationen, Ruleset, passendem Loader und Tests für Einwilligung sowie Datenflüsse.
Das Ruleset wählt die Konfiguration. Die Einwilligungspflicht und tatsächliche Tag-Blockierung bleiben gesondert zu prüfen.

2. Globale Vorgabe und regionale Regeln einrichten

Im Bereich Geolocation Rulesets wird ein Ruleset angelegt. Dessen Global Configuration bestimmt die Vorgabe; regionale Regeln verknüpfen ausgewählte Gebiete mit anderen Settings IDs. Die enthaltenen Konfigurationen dürfen keine widersprüchliche zusätzliche geografische Einschränkung besitzen.

Die Länderauswahl ist ausdrücklich zu kontrollieren: Die EU-Sammelauswahl umfasst beispielsweise weder das Vereinigte Königreich noch die Schweiz. Mehrere Rechtsräume lassen sich nicht allein anhand der Bezeichnung „Rest der Welt“ zusammenfassen.

„Do not display CMP layer“ ist keine harmlose Darstellungsoption. Laut Hersteller läuft die CMP dabei im Hintergrund weiter und behandelt alle Dienste standardmäßig als zugestimmt. Diese Wirkung gehört in die fachliche Freigabe und in die Tests. Eine automatische Produktvoreinstellung ist keine tatsächlich erteilte Einwilligung.

3. Das passende Einbauskript verwenden

Die Ruleset-ID steuert die regionale Auswahl. Für den dokumentierten neueren Loader lautet das relevante Attribut data-ruleset-id. Eine unverändert eingebundene feste data-settings-id lädt dagegen die einzelne Konfiguration.

<script id="usercentrics-cmp"
  data-ruleset-id="RULESET_ID_PLACEHOLDER"
  src="https://web.cmp.usercentrics.eu/ui/loader.js"></script>

Das Skript gehört in den Dokumentkopf vor einwilligungspflichtige Dienste. Das Beispiel gilt für den angegebenen Loader und enthält eine Platzhalter-ID. Die ältere Browser-UI-Dokumentation mit app.usercentrics.eu/browser-ui/latest/loader.js verwendet stattdessen ruleset-id. Loader und Attribut müssen zusammenpassen. Maßgeblich ist die zur verwendeten CMP-Version passende Einbauanleitung. Eine zweite parallele CMP-Installation ist zu vermeiden.

4. Auswahl und tatsächliche Datenflüsse prüfen

Ein VPN oder ein externer Teststandort kann die IP-basierte Auswahl prüfen. Ein VPN ist jedoch nicht die einzige Testmöglichkeit. Das Browser-SDK dokumentiert auch userCountryData zur Simulation in Testintegrationen; das ist kein Ersatz für die Prüfung der produktiven IP-Erkennung.

  • Frischer Besuch: Neues Browserprofil oder vollständig gelöschte Website-Daten verwenden. Nur den HTTP-Cache zu leeren beseitigt keine gespeicherte Einwilligung.
  • Region: Für jedes vorgesehene Gebiet erwartete und geladene Konfiguration dokumentieren; zusätzlich ein Gebiet ohne passende Regel prüfen.
  • Entscheidung: Zustand vor Auswahl, Ablehnung, Zustimmung und späteren Widerruf anhand von Netzwerkanfragen, Cookies und Speicherzugriffen prüfen.
  • Fehler: Fehlende Ortsdaten und Ladefehler gesondert testen. Bis zur geklärten Freigabe dürfen einwilligungspflichtige Tags nicht eigenständig starten.
  • Wiederkehr: Einen weiteren Aufruf mit gespeicherter Auswahl und einen Wechsel der Testregion prüfen.

Die Banneransicht allein belegt weder die richtige Settings ID noch die korrekte Blockierung. Im Netzwerkprotokoll lässt sich die geladene CMP-Konfiguration mit der Zuordnungsliste vergleichen. Kontospezifische Menüs und verfügbare Funktionen können von der hier beschriebenen Dokumentationsfassung abweichen.

Fragen und Antworten

Wie bleiben mehrere Profile konsistent?

Eine gemeinsame Diensteliste und dokumentierte regionale Abweichungen bilden die Referenz. Bei jeder Änderung an Diensten, Tags oder Rechtsgrundlagen erfolgt ein Abgleich sämtlicher betroffener Konfigurationen. Eine regelmäßige Kontrolle ergänzt diesen Ablauf; ein vierteljährlicher Vergleich allein würde neue Fehler bis zum nächsten Termin stehen lassen.

Was geschieht ohne passende regionale Regel?

Die globale Konfiguration des Rulesets ist die dokumentierte Rückfallkonfiguration. Das unterscheidet sich vom Einbau einer festen Settings ID ohne Ruleset. Ein fehlgeschlagener CMP-Aufruf ist wiederum ein eigener Fehlerfall und beweist keine erfolgreich geladene globale Vorgabe. Die Integration braucht dafür eine getestete Ausgangssperre einwilligungspflichtiger Tags.

Beweist ein abweichendes Banner einen Fehler der Geodaten?

Nein. Mögliche Ursachen sind IP-Zuordnung, Regeln, eingebundene ID, Konfigurationsstand und gespeicherte Entscheidungen. Ein CDN-Ländercode ist eine zusätzliche Beobachtung, kein Beweis des tatsächlichen Aufenthaltsorts. Die Diagnose vergleicht deshalb erkannte Region, geladene Konfiguration und tatsächliches Tagverhalten im selben Testlauf.

Lukas Wojcik

Lukas Wojcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Kontakt

Eine Frage oder eine Idee für ein Webprojekt? Schreib mir kurz, worum es geht. Das Formular nutzt reCAPTCHA zum Schutz vor Spam.

Kommentar schreiben

Beobachtungen aus anderen Umsetzungen, Einwände und Rückfragen sind hier willkommen.

Die E-Mail-Adresse wird nicht veröffentlicht. Pflichtfelder sind mit einem Stern versehen.