Data Collection

Data Engineering

SQL Query Generation

Automatically generate compliant query SQL from business requirements based on AE system data specs and Trino SQL syntax, complete with event-table/user-table structures and partition-field specs, upgrading SQL writing from "guessing from memory" to "generating to spec".

IndustriesAll industries

Agent · Skills Live

skill · loadedindustry+100

Run this Skill on my data

Query console

generated

query.sql · generated

SELECT channel, count(*)

FROM v_payment

GROUP BY channel — 0.4s

12 rows returned

Analysis readyevidence attached

The Generate SQL Skill is a SQL-generation capability in ThinkingAI's industry Skill library. It helps data and operations teams automatically generate compliant query SQL from business requirements, based on AE system data specs (event-table/user-table structures, partition fields, and field-naming rules) and Trino/Presto SQL syntax, covering common scenarios like single-event queries, multi-event queries, event-plus-user join queries, and abnormal-player investigation, upgrading SQL writing from guessing field names and partition conditions from memory to precisely generating syntax-error-free SQL to spec. This is ThinkingAI's decade of industry experience, packaged into ready-to-use Skills.

Live walkthrough

AgentSave as AgentExport session

generate-sql-query

Write me a SQL query: for channel suspect_channel, get the distribution of key behavioral events for players between March 1 and 2. My own version ran for ten minutes and timed out.

Get project info via MCP

project_id=2, event table ta.v_event_2

Confirm the "key behavior" event list

Matched from metadata: login / battle_start / payment / item_use

Generate SQL per AE data conventions: partition filters, double-quoted fields, group by rules

Syntax check and execution

Returned in 9.4 seconds, scanned 2 partitions

The SQL is written and verified. First, why yours timed out: it had no `$part_date` or `$part_event` partition filters. AE event tables are partitioned by date and event name, and missing partition filters means a full scan of years of detail, so a timeout was inevitable.

1. Compliant SQL

sql

SELECT
  "$part_event"                AS event_name,
  COUNT(*)                     AS event_count,
  COUNT(DISTINCT "#user_id")   AS user_count
FROM ta.v_event_2
WHERE "$part_date" BETWEEN '2026-03-01' AND '2026-03-02'
  AND "$part_event" IN ('login', 'battle_start', 'payment', 'item_use')
  AND "channel" = 'suspect_channel'
GROUP BY "$part_event"
ORDER BY event_count DESC
LIMIT 100

2. Key conventions (so you can avoid the traps yourself next time)

$part_date + $part_event must go in the WHERE clause; it scans only the matched partitions, and this query dropped from timeout to 9.4 seconds

Always double-quote field names; Trino lowercases bare identifiers, and fields like #user_id error out without quotes

Use original field names or positional numbers in GROUP BY, not SELECT aliases

Add a LIMIT safety net by default to avoid an accidental full query bogging down the queue

3. Execution results

Event	Event count	Triggering users	Per-user count
login	48,213	8,632	5.6
battle_start	12,401	3,207	3.9
item_use	3,120	1,872	1.7
payment	89	41	2.2

← Scroll to see more

As an aside on a data trait: this channel had 8,632 logins over two days, but only 37% ever started a battle and just 41 users paid: high login volume, thin core behavior, a behavioral structure clearly unlike a normal channel.

Recommendation

This distribution matches the typical profile of a fraud channel. To draw a conclusion, use the "Channel Quality Analysis" Skill for a full six-metric evaluation (retention / payment / LTV / ROI crossed); the event distribution alone isn't enough.

The SQL is saved to the project query library under "Channel Behavior Investigation" and can be reused with adjusted parameters.

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

SQL queries in the AE system are an important means of data insight, but over 60% of teams writing SQL fall into the same traps: not knowing the event table name is ta.v_event_{project_id}; not knowing that $part_date and $part_event partition conditions are required or the query is extremely slow; not knowing that field names must be double-quoted to avoid Trino recognition errors; and not knowing that GROUP BY cannot use SELECT aliases. SQL written from memory has a syntax error rate over 40% and a slow-query rate over 50%.

What it does

AE data specs built in: the structure, partition fields, and key fields of the event table (ta.v_event_{project_id}) and user table (ta.v_user_{project_id}) are all built in

Partition fields enforced: $part_date and $part_event must appear in the WHERE clause to avoid full-table scans and slow queries

Trino syntax compliance: field names double-quoted, GROUP BY using original field names or position numbers rather than aliases, and a default LIMIT 100 to cap result volume

Four common scenario templates: single-event query, player-behavior query, event-plus-user join query, and abnormal-player investigation, with the template auto-selected by scenario

No guessing, no randomness: project_id, event names, and property names are all obtained from context or MCP queries, never randomly generated

When to use it

Writing SQL to query specific event data (e.g. the channel distribution of registered users)

Writing SQL to query a specific player's behavior sequence (e.g. a player's login/payment behavior)

Writing SQL to join the event table and user table (e.g. a paying user's cumulative recharge amount)

Writing SQL to investigate abnormal players (e.g. the event distribution and anomaly patterns of players from a channel)

Confirming the AE system's event-table/user-table structure and partition-field specs

Preferring ae-analysis over hand-writing SQL when the data need is already covered by a report or MCP

In the field

Case

An operations team · abnormal-channel player behavior query

The team needed to query the key-behavior distribution of players from the suspect_channel channel on March 1-2, but hand-written SQL timed out because it forgot the $part_date and $part_event partition conditions. The Generate SQL Skill automatically generated compliant SQL: using the v_event_2 event table, adding event and date partition filters, double-quoting field names, and using original field names in GROUP BY. The query went from timing out to returning results within 10 seconds, with zero syntax errors.

FAQ

Why are partition conditions required?

AE event tables are partitioned by date ($part_date) and event name ($part_event), and omitting partition conditions triggers a full-table scan that makes the query extremely slow or even time out.

Why do field names need double quotes?

In Trino/Presto SQL, identifiers without double quotes are automatically lowercased, which causes mismatches with the AE system's actual field names. Double-quoting preserves the original case.

What is the difference from ae-analysis?

If the data need can be covered by an ae-analysis report query or Builder Ad-hoc, prefer ae-analysis; use generate-sql only when a custom SQL query is required.