Best practices for configuring Conversational Analytics in Looker

Conversational Analytics lets users query data that is modeled in LookML by asking natural language questions within a Looker instance. Users can query data in the following ways:

Starting a conversation with a Looker Explore that is based on a LookML model
Starting a conversation with a data agent that is connected to up to five Looker Explores

This guide provides strategies and best practices to help LookML developers successfully configure and optimize Conversational Analytics. This guide covers the following topics:

LookML best practices for Conversational Analytics
When to add context to LookML versus Conversational Analytics
Best practices for setting up an Explore for use with Conversational Analytics

By preparing your LookML model and Conversational Analytics, you can increase user adoption and ensure that users get accurate and useful answers to their questions.

Learn how and when Gemini for Google Cloud uses your data .

LookML best practices for Conversational Analytics

Conversational Analytics interprets natural language questions by leveraging two primary inputs:

The LookML model: Conversational Analytics analyzes the structure, fields (dimensions, measures), labels, descriptions, and synonyms that are defined in the LookML model that underlies the Looker Explore.
Distinct field values: Conversational Analytics examines the data values within fields (specifically, string dimensions and synonyms) to identify the available categories and entities that users might ask about. Cardinality (the number of unique values) can influence how these values are used.

The effectiveness of Conversational Analytics is directly tied to the quality and clarity of these two inputs. The following table contains common ways that unclear or ambiguous LookML can negatively affect Conversational Analytics, along with solutions for improving the output and user experience.

Common LookML quality issue

Solution for clearer Conversational Analytics

Lack of clarity: Fields that don't have clear labels or descriptions are ambiguous both to Conversational Analytics and to its users.

Apply clear labels: Use the label parameter to give fields intuitive, business-friendly names that users are likely to use in their questions.

Field bloat: Exposing too many fields, especially internal IDs (primary keys), duplicate fields that are inherited from joins, or intermediate calculation fields, can clutter the options that are available to Conversational Analytics.

Hide irrelevant fields: Ensure that all primary keys, foreign keys, redundant fields from joins, and purely technical fields remain hidden . (Optional) Extend Explores: If your Explore contains a large number of fields, consider creating a new Explore that extends an existing one . This lets you tailor a dedicated version of popular content for Conversational Analytics without modifying Explores that other content may rely on.

Naming conflicts: Multiple fields that have similar or identical names or labels across different views within the Explore can lead to incorrect field selection.

Write thorough descriptions: Descriptions provide critical context for Conversational Analytics. Use the description parameter for the following tasks:

Describe the field clearly using natural language.
Include company- or industry-specific terminology or synonyms.
Explain calculations or context. Conversational Analytics uses descriptions to better identify field meanings and to map user terms.

For example, a field that has the label user_count could have the description "The total number of unique users who visited the website."

Standardize naming: Review field names and labels for consistency and clarity.

Hidden complexity: Relying heavily on dashboard-level custom fields or table calculations means that potentially critical business logic won't be accessible to Conversational Analytics.

Incorporate custom logic: Identify important and commonly used custom fields or table calculations . Convert the logic for these fields into LookML dimensions and measures so that Conversational Analytics can use them.

Messy data: The following types of inconsistent or poorly structured data make it difficult for Conversational Analytics to interpret queries accurately.

Value variations: Inconsistent capitalization or naming conventions (for example, a mix of the values complete , Complete , and COMPLETE ) can lead to data duplication or incorrect data relationships in Conversational Analytics.
Inconsistent data types: Columns that are intended to be numeric and that contain occasional string values force the field type to be string , which prevents numerical operations.
Timezone ambiguity: Lack of standardized time zones in timestamp fields can lead to incorrect filtering or aggregation.

Address data quality: Where possible, flag data quality issues (inconsistent values, types, time zones) that you identify during data curation. Work with data engineering teams to clean up the source data or apply transformations in the ETL/data modeling layer.

For more best practices for writing clean, efficient LookML, see the following documentation:

When to add context to LookML versus Conversational Analytics

In Conversational Analytics, you can add context inputs, such as field synonyms and descriptions , both to LookML and inside agent instructions . When you're deciding where to add context, apply the following guidance: Context that is always true should be added directly to your LookML model. Looker Explores may be used multiple places, including both in dashboards and in Conversational Analytics, so context that's applied in LookML must hold true for all possible users who will interact with the data.

Agent context should be qualitative and focused on the user, and there can be many agents serving different users from one Explore. Examples of context that should be included in agent instructions, but not in LookML, are as follows:

Who is the user that is interacting with the agent? What is their role? Are they internal or external to the company? What is their previous analytics experience?
What is the goal of the user? What type of decision are they looking to make at the end of the conversation?
What are some types of questions that this user will ask?
What are the top fields that are specific to this user? What are fields that this user will never need to use?

Best practices for setting up an Explore for use with Conversational Analytics

To help Conversational Analytics provide the most helpful answers, consider following these best practices when defining your Explores to use as data source for Conversational Analytics:

In your Explore's underlying LookML, define only the fields that are useful for analysis by end users.
Give each field a clear and concise name.
Give each field a clear description, including sample values where relevant. These field descriptions are included in the prompt that is sent to Conversational Analytics, and they can be helpful for providing context. Sample values are especially helpful for string fields.

Related resources

Recommended setup and rollout strategy for Conversational Analytics in Looker