Data Analysis

Anomaly Diagnosis

System Field Reference Guide

Help users expose AE preset system fields (visible in SQL but not in the front-end analysis model) for use in the front-end model.

IndustriesAll industries

Agent · Skills Live

skill · loadedindustry+100

Run this Skill on my data

Tracking schema

events · properties

event · payment3 props

user_idstring

pay_amountnumber

channelstring

Analysis readyevidence attached

The System Field Reference Guide is a field-configuration capability in ThinkingAI's industry Skill library. It helps data analysts take AE preset system fields (such as #event_time, #user_id, and #reg_time) from "usable in SQL but not in the front-end analysis model" and expose them to the front-end model through two steps, "create and connect" and "create virtual property," so analysts can filter and group by these key fields without writing SQL. This is ThinkingAI's decade of industry experience, packaged into ready-to-use Skills.

Live walkthrough

AgentSave as AgentExport session

system-field-reference-guide

I want to group by #server_time in front-end event analysis to look at reporting delay, but I can't find that field in the property list. Also, can you put together a quick-reference table of the common system fields? New teammates come ask about it every single week.

Query the connection status of #server_time in a sample online-education app DEMO project

Not yet created and connected, and it exists in both the event table and the user table

Confirm cross-table field ownership: judged to use the event-table side per "analyze the reporting delay of each event"

Step 1: Data Management → Event Properties → Source Event Property Management, create and connect #server_time

Step 2: Create a virtual property (association method relation_always) to expose it to the front-end model

Now visible in the front-end event analysis property list

Compile a quick-reference table of common system fields, validating each one's type and exposure path

7 high-frequency fields, mapping to 3 exposure paths

Both are done: `#server_time` now appears in the front-end event analysis property list, and the quick-reference table is ready. The key is distinguishing the two paths, "one step for user-table fields, two steps for event-table fields," and the reason you couldn't find the field this time is that event-table fields were missing the second step.

1. Why `#server_time` took two steps this time

1.Confirm cross-table ownership: #server_time exists in both the event table and the user table; since you want the reporting delay of each event, use the event-table side

2.Create and connect: Data → Data Management → Event Properties → Source Event Property Management

3.Create a virtual property (association method relation_always): event-table fields require this step before they're visible on the front end; user-table fields are usable directly once connected and don't need this step

2. Quick-reference table of common system fields

Field	Meaning	Type	Front-end exposure path	Example value
`#user_id`	AE internal unique user ID	Numeric	Cross-table field, confirm ownership before connecting	1088342
`#distinct_id`	Visitor ID (logged-out identifier)	Text	Event table: connect + virtual property	d8f3a1c0
`#account_id`	Registered account ID	Text	Cross-table field, confirm ownership before connecting	stu_88213
`#event_time`	Event occurrence time (client)	Time	Event table: connect + virtual property	2026-07-12 21:03:44
`#server_time`	Server receive time	Time	Event table: connect + virtual property (done this time)	2026-07-12 21:03:52
`#reg_time`	User registration time	Time	User table: usable directly after connecting	2026-05-30 10:11:07
`$part_date`	Data partition date	Text	Usable directly in SQL, no exposure needed	2026-07-12

← Scroll to see more

3. No action needed on the SQL side

All system fields work out of the box in SQL, with no connection or virtual property required. I used the query below to check the reporting delay you cared about: over the last 7 days the average delay is 7.6 seconds, and only 07-12 spiked to 21.4 seconds because of the evening live-class peak, with every other day under 10 seconds, so the reporting pipeline is healthy.

sql

-- Reporting delay = the difference between #server_time and #event_time (system fields are usable directly in 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

Conclusion

One rule for routing is enough: need it in SQL → use it directly; need it on the front end → one step for the user table, two steps for the event table; cross-table field → confirm ownership first. A virtual property takes effect project-wide once created, so I'd suggest a data admin handle it centrally to avoid the same field getting multiple duplicate virtual properties.

The system-field quick-reference table is saved to the project knowledge base, where new teammates can look it up directly.

On your data

That was a simulated run

Leave your work email and we will run a live walkthrough on your real business data.

The problem

AE presets a set of system fields that can be used directly in SQL queries but are hidden and unavailable in the front-end analysis model by default. Analysts hit a need blocked by a hidden field 3 to 5 times a quarter on average, each time spending 1 to 2 hours finding the right path or rewriting SQL. More complex still, event-table and user-table system fields have different operation paths, and confusing them wastes time or causes misconfiguration.

What it does

Automatically identify the field category: event-table system fields (two steps) versus user-table system fields (one step), avoiding path confusion

Fast path for connected fields: once a field is created and connected, event-table fields automatically prompt to create a virtual property while user-table fields are simply reported as available

Guided operations for unconnected fields: give the exact front-end path, with no guessing and no vagueness

Mandatory confirmation for cross-table fields: fields present in both the event and user tables, such as #user_id and #account_id, must have their ownership confirmed by the user

Quick answer for SQL scenarios: when the user only wants to use a system field in SQL, simply report that it can be used directly with no operation needed

When to use it

You want to filter or group by #event_time in front-end event analysis but cannot find it in the property list

You want to group by #reg_time in retention analysis but don't know how to expose the field

You want to use #distinct_id as an associated property in funnel analysis but it is not visible in the front-end model

You used a system field like #server_time in a SQL query and want to use it in the front-end model too

You are unsure whether a system field belongs to the event table or user table and need the correct operation path

In the field

Case

A game project · referencing #server_time in the front-end model

The analyst wanted to group by #server_time to view data latency. The Skill found #server_time was not yet connected and existed in both the event and user tables, guided the user to confirm it belonged to the event table, then completed create-and-connect via Data, Data Management, Event Properties, Source Event Property Management, and created the virtual property relation_always, making it usable in the front-end model.

FAQ

Why can it be used in SQL but not in the front-end model?

AE system fields are hidden by default in the front-end analysis model and must be exposed by create-and-connect; event-table fields additionally require creating a virtual property.

What is the difference between event-table and user-table system fields?

Event-table fields require two steps, create-and-connect plus creating a virtual property; user-table fields are usable directly after create-and-connect.