Tutorial: Configuring Geolocation Rules in Usercentrics
Contents
Adapting consent banners to regional privacy laws is a fundamental requirement for global websites. While the European Union enforces strict opt-in rules under the GDPR, other regions often permit opt-out models or informational notices, which significantly reduces friction for users. This guide explains how to properly configure Geolocation Rules using different Settings IDs in Usercentrics.
Step 1: Creation of Settings IDs
The implementation requires at least two separate configurations within the Usercentrics platform. One configuration acts as the primary profile (e.g., for the GDPR region), while a secondary configuration is created as an alternative profile (e.g., for the Rest of the World).
- Primary Settings ID: Designed for strict compliance (EU/EEA).
- Alternative Settings ID: Designed for regions with fewer restrictions.
Step 2: Configuration of the GDPR Profile
The GDPR profile requires an explicit “Opt-in” setup. In the Admin Interface for this specific Settings ID, all data processing services (like Google Analytics or Meta Pixel) must be set to require explicit user consent before any tracking scripts are activated. The banner must provide clear “Accept” and “Deny” options.
Step 3: Configuration of the Rest of World (RoW) Profile
For the alternative Settings ID, a looser configuration is applied. Depending on internal legal guidelines, an “Opt-out” model can be selected. In this setup, services are activated by default, and the banner merely informs visitors about the tracking, providing a link to privacy settings where tracking can be disabled. Alternatively, the banner display can be completely deactivated for specific regions.
Step 4: Geolocation Mapping in the Admin Interface
Once both configurations are ready, the geographic routing must be established. This ensures the correct banner is served based on the visitor’s IP address.
- The navigation is directed to the Configuration menu, followed by the Geolocation Rules tab.
- The primary Settings ID (GDPR) is linked to the core website script.
- A new Geolocation Rule is created.
- The alternative Settings ID is selected from the dropdown menu.
- The target regions are assigned. For a “Rest of World” setup, it is highly efficient to define the GDPR profile as the default for EU/EEA countries and assign all non-European countries (e.g., USA, Canada, Australia, Asia) to the alternative Settings ID.
Step 5: Testing and Verification
Verification is crucial to ensure the correct logic is applied. A VPN connection is necessary for this step. The website is visited first with a European IP address (to verify the strict opt-in banner) and subsequently with an IP address from the United States or Asia (to verify the opt-out banner or the absence of the banner). The browser cache must be cleared between the tests.
Related articles
2 comments
two separate configurations instead of one with exceptions is the version that is still comperhensible a year later — the exception approach always collapses under the second special case.
The cost is duplication, though. When a new tool is added to the site, both profiles need it. How is that kept from drifting apart?
By treating one profile as the source and the other as a documented delta — not by trying to keep two full configurations equal from memory.
The drift always runs the same way: a new service is added while working on one region, the other profile is not open at that moment, and nothing complains. Both banners keep working, and the service is simply governed by consent in one region and not in the other. That is precisely the error the setup exists to prevent, arriving through the back door.
The cheap guard is a quarterly diff of the two service lists — most platforms can export them, and comparing two text files takes a minute. Where a service belongs to only one profile deliberately, a one-line note next to it turns a difference into a decision, and the next reviewer stops re-investigating it.