Turning Business Questions Into Data Queries

Turning business questions into data queries means resolving five things the person asking left unsaid.

“Which customers are about to churn?” is not a query. It is a request that could map to a dozen different queries depending on what counts as a customer, what counts as churn, how far ahead “about to” reaches, which signals count as risk, and what the answer will be used for. The translation work is pinning down five elements: the entity, the metric, the timeframe, the comparison, and the threshold. Once those are settled, writing the query takes minutes. Skip them and you build the wrong thing, twice.

This is also exactly what an AI analytics chat is doing when you type a plain-language question into it. Kissmetrics resolves the question against the events it already captured from your site, builds the metric or report, and saves the setup so the next person who asks gets the same answer instead of a fresh interpretation. For the harder questions it composes the query itself and picks an efficient path to run it. Knowing what the translation involves still matters, because a vague question produces a vague answer from a human analyst and from an LLM alike.

The Five Things Every Question Leaves Unsaid

Take the churn question again. It contains at least five ambiguities the person asking does not realize they left open:

• What is a “customer”? An account? A subscription? A billing entity? A user? In many organizations, these are different things with different tables in the database.
• What does “about to” mean? Within the next 30 days? Before their renewal date? Before the end of the quarter?
• What does “churn” mean? Cancellation? Non-renewal? Downgrade to a free plan? Reduced usage below a threshold? Each definition produces a different list.
• What signals indicate risk? Declining usage? Support tickets? Missed QBRs? Payment failures? The VP likely has an intuition but has not made it explicit.
• What will they do with the answer? If the goal is to assign CSMs for intervention, they need the list sorted by save-ability. If the goal is to forecast revenue, they need it sorted by ARR.

These are not edge cases. Every business question that a sales leader asks contains this kind of ambiguity. The analyst who starts querying before resolving these ambiguities will produce technically correct results that answer the wrong question.

Organizational dynamics make this worse. The VP does not want to spend 20 minutes defining their terms. They asked what they consider a simple question and expect a quick answer. The analyst does not want to seem unhelpful by pushing back with a list of clarifying questions. So the analyst guesses, spends a day building the query, delivers a result, and starts the cycle again when the VP says “that is not quite what I meant.” For a broader framework on handling this dynamic, see our guide on handling vague stakeholder requests.

The Five Question Types

Most questions from sales and revenue leaders fall into five categories. Knowing the category tells you which ambiguity to resolve first.

Health and Risk Questions

“Which accounts are at risk?” “Are our enterprise customers healthy?” “Who should we be worried about?”

These questions require you to define a health or risk score based on observable signals. The translation involves: defining which behavioral signals indicate health versus risk (login frequency, feature usage, support interactions, expansion activity), setting thresholds that separate healthy from at-risk, and choosing the time window over which to evaluate. A customer who has not logged in for 14 days is a very different signal in a daily-use product versus a monthly-reporting product.

Performance Questions

“How did we do this quarter?” “Which reps are performing?” “Are we hitting our targets?”

These questions require clarifying: performance on which metric (bookings, pipeline, win rate, deal velocity), at which level of granularity (company, team, individual rep, deal), and compared to what baseline (target, previous quarter, same quarter last year). The same question, “how did we do?”, produces radically different analyses depending on these choices.

Forecasting Questions

“Will we hit our number?” “What does pipeline coverage look like?” “How much revenue are we at risk of losing?”

Forecasting questions are uniquely tricky because they require you to combine historical data with forward-looking assumptions. The translation involves: defining the forecast period, choosing the forecasting methodology (weighted pipeline, historical conversion rates, regression model), and making explicit the assumptions embedded in each approach. A pipeline-weighted forecast assumes that deal stages have stable conversion rates, which may not be true if the market or product has changed.

Segmentation Questions

“Who are our best customers?” sounds like a simple question, but “best” could mean highest revenue, highest growth, highest engagement, best retention, or most likely to refer. Each definition produces a different list with different strategic implications.

Segmentation questions require you to define the dimension (what makes one segment different from another), the metric (what you are measuring for each segment), and the purpose (what decision will the segmentation inform). If the VP wants to know best customers to inform a case study campaign, the answer is different than if they want to know best customers to inform pricing strategy.

Attribution Questions

“What is working?” “Why did churn spike?” “What drove the increase in enterprise deals?”

Attribution questions are the hardest to translate because they ask about causation, which data alone rarely proves. The translation involves: defining the outcome precisely, defining the candidate causes, and choosing an analytical approach that provides useful signal (correlation analysis, cohort comparison, time-series analysis) while being honest about the limitations of causal inference from observational data.

The Translation Checklist

Once you know the question category and have resolved the obvious ambiguities, map the question to specific, queryable metrics. Five elements, in order, make this systematic.

1. Define the Entity

What is the unit of analysis? Accounts, users, deals, subscriptions, or something else? This determines which table or data source is the starting point for your query. It also determines the grain of the result set: one row per account, one row per user, or one row per deal.

2. Define the Metric

What are you measuring about each entity? Revenue, usage, conversion, health score, or something else? Be precise about the calculation. “Revenue” could mean contracted ARR, recognized revenue, MRR, or total lifetime payments, and each comes from a different field in most data warehouses.

3. Define the Timeframe

What time period does the question cover? This quarter, trailing 90 days, since the customer started, or year-over-year? The timeframe affects both the query logic and the interpretation of results. Trailing-period metrics smooth out seasonality. Fixed-period metrics align with business reporting cycles. Lifetime metrics capture the full history but can obscure recent trends.

4. Define the Comparison

Is the question asking for an absolute value or a comparison? Most useful analyses are comparative: this period versus last period, this segment versus that segment, actual versus target. If the VP asks “how is retention?” the answer “82%” is less useful than “82%, which is 3 points below target and 5 points below same quarter last year.” Tools that support built-in period-over-period comparison make this trivially easy to include.

5. Define the Threshold

If the question involves a judgment (“at risk,” “best,” “underperforming”), what numeric threshold defines that judgment? This is often the step where the VP’s intuition gets made explicit. “At risk” might mean usage declined more than 30% month-over-month, or health score dropped below 60, or the account has not logged in within 21 days. Getting this threshold agreed upon before running the query prevents the “that does not look right” response when the results arrive.

The five-element checklist transforms a vague business question into a precise analytical specification. It takes five minutes to work through and saves hours of rework. For additional frameworks on connecting analysis to decisions, see our guide on turning data into business decisions.

Letting AI Do the Translation

The checklist above describes what a good analyst does in their head. It is also what an LLM has to do, and where most AI analytics attempts fall over. Paste a schema into ChatGPT or Claude and ask “which customers are about to churn?” and you will get plausible SQL against columns that may or may not exist, using a churn definition the model invented. The output looks confident and is unverifiable without reading every line. Our guide on using AI to generate SQL without hallucinations covers why that happens.

The fix is to give the model a schema it did not have to guess at. Kissmetrics scans your site and configures tracking on its own, so the events and properties the AI chat sees are the real ones from your product, already named and typed. When you ask a plain-language question, the chat resolves it against that live schema rather than a pasted approximation, builds the metric or report, and saves the definition it used. Harder questions, the ones a human analyst would answer with a join or a window function, get composed by the chat internally on a path it picks for efficiency, and the metric or report that comes out is saved so you can rerun it or put it on a schedule. The event and property names it resolves against are yours to inspect and correct in the schema settings, so if the chat is reading an event under the wrong name you fix it at the source rather than in a query.

What AI Still Cannot Decide for You

An AI chat resolves the entity, the metric, and the timeframe well, because those are readable from the schema and the phrasing. It cannot resolve the threshold or the purpose. Nothing in your event data says whether “at risk” means a 30 percent usage drop or a 60-day login gap. That is a business decision, and if you do not make it, the model will pick something reasonable and never tell you it picked. The practical workflow is: state the threshold in the question itself, then let the AI handle the rest.

The second thing AI does not fix is disagreement. If sales and finance define revenue differently, an AI chat will happily produce both numbers, and the argument moves from the query to the answer. The glossary work below is still yours.

Building a Reusable Library

The same categories of questions come up repeatedly. Saving each resolved question turns a multi-day project into a lookup. In Kissmetrics, a question answered through the AI chat gets saved as a metric or a report, so the next person who asks it reruns the same definition instead of getting a fresh interpretation. The habit matters more than the storage: settle the definition once, give it a name people recognize, and reuse it.

Template Structure

A good query template has four components. First, the business question it answers, stated in plain language. Second, the parameters that the analyst needs to fill in for each instance (time period, segment, threshold). Third, the query or analytical approach, with parameters clearly marked. Fourth, the interpretation guide: how to read the results and what caveats apply.

Example: The Churn Risk Template

Business question: “Which accounts are at risk of churning within the next X days?” Parameters: risk window (default 60 days), usage decline threshold (default 30%), minimum ARR (default $0, include all). The query identifies accounts where trailing 30-day usage has declined by more than the threshold compared to the previous 30 days, filtered by accounts with renewal dates within the risk window. The output includes account name, ARR, usage decline percentage, last login date, and assigned CSM, sorted by ARR descending so the most valuable at-risk accounts surface first. In Kissmetrics this is a Population defined on behavior, which stays current as people enter and leave the condition rather than freezing into a static list.

Example: The Segment Performance Template

Business question: “How does metric X compare across segments?” Parameters: metric (e.g., net revenue retention), segmentation dimension (e.g., company size), time period (e.g., trailing 12 months). The query calculates the specified metric for each value of the segmentation dimension, alongside the count of entities in each segment and the period-over-period change. This single template answers dozens of variations: NRR by company size, win rate by industry, deal velocity by source.

Building the Template Library

Start by cataloging every analytics request your team received in the last quarter. Group them by the five question categories (health, performance, forecasting, segmentation, attribution). For each category, identify the two or three most common specific questions and build templates for those first. A short list of well-built templates covers the bulk of incoming requests because request volume is heavily concentrated in a handful of recurring asks.

Document the templates somewhere both analysts and stakeholders can see. When stakeholders can browse the library, they start framing their questions to match what exists, which removes most of the clarification loop before it starts. Pair the library with metrics stakeholders can explore themselves and the simple questions stop reaching the analytics team at all, which is the point. Analyst time goes to the translations that genuinely need judgment.

How Do You Create a Data Dictionary for Your Organization?

Start with your five to ten most important metrics. For each one, document four things: the exact definition (what counts and what does not), the calculation formula, the primary data source, and any known caveats or limitations. Store this in a shared, searchable location: a wiki page, a Notion database, or even a well-organized spreadsheet. Review it quarterly to catch drift as tracking evolves. The most common failure is writing the dictionary once and never updating it. Assign an owner for each metric who is responsible for keeping the definition current. A living data dictionary ends the “whose number is right?” debates that waste hours in every cross-functional meeting. It also makes AI answers auditable, because you can check the definition the chat used against the one you agreed on. See our metrics vs. analytics guide for more on building a metrics-informed practice.

Key Takeaways

Turning business questions into data queries is a skill that gets faster with structure, and most of it can be handed to an AI chat once the question is specific enough.

The best analytics teams do not just answer questions. They build systems that make questions easier to ask, faster to answer, and more likely to drive the right decision.