系统字段引用指引

帮助用户将 AE 预置的系统字段（SQL 可见但前端分析模型不可见）暴露到前端模型中使用。

数据分析

异常诊断全行业

系统字段引用指引是 ThinkingAI 行业 Skill 库中的一项字段配置能力，帮助数据分析师将 AE 预置的系统字段（如 #event_time、#user_id、#reg_time 等）从"SQL 可用但前端分析模型不可用"的状态，通过"创建并连接"和"创建虚拟属性"两步操作暴露到前端分析模型中——让分析师不用写 SQL 就能用这些关键字段做筛选和分组。这正是 ThinkingAI「10 年行业经验沉淀为开箱即用 Skill」的体现。

Agent存为 Agent导出会话

system-field-reference-guide

我想在前端事件分析里按 #server_time 分组看上报延迟，但属性列表里找不到这个字段。另外，常用的系统字段能不能帮我整理一张速查表？新同事每周都要来问一遍。

查询 #server_time 在某在线教育APP DEMO 项目中的连接状态

尚未创建并连接，且同时存在于事件表和用户表

跨表字段归属确认 — 按「分析每条事件的上报延迟」判定使用事件表侧

第一步：数据管理 → 事件属性 → 来源事件属性管理，创建并连接 #server_time

第二步：创建虚拟属性（关联方式 relation_always）暴露到前端模型

前端事件分析属性列表已可见

汇编常用系统字段速查表，逐个校验类型与暴露路径

7 个高频字段，对应 3 条暴露路径

两件事都办完了：`#server_time` 已经出现在前端事件分析的属性列表里，速查表也整理好了。核心是分清「用户表一步、事件表两步」这两条路径——你这次找不到字段，就是因为事件表字段少了第二步。

一、`#server_time` 这次为什么是两步

1.确认跨表归属——#server_time 在事件表和用户表都存在，你要看的是每条事件的上报延迟，用事件表侧

2.创建并连接：数据 → 数据管理 → 事件属性 → 来源事件属性管理

3.创建虚拟属性（关联方式 relation_always）——事件表字段必须有这一步前端才可见；用户表字段连接后即可直接用，不需要这步

二、常用系统字段速查表

字段	含义	类型	前端暴露路径	示例值
`#user_id`	AE 内部用户唯一 ID	数值	跨表字段，先确认归属再连接	1088342
`#distinct_id`	访客 ID（未登录态标识）	文本	事件表：连接 + 虚拟属性	d8f3a1c0
`#account_id`	注册账号 ID	文本	跨表字段，先确认归属再连接	stu_88213
`#event_time`	事件发生时间（客户端）	时间	事件表：连接 + 虚拟属性	2026-07-12 21:03:44
`#server_time`	服务端接收时间	时间	事件表：连接 + 虚拟属性（本次已完成）	2026-07-12 21:03:52
`#reg_time`	用户注册时间	时间	用户表：连接后直接可用	2026-05-30 10:11:07
`$part_date`	数据分区日期	文本	SQL 直接可用，无需暴露	2026-07-12

← 左右滑动查看

三、SQL 侧不需要任何操作

所有系统字段在 SQL 里开箱即用，不需要连接和虚拟属性。顺手用下面这条 SQL 看了你关心的上报延迟：近 7 天平均延迟 7.6 秒，仅 07-12 因晚间直播课高峰冲到 21.4 秒，其余日期都在 10 秒以内，上报链路健康。

sql

-- 上报延迟 = #server_time 与 #event_time 的差值（SQL 侧系统字段直接可用）
SELECT
  "$part_date"                                             AS dt,
  AVG(date_diff('second', "#event_time", "#server_time"))  AS avg_delay_sec
FROM ta.v_event_9
WHERE "$part_date" BETWEEN '2026-07-10' AND '2026-07-16'
GROUP BY "$part_date"
ORDER BY dt

结论

分流原则记一条就够：SQL 要用 → 直接用；前端要用 → 用户表一步、事件表两步；跨表字段 → 先确认归属。虚拟属性创建后全项目生效，建议由数据管理员统一操作，避免同一字段被重复创建多个虚拟属性。

系统字段速查表已保存至项目知识库，新同事可直接查阅。

行业痛点

AE 预置了一批系统字段，这些字段在 SQL 查询中可以直接使用，但在前端分析模型中默认隐藏不可用。分析师每季度平均遇到 3-5 次需求被隐藏字段卡住，每次需花 1-2 小时找操作路径或改写 SQL。更复杂的是事件表和用户表系统字段操作路径不同，混淆会导致浪费时间甚至配置错误。

核心价值

自动识别字段类别：事件表系统字段（需两步）vs 用户表系统字段（只需一步），避免混淆操作路径
已连接字段快速路径：字段已创建并连接后，事件表字段自动提议创建虚拟属性，用户表字段直接告知可用
未连接字段引导操作：精确给出前端操作路径，不猜不模糊
跨表字段强制确认：#user_id、#account_id 等同时存在于事件表和用户表的字段，必须由用户确认归属
SQL 场景快速告知：用户只想在 SQL 中使用系统字段时，直接告知无需任何操作可直接使用

适用场景

想在前端事件分析中按 #event_time 做筛选或分组，但属性列表中找不到

想在留存分析中用 #reg_time 做分组，但不知道怎么暴露字段

想在漏斗分析中用 #distinct_id 做关联属性，但前端模型中不可见

SQL 查询中用了 #server_time 等系统字段，想在前端模型中也用起来

不确定某个系统字段属于事件表还是用户表，需要正确操作路径

实战案例

某游戏项目 · #server_time 前端模型引用

分析师想按 #server_time 分组查看数据延迟。Skill 查询发现 #server_time 尚未连接且同时存在于事件表和用户表，引导用户确认归属事件表后，按数据→数据管理→事件属性→来源事件属性管理完成创建并连接，再创建虚拟属性 relation_always，最终前端模型可用。

常见疑问

为什么 SQL 能用但前端模型不能用？

AE 系统字段在前端分析模型中默认隐藏，需要通过创建并连接暴露；事件表字段还需额外创建虚拟属性。

事件表和用户表系统字段操作有什么区别？

事件表字段需创建并连接 + 创建虚拟属性两步；用户表字段创建并连接后即可直接使用。

已经连接的字段还需要再操作吗？

事件表字段已连接后仍需创建虚拟属性；用户表字段已连接后可直接使用。