Conversational Analytics permet aux utilisateurs d'interroger des données modélisées dans LookML en posant des questions en langage naturel dans une instance Looker. Les utilisateurs peuvent interroger des données de différentes manières :
- En lançant une conversation avec une exploration Looker basée sur un modèle LookML
- En lançant une conversation avec un agent de données connecté à un maximum de cinq explorations Looker
Ce guide fournit des stratégies et des bonnes pratiques pour aider les développeurs LookML à configurer et à optimiser Conversational Analytics. Ce guide couvre les sujets suivants :
- Bonnes pratiques LookML pour Conversational Analytics
- Quand ajouter du contexte à LookML plutôt qu'à Conversational Analytics
- Bonnes pratiques pour configurer une exploration à utiliser avec Conversational Analytics
En préparant votre modèle LookML et Conversational Analytics, vous pouvez augmenter l'adoption par les utilisateurs et vous assurer qu'ils obtiennent des réponses précises et utiles à leurs questions.
Découvrez comment et quand Gemini pour Google Cloud utilise vos données.
Bonnes pratiques LookML pour Conversational Analytics
Conversational Analytics interprète les questions en langage naturel en s'appuyant sur deux entrées principales :
Le modèle LookML : Conversational Analytics analyse la structure, les champs (dimensions, mesures), les libellés, les descriptions et les synonymes définis dans le modèle LookML qui sous-tend l'exploration Looker.
Les valeurs de champ distinctes : Conversational Analytics examine les valeurs de données dans les champs (en particulier, les dimensions de chaîne et les synonymes) pour identifier les catégories et les entités disponibles sur lesquelles les utilisateurs peuvent poser des questions. La cardinalité (le nombre de valeurs uniques) peut influencer la façon dont ces valeurs sont utilisées.
L'efficacité de Conversational Analytics est directement liée à la qualité et à la clarté de ces deux entrées. Le tableau suivant présente les façons courantes dont un LookML peu clair ou ambigu peut avoir un impact négatif sur Conversational Analytics, ainsi que des solutions pour améliorer la sortie et l'expérience utilisateur.
| Problème courant de qualité LookML | Solution pour une analyse conversationnelle plus claire |
|---|---|
| Manque de clarté : les champs qui ne comportent pas de libellés ou de descriptions clairs sont ambigus à la fois pour Conversational Analytics et pour ses utilisateurs. | Appliquer des libellés clairs : utilisez le paramètre label pour attribuer aux champs des noms intuitifs et adaptés à l'entreprise que les utilisateurs sont susceptibles d'utiliser dans leurs questions. |
| Surcharge de champs : exposer trop de champs, en particulier des ID internes (clés primaires), des champs en double hérités de jointures ou des champs de calcul intermédiaires, peut encombrer les options disponibles pour Conversational Analytics. | Masquer les champs non pertinents : assurez-vous que toutes les clés primaires, les clés étrangères, les champs redondants des jointures et les champs purement techniques restent masqués. (Facultatif) Étendre les explorations : si votre exploration contient un grand nombre de champs, envisagez de créer une exploration qui étend une exploration existante. Cela vous permet d'adapter une version dédiée de contenu populaire pour Conversational Analytics sans modifier les explorations sur lesquelles d'autres contenus peuvent s'appuyer. |
| Conflits de noms : plusieurs champs portant des noms ou des libellés similaires ou identiques dans différentes vues de l'exploration peuvent entraîner une sélection de champ incorrecte. | Rédiger des descriptions complètes : les descriptions fournissent un contexte essentiel pour Conversational Analytics. Utilisez le paramètre description pour les tâches suivantes :
Par exemple, un champ portant le libellé |
| Charge de base de données inutile : Conversational Analytics utilise la méthode de suggestions de nom de champ de modèle de l'API Looker pour récupérer des exemples de valeurs pour les champs et choisir la valeur de champ ou de filtre appropriée pour les requêtes générées. Ces suggestions sont extraites de la base de données. Elles peuvent donc être lentes à remplir ou entraîner une charge inutile. | Utiliser LookML : vous pouvez éviter d'avoir à exécuter des requêtes API pour récupérer des valeurs de suggestion en définissant des exemples de valeurs dans LookML :
|
| Complexité masquée : s'appuyer fortement sur des champs personnalisés au niveau du tableau de bord ou des calculs de table signifie que la logique métier potentiellement critique ne sera pas accessible à Conversational Analytics. | Intégrer une logique personnalisée : identifiez les champs personnalisés ou les calculs de table importants et couramment utilisés. Convertissez la logique de ces champs en dimensions et mesures LookML afin que Conversational Analytics puisse les utiliser. |
Données désordonnées : les types de données incohérents ou mal structurés suivants empêchent Conversational Analytics d'interpréter les requêtes avec précision.
|
Résoudre les problèmes de qualité des données : dans la mesure du possible, signalez les problèmes de qualité des données (valeurs, types, fuseaux horaires incohérents) que vous identifiez lors de la curation des données. Collaborez avec les équipes d'ingénierie des données pour nettoyer les données sources ou appliquer des transformations dans la couche ETL/de modélisation des données. |
Pour en savoir plus sur les bonnes pratiques concernant l'écriture de code LookML propre et efficace, consultez la documentation suivante :
- Bonne pratique : ce qu'il faut faire et ne pas faire avec LookML
- Bonne pratique : créer une expérience positive pour les utilisateurs de Looker
- Bonne pratique : écrire du code LookML durable et facile à gérer
Quand ajouter du contexte à LookML plutôt qu'à Conversational Analytics
Dans Conversational Analytics, vous pouvez ajouter des entrées de contexte, telles que des synonymes et des descriptions de champs, à la fois à LookML et dans les instructions de l'agent. Lorsque vous décidez où ajouter du contexte, appliquez les consignes suivantes : le contexte qui est toujours vrai doit être ajouté directement à votre modèle LookML. Les explorations Looker peuvent être utilisées à plusieurs endroits, y compris dans les tableaux de bord et dans Conversational Analytics. Par conséquent, le contexte appliqué dans LookML doit être vrai pour tous les utilisateurs possibles qui interagiront avec les données.
Le contexte de l'agent doit être qualitatif et axé sur l'utilisateur. De nombreux agents peuvent servir différents utilisateurs à partir d'une même exploration. Voici quelques exemples de contexte à inclure dans les instructions de l'agent, mais pas dans LookML :
- Qui est l'utilisateur qui interagit avec l'agent ? Quelle est sa fonction ? Est-il interne ou externe à l'entreprise ? Quelle est son expérience précédente en matière d'analyse ?
- Quel est l'objectif de l'utilisateur ? Quel type de décision cherche-t-il à prendre à la fin de la conversation ?
- Quels types de questions cet utilisateur posera-t-il ?
- Quels sont les principaux champs spécifiques à cet utilisateur ? Quels sont les champs que cet utilisateur n'aura jamais besoin d'utiliser ?
Bonnes pratiques pour configurer une exploration à utiliser avec Conversational Analytics
Pour aider Conversational Analytics à fournir les réponses les plus utiles, suivez ces bonnes pratiques lorsque vous définissez vos explorations à utiliser comme source de données pour Conversational Analytics :
- Dans le LookML sous-jacent de votre exploration, ne définissez que les champs utiles pour l'analyse par les utilisateurs finaux.
- Attribuez à chaque champ un nom clair et concis.
- Attribuez à chaque champ une description claire, y compris des exemples de valeurs, le cas échéant. Ces descriptions de champ sont incluses dans l'invite envoyée à Conversational Analytics et peuvent être utiles pour fournir du contexte. Les exemples de valeurs sont particulièrement utiles pour les champs de chaîne.