Práticas recomendadas para configurar a análise de conversação no Looker

Com a Análise de Conversação, os usuários podem consultar dados modelados em LookML fazendo perguntas em linguagem natural em uma instância do Looker. Os usuários podem consultar dados das seguintes maneiras:

Este guia oferece estratégias e práticas recomendadas para ajudar os desenvolvedores do LookML a configurar e otimizar a Análise de conversas. Neste guia, abordamos os seguintes tópicos:

Ao preparar seu modelo LookML e a Análise de Conversação, você pode aumentar a adoção pelos usuários e garantir que eles recebam respostas precisas e úteis para as perguntas.

Saiba como e quando o Gemini para Google Cloud usa seus dados.

Práticas recomendadas de LookML para Análise Conversacional

A Análise de conversação interpreta perguntas em linguagem natural usando duas entradas principais:

  1. O modelo do LookML: a análise de conversação analisa a estrutura, os campos (dimensões, métricas), os rótulos, as descrições e os sinônimos definidos no modelo do LookML que embasa a Análise do Looker.

  2. Valores de campo distintos: a Análise de conversas examina os valores de dados nos campos (especificamente, dimensões de string e sinônimos) para identificar as categorias e entidades disponíveis que os usuários podem consultar. A cardinalidade (o número de valores únicos) pode influenciar como esses valores são usados.

A eficácia da análise de dados de conversação está diretamente ligada à qualidade e à clareza dessas duas entradas. A tabela a seguir contém maneiras comuns de uma LookML pouco clara ou ambígua afetar negativamente a análise de conversas, além de soluções para melhorar a saída e a experiência do usuário.

Problema comum de qualidade da LookML Solução para análises de conversação mais claras
Falta de clareza:campos sem rótulos ou descrições claras são ambíguos para a análise de conversas e para os usuários. Use rótulos claros:use o parâmetro label para dar aos campos nomes intuitivos e adequados para empresas que os usuários provavelmente usarão nas perguntas.
Excesso de campos:expor muitos campos, especialmente IDs internos (chaves primárias), campos duplicados herdados de junções ou campos de cálculo intermediário, pode prejudicar as opções disponíveis para a Análise de dados de conversação. Ocultar campos irrelevantes:verifique se todas as chaves primárias, chaves estrangeiras, campos redundantes de junções e campos puramente técnicos permanecem ocultos.

(Opcional) Estender as análises detalhadas:se a sua análise detalhada tiver muitos campos, crie uma que estenda uma já existente. Assim, você pode personalizar uma versão dedicada de conteúdo popular para a Análise de dados de conversação sem modificar as análises detalhadas que outros conteúdos podem usar.
Conflitos de nomenclatura:vários campos com nomes ou rótulos semelhantes ou idênticos em diferentes visualizações na análise detalhada podem levar à seleção incorreta de campos. Escreva descrições detalhadas:elas fornecem contexto essencial para o Conversational Analytics. Use o parâmetro description para as seguintes tarefas:
  • Descreva o campo com clareza usando linguagem natural.
  • Inclua terminologia ou sinônimos específicos da empresa ou do setor.
  • Explicar cálculos ou contexto. As Análises de conversação usam descrições para identificar melhor os significados dos campos e mapear os termos dos usuários.

Por exemplo, um campo com o rótulo user_count pode ter a descrição "O número total de usuários únicos que visitaram o site".

Padronizar a nomenclatura:revise os nomes dos campos e os rótulos para garantir consistência e clareza.
Complexidade oculta:depender muito de campos personalizados ou cálculos de tabela no nível do painel significa que a lógica de negócios potencialmente crítica não estará acessível às Análises de conversação. Incorpore lógica personalizada:identifique campos personalizados ou cálculos de tabela importantes e usados com frequência. Converta a lógica desses campos em dimensões e métricas do LookML para que a Análise de conversas possa usá-las.
Dados desorganizados:os seguintes tipos de dados inconsistentes ou mal estruturados dificultam a interpretação precisa das consultas pela Análise de conversas.
  • Variações de valor:capitalização ou convenções de nomenclatura inconsistentes (por exemplo, uma mistura dos valores complete, Complete e COMPLETE) podem levar à duplicação de dados ou a relações de dados incorretas na análise de conversas.
  • Tipos de dados inconsistentes:colunas que devem ser numéricas e que contêm valores de string ocasionais forçam o tipo de campo a ser string, o que impede operações numéricas.
  • Ambiguidade de fuso horário:a falta de fusos horários padronizados nos campos de carimbo de data/hora pode levar a filtragem ou agregação incorretas.
Qualidade dos dados de endereço:sempre que possível, sinalize problemas de qualidade dos dados (valores, tipos, fusos horários inconsistentes) identificados durante a curadoria. Trabalhe com equipes de engenharia de dados para limpar os dados de origem ou aplique transformações na camada de ETL/modelagem de dados.

Para mais práticas recomendadas de como escrever LookML limpo e eficiente, consulte a seguinte documentação:

Quando adicionar contexto à LookML ou à Análise Conversacional

Na Análise de dados de conversação, é possível adicionar entradas de contexto, como sinônimos de campo e descrições, tanto à LookML quanto às instruções do agente. Ao decidir onde adicionar contexto, siga estas orientações: o contexto que é sempre verdadeiro deve ser adicionado diretamente ao seu modelo LookML. As Análises do Looker podem ser usadas em vários lugares, incluindo painéis e Análise de Conversação. Portanto, o contexto aplicado no LookML precisa ser válido para todos os usuários que vão interagir com os dados.

O contexto do agente precisa ser qualitativo e focado no usuário. Além disso, pode haver muitos agentes atendendo a usuários diferentes em uma Análise. Veja exemplos de contexto que devem ser incluídos nas instruções do agente, mas não na LookML:

  • Quem é o usuário que está interagindo com o agente? Quais são as funções dessas pessoas? Eles são internos ou externos à empresa? Qual é a experiência anterior deles com análise de dados?
  • Qual é o objetivo do usuário? Que tipo de decisão eles querem tomar no final da conversa?
  • Quais são alguns tipos de perguntas que esse usuário vai fazer?
  • Quais são os principais campos específicos para esse usuário? Quais campos ele nunca vai precisar usar?

Práticas recomendadas para configurar uma análise detalhada para uso com a Análise Conversacional

Para ajudar a Análise Conversacional a fornecer as respostas mais úteis, siga estas práticas recomendadas ao definir suas análises detalhadas para usar como fonte de dados:

  • Na LookML da análise detalhada, defina apenas os campos úteis para a análise dos usuários finais.
  • Dê um nome claro e conciso para cada campo.
  • Dê a cada campo uma descrição clara, incluindo valores de exemplo quando relevante. Essas descrições de campo estão incluídas no comando enviado ao Conversational Analytics e podem ser úteis para fornecer contexto. Os valores de amostra são especialmente úteis para campos de string.