What Is Conversational Analytics? Multi-Turn Data Investigation Explained

Business users often ask follow-up questions in fragments: “now show me just Q4,” “what about North America?” or “which of those grew?” Typically, in traditional analytics workflows, the user has had to restate the relevant metric, filters and dimensions in each new query.

Conversational analytics gives analytics systems a way to work with those incomplete follow-ups. The system carries forward enough context to reconstruct what the user means, then resolves the new request against the underlying data and business definitions. The quality of that context handling largely determines how useful the conversation remains after the first turn.

Conversational analytics is the practice of querying and exploring business data through natural language interactions that retain context across multiple questions. A conversational analytics system interprets the user’s intent, resolves the request against the meaning and structure of the underlying data, generates and runs the appropriate query, then carries relevant context into subsequent turns.

In business intelligence (BI), conversational analytics lets users investigate data through an exchange that feels closer to ordinary dialogue. Someone might begin with “Show me support ticket volume by product,” follow with “Just the ones that took more than a day to resolve,” then “Which issues show up most often?” The three prompts form a single analysis, even though the later questions leave much of the original context unstated.

In contact centers, the term conversational analytics is used to describe conversation intelligence, but in broader data analytics applications, it refers to the use of natural language processing (NLP), large language models (LLMs) and text-to-SQL techniques to support multi-turn querying.

Watch how Cortex Agents uses enterprise data to answer natural language questions:

Conversational analytics involves natural language, but a natural language query is self-contained. For example, the user asks, “What was total revenue in Q4?” and the system interprets the question, generates a query and returns the result. Once that transaction is complete, nothing necessarily has to carry forward.

Conversational analytics is stateful. It carries context forward to support a line of questioning.

Consider the support example exchange:

“Show me support ticket volume by product.”

“Just the ones that took more than a day to resolve.”

“Which issues show up most often?”

By the third turn, the user no longer needs to restate the product context or the resolution-time filter. The system knows that both still belong in the analysis, then interprets “issues” within that context.

That dependency also affects how conversational systems need to be evaluated. A text-to-SQL system might perform well against a benchmark of isolated questions yet struggle when each turn depends on the interpretation of the previous one. In a multi-turn analysis, an error early in the sequence can affect everything that follows.

Underneath the conversational interface, the model needs a working representation of the analysis in progress. This includes the entities under discussion, active filters, relevant dimensions and the metric definition being used.

References and filters carry the immediate state

Reference resolution is one visible part of that process. Terms such as “that,” “those,” “it” or “the same thing for last year” have to map back to specific business concepts, columns and values from earlier turns.

Filter inheritance is less obvious. Suppose a user narrows a revenue analysis to Q4, then asks a new question without mentioning a time period. Should Q4 still apply? Sometimes yes. Sometimes no. The correct answer depends on what the user intended, and the language alone doesn’t always make that clear.

Question reconstruction turns follow-ups into complete requests

One approach to manage this process, described in Snowflake Engineering’s discussion of Cortex Analyst multi-turn conversations, is to rewrite the latest request into a self-contained question before sending it through the existing text-to-SQL pipeline. An LLM summarization step combines the new question with the relevant conversation history, so the downstream query-generation process still receives a complete analytical request.

For example, if a user asks the initial question, “What is the month-over-month revenue growth for 2021 in Asia?” and then follows with “What about North America?”, the system recognizes the dependency and reformulates the follow-up as a complete request: “What is the month-over-month revenue growth for 2021 in North America?” It then generates SQL from that reconstructed question.

This keeps the conversational logic separate from the underlying text-to-SQL workflow. The query-generation system still works from a standalone question; the conversational layer handles the state needed to produce it.

Longer conversations need compression and semantic grounding

Longer conversations introduce a context window constraint. Context windows are finite, and replaying an ever-growing transcript increases token use and latency. For this reason, systems often summarize or selectively retain earlier turns rather than continually sending the full conversation. Recent state can then be combined with a compressed representation of older history.

Through all of this, semantic context anchors the analysis. The system shouldn’t rely on conversation history to reconstruct what a business metric such as revenue means. Instead, each request should resolve against governed definitions of metrics, dimensions and relationships while conversational state tracks what the user is currently discussing.

Research suggests the difference between single-turn and multi-turn performance can be substantial. As detailed in their paper LLMs Get Lost in Multi-Turn Conversation, researchers Philippe Laban et al. evaluated 15 models across more than 200,000 simulated conversations and found that aptitude fell 16% while unreliability increased 112% in multi-turn settings. As the authors put it, “when LLMs take a wrong turn in a conversation, they get lost and do not recover.”

Question reconstruction and governed semantic context can reduce some sources of this multi-turn degradation. Rewriting each follow-up into a self-contained request limits how much conversational state the downstream query system has to infer, while semantic definitions keep metrics, dimensions and relationships grounded across turns. But they don’t completely eliminate the risk: if the reconstruction step carries forward the wrong filter or resolves a reference incorrectly, later turns can still inherit that error.

The same state that lets a user keep an analysis going also creates dependencies between turns. If the system carries the wrong interpretation, filter or assumption forward, later answers can inherit the mistake.

Ambiguity can propagate across turns

Suppose a user’s first question has two plausible SQL interpretations and the system simply chooses one. If the next four questions build on that answer, all four inherit the original, possibly irrelevant interpretation unless something forces the system to reconsider it.

Research on text-to-SQL shows how common that underlying ambiguity is. The AmbiQT benchmark paired more than 3,000 natural language questions with two equally valid SQL interpretations, and found that state-of-the-art text-to-SQL systems frequently failed to surface both readings.

When different interpretations would materially change the result, the system should ask the user for clarification. For example, Snowflake’s Cortex Analyst pipeline includes a classification step that identifies ambiguous or unanswerable questions and routes users toward suggested related questions rather than silently choosing an interpretation.

Filters can outlive their usefulness

A filter that made sense three turns ago may no longer reflect what the user intends. Someone might narrow an analysis to a region, product category or quarter, then move on without explicitly removing that constraint so the system continues applying it.

This is especially easy to miss in a conversational interface. Traditional BI tools often show filter state visually, but in a chat-style interaction, users typically have fewer cues about which constraints are still active. Systems therefore need a way to carry relevant filters forward while dropping or surfacing ones that no longer fit the current request.

Long conversations can lose the thread

As a conversation expands, users often change subjects, revisit earlier questions and introduce new analytical goals. The system then has to decide which parts of the accumulated context still belong in the current turn.

Very long conversations or frequent shifts in intent can make follow-up questions more difficult to interpret. Prior context can begin interfering with the current request instead of helping resolve it.

The performance drop can show up quickly. In the multi-turn LLM study, performance across six generation tasks, including text-to-SQL, fell 39% on average from single-turn to multi-turn interaction, with degradation appearing as early as the second turn. In these cases, resetting the conversation can provide a clean starting point.

Teams should evaluate conversational systems on long analyses that are representative of real-world investigations, and then examine the results: Did references resolve correctly? Did filters persist or expire appropriately? Did ambiguous requests trigger clarification? Did earlier interpretations remain consistent as the analysis developed?

Snowflake Cortex Agents supports conversational analytics over structured and unstructured data, including natural language querying against Semantic Views. For analytical questions, the agent generates SQL using the definitions and relationships encoded in the semantic layer, while server-managed Threads preserve conversation context across turns. That allows a follow-up question to remain connected to the analysis already in progress rather than requiring the application to reconstruct state on the client side.

Semantic grounding comes from Horizon Context, a capability within Snowflake Horizon Catalog. Horizon Context builds on catalog metadata with business definitions, relationships and other semantic information that AI agents and analytics tools can apply when interpreting a request. Conversation state can then track what the user is currently discussing while governed semantic context supplies what those metrics, dimensions and business concepts mean.

Horizon Catalog provides the broader governance foundation around that interaction, including lineage, data quality, sensitive data protection, AI governance and access controls. Those controls continue to apply to the underlying data and tools as users move through a conversational analysis.

For end users, Snowflake CoWork provides a conversational surface for working with Snowflake data and capabilities through natural language. Behind that experience, Cortex Agents manages the analytical interaction and conversational state, Horizon Context supplies governed business meaning and Horizon Catalog governs the underlying data and AI environment.

Teams implementing conversational analytics systems will need to think beyond natural language input and text-to-SQL. The quality of the experience depends on how well the system manages conversation state, resolves business definitions, surfaces ambiguity and governs access to the underlying data. This puts semantic models, metadata, lineage and evaluation closer to the center of the implementation than they might appear in a demo.

As those pieces mature, conversational analytics could support longer and more exploratory analyses without asking users to continually restate what they mean. The interface may look like chat, but the implementation work increasingly sits in the context and governance beneath it.