Region 隔离规则

隔离关系概览

flowchart TD
    ORG[组织]
    EU[EU Region]
    NA[NA Region]
    APP1[应用 A]
    APP2[应用 B]
    APP3[应用 C]
    KEY1[EU 服务端密钥]
    KEY2[NA 服务端密钥]
    EVENT1[EU 事件与访客]
    EVENT2[NA 事件与访客]
    WH1[EU Webhook]
    WH2[NA Webhook]

    ORG --> EU
    ORG --> NA
    EU --> APP1
    EU --> APP2
    NA --> APP3
    EU --> KEY1
    NA --> KEY2
    APP1 --> EVENT1
    APP2 --> EVENT1
    APP3 --> EVENT2
    EU --> WH1
    NA --> WH2

应用与接入端

一个应用只能属于一个 Region。应用下的所有接入端自动继承该 Region。

例如，在 EU 创建的应用，其 Web、iOS 和 Android 接入端都属于 EU。接入端生成的 Public API Key 也应只用于当前应用和平台。

不要在以下场景中混用 Public API Key：

• 将 EU 应用的 Key 用于 NA 应用。
• 将 Web 接入端的 Key 用于 iOS 或 Android。
• 将一个应用的 Key 用于另一个应用。

图示：应用与接入端归属

事件

每条事件都归属于明确的组织、Region、应用和接入端。

在事件页面查询时：

• 选择应用后，只展示该应用对应 Region 中的事件。
• 切换应用后，页面重新加载新应用的数据。
• 已知其他 Region 的 Request ID，也不能绕过权限直接查看。
• 事件详情中的设备、网络和风险信号均属于该事件所在 Region。

应用和 Region 是事件查询的基础范围，不是普通的可删除筛选条件。

访客

访客是基于 device_id 聚合形成的设备视图。访客列表和访客详情遵循当前应用及 Region 的数据范围。

默认情况下：

• 不同应用的事件不会自动合并到同一个访客页面。
• 不同 Region 的事件不会自动合并。
• 访客的首次出现、最近访问、事件数量和风险信号只基于当前可查询数据计算。
• 数据保留期之外的历史事件不会继续出现在访客详情中。

不要使用一个 Region 中的 Device ID，直接推断另一个 Region 中的访客身份。

服务端密钥

服务端密钥按 Region 管理。同一 Region 下的应用可以使用该 Region 的服务端密钥调用服务端 API。

如果你的组织同时使用 EU 和 NA，应分别配置：

EU 业务服务 → EU 服务端密钥 → EU 应用数据
NA 业务服务 → NA 服务端密钥 → NA 应用数据

服务端密钥不能跨 Region 使用，也不能放在网页、iOS 或 Android 客户端中。

轮换某个 Region 的服务端密钥时，需要更新该 Region 下所有使用该密钥的服务端配置，其他 Region 不受影响。

图示：Region 服务端密钥

Webhook

一个 Webhook 只能绑定同一 Region 下的应用。

创建 Webhook 时：

1. 先选择 Region。
2. 控制台只显示该 Region 下可绑定的应用。
3. 可以选择该 Region 下的全部应用，也可以只选择部分应用。
4. 不能在同一个 Webhook 中同时选择 EU 和 NA 应用。

如果需要接收多个 Region 的事件，请分别创建 Webhook：

EU Webhook → 接收 EU 应用事件
NA Webhook → 接收 NA 应用事件

两个 Webhook 可以指向不同区域的接收服务。是否把多个 Region 的事件汇入同一个下游系统，应由你的合规团队确认。

图示：Webhook 与 Region 绑定