数据区域、时间与数据保留

正确理解 Region、时间字段和数据保留期，是准确阅读概览指标、事件记录、访客统计和风险趋势的前提。

Region 的合规意义

Region 决定应用数据的存储和计算区域，也是服务端密钥和 Webhook 的隔离边界。

创建应用时，应根据业务用户所在地、企业合规要求和数据处理政策选择 Region。Region 创建后不可修改。如果业务需要迁移数据区域，通常需要在目标 Region 创建新应用和接入端，并按照迁移方案重新接入。

控制台会列出当前可用的 Region 及其服务范围，例如 EU、NA 或 Global。请以创建应用时看到的选项为准；不同组织或套餐可用的 Region 可能不同。

使用 Region 时需遵循以下规则：

• 一个应用只能属于一个 Region。
• 同一 Region 下的应用共享该 Region 的服务端密钥。
• Webhook 只能绑定同一 Region 下的应用。
• 事件和访客查询应在明确的 App × Region 上下文中执行。
• 控制台不会汇总组织下所有 Region 的数据。查看其他区域时，请先切换到对应 Region。

控制台统计时区

GEELAB 控制台使用 UTC+0 统计“今日识别事件”等按天展示的指标。因此，“今天”表示 UTC+0 的 00:00:00 至当前时刻，可能与你所在地区的自然日不同。

查看日级指标或选择查询日期时，请按 UTC+0 理解时间范围。例如：

今天（UTC+0）
2026-08-25 00:00:00 至当前时间

将控制台数据与业务日志进行对照前，请先把双方时间转换到同一时区。服务端 API 返回时间的格式和时区以对应字段说明为准。

服务端接收时间与客户业务时间

一条业务记录可能同时包含两类时间：

事件页面按照 GEELAB 服务端接收时间进行筛选和排序。查找某次业务操作对应的识别事件时，可以先根据业务发生时间确定大致范围，再结合 request_id 精确定位。

客户业务时间来自你的业务系统，可能受到客户端时钟、所用时区或网络延迟影响。对照业务日志时，请确认该时间的来源和时区，并与 GEELAB 服务端接收时间区分使用。

Webhook 投递日志还会记录投递时间。事件接收时间与 Webhook 投递时间可能因处理过程和网络传输存在间隔。排查投递问题时，请分别核对事件的 request_id、服务端接收时间和 Webhook 投递时间。当前版本失败后不会自动重试。

套餐数据保留期

控制台可查询的事件明细和访客统计受套餐数据保留期限制，例如近 30 天或近 90 天。实际保留期以当前组织套餐和控制台提示为准。

数据保留期会影响：

事件列表

超过保留期的事件可能无法继续在事件列表中查询，也不能通过 Request ID 打开完整事件详情。

访客首次出现时间

访客页面中的“首次出现时间”通常表示当前保留期内第一次识别到该设备的时间，不一定是该设备历史上第一次被 GEELAB 识别的时间。

访客最近访问时间

最近访问时间表示当前可查询数据范围内，该设备最近一次被识别的时间。

访客事件数与风险信号

保存期内总识别数、近 7 日事件数、命中风险信号和历史设备环境，都只能根据当前仍可查询的数据计算。保留期外的历史事件被清理后，相应汇总结果可能发生变化。

风险趋势和环比

如果所选时间范围或上一周期超出数据保留期，趋势和环比可能不完整。看到“数据不完整”或“无上一周期数据”提示时，请缩小查询范围，不要把缺失数据理解为零。

阅读数据时的建议

• 查询事件前，先确认当前组织、应用、Region 和时间范围。
• 对比业务日志时，确认双方使用的时间字段和时区。
• 查看“首次出现时间”时，注意它是否带有“保存期内”限定。
• 调查风险信号时，从汇总卡片继续进入具体事件，不要只看聚合数字。
• 需要长期审计时，应根据企业要求规划外部日志或数据归档，不应默认控制台永久保存所有事件。