Academy
4. Asking Great Questions
Learn practical techniques for writing effective queries: naming columns precisely, specifying periods and groupings, asking one thing at a time, and handling ambiguous column names.
When you type a question in OUPI Data, the platform doesn't let a language model eyeball your spreadsheet and guess. Instead, it reads your dataset's structure — column names, types, a sample of rows — and writes actual code to answer your question. That code runs on every row in a secure sandbox, producing an exact result. A plain-language summary is then generated and automatically verified: every number in the summary is compared against the computed data, and mismatches are flagged. This means arithmetic is always done by code, not by a model approximating. What can vary is how your question was interpreted — which is exactly why the generated code and result table are shown to you. Understanding this pipeline is the key to writing better questions: your job is to make the interpretation step as unambiguous as possible.
The single most impactful habit is to name columns exactly as they appear in your dataset. If your spreadsheet has a column called "revenue_q2" rather than "Revenue", use that label in your question. The engine maps your words to real columns; a close match works, but an exact match removes all guesswork. Before querying, glance at your dataset's detected structure — OUPI shows columns and types after import — so you know the precise names available to you.
Always specify the period and the grouping you want. Compare "show me revenue" (vague) with "total revenue by region for Q2 2025" (clear period, clear grouping, clear metric). The more structure you give, the less the engine has to assume.
Ask one thing at a time. A question like "What are the top 10 customers by margin in 2025, and also plot the monthly trend of returns by product category?" bundles two unrelated analyses. Split it into two queries. Each query keeps its code, result table, summary, and chart — you can save both and revisit them on refreshed data whenever you need. Simpler questions also make it easier to verify that the engine understood you correctly by inspecting the generated code.
Sometimes a column name is ambiguous — "amount" could mean invoice amount, payment amount, or credit amount if your dataset has several similarly named fields. When this happens, the engine either asks you to clarify or states the assumption it made in the answer. Read the summary carefully: if it picked the wrong column, simply correct your question (e.g., "use the column payment_amount") and re-ask. The code is always visible, so you can confirm exactly which column was used.
Open OUPI Data → Query. Pick a dataset you know well. Write a question that names a specific column, states a period, and requests a grouping — for example: "average unit_price by supplier for January 2025". Check the generated code and summary. Then rephrase the same question vaguely ("show me prices") and compare how the engine interprets it.
If your dataset is large and the engine's interpretation seems off, remember: the model reads a sample of rows to understand structure, but computation always runs on all rows. The issue is usually a naming mismatch, not missing data. Refine column names in your question rather than doubting the numbers.
Four rules for great natural-language queries: (1) use exact column names from your dataset, (2) state the period and grouping explicitly, (3) ask one question per query, and (4) when a column name is ambiguous, read the engine's assumption and correct it. The platform does arithmetic by code — not by guessing — and verifies every number in the summary. Your role is to make the question unambiguous so the interpretation matches your intent. Save your best queries to re-run them as data refreshes.