{"id":301,"date":"2026-07-13T10:51:58","date_gmt":"2026-07-13T08:51:58","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=301"},"modified":"2026-10-24T01:56:23","modified_gmt":"2026-10-23T23:56:23","slug":"tutorial-configuring-geolocation-rules-in-usercentrics","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/data-privacy\/tutorials-en\/tutorial-configuring-geolocation-rules-in-usercentrics\/","title":{"rendered":"Tutorial: Configuring Geolocation Rules in Usercentrics"},"content":{"rendered":"

Geolocation rules select a Usercentrics configuration using an IP-based location estimate. Settings IDs<\/strong> identify individual configurations; a Ruleset ID<\/strong> identifies their regional mapping. This technical selection does not determine which privacy rules apply to the actual processing.<\/p>\n

A blanket profile of \u201coutside the EU\/EEA means no consent\u201d is unsuitable. Other regions also impose privacy obligations, and GDPR applicability does not depend solely on the detected IP country. The starting point is a documented decision for each processing activity and region, rather than a desired banner rate.<\/p>\n

1. Define configurations and responsibilities<\/h2>\n

Different regional behaviour requires the relevant configurations with their own Settings IDs. Uniform worldwide behaviour does not necessarily require two profiles. A concise mapping records the region, Settings ID, services, consent requirements and responsible approval.<\/p>\n

Services that require consent remain blocked before consent is given. Strictly necessary functions need separate assessment. The CMP must be connected to the actual scripts and tags; listing a service in the banner does not automatically block every existing integration.<\/p>\n

\"Workflow
The ruleset selects the configuration. Consent requirements and actual tag blocking still need separate checks.<\/figcaption><\/figure>\n

2. Set a global default and regional rules<\/h2>\n

A ruleset is created under Geolocation Rulesets<\/strong>. Its Global Configuration<\/strong> defines the default; regional rules connect selected areas to other Settings IDs. Included configurations must not impose conflicting additional geographic restrictions.<\/p>\n

The country selection needs explicit review: the EU bundle, for example, includes neither the United Kingdom nor Switzerland. The label \u201cRest of World\u201d alone cannot establish a common legal treatment for multiple jurisdictions.<\/p>\n

\u201cDo not display CMP layer\u201d is not merely a visual option.<\/strong> The vendor states that the CMP continues running in the background with all services consented by default. That effect belongs in approval and testing. An automatic product default is not consent actually given by a visitor.<\/p>\n

3. Use the matching implementation script<\/h2>\n

The Ruleset ID controls regional selection. The documented newer loader uses data-ruleset-id<\/code>. Leaving a fixed data-settings-id<\/code> in place instead loads the individual configuration.<\/p>\n

<script id="usercentrics-cmp"\n  data-ruleset-id="RULESET_ID_PLACEHOLDER"\n  src="https:\/\/web.cmp.usercentrics.eu\/ui\/loader.js"><\/script><\/code><\/pre>\n
The script belongs in the document head before services requiring consent. The example applies to the specified loader and contains a placeholder ID. The older Browser UI documentation for app.usercentrics.eu\/browser-ui\/latest\/loader.js<\/code> uses ruleset-id<\/code> instead. Loader and attribute must match. The implementation instructions for the CMP version in use take precedence. A second parallel CMP installation should be avoided.<\/p>\n
4. Check selection and actual data flows<\/h2>\n
A VPN or an external test location can exercise IP-based selection. A VPN is not the only testing option: the Browser SDK also documents userCountryData<\/code> for simulation in test integrations. Simulation does not replace testing production IP detection.<\/p>\n