Select Region

Available Regions

When creating an application, the console will display the Regions available to the current account, for example:

The actual available Regions and corresponding service scope are subject to the console and the service agreement signed between you and Geelab.

Illustration: Select Region when creating an application

How to determine which Region should be selected?

Before choosing, it is recommended to confirm the following questions in order.

Where are your main users?

Prioritize understanding of the countries or regions where business users and data subjects are located. If the business mainly serves European users, EU can be evaluated first; if the business mainly serves North American users, NA can be evaluated first.

The user's location is only one of the selection criteria. If there is a clear data area policy within the enterprise, the enterprise's compliance requirements should prevail.

Does the enterprise have data residency requirements?

Confirm whether device identification data must be stored and processed in a designated country or region. Relevant requests may come from:

• Corporate privacy and data security policy.
• Customer contract or data processing agreement.
• Industry regulatory requirements.
• Applicable laws and regulations in the region where the business is located.

Are there any restrictions on cross-border transfers?

If the business does not allow relevant data to be transferred to other regions, you should select a Region that can meet the data residency requirements, and also check the deployment locations of logs, Webhooks, data exports, and downstream systems.

Where is your server deployed?

It is recommended to consider the area where the business server, database, logging platform and Webhook receiving service are located. Having related systems deployed in similar areas often makes it easier to manage data flows and helps reduce network latency.

Will we need to operate multiple regions in the future?

If the same business needs to serve users in Europe and North America respectively, you can create separate applications for different regions instead of having one application span multiple Regions.

For example:

Main Storefront - EU
Main Storefront - NA

Both applications have their own endpoints, events, visitors data, and zone keys.

Recommended selection process

Confirm the primary user and business regions
          ↓
Confirm corporate data residency and cross-border requirements
          ↓
Check server, log, and Webhook deployment regions
          ↓
Select EU, NA, or Global
          ↓
Does an existing Region meet the requirements?
    ├─ Yes: Create the application
    └─ No: Contact Geelab to request a custom Region

Region cannot be modified after creation

After the application is created, the Region cannot be modified. The reason is that Region is not only the display attribute of the application, but also determines the scope of application data, server keys and Webhooks.

If direct modification of the Region is allowed, it may result in:

• Historical events and new events belong to different data areas.
• The visitor statistics range changes.
• The original server key no longer matches the application area.
• Webhook binding relationship is invalid.
• Unclear scope of data migration and cross-border processing.

Therefore, please double-check the Region before clicking Confirm Creation.

Illustration: Region after the application is successfully created

What to do if you select the wrong Region?

If the application has not been officially connected, it is recommended to delete or deactivate the wrong application and re-create it in the correct Region.

If your application already generates business data, please contact Geelab support to evaluate migration options. Generally need to complete:

1. Create a new application in the target Region.
2. Re-create the web, iOS or Android endpoints.
3. Update the Public API Key used by the client.4. Configure the server key of the target Region.
4. Re-create the Webhook in the target Region.
5. Switch to production traffic after completing the test.

Whether historical events, visitor data, and device identification can be migrated depends on the specific service plan. Please check with Geelab before migrating and do not just assume that data will be automatically synchronized.