
⚡Key Takeaways
- Looker Conversational Analytics combines Gemini with LookML, governed Explores, permissions, and configurable data agents to let users query business data through natural language.
- Its strongest fit is for organizations already invested in Looker, particularly those with mature LookML models, established governance, and teams able to maintain the required configuration.
- For customer-facing SaaS use cases, teams should account for additional implementation considerations such as iframe-based embedding, limited conversational-interface theming, external-user mapping, tenant permissions, and ongoing AI configuration.
- Qrvey is a stronger fit for SaaS teams that prioritize product-native embedded analytics, multi-tenant governance, structured AI agents, and predictable flat-rate licensing as customer adoption grows.
Looker Conversational Analytics can make governed data easier to explore, especially for teams already invested in LookML, Google Cloud, and Looker’s analytics ecosystem. But the real question is not whether users can ask questions in plain language. It’s how much setup, modeling, permissioning, and product integration your team needs before those answers are useful and trusted.
This review breaks down Looker Conversational Analytics across features, setup, pros, cons, and best-fit use cases. We’ll also look at where Qrvey fits for SaaS teams that need conversational analytics embedded into a secure, multi-tenant customer-facing product.
What Is Looker Conversational Analytics?
Looker Conversational Analytics is a Gemini-powered interface that lets users ask questions about governed Looker data in natural language instead of building queries manually. Users can ask questions such as “What were our top-performing regions last quarter?” and receive answers and visualizations based on the data available through Looker Explores.
Under the hood, Looker grounds these interactions in its semantic modeling layer. It uses LookML definitions, field metadata, underlying data values, and existing permissions to interpret the question, determine the appropriate fields and filters, and execute a governed Looker query. This helps keep conversational answers aligned with the same business definitions and access rules used elsewhere in Looker.
Teams can further refine the experience with Looker data agents. A data agent connects to selected Explores and adds curated instructions and business context, such as which fields matter, how business terminology should map to the data, and which fields should be used for filtering or grouping.
Conversational Analytics is available in both Looker (original) and Looker (Google Cloud core). Its primary role is conversational access to governed Looker data rather than autonomous analytics workflows that independently plan and execute broader actions.
Looker Conversational Analytics Features
Looker Conversational Analytics goes beyond a basic natural-language search box. It combines Looker’s governed semantic layer with Gemini, configurable data agents, multi-turn analysis, visual responses, and optional advanced analytics. Here are the main features available in Looker today:
1. Natural-Language Queries Across Looker Explores
Users can ask questions about Looker data in everyday language instead of manually choosing dimensions, measures, filters, and sorts. Looker maps the request to the underlying LookML model, generates the appropriate Looker query, and can return an answer as text, a data table, or a visualization.
Users can query a single Explore directly or work through a data agent connected to multiple Explores. Because the query is generated through Looker rather than sent directly to the database, existing LookML definitions, joins, filtering logic, aggregations, and data permissions continue to apply.
2. Multi-Turn Conversations With Fast and Thinking Modes
Conversational Analytics supports follow-up questions, so users don’t have to restate the full context each time. For example, after asking for revenue by region, a user could follow up with “only show enterprise customers” or ask to change the visualization. Looker takes previous questions and answers from the active conversation into account.
Users can also choose between Fast and Thinking modes. Fast mode is designed for straightforward questions that map closely to predefined LookML metrics, while Thinking mode handles more complex, multi-step analytical questions such as comparisons, trend analysis, and “why” questions.
3. Custom Looker Data Agents
Teams can create Explore data agents that add curated business context on top of Looker’s semantic model. Each agent can connect to up to five Explores and include instructions describing important fields, terminology, filtering rules, grouping behavior, or other domain-specific guidance.
This is useful when the meaning of a question depends on company-specific language. Instead of relying solely on field names, the agent can use both LookML metadata and its instructions to understand what terms such as “top customers,” “new business,” or other internal definitions are supposed to mean. Agents can also be shared with other Looker users.
4. Dashboard Agents
Looker also offers dashboard agents, currently in Preview. Rather than starting from an Explore, users can select Chat with this dashboard and ask questions about a user-defined or LookML dashboard and its query-linked tiles.
For user-defined dashboards, teams can add instructions and context to influence how the agent interprets dashboard data. This gives users a more focused conversational experience when they want to investigate an existing dashboard without moving into the broader Explore interface.
5. Advanced Analytics With Python
For questions that go beyond standard SQL-based analysis, Looker provides Advanced Analytics. The feature translates a natural-language request into Python, executes the code in a Google-managed environment, and uses the result to provide deeper analysis or visualizations.
This extends Conversational Analytics into tasks such as more complex calculations, charting, and time-series forecasting that would normally require coding or statistical expertise. Advanced Analytics works with Conversational Analytics data agents in both Looker (original) and Looker (Google Cloud core), although it isn’t available when chatting directly with an Explore or with dashboard agents.
6. Visual Answers and Query Transparency
Answers aren’t limited to generated text. Depending on the question, Looker can return visualizations, data tables, and supporting details, and users can open query results directly in Explore for further investigation.
Looker also provides a How was this calculated? option that can show the fields, filters, calculations, sorting, and other steps used to produce an answer. With the appropriate agent settings, users can also inspect generated Looker queries, underlying data tables, reasoning steps, and debug information.
7. Embedded Conversational Analytics
Conversational Analytics can also be embedded into another website or application. Looker supports both private embedding, where users authenticate with their Looker credentials, and signed embedding, where authentication is handled through the host application.
This makes the conversational interface relevant beyond internal Looker usage, although Looker currently embeds Conversational Analytics through an HTML iframe rather than as a fully native UI component.
Unlike Looker’s iframe-based approach, Qrvey avoids iframes and uses JavaScript-based components for embedded analytics.
Its Sidekick conversational interface can also be opened as an embedded widget, giving SaaS teams a way to bring conversational analytics into the surrounding product experience without relying on framed external content.

8. Triggered Agentic Workflows
Looker has also introduced triggered agentic workflows in Preview. Users can define metric-based monitoring and alerts through natural-language conversations with Explores or Explore data agents, allowing Looker to monitor specified thresholds and send notifications when those conditions are met.
This adds a limited proactive capability to Conversational Analytics, but it shouldn’t be confused with a fully autonomous agentic analytics platform. The feature is currently centered on predefined data monitoring and threshold-triggered workflows rather than open-ended autonomous decision-making and action.
How LookML and Data Agents Ground the Answers
Looker Conversational Analytics doesn’t ask Gemini to interpret raw database schemas on its own. It grounds questions using the LookML semantic model, underlying data values, and any additional context configured for the data agent. The quality of those inputs directly affects the quality of the response.
LookML Provides the Semantic Foundation
LookML gives Conversational Analytics a structured definition of the data before Gemini interprets a question. The agent can use:
- Dimensions and measures: Define the fields and calculations available for analysis.
- Labels, descriptions, and synonyms: Help map the language users type to the correct fields.
- Explore logic: Looker applies configured joins, filtering, aggregations, access grants, user attributes, and other model logic when composing the query.
Data Agents Add Business-Specific Context
Data agents add context that may not belong in the underlying semantic model. Teams can tell an agent:
- Which fields matter most or should be excluded
- Which fields to use for filtering or grouping
- How company-specific terminology should be interpreted
- What defaults to apply when a question is ambiguous
- What types of questions its intended users are likely to ask
Looker also supports verified queries, which pair natural-language questions with corresponding Explore queries to give the agent proven examples for common or important requests.
What Determines Answer Quality?
Good grounding still depends on the underlying analytics environment. Google specifically calls out clear LookML, clean source data, curated Explores, useful descriptions, focused agent instructions, and well-defined business logic as important inputs. User permissions also determine what data and Explores an agent can access.
Simple example:
- Before: A field called revenue has no description, while several similar sales fields exist. “What was revenue last month?” leaves more room for the wrong field to be selected.
- After: A LookML measure labeled Net Revenue clearly defines what it includes and excludes and provides relevant synonyms. The agent has much stronger context for mapping “revenue” to the intended metric.
Qrvey tackles a similar grounding problem through its MCP Server, which connects Sidekick and AI Agents to datasets, dashboards, metadata, analytics models, and tenant-aware permissions.

Rather than relying on a generic chatbot disconnected from the analytics layer, AI operates within the same governed environment used to deliver customer-facing analytics.
How to Set Up Looker Conversational Analytics
Setting up Looker Conversational Analytics involves enabling Gemini, assigning the right permissions, preparing your Explores, and then configuring and testing a data agent. Here’s the process:
Step 1: Enable Gemini in Looker
An admin first needs to enable Gemini in Looker and the Conversational Analytics setting.
- Looker (original): A Looker admin enables Gemini in Looker and Conversational Analytics in the instance settings.
- Looker (Google Cloud core): A user with the roles/looker.admin IAM role enables Gemini in the Google Cloud console, then a Looker admin enables Conversational Analytics from Admin → Gemini in Looker.
If your instance uses an IP allowlist, it must also allow the required Google Cloud service connections.
Step 2: Grant User Permissions
Users need permissions for the Looker models and Conversational Analytics functions they’ll access. At minimum, interacting with data agents requires access_data, gemini_in_looker, and chat_with_agent.
Creating Explore data agents additionally requires permissions including chat_with_explore and save_agents.
Step 3: Prepare the LookML and Explores
Before creating an agent, select well-structured Explores with clear dimensions, measures, descriptions, and business logic. Google recommends beginning with one or two curated Explores and a limited set of knowledgeable users rather than immediately opening Conversational Analytics across the organization.
Step 4: Create a Data Agent
Go to Conversations → Agents → + New agent. Then:
- Give the agent a name and description.
- Connect up to five Looker Explores.
- Add instructions describing important fields, terminology, filtering rules, exclusions, or other business context.
Step 5: Configure Optional Capabilities
Depending on the use case, admins can also enable Advanced Analytics, dashboard agents, verified queries, and agentic workflows. Some of these capabilities are currently Preview features and have additional requirements.
Step 6: Test Before Wider Rollout
Use the agent preview to ask realistic questions, test edge cases, and refine its LookML or instructions. Google recommends validating responses internally before gradually expanding access because Gemini-generated answers can still be incorrect.
See why embedded analytics is harder than vibe coding a dashboard in this video featuring Qrvey’s Head of CX, Natan Cohen.
How to Ask Questions and Get Useful Answers
Looker Conversational Analytics accepts everyday language without requiring special syntax, but more specific questions give it clearer signals about what you actually want analyzed.
1. Start With a Specific Business Question
Include the metric, dimension, filter, comparison, or time period that matters where possible. For example:
- “Show monthly recurring revenue by region for the last six months.”
- “Which ten accounts had the largest decline in product usage this quarter?”
- “Compare average order value between new and returning customers.”
A question like “How are sales doing?” leaves several decisions open. Which sales metric? Over what period? Compared with what?
A stronger version would be: “Compare total sales this quarter with the previous quarter by region.”
Looker can ask clarifying questions when it detects ambiguity, including cases where multiple similarly named fields could match a request.
2. Use Follow-Up Questions to Refine the Analysis
You don’t need to start over every time you want a different view. Looker maintains the context of previous questions and answers within the active conversation.
For example, after asking for revenue by region, you could continue with:
- “Only include enterprise customers.”
- “Now compare it with the same period last year.”
- “Break that down by product.”
- “Show this as a line chart instead.”
This makes it easier to move from a broad result into the specific segment, period, or visualization you need.
3. Inspect and Verify the Result
Don’t treat the first AI-generated answer as automatically correct. Looker itself recommends validating Gemini output before using it.
Depending on the query and agent configuration, you can inspect:
- Question interpretation: Check how Looker understood or rephrased your request.
- Fields and filters: Open How was this calculated? to see raw fields, filters, sorting, and calculations.
- Query results: Open the result in Explore to examine the underlying data.
- Visualization: Check whether the generated chart accurately represents the question and data.
- Python code: When Advanced Analytics is used, the Code tab shows the Python generated for the analysis.
Limitations and Access Requirements
Looker Conversational Analytics isn’t available automatically to every Looker user. Access depends on instance settings, permissions, and the specific Conversational Analytics capability being used. Some newer features also remain in Preview.
| Limitation or requirement | What to know |
|---|---|
| Admin enablement is required | Conversational Analytics must be enabled at the Looker instance level before users can access it. |
| Access follows Looker permissions | Users can only query models, Explores, fields, and data they already have permission to access. |
| Agent scope is limited | An Explore data agent can connect to up to five Explores, so broader use cases may require multiple agents. |
| Feature availability varies | Some capabilities, including dashboard agents and agentic workflows, are still Preview features or have deployment-specific availability. |
| Generated answers aren’t guaranteed to be correct | Response quality depends on the LookML model, source data, agent configuration, and the question being asked. Important outputs should still be verified. |
Can You Embed Looker Conversational Analytics in a SaaS Product?
Yes. Looker Conversational Analytics can be embedded into a modern SaaS application, but the bigger question is whether its authentication, permissions, customization, and security model fit how your product serves external customers.
1. Embedding and Authentication Options
Looker supports two primary ways to embed the ready-made Conversational Analytics interface:
- Private embedding: Users authenticate with their Looker login before accessing the embedded experience.
- Signed embedding: Authentication happens through your SaaS application, which generates a signed embed session for the user.
Both approaches deliver the Conversational Analytics interface through an HTML iframe.
For teams that need more control, Looker also provides ConversationalAnalytics API endpoints. These expose APIs for agents, conversations, messages, and chat, allowing developers to build a custom conversational interface rather than relying entirely on Looker’s prebuilt iframe experience. That flexibility comes with additional development work, including managing conversation state and persisting messages for multi-turn interactions.
2. Permissions and Tenant Data Access
Embedding the interface doesn’t bypass Looker’s security model. External users still need the appropriate data access, feature access, and agent access for the models and Explores they’re allowed to query.
With signed embedding, your application also needs to correctly map each user into Looker. The signed session can include:
- A unique external_user_id
- Looker permissions and allowed models
- Group membership
- User attributes used to control data access
For a multi-tenant SaaS product, that means your engineering team must ensure the host application’s customer, role, and tenant context is represented correctly in Looker’s access model.

Google specifically warns that incorrectly reusing an external_user_id across users with different permissions or attributes can expose data that those users shouldn’t see.
3. Customization and Product Experience
Looker provides embedded theming and private-label options, including the ability to remove the default Powered by Looker footer when the appropriate private-label feature is enabled.
However, Conversational Analytics has more limited theming than other Looker embedded content. Google currently states that only the General theme options apply to the Conversational Analytics interface; other embedded theming options aren’t supported.
That matters when conversational analytics needs to feel indistinguishable from the rest of your SaaS product. Teams should evaluate the chat layout, navigation, branding, responsive behavior, and iframe integration alongside the analytical capabilities themselves.
When Looker Is a Strong Fit for Customer-Facing Analytics
Looker can make a lot of sense for SaaS companies that already have:
- Mature LookML models and governed metrics
- Established Looker permissions and data access rules
- Significant investment in the Looker ecosystem
- Engineering teams comfortable managing signed embedding and external-user access
In that environment, Conversational Analytics builds on analytics definitions and governance the team already maintains rather than introducing another semantic layer.
For SaaS teams that need conversational analytics to go beyond answering questions, Qrvey takes a broader approach with governed agentic workflows.

It combines conversational workflows, structured AI agents, and governed access to multi-tenant analytics environments directly inside the SaaS product.
This lets teams move from asking questions to delivering more actionable AI-driven workflows, while keeping generated outputs aligned with how analytics is defined, secured, and delivered across the platform.
Looker Conversational Analytics Pros and Cons
Looker Conversational Analytics has clear strengths, but also some limitations to weigh before rolling it out broadly:
Pros
- Governed answers: Uses LookML models, permissions, and business definitions to ground responses.
- Natural-language access: Lets non-technical users explore data without building queries manually.
- Multi-turn analysis: Supports follow-up questions that refine filters, dimensions, time periods, and visualizations.
- Configurable data agents: Teams can add business terminology, instructions, relevant fields, and use-case context.
- Multiple output formats: Can return written answers, tables, charts, and deeper analytical results.
- Advanced Analytics support: Python-based analysis extends the experience to more complex calculations and forecasting.
- Embedding options: Supports private and signed embedding, with APIs available for teams building a more customized conversational experience.
- Strong fit for existing Looker environments: Companies with mature LookML models can build on governance and data structures they already maintain.
Cons
- Requires careful setup: Useful results depend heavily on well-designed LookML, curated Explores, field descriptions, and agent instructions.
- AI answers still need verification: Grounding improves consistency, but generated responses aren’t guaranteed to be correct.
- Embedding has UX limitations: The prebuilt conversational interface uses an iframe and offers more limited theming than some other Looker embedded experiences.
- Multi-tenant implementation takes engineering work: SaaS teams need to correctly map external users, permissions, roles, and tenant context into Looker.
- Agent scope is limited: An Explore data agent can currently connect to up to five Explores.
- Some capabilities remain in Preview: Features such as dashboard agents and agentic workflows may not yet suit every production use case.
Who Looker Conversational Analytics Is Best For
Looker Conversational Analytics is best suited to organizations that already have a governed Looker environment and want to make established business data easier to query through natural language:
- Existing Looker customers: Organizations with mature LookML models can add conversational access without rebuilding their existing semantic definitions from scratch.
- Internal analytics teams: Companies that want employees to ask questions about governed business data while continuing to use established Looker models, metrics, and permissions.
- Data-mature organizations: Teams with the resources to maintain LookML, configure data agents, manage permissions, test responses, and refine the experience over time.
- Teams prioritizing semantic governance: Buyers that care more about consistent metric definitions and controlled data access than deploying a lightweight standalone chatbot on top of raw data.
Looker is a weaker fit for organizations that don’t already use the platform or small teams without the resources to maintain semantic models and AI configuration.
SaaS companies may also find it less suitable when they need highly customized, customer-facing conversational analytics or want to avoid maintaining separate analytics permissions, user mappings, and AI configuration alongside their application.
Best Alternatives to Looker Conversational Analytics
Looker is a strong choice when you already have mature LookML models and governance in place. If you need a more SaaS-focused embedded experience, a more agentic approach to analytics, or less dependence on LookML, these are three alternatives worth considering:
1. Qrvey: Best for Multi-Tenant SaaS Conversational Analytics

Qrvey is built specifically for SaaS companies that want to deliver conversational and agentic analytics directly to their customers.

Sidekick provides the conversational interface, while built-in and Custom AI Agents support defined analytical workflows.

The Qrvey MCP Server connects those agents to datasets, dashboards, metadata, and tenant-aware permissions so generated outputs remain aligned with the same analytics and governance environment used by the rest of the product.
That makes Qrvey particularly relevant where Looker’s customer-facing architecture creates friction. Looker’s ready-made Conversational Analytics interface is embedded through an HTML iframe and currently supports only part of Looker’s embedded theming options.
Qrvey instead focuses on product-native embedded analytics, tenant-aware access, structured agents, and governed workflows designed around external SaaS customers.

Pricing is another difference. Qrvey Pro and Qrvey Ultra use flat-rate licensing, with unlimited tenants, users, and dashboards. Pro is designed for teams bringing an analytics-ready database, while Ultra adds Qrvey’s built-in data engine and transformation layer.
Qrvey also offers perpetual licensing for both editions. This model avoids costs increasing simply because more customers or users adopt the analytics experience, which can make total cost of ownership more predictable as a SaaS product scales.
2. ThoughtSpot: Best for Search-First and Agentic Analytics

ThoughtSpot is a strong Looker alternative for teams that want conversational analytics to be the primary way users explore data. Its Spotter 3 agent supports natural-language questions, advanced analysis, quick-search and deep-research modes, automatic data-model selection, chat history, and third-party MCP connectors.
For customer-facing products, ThoughtSpot provides Visual Embed SDK components for embedding the full Spotter experience or a more stripped-down agent interface inside an application. It’s particularly compelling for teams that want a search-first, AI-agent experience without centering their analytics architecture around LookML.
3. Sigma: Best for Warehouse-Native Conversational Analysis

Sigma is a strong alternative for teams that want conversational analytics directly on governed cloud-warehouse data. Sigma Assistant lets users ask natural-language questions, generate charts, ask follow-ups, inspect the analysis logic, and move a result into an editable workbook for deeper exploration.
Sigma Assistant can also be embedded into an application, while Sigma’s broader embedded platform supports secure JWT-based embedding, row- and column-level security, and multi-tenant data isolation. It’s particularly attractive for organizations that want conversational analytics tightly connected to live warehouse data and prefer Sigma’s spreadsheet-style analytical experience over maintaining a LookML-centric workflow.
Deliver Governed Conversational Analytics Inside Your SaaS Product With Qrvey
Your customers shouldn’t need to understand your data model to get an answer. They should be able to ask a question, get a useful response, and keep moving without leaving your product or wondering whether the AI crossed a tenant boundary.
That’s the experience Qrvey is built to deliver.
Qrvey brings conversational analytics directly into multi-tenant SaaS products through Sidekick, structured AI Agents, Custom Agents, and the Qrvey MCP Server. Together, they connect natural-language interactions to the same datasets, metadata, permissions, and analytics logic already governing the rest of the product.
For product and engineering teams, that means you can:
- Keep AI inside your product: Deliver conversational workflows as part of the customer experience.
- Respect tenant context automatically: Keep data access aligned with existing permissions and customer boundaries.
- Move beyond simple Q&A: Build agents around specific analytical workflows, roles, and use cases.
- Stay in control: Shape how AI behaves without building the orchestration and governance layer from scratch.
If conversational analytics is becoming part of your product roadmap, Qrvey gives you a path to ship it as a governed SaaS capability, not another disconnected AI feature.
See how Qrvey can bring governed conversational analytics into your SaaS product!
FAQs
1. Does Looker Conversational Analytics Replace Dashboards and Explores?
No. Conversational Analytics adds another way to interact with Looker data rather than replacing dashboards or Explores.
Dashboards remain useful for monitoring recurring KPIs and giving teams a consistent view of performance, while Explores provide structured data investigation. Conversational Analytics is most useful when someone has an ad hoc or follow-up question that was not anticipated when the original dashboard was created.
2. Which Questions Should Still Go to a Data Analyst?
Conversational Analytics is well suited to questions involving comparisons, trends, segmentation, summaries, and governed metrics already represented in Looker.
Analyst involvement is still valuable when a question requires designing a new metric, resolving conflicting definitions, validating statistical significance, establishing causation, integrating unavailable data, or making a high-stakes interpretation. Natural-language access reduces routine analytical work, but it does not remove the need for expert judgment.
3. How Should You Measure the Success of Looker Conversational Analytics?
Start with more than the number of questions users ask. Useful measures include repeat usage, successful question completion, response correction rates, unanswered questions, time to insight, and whether users continue their analysis without requesting help from analysts.
Teams can also monitor whether conversational access reduces reporting requests or increases engagement with governed data. High chat volume alone is not success if users frequently distrust or abandon the answers.
4. Should Every Looker User Get Conversational Analytics Access Immediately?
Usually not. A phased rollout makes it easier to test question quality, identify poorly defined fields, improve LookML descriptions, refine agent instructions, and understand which use cases users actually value.
Begin with a small set of curated Explores and knowledgeable users, then review ambiguous questions, incorrect outputs, and common terminology before expanding access. This also gives teams a chance to establish verification expectations for higher-impact business decisions.
5. Can Qrvey Complement Looker Instead of Replacing It?
Yes. A SaaS company can keep Looker for internal analytics, governed LookML modeling, and employee-facing BI while using Qrvey as the customer-facing embedded analytics layer.
Qrvey can connect to existing data sources and provide multi-tenant dashboards, conversational analytics, AI agents, and product-native JavaScript embedding for external users. This can be useful when a company wants to preserve its existing internal Looker investment without exposing the same analytics experience directly to every SaaS customer.

Natan brings over 20 years of experience helping product teams deliver high-performing embedded analytics experiences to their customers. Prior to Qrvey, he led the Client Technical Services and Support organizations at Logi Analytics, where he guided companies through complex analytics integrations. Today, Natan partners closely with Qrvey customers to evolve their analytics roadmaps, identifying enhancements that unlock new value and drive revenue growth.