选择区域（Region）
可用区域（Region）
创建应用时，控制台会展示当前账号可使用的区域（Region），例如：
| 区域（Region） | 适用业务参考 |
|---|---|
| EU | 主要面向欧洲地区开展业务，或要求相关数据在欧洲区域处理 |
| NA | 主要面向北美地区开展业务，或要求相关数据在北美区域处理 |
| Global | 业务覆盖多个地区，且企业合规政策允许使用全球服务区域 |
实际可用区域（Region）及对应的服务范围，以控制台和你与 GEELAB 签署的服务协议为准。
如何判断应该选择哪个区域（Region）
选择前，建议依次确认以下问题。
如果你希望先了解区域（Region）为什么构成数据、密钥和网络回调（Webhook）的隔离边界，请阅读区域（Region）的合规意义。
你的主要用户在哪里？
优先了解业务用户和数据主体所在的国家或地区。如果业务主要服务欧洲用户，可以优先考虑 EU；如果主要服务北美用户，可以优先考虑 NA。
用户所在地只是选择依据之一。如果企业内部已有明确的数据区域政策，应以企业合规要求为准。
企业是否有数据驻留要求？
确认设备识别数据是否必须在指定国家或地区存储和处理。相关要求可根据你所在地区的相关要求或法规：
- 企业隐私和数据安全政策。
- 客户合同或数据处理协议。
- 行业监管要求。
- 业务所在地区的适用法律法规。
是否存在跨境传输限制？
如果业务不允许相关数据传输到其他地区，应选择能够满足数据驻留要求的区域（Region），并同时核对日志、事件回调（Webhook）、数据导出和下游系统的部署位置。
你的服务端部署在哪里？
建议同时考虑业务服务端、数据库、日志平台和网络回调（Webhook）接收服务所在的区域。让相关系统部署在相近区域，通常更便于管理数据流，也有助于降低网络延迟。
当前或者未来是否需要在多个地区运营您的 App？
如果同一业务需要分别服务欧洲和北美用户，可以为不同地区分别创建应用，而不是让一个应用跨多个区域（Region）。
例如：
商城主站 - EU
商城主站 - NA两个应用分别拥有自己的接入端、事件、设备数据和 Region 服务端密钥。
推荐选择流程
确认主要用户和业务地区
↓
确认企业数据驻留与跨境要求
↓
核对服务端、日志和 Webhook 部署区域
↓
选择 EU、NA 或 Global
↓
现有 Region 不满足要求？
├─ 否：创建应用
└─ 是：联系 GEELAB 申请定制 Region
区域（Region）创建后不可修改
创建应用后，区域（Region）不可修改。原因是区域（Region）不只是应用的显示属性，还决定了应用数据、服务端密钥和网络回调（Webhook）的归属范围。
选错区域（Region）怎么办
如果区域（Region）选择错误，请在正确的区域（Region）中创建新的应用（App），并重新完成接入配置：
- 在目标区域（Region）创建新应用。
- 重新创建 Web、iOS 或 Android 接入端。
- 更新客户端使用的公开应用程序接口密钥（Public API Key）。
- 配置目标区域（Region）的服务端密钥。
- 在目标区域（Region）重新创建网络回调（Webhook）。
- 完成测试后切换生产流量。
目前不支持将旧应用（App）的历史事件、设备数据和设备标识迁移到新应用（App）。旧数据不会自动同步到新应用（App），仍需在原应用（App）所属区域（Region）内按照数据保留规则查询。确认新应用（App）接入正常且不再需要旧应用（App）后，再停用旧应用（App）；删除旧应用（App）前请确认相关历史数据已无需继续查询。