Product analytics queries you can read and trust
Data literacy is now the top skill PMs say AI makes more important, and many PMs are semi-technical, able to read SQL but slow to write it. Describing the question and the schema in plain language gets a working query plus an explanation and edge cases, and it never requires touching a single user's personal data if you keep the schema abstract.
You are an analytics engineer helping a product manager answer a product question with SQL. Prioritize a query I can read and verify over a clever one. Question I'm trying to answer: {{question}} My warehouse: {{warehouse}} Relevant tables and columns (names and types): {{schema}} Provide: 1. An "Assumptions" list stating everything you assumed about my schema and the metric definition. 2. The query, with a comment on each non-obvious clause explaining what it does and why. 3. Edge cases that will skew the result — NULLs, duplicate events, timezone handling, bot/internal traffic, users with no activity — and how the query handles or should handle each. 4. A validation check: a second, simpler query or a known number I can compare against to confirm the result is sane. Rules: - Do not invent table or column names I didn't give you. Where you need one, use a clear placeholder like "[WHICH TABLE?]" and list it under assumptions. - Read-only only: no INSERT, UPDATE, DELETE, or DROP. If the task seems to need a write, stop and tell me. - If my definition of the metric is ambiguous (e.g., "active user"), state the interpretation you used and note the alternatives.
Fill in your details and the prompt updates live — then copy.
Assumptions: "connected a source" = an events row where event_name = 'source_connected'; week-1 retention = any event in days 7-13 after signup; timestamps are UTC. -- cohort: users, flagged by whether they connected in session 1 (first 30 min) -- retained: any event in the day 7-13 window SELECT connected_first_session, COUNT(*) AS users, AVG(CASE WHEN retained THEN 1 ELSE 0 END) AS wk1_retention FROM ... GROUP BY 1; Edge cases: exclude internal user_ids (bot traffic) or retention inflates; dedupe events before counting. Validation: total users here should equal COUNT(DISTINCT user_id) in the signup cohort.
The full workflow
- Describe the schema with table and column names but no actual user rows
- Run the query in a read-only environment or against a dev copy first, never blind on production
- Execute the validation check and reconcile it to a number you already trust
- Confirm the metric definition matches your team's official one before sharing the result
Watch out for
Never paste query results containing user emails, names, or other PII into a consumer AI tool; that's personal data under GDPR and CCPA. Share the schema and abstract questions, not exported rows.
A query that returns a number isn't a query that's right. Timezone, dedup, and bot-traffic mistakes produce clean-looking but wrong metrics — always run the validation check before the number reaches a decision.
Guard the warehouse. Only run AI-generated SQL with read-only credentials, and never let a model talk you into a write it labeled 'harmless'.
Where this comes from
Every use case on this site is grounded in real reports from working product managers — not invented by us.