Implémenter une segmentation au niveau des lignes pour le contenu Looker intégré

Rédigé par Christopher Seymour, analyste de données senior, et Dean Hicks, ingénieur Developer Relations

La segmentation au niveau des lignes vous permet de limiter les données auxquelles un utilisateur individuel peut accéder, en fonction des valeurs stockées dans un ou plusieurs champs de base de données. Ce guide décrit les méthodes permettant d'implémenter la segmentation au niveau des lignes dans le contenu Looker intégré. Il contient les sections suivantes :

Introduction

La fonctionnalité d'intégration de Looker est l'une des fonctionnalités les plus puissantes et les plus utiles du produit. Si vous lisez ce guide, c'est probablement parce que vous intégrez déjà du contenu Looker à votre application ou que vous prévoyez de le faire prochainement.

Ce guide est destiné à vous aider à mieux comprendre la conception de la fonctionnalité d'intégration de Looker et à implémenter la segmentation dans une application où les partenaires peuvent gérer l'accès à plusieurs marques. Comme il s'agit d'une exploration approfondie du sujet, il est un peu long à lire. Gardez à l'esprit que ce guide n'est pas une solution rapide à un problème simple, mais plutôt un composant de base pour vous aider à mieux gérer l'ensemble de votre cas d'utilisation d'intégration Looker.

Présentation du cas d'utilisation

Ce guide décrit un cas d'utilisation courant dans lequel votre entreprise intègre du contenu Looker à son produit et propose des segments d'utilisateurs qui doivent voir différentes tranches de vos données.

Pour ce cas d'utilisation d'intégration signée, supposons que vous êtes l'administrateur de votre instance Looker. Vous travaillez avec deux types d'utilisateurs externes d'intégration : les clients, qui ne doivent pouvoir accéder qu'aux données concernant leur marque spécifique, et les partenaires, qui pourront accéder aux données de plusieurs marques. Vous disposez d'un tableau de bord avec quelques tuiles que vous montrez à chaque client qui utilise votre produit. Vous avez besoin que le tableau de bord soit automatiquement filtré pour chaque client afin qu'il n'affiche que les données spécifiques à ce client. Les exemples de ce document utilisent deux entreprises fictives : Hooli et Pied Piper.

Vous disposez d'un tableau appelé products, qui affiche certaines métriques produit pour différentes marques. Chaque marque correspond à un utilisateur d'intégration différent (avec un external_user_id différent) dans l'application d'intégration signée. Étant donné que chaque utilisateur intégré ne doit pouvoir voir que les données de sa propre marque, vous disposez d'une exploration qui utilise un filtre d'accès sur un attribut utilisateur brand (marque) :

explore: products {
  access_filter: {
    field: products.brand
    user_attribute: brand
  }
}

Vous disposez d'un tableau de bord basé sur cette exploration et comportant deux tuiles : l'une affiche le nom de la marque et l'autre le nombre de produits de cette marque.

Vous utilisez le point de terminaison create_sso_embed_url pour générer des URL d'intégration de ce tableau de bord pour chaque utilisateur intégré. Cet exemple utilise deux marques : Pied Piper et Hooli. Voici le corps de la requête que vous utilisez dans l'appel create_sso_embed_url pour Pied Piper, avec external_user_id pied_piper :

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "pied_piper",
  "first_name": "PiedPiper",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper"}
}

L'URL que vous avez générée pour Pied Piper affiche le tableau de bord de cette manière :

Voici le corps de la requête utilisé dans l'appel create_sso_embed_url pour Hooli, avec external_user_id hooli :

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "hooli",
  "first_name": "Hooli",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Hooli"}
}

L'URL générée pour Hooli affiche le tableau de bord de cette manière :

Voilà ! Le tableau de bord est filtré en fonction de la valeur de l'attribut utilisateur brand pour chaque utilisateur intégré.

Pour aller plus loin

Trop cool ! Mais que se passe-t-il si je souhaite donner accès à plusieurs marques à un seul utilisateur ? Comment puis-je m'assurer que mes données ne sont visibles que par les utilisateurs concernés ?

Bonne nouvelle ! La fonctionnalité d'intégration signée de Looker a été conçue pour permettre aux développeurs de créer des expériences de données puissantes et personnalisées pour les utilisateurs, tout en garantissant le maintien de la gouvernance des données définie par votre modèle de données et vos règles d'accès au contenu.

Pour offrir une expérience de données efficace, il est essentiel de s'assurer que la gouvernance des données est hermétique. Poursuivez votre lecture pour découvrir des concepts et des bonnes pratiques que vous pouvez utiliser pour concevoir l'expérience qui vous convient le mieux. Tout d'abord, voici un bref aperçu du fonctionnement de tout cela.

Principes de base de l'intégration signée Looker

Il est important de garder à l'esprit que l'authentification et la gestion des utilisateurs de Looker dans le contexte d'intégration fonctionnent fondamentalement de la même manière que dans le contexte non intégré et que dans la plupart des autres applications Web.

Cela peut être déroutant dans le contexte de l'intégration signée de Looker, car l'étape d'authentification signée, les paramètres utilisateur et le tableau de bord lui-même sont tous combinés en une longue URL complexe. Toutefois, cette URL est utilisée pour établir la session, ce qui s'applique même après le raccourcissement de l'URL. Garder ce concept à l'esprit vous aidera à créer des expériences de données de qualité.

Structure des URL d'intégration signées

Voici l'une des URL d'authentification d'intégration signées générées par l'appel create_sso_embed_url avec le corps de la requête pour Pied Piper :

https://mylookerinstance.cloud.looker.com/login/embed/%2Fembed%2Fdashboards%2F17?permissions=%5B%22access_data%22%2C%22see_user_dashboards%22%5D&models=%5B%22thelook%22%5D&signature=iG6vcKBgnA50jaL2iShFeQHwFPN7wvTx7Rz6r%2FtFuvE%3D&nonce=%22967729518a7dbb8a178f1c03a3511dd1%22&time=1696013242&session_length=300&external_user_id=%22pied_piper%22&access_filters=%7B%7D&first_name=%22Pied%22&last_name=%22Piper%22&user_attributes=%7B%22brand%22%3A%22Pied+Piper%22%7D&force_logout_login=true

Voici la même URL décodée et répartie sur plusieurs lignes :

https://mylookerinstance.cloud.looker.com/login/embed/
/embed/dashboards/17
?permissions=["access_data","see_user_dashboards"]
&models=["thelook"]
&signature=iG6vcKBgnA50jaL2iShFeQHwFPN7wvTx7Rz6r/tFuvE=
&nonce="967729518a7dbb8a178f1c03a3511dd1"
&time=1696013242
&session_length=300
&external_user_id="pied_piper"
&access_filters={}
&first_name="PiedPiper"
&last_name="User"
&user_attributes={"brand":"Pied Piper"}
&force_logout_login=true

Lorsque vous accédez à cette URL, plusieurs choses se produisent :

  1. Looker recherche un compte utilisateur existant avec external_user_id = pied_piper. Si aucun n'existe, Looker crée un compte utilisateur avec cet external_user_id.

  2. Les informations du compte de l'utilisateur existant, y compris les autorisations, les modèles, les groupes (le cas échéant) et les valeurs des attributs utilisateur (le cas échéant), sont remplacées par les informations de compte spécifiées dans l'URL.

  3. Looker authentifie l'utilisateur et établit une session pour cet utilisateur en stockant un cookie de session dans le navigateur.

  4. Looker redirige ensuite l'utilisateur vers l'URL cible ou l'URL de redirection spécifiée dans l'appel create_sso_embed_url :

    https://mylookerinstance.cloud.looker.com/embed/dashboards/17.

    Vous pouvez voir cette URL de redirection sous la forme d'une URL relative encodée dans l'URL d'intégration signée d'origine :

    %2Fembed%2Fdashboards%2F17

Bien que les étapes 1 à 3 se déroulent automatiquement en arrière-plan et que l'utilisateur final ne voie que le résultat final (le tableau de bord lui-même), ces étapes sont fondamentalement les mêmes que celles utilisées par un utilisateur Looker standard (non intégré) pour s'authentifier. Supposons que vous souhaitiez qu'un utilisateur se connecte avec un nom d'utilisateur et un mot de passe. Le processus se déroulerait comme suit :

  1. En tant qu'administrateur Looker, accédez au panneau "Admin – Utilisateurs" et utilisez la barre de recherche pour vérifier si un compte utilisateur existe déjà pour cet utilisateur. Si ce n'est pas le cas, créez un nouvel utilisateur.

  2. En tant qu'administrateur Looker, vous cliquez sur Modifier à côté de l'utilisateur dans le panneau "Admin – Utilisateurs", puis vous lui attribuez des autorisations, des modèles, des groupes, des valeurs d'attribut utilisateur et d'autres valeurs.

  3. L'utilisateur accède à la page de connexion à l'adresse https://mylookerinstance.cloud.looker.com/login et saisit son nom d'utilisateur et son mot de passe. Looker authentifie l'utilisateur et établit une session pour cet utilisateur en stockant un cookie de session dans le navigateur.

  4. Looker redirige ensuite l'utilisateur vers la page de destination (généralement https://mylookerinstance.cloud.looker.com/browse).

Notez que le cookie de session s'appliquera à tous les onglets de la fenêtre du navigateur. Si l'utilisateur commence sur https://mylookerinstance.cloud.looker.com/browse, ouvre un nouvel onglet de navigateur et accède à une page à laquelle ses autorisations lui donnent accès, la page se chargera comme prévu à l'aide du cookie de session déjà établi dans l'onglet de navigateur d'origine.

Il en va de même pour les utilisateurs d'intégrations. Les utilisateurs intégrés ont un accès plus limité aux pages de l'interface utilisateur. Ils ne peuvent accéder qu'aux URL de looks, de tableaux de bord et d'explorations avec le préfixe /embed. Toutefois, ils peuvent toujours accéder manuellement à n'importe quel tableau de bord auquel les informations de leur compte utilisateur leur donnent accès. Supposons que l'URL d'intégration signée d'origine vous redirige vers https://mylookerinstance.cloud.looker.com/embed/dashboards/17 dans un onglet de navigateur. Vous ouvrez ensuite un nouvel onglet de navigateur et chargez un autre tableau de bord intégré qui se trouve dans le même dossier (et qui présente donc les mêmes restrictions d'accès) : https://mylookerinstance.cloud.looker.com/embed/dashboards/19.

Bien que l'URL de redirection spécifiée dans l'URL d'intégration signée d'origine soit pour le tableau de bord 17, vous pouvez constater que le tableau de bord 19 se charge comme prévu si vous saisissez manuellement l'URL dans un onglet de navigateur. Notez qu'une autre URL d'intégration signée n'était pas nécessaire pour charger un autre tableau de bord.

L'idée clé ici est que tous les détails du compte utilisateur établis dans l'URL (autorisations, attributs utilisateur, etc.) sont appliqués à l'ensemble de la session utilisateur, et pas seulement au tableau de bord spécifique indiqué dans l'URL signée d'origine. En d'autres termes, comme leur nom l'indique, les attributs utilisateur sont une caractéristique de l'utilisateur, et non du tableau de bord. Ils doivent être utilisés pour déterminer les niveaux d'accès d'un utilisateur spécifique dans l'ensemble de l'application, et pas seulement dans un onglet spécifique.

Accéder à plusieurs marques en même temps

N'oubliez pas que vous avez également des partenaires externes qui peuvent posséder ou gérer plusieurs marques. Dans cet exemple, un partenaire gère les marques Pied Piper et Hooli.

L'approche du point de vue d'un utilisateur qui n'intègre pas de contenu

Les sessions utilisateur Looker intégrées signées fonctionnent fondamentalement de la même manière que les sessions utilisateur Looker standards non intégrées. Il peut donc être utile de reformuler l'approche problématique décrite précédemment dans le contexte d'une session utilisateur Looker standard non intégrée et de décomposer ces étapes pour comprendre comment implémenter cette solution de manière plus robuste. Voici à quoi ressemblerait ce workflow si vous donniez des instructions à un utilisateur de BI standard ayant accès à l'interface utilisateur Looker :

  1. Créez deux comptes utilisateur différents sur la page "Admin > Utilisateurs".
    1. Sur la page de modification du premier compte utilisateur, définissez la valeur de l'attribut utilisateur brand sur pied_piper.
    2. Sur la page de modification du deuxième compte utilisateur, définissez la valeur de l'attribut utilisateur brand sur hooli.
  2. Vous envoyez au partenaire des e-mails de configuration de compte pour les deux comptes utilisateur.
  3. Le partenaire configure des identifiants (adresse e-mail et mot de passe) distincts pour chaque compte.
  4. Vous donnez à votre partenaire le lien vers le tableau de bord (https://mylookerinstance.cloud.looker.com/dashboards/17) et lui expliquez que, pour passer d'une marque à l'autre, il devra revenir à la page de connexion dans un autre onglet, saisir les identifiants de son autre compte utilisateur, puis recharger le tableau de bord dans cet onglet.

Le partenaire suit les instructions. Toutefois, après avoir saisi le nom d'utilisateur et le mot de passe du compte utilisateur Hooli dans le deuxième onglet du navigateur, puis être revenu au premier onglet où le tableau de bord Pied Piper était déjà chargé, le partenaire clique sur le bouton Recharger. À la surprise du partenaire, le tableau de bord affiche les données de Hooli.

Vous vous demandez peut-être :

Attendez… c'est très gênant. Quelle est la meilleure façon de procéder ?

Oui, il y en a ! Ces scénarios illustrent un principe qui est déjà trivial dans le contexte non intégré, mais qui peut être obscurci par les abstractions du contexte intégré : Un même utilisateur humain doit être associé à un seul compte utilisateur Looker avec un seul ensemble de valeurs d'attributs utilisateur. Cela est également précisé dans notre explication de external_user_id dans notre documentation sur l'intégration signée.

Looker utilise external_user_id pour différencier les utilisateurs d'intégrations signées. Chaque utilisateur doit donc disposer d'un ID unique.

Vous pouvez créer un external_user_id pour un utilisateur avec n'importe quelle chaîne de caractères, à condition qu'elle soit unique pour cet utilisateur. Chaque ID est associé à un ensemble d'autorisations, d'attributs utilisateur et de modèles. Un seul navigateur ne peut prendre en charge qu'un seul external_user_id ou une seule session utilisateur à la fois. Il est impossible de modifier les autorisations ou les attributs d'un utilisateur en cours de session.

Accéder à plusieurs marques en même temps : ce qu'il ne faut PAS faire

Comme pour toute solution personnalisable, il existe certaines approches à éviter. Par exemple, une implémentation dans laquelle votre application génère les URL pour les deux external_user_ids à l'aide des mêmes entrées dans l'appel create_sso_embed_url affiché précédemment, et crée un onglet dans l'application pour charger chaque tableau de bord auquel le partenaire doit accéder. Nous avons souvent vu des développeurs implémenter des solutions comme celle-ci, ce qui entraîne un workflow incorrect pour l'utilisateur :

  1. Accédez à l'onglet du tableau de bord Pied Piper.
  2. Accédez à l'onglet du tableau de bord Hooli.
  3. Revenez à l'onglet du tableau de bord Pied Piper.
  4. Cliquez sur le bouton Recharger du tableau de bord Pied Piper.

…le tableau de bord Pied Piper affiche les données Hooli !

Vous pouvez essayer une approche similaire, mais en utilisant le même external_user_id test_user pour les deux appels create_sso_embed_url. Mais le comportement est exactement le même : une fois l'onglet rechargé avec le tableau de bord Pied Piper, il affiche les données de Hooli.

Comment m'assurer que le tableau de bord de chaque marque n'affiche que les données de cette marque ?

Mettre en pratique les bonnes pratiques

Pour appliquer l'approche décrite dans la section L'approche du point de vue d'une application non intégrée, vous aurez besoin d'une seule valeur d'attribut utilisateur qui donne accès à TOUTES les données auxquelles le partenaire doit avoir accès dans l'application. Pour ce faire, vous pouvez utiliser une valeur séparée par une virgule pour l'attribut brand Pied Piper,Hooli :

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper,Hooli"}
}

Pour que cette syntaxe fonctionne, vous devez vous assurer que votre attribut utilisateur est défini sur Filtre de chaîne (avancé) :

Notez que vous pouvez toujours modifier l'ensemble des attributs utilisateur pour un utilisateur si quelque chose change dans ses niveaux d'accès aux données. Par exemple, si le partenaire devient propriétaire d'une troisième marque, vous pouvez l'ajouter à la liste séparée par des virgules que vous avez spécifiée pour l'attribut utilisateur brand. Ainsi, lorsque l'utilisateur se déconnectera et se reconnectera, les modifications seront appliquées.

Filtrer les résultats du tableau de bord

OK, je comprends que les attributs utilisateur doivent spécifier toutes les données auxquelles un utilisateur peut accéder dans l'application. Mais si je spécifie les attributs utilisateur de cette manière, les données de toutes ces marques s'afficheront dans mon tableau de bord. Comment limiter les résultats d'un tableau de bord spécifique à une marque donnée ?

Pour filtrer un tableau de bord spécifique, vous devez utiliser des filtres de tableau de bord. (Cela peut sembler évident maintenant, mais nous avons vu certaines personnes bloquer sur les attributs utilisateur comme seul moyen d'appliquer des filtres dans le contexte d'intégration, peut-être parce que user_attributes est un paramètre dans l'URL d'intégration signée et que les filtres ne le sont pas.)

Veillez à exiger une valeur de filtre et à utiliser l'une des options de commande de sélection unique, comme le menu déroulant :

Assurez-vous que le filtre est appliqué au bon champ dans toutes les tuiles nécessaires :

Votre partenaire peut désormais choisir entre ces deux valeurs (et uniquement ces deux-là), car les options disponibles dans le menu déroulant sont limitées par les attributs utilisateur :

Préremplir les filtres du tableau de bord

D'accord, le tableau de bord peut désormais être filtré sur une marque spécifique, mais j'aimerais que la valeur du filtre soit déjà définie sur une marque spécifique lorsque l'utilisateur charge le tableau de bord pour cette marque dans mon application.

Là encore, il est utile de réfléchir à la façon dont cela fonctionne dans un contexte non intégré. Comment envoyer à quelqu'un un lien vers un tableau de bord auquel une valeur de filtre spécifique est déjà appliquée ? Vous avez peut-être remarqué que lorsque vous sélectionnez une valeur de filtre, elle apparaît dans l'URL du tableau de bord :

Incluez cette partie de l'URL dans votre target_url pour l'appel create_sso_embed_url :

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17?Brand=Hooli",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper,Hooli"}
}

Si vous utilisez le SDK d'intégration, vous pouvez utiliser withFilters pour spécifier les filtres initiaux à appliquer au contenu intégré :

https://looker-open-source.github.io/embed-sdk/classes/EmbedBuilder.html#withFilters

Si vous utilisez votre propre script personnalisé, assurez-vous d'ajouter le filtre à l'URL avant que le chemin ne soit encodé. Il est possible que certaines valeurs soient déjà encodées dans la chaîne de filtre (par exemple, un espace est encodé sous la forme d'un signe + dans ?Brand=Pied+Piper). Ces valeurs seront donc doublement encodées dans l'URL finale. Consultez Tableau de bord intégré SO : définir le filtre du tableau de bord dans l'URL. Post de la communauté Looker pour en savoir plus sur ces nuances. Si vous rencontrez toujours des difficultés pour appliquer les filtres, vous pouvez également poser vos questions sur ce post de la communauté.

Masquer les filtres du tableau de bord

J'ai compris comment définir les filtres initiaux sur mes tableaux de bord, mais je ne veux pas non plus que le partenaire puisse modifier lui-même les filtres du tableau de bord. La valeur du filtre ne doit être déterminée QUE par le tableau de bord vers lequel le partenaire a accédé dans mon application. Comment puis-je masquer les filtres du tableau de bord ?

Pour cela, vous pouvez utiliser des thèmes. Les thèmes sont une fonctionnalité payante. Si elle n'est pas encore activée sur votre instance Looker, contactez votre équipe commerciale Looker pour l'activer.

Une fois cette fonctionnalité activée, accédez à la section Commandes du tableau de bord de la page "Admin – Thèmes", où vous pouvez décocher l'option Afficher la barre de filtres :

Vous pouvez ensuite définir votre thème comme thème par défaut ou l'appliquer dans l'URL de vos tableaux de bord spécifiques. Encore une fois, cela se ferait dans le target_url de l'appel create_sso_embed_url :

{
  "target_url": "https://mylookerinstance.cloud.looker.com/embed/dashboards/17?Brand=Hooli&theme=test_theme",
  "session_length": 300,
  "force_logout_login": true,
  "external_user_id": "test_user",
  "first_name": "Test",
  "last_name": "User",
  "permissions": ["access_data","see_user_dashboards"],
  "models": ["thelook"],
  "user_attributes": {"brand":"Pied Piper,Hooli"}
}

Pour en savoir plus sur le masquage des filtres de tableaux de bord intégrés, y compris des extraits de code du SDK d'intégration, consultez le tutoriel YouTube Intégrer Looker avec des filtres personnalisés.

Le résultat final doit être identique à l'expérience utilisateur de la question d'origine :

Désormais, comme les valeurs de filtre sont encodées dans les URL cibles respectives intégrées à l'application, le tableau de bord de chaque marque affichera toujours les données filtrées pour la marque concernée, même si vous passez d'un onglet à l'autre.

Tester en tant qu'autres utilisateurs

L'expérience utilisateur ressemble désormais beaucoup à ce que j'avais imaginé à l'origine. Toutefois, dans mon cas d'utilisation, le partenaire dispose d'autorisations et d'autres paramètres utilisateur dont ne disposent pas les utilisateurs individuels avec les rôles external_user_id=pied_piper et external_user_id=hooli. Cela entraîne des différences dans les options disponibles dans l'UI et une expérience utilisateur légèrement différente dans l'ensemble. Je souhaite permettre à un utilisateur de voir exactement ce que voient les utilisateurs pied_piper et hooli, comme s'il s'était réellement connecté en tant que ces utilisateurs. Comment puis-je faire cela ?

Si vous souhaitez qu'un utilisateur puisse effectuer des tests en tant que chacun des utilisateurs de marques individuels, vous pouvez créer une fonction sudo similaire dans votre application qui chargera les URL d'intégration pour external_user_id=pied_piper lorsque l'utilisateur effectue un sudo en tant qu'utilisateur Pied Piper, et les URL d'intégration pour external_user_id=hooli lorsque l'utilisateur effectue un sudo en tant qu'utilisateur Hooli. Vous pouvez également utiliser le point de terminaison de l'API login_user pour agir en tant qu'utilisateur de la marque avec l'API si votre application l'utilise.

Toutefois, si vous repensez au contexte non intégré : sur la page "Admin – Utilisateurs", vous ne pouvez pas emprunter simultanément l'identité de plusieurs utilisateurs non intégrés dans plusieurs onglets. La session sudo s'appliquera à l'ensemble de la fenêtre du navigateur, comme toutes les autres sessions utilisateur. Par conséquent, vous devez concevoir sudo to sudo pour un seul utilisateur à la fois. Et, si vous y réfléchissez, cette conception est plus cohérente avec l'imitation parfaite de l'expérience des utilisateurs pour lesquels vous exécutez la commande sudo. L'utilisateur pied_piper, par exemple, n'a accès qu'au tableau de bord Pied Piper et ne peut pas ouvrir d'autres tableaux de bord dans d'autres onglets. Par conséquent, vous ne devriez pas non plus pouvoir ouvrir différents tableaux de bord dans différents onglets lorsque vous vous substituez à cet utilisateur.

Conclusion

Nous espérons que ce guide vous a été utile et que vous êtes prêt à créer vos contenus Looker intégrés signés ! Nous nous efforçons constamment de faire de Looker l'offre d'analyse de données intégrées la plus flexible et la plus robuste. N'hésitez pas à nous faire part de vos commentaires ! Si vous avez des questions ou souhaitez en savoir plus, vous pouvez nous contacter sur la communauté Looker et participer à nos événements communautaires.