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

Par Christopher Seymour, analyste de données senior, et Dean Hicks, ingénieur DevRel

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 une 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 Looker. Si vous lisez ce guide, il est probable que vous intégriez déjà du contenu Looker dans votre application ou que vous envisagiez de le faire prochainement.

Ce guide vous aidera à 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. Ce guide est assez long, car il présente en détail le sujet. Gardez à l'esprit qu'il n'a pas vocation à vous fournir une solution rapide à un problème simple, mais plutôt à vous aider à mieux gérer l'ensemble de votre cas d'utilisation de l'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 dans votre produit et diffuse des segments d'utilisateurs qui doivent voir différents segments de vos données.

Pour ce cas d'utilisation d'intégration avec signature, supposons que vous soyez l'administrateur de votre instance Looker. Vous travaillez avec deux types d'utilisateurs externes intégrés: 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 composé de quelques cartes que vous présentez à tous les clients qui utilisent votre produit. Vous avez besoin que le tableau de bord soit filtré automatiquement 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 intitulé products, qui présente certaines métriques sur les produits 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 marque:

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

Vous disposez d'un tableau de bord basé sur cette exploration et qui comporte deux cartes: 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 les URL d'intégration de ce tableau de bord pour chaque utilisateur d'intégration. 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 comme suit:

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 comme suit:

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

Pour aller plus loin

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

Bonne nouvelle ! La fonctionnalité d'intégration avec signature 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 veillant à ce que la gouvernance des données définie par votre modèle de données et vos règles d'accès au contenu soit maintenue.

Pour offrir une expérience de données efficace, il est essentiel de s'assurer que la gouvernance des données est rigoureuse. Lisez la suite pour découvrir des concepts et des bonnes pratiques que vous pouvez utiliser pour concevoir l'expérience qui vous convient le mieux. Voici un bref aperçu du fonctionnement de tout cela.

Principes de base de l'intégration avec signature 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 prêter à confusion dans le contexte d'intégration avec signature Looker, car l'étape d'authentification avec signature, les paramètres utilisateur et le tableau de bord lui-même sont tous combinés dans une seule URL longue et complexe. Toutefois, cette URL est utilisée pour établir la session, qui s'applique toujours même après avoir raccourci l'URL. Gardez ce concept à l'esprit pour réussir à créer des expériences de données de qualité.

Structure de l'URL d'intégration signée

Voici l'une des URL d'authentification d'intégration signée générée 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 compte 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 écrasées par les informations du 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 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 produisent automatiquement en arrière-plan et que l'utilisateur final ne voit que le résultat final (le tableau de bord lui-même), ces étapes sont fondamentalement les mêmes que celles par lesquelles un utilisateur Looker standard, non intégré, s'authentifie. Supposons que vous souhaitiez qu'un utilisateur se connecte avec un nom d'utilisateur et un mot de passe. Le processus se présente comme suit:

  1. Vous (l'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. Sinon, créez un compte utilisateur.

  2. Vous (l'administrateur Looker) cliquez sur Modifier à côté de l'utilisateur dans le panneau "Admin - Utilisateurs", puis attribuez à l'utilisateur des autorisations, des modèles, des groupes, des valeurs d'attributs 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 vers la page de destination (généralement https://mylookerinstance.cloud.looker.com/browse).

Notez que le cookie de session s'applique à 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 charge 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égration. Les utilisateurs intégrés ont accès à un nombre de pages plus limité dans l'interface utilisateur. Ils ne peuvent accéder qu'aux URL de Look, du tableau de bord et des explorations avec le préfixe /embed. Ils peuvent toutefois 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 du navigateur. Vous ouvrez ensuite un nouvel onglet de navigateur et chargez un autre tableau de bord d'intégration situé 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 était destinée au 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 toutes les informations du compte utilisateur établies dans l'URL (autorisations, attributs utilisateur, etc.) sont appliquées à l'ensemble de la session utilisateur, et pas seulement au tableau de bord particulier spécifié dans l'URL signée d'origine. En d'autres termes, comme leur nom l'indique, les attributs utilisateur sont une fonctionnalité 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 non uniquement dans un onglet spécifique.

Accéder simultanément à plusieurs marques

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 à la fois les marques Pied Piper et Hooli.

Approche du point de vue de l'intégration

Les sessions utilisateur 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 recadrer 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 BI standard ayant accès à l'UI Looker:

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

Le partenaire suit les instructions. Cependant, 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 appuie sur le bouton Reload (Actualiser). À la surprise du partenaire, le tableau de bord affiche les données Hooli.

Vous vous demandez peut-être:

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

Bien sûr ! Ces scénarios illustrent un principe déjà évident dans le contexte non intégré, mais qui peut être masqué par les abstractions du contexte intégré: Un seul utilisateur humain doit être associé à un seul compte utilisateur Looker avec un seul ensemble de valeurs d'attributs utilisateur. Cela est également clair dans notre explication de la external_user_id dans notre documentation sur l'intégration signée.

Looker utilise external_user_id pour différencier les utilisateurs intégrés connectés. Par conséquent, chaque utilisateur doit se voir attribuer un ID unique.

Vous pouvez créer un external_user_id pour un utilisateur avec n'importe quelle chaîne, à condition qu'elle soit propre à 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 session utilisateur, à la fois. Vous ne pouvez pas modifier les autorisations ni les attributs d'un utilisateur en cours de session.

Accéder à plusieurs marques en même temps : que ne pas faire

Comme pour toute solution personnalisable, certaines approches sont à éviter. Par exemple, une implémentation dans laquelle votre application génère les URL des deux external_user_ids à l'aide des mêmes entrées dans l'appel create_sso_embed_url présenté précédemment, et crée un nouvel 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 Actualiser du tableau de bord Pied Piper.

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

Vous pouvez essayer une approche similaire, mais utilisez plutôt le même utilisateur test_user external_user_id pour les deux appels create_sso_embed_url. Cependant, le comportement est exactement le même : une fois l'onglet actualisé avec le tableau de bord Pied Piper, les données de Hooli s'affichent à la place.

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

Appliquer les bonnes pratiques

Pour appliquer l'approche décrite dans la section Approche du point de vue de l'intégration, vous avez besoin d'une seule valeur d'attribut utilisateur qui accorde l'accès à TOUTES les données auxquelles le partenaire doit avoir accès dans l'application. Pour ce faire, utilisez une valeur séparée par une virgule pour l'attribut marque 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 d'attributs utilisateur d'un utilisateur si son niveau d'accès aux données change. Par exemple, si le partenaire prend possession d'une troisième marque, vous pouvez l'ajouter à la liste séparée par des virgules que vous avez spécifiée pour son attribut utilisateur marque. Ainsi, lorsqu'il se déconnectera et se reconnectera, les modifications seront appliquées.

Filtrer les résultats du tableau de bord

D\'accord. 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 affiner les résultats d'un tableau de bord spécifique à une marque spécifique ?

La bonne façon de filtrer un tableau de bord particulier est d'utiliser les filtres de tableau de bord standards. (Cela peut sembler évident maintenant, mais nous avons vu certains utilisateurs s'en tenir aux 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.)

Assurez-vous d'exiger une valeur de filtre et d'utiliser l'une des options de commande de sélection unique, comme un menu déroulant:

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

Votre partenaire peut désormais choisir entre ces deux valeurs (et seulement ces deux valeurs), 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 maintenant être filtré pour une marque spécifique, mais je voudrais que la valeur du filtre soit déjà définie sur une marque spécifique lorsque l\'utilisateur charge le tableau de bord de cette marque dans mon application.

Encore une fois, il est utile de réfléchir à la façon dont cela fonctionne dans le contexte de non-intégration. 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, cette valeur 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 l'encodage du chemin d'accès. Certaines valeurs peuvent déjà être encodées dans la chaîne de filtre (par exemple, un espace est encodé en tant que + dans ?Brand=Pied+Piper). Ces valeurs seront donc encodées deux fois dans l'URL finale. Vous pouvez consulter SO embedded dashboard - set dashboard filter as part of URL? (Tableau de bord intégré SO - définir le filtre du tableau de bord dans l'URL ?) Pour en savoir plus sur ces nuances, consultez le post de la communauté Looker. Si vous ne parvenez toujours pas à appliquer les filtres, vous pouvez également poser vos questions dans ce post destiné à la communauté.

Masquer les filtres du tableau de bord

OK, je vois comment définir les filtres initiaux de mes tableaux de bord, mais je ne veux pas non plus que le partenaire modifie lui-même les filtres du tableau de bord. La valeur du filtre doit être déterminée UNIQUEMENT par le tableau de bord auquel le partenaire accède dans mon application. Comment puis-je masquer les filtres du tableau de bord ?

Pour ce faire, vous pouvez utiliser des thèmes. Les thèmes sont une fonctionnalité payante. Si vous ne l'avez pas encore activée sur votre instance Looker, contactez votre équipe commerciale Looker pour qu'elle l'active.

Une fois cette fonctionnalité activée, accédez à la section Commandes du tableau de bord de la page "Administration - Thèmes". Vous pouvez alors désactiver l'option Afficher la barre de filtres:

Vous pouvez ensuite définir votre thème par défaut ou l'appliquer dans l'URL de vos tableaux de bord spécifiques. Encore une fois, cela s'appliquerait à la 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 du tableau de bord intégré, y compris certains extraits de code du SDK intégré, consultez ce tutoriel YouTube sur l'intégration de Looker avec des filtres personnalisés.

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

Toutefois, 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 est toujours filtré pour afficher la bonne marque, même lorsque vous passez d'un onglet à un autre.

Tester en tant qu'autres utilisateurs

L'expérience utilisateur est maintenant très proche de ce que j'avais imaginé au départ. Toutefois, dans mon cas d'utilisation, le partenaire dispose d'autorisations et d'autres paramètres utilisateur différents de ceux des utilisateurs individuels avec external_user_id=pied_piper et external_user_id=hooli. Cela entraîne des options différentes disponibles dans l'interface utilisateur et une expérience utilisateur légèrement différente dans l'ensemble. Je souhaite autoriser un utilisateur à voir tout exactement comme les utilisateurs pied_piper et hooli , comme s'il s'était réellement connecté en tant que ces utilisateurs. Comment puis-je y parvenir ?

Si vous souhaitez qu'un utilisateur puisse effectuer des tests en tant que chaque utilisateur de la marque, 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 exécute sudo en tant qu'utilisateur Pied Piper, et les URL d'intégration pour external_user_id=hooli lorsque l'utilisateur exécute sudo en tant qu'utilisateur Hooli. Vous pouvez également utiliser le point de terminaison de l'API login_user pour exécuter sudo en tant qu'utilisateur de la marque avec l'API si votre application l'utilise.

Toutefois, si vous revenez au contexte non intégré, sur la page "Admin > Utilisateurs", vous ne pouvez pas exécuter sudo simultanément en tant que plusieurs utilisateurs non intégrés dans plusieurs onglets. La session sudo s'applique à l'ensemble de la fenêtre du navigateur, comme toutes les autres sessions utilisateur. Par conséquent, vous devez concevoir sudo pour qu'il ne soit utilisé que par un seul utilisateur à la fois. Et, si vous y réfléchissez, cette conception est plus cohérente, car elle imite parfaitement l'expérience des utilisateurs avec lesquels vous utilisez 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 pouvoir ouvrir différents tableaux de bord dans différents onglets lorsque vous utilisez sudo avec cet utilisateur.

Conclusion

Nous espérons que ce guide vous a été utile et que vous vous sentez prêt à créer votre contenu intégré signé Looker. Nous nous efforçons constamment de faire de Looker l'offre d'analyse de données intégrée la plus flexible et la plus robuste. Nous aimerions connaître votre avis. Si vous avez des questions ou souhaitez en savoir plus, vous pouvez interagir avec nous sur la communauté Looker et participer à nos événements communautaires.