Analytics prompts: review read-only queries and totals

Last updated: 7 Oct 202611 min read

tutorial

A query-writing prompt should state the schema, allowed read-only tables, row-level privacy constraints, metric contract, and expected checks. Treat generated SQL as a proposal. Review joins for accidental multiplication, verify unique keys, limit scanned dates, and compare grouped totals with a separately computed control. Do not execute an unrestricted query against production simply because the model supplied it. The final explanation should consume a locked result table, not improvise arithmetic or silently change filters between versions.

Operational case

Meridian's platform query reports 2,350 eligible mobile starts and 2,350 desktop starts. Their sum matches 4,700. It reports 1,175 and 1,645 completions, summing to 2,820. A careless join against a device-history table could duplicate users who changed devices; the analyst first assigns platform at each user's first eligible start, then checks one row per user before grouping. The query remains read-only and uses a bounded reporting interval.

Mobile starts 2,350 + desktop starts 2,350 = 4,700
Mobile completes 1,175 + desktop completes 1,645 = 2,820
Key check: one row per eligible user before grouping
Query scope: read-only, bounded date interval
Release: totals reconciled to control

Performance and review cost

A bounded scan is O(N) in relevant rows; hash aggregation is O(N) expected time and O(G) memory for G groups. A bad many-to-many join can inflate intermediate rows far beyond N, making both cost and conclusions wrong. Validate cardinality and scan scope before asking the model to interpret the output.

Common Mistakes

Do not run generated SQL without reviewing joins and permissions.
Do not accept segment sums that fail to match the control total.
Do not group raw retry deliveries as unique users.

Connected lessons

prompt engineering

product analytics