Segmentierung auf Zeilenebene für eingebettete Looker-Inhalte implementieren

Von Christopher Seymour, Senior Data Analyst, und Dean Hicks, Developer Relations Engineer

Mit der Segmentierung auf Zeilenebene können Sie die Daten einschränken, auf die ein einzelner Nutzer zugreifen kann, basierend auf den Werten, die in einem oder mehreren Datenbankfeldern gespeichert sind. In diesem Leitfaden werden Methoden zur Implementierung der Segmentierung auf Zeilenebene in eingebetteten Looker-Inhalten beschrieben. Er enthält die folgenden Abschnitte:

Einleitung

Die Einbettungsfunktion von Looker ist eine der leistungsfähigsten und wertvollsten Funktionen von Looker. Wenn Sie diesen Leitfaden lesen, haben Sie wahrscheinlich bereits Looker-Inhalte in Ihre Anwendung eingebettet oder beabsichtigen dies in naher Zukunft.

Dieser Leitfaden soll Ihnen helfen, das Design der Einbettungsfunktion von Looker besser zu verstehen und die Segmentierung in eine Anwendung zu implementieren, mit der Partner den Zugriff auf mehrere Marken verwalten können. Da dieser Leitfaden einen detaillierten Einblick in das Thema bietet, ist er etwas länger. Beachten Sie, dass er nicht als schnelle Lösung für ein einfaches Problem gedacht ist, sondern als Baustein, mit dem Sie Ihren gesamten Looker-Embed-Anwendungsfall besser verwalten können.

Anwendungsfall – Übersicht

In diesem Leitfaden wird ein häufiger Anwendungsfall beschrieben, bei dem Ihr Unternehmen Looker-Inhalte in Ihr Produkt einbettet und Nutzersegmente bedient, denen unterschiedliche Bereiche Ihrer Daten angezeigt werden sollten.

Angenommen, Sie sind der Administrator Ihrer Looker-Instanz. Sie arbeiten mit zwei Arten von Nutzern, die extern eingebettet sind: Kunden, die nur auf Daten zugreifen können sollten, die für ihre Marke relevant sind, und Partner, die auf Daten mehrerer Marken zugreifen können. Sie haben ein Dashboard mit einigen Tiles, die Sie allen Kunden anzeigen, die Ihr Produkt verwenden. Sie möchten jedoch, dass das Dashboard automatisch für jeden Kunden gefiltert wird, damit in den Dashboards nur die Daten angezeigt werden, die für diesen Kunden spezifisch sind. In den Beispielen in diesem Dokument werden zwei fiktive Unternehmen verwendet: Hooli und Rattenfänger.

Sie haben die Tabelle Produkte mit einigen Produktmesswerten für verschiedene Marken. Jede Marke entspricht einem anderen eingebetteten Einbettungsnutzer (mit einer anderen external_user_id) in der signierten Einbettungsanwendung. Da jeder Nutzer eingebetteter Inhalte nur die Daten für seine eigene Marke sehen soll, haben Sie ein Explore, in dem ein Zugriffsfilter für das Nutzerattribut brand verwendet wird:

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

Sie haben ein Dashboard, das auf diesem Explore basiert und zwei Kacheln enthält: Auf der einen ist der Name der Marke zu sehen, auf der anderen die Anzahl der Produkte für diese Marke.

Mit dem Endpunkt create_sso_embed_url kannst du Einbettungs-URLs dieses Dashboards für jeden eingebetteten Nutzer generieren. In diesem Beispiel werden zwei Marken verwendet: Rattenfänger und Hooli. Hier ist der Anfragetext, den Sie im create_sso_embed_url-Aufruf für Pied Piper mit external_user_id pied_piper verwenden:

{
  "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"}
}

Die URL, die Sie für Pied Piper generiert haben, stellt das Dashboard wie folgt dar:

Hier ist der Anfragetext, der im create_sso_embed_url-Aufruf für Hooli mit external_user_id hooli verwendet wurde:

{
  "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"}
}

Über die für Hooli generierte URL wird das Dashboard so angezeigt:

Voilà! Das Dashboard wird entsprechend dem Wert der einzelnen eingebetteten Nutzer für das Nutzerattribut brand gefiltert.

Mehr erfahren

Sehr cool! Aber was ist, wenn ich einem einzelnen Nutzer Zugriff auf mehrere Marken gewähren möchte? Wie kann ich dafür sorgen, dass meine Daten nur relevanten Nutzern angezeigt werden?

Gute Neuigkeiten! Die signierte Einbettungsfunktion von Looker wurde entwickelt, um Entwicklern die Erstellung leistungsstarker, maßgeschneiderter Datenerlebnisse für Benutzer zu ermöglichen und gleichzeitig sicherzustellen, dass die durch Ihr Datenmodell und die Zugriffsrichtlinien für Inhalte definierte Data Governance aufrechterhalten wird.

Eine lückenlose Datenverwaltung ist entscheidend, um eine leistungsstarke Datennutzung zu ermöglichen. Lesen Sie weiter, um einige Konzepte und Best Practices kennenzulernen, mit denen Sie die User Experience so gestalten können, die für Sie am besten geeignet ist. Zunächst erhalten Sie einen kurzen Überblick darüber, wie all dies funktioniert.

Die Grundlagen der von Looker signierten Einbettung

Die Nutzerauthentifizierung und -verwaltung in Looker funktioniert im eingebetteten Kontext im Grunde genauso wie im nicht eingebetteten Kontext und im Grunde genauso wie in den meisten anderen Webanwendungen.

Dies kann im Kontext der von Looker signierten Einbettung verwirrend sein, da der signierte Authentifizierungsschritt, die Benutzereinstellungen und das Dashboard selbst in einer langen, komplexen URL zusammengefasst sind. Diese URL wird jedoch zum Aufbau der Sitzung verwendet, die auch nach der Kürzung der URL weiterhin gilt. Wenn Sie dieses Konzept im Hinterkopf behalten, wird dies Ihrem Erfolg bei der Schaffung großartiger Datenerlebnisse beiträgt.

Struktur der signierten Einbettungs-URL

Hier ist eine der signierten URLs für die Authentifizierung eingebetteter Inhalte, die durch den create_sso_embed_url-Aufruf mit dem Anfragetext für Pied Piper generiert wurden:

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

Im Folgenden sehen Sie dieselbe URL decodiert und in einzelne Zeilen aufgeteilt:

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

Wenn Sie auf diese URL zugreifen, passiert Folgendes:

  1. Looker sucht nach einem vorhandenen Nutzerkonto mit external_user_id = pied_piper. Ist keins vorhanden, erstellt Looker ein neues Nutzerkonto mit dieser external_user_id.

  2. Die Kontodetails des vorhandenen Nutzers, einschließlich Berechtigungen, Modelle, Gruppen (falls angegeben) und Nutzerattributwerte (falls angegeben), werden mit den in der URL angegebenen Kontodetails überschrieben.

  3. Looker authentifiziert den Nutzer und stellt eine Sitzung für ihn her, indem ein Sitzungscookie im Browser gespeichert wird.

  4. Looker leitet dann zur Ziel-URL oder Weiterleitungs-URL weiter, die im create_sso_embed_url-Aufruf angegeben ist:

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

    Sie können diese Weiterleitungs-URL als codierte relative URL in der ursprünglichen signierten Einbettungs-URL sehen:

    %2Fembed%2Fdashboards%2F17

Die Schritte 1 bis 3 werden automatisch im Hintergrund ausgeführt und der Endnutzer sieht nur das Endergebnis (das Dashboard selbst). Diese Schritte sind im Grunde dieselben wie bei der Authentifizierung eines regulären Looker-Nutzers, der kein eingebettetes Dashboard verwendet. Angenommen, Sie möchten, dass sich ein Nutzer mit Nutzername und Passwort anmeldet. Der Vorgang würde in etwa so aussehen:

  1. Sie (der Looker-Administrator) rufen den Bereich „Verwaltung“ - „Nutzer“ auf und prüfen in der Suchleiste, ob für diesen Nutzer bereits ein Nutzerkonto vorhanden ist. Ist dies nicht der Fall, erstellen Sie ein neues Nutzerkonto.

  2. Als Looker-Administrator haben Sie im Bereich „Admin – Nutzer“ neben dem Nutzer auf Bearbeiten geklickt und ihm Berechtigungen, Modelle, Gruppen, Nutzerattributwerte und andere Werte zugewiesen.

  3. Der Nutzer ruft die Anmeldeseite unter https://mylookerinstance.cloud.looker.com/login auf und gibt seinen Nutzernamen und sein Passwort ein. Looker authentifiziert den Nutzer und stellt eine Sitzung für ihn her, indem ein Sitzungscookie im Browser gespeichert wird.

  4. Looker leitet Sie dann zur Landingpage weiter (normalerweise https://mylookerinstance.cloud.looker.com/browse).

Beachten Sie, dass das Sitzungscookie für jeden Tab im Browserfenster gilt. Wenn der Nutzer https://mylookerinstance.cloud.looker.com/browse aufruft, einen neuen Browsertab öffnet und eine Seite aufruft, auf die er gemäß seinen Berechtigungen Zugriff hat, wird die Seite wie erwartet mit dem Sitzungs-Cookie geladen, das bereits im ursprünglichen Browsertab festgelegt wurde.

Dasselbe gilt für Nutzer, die Inhalte einbetten. Beim Einbetten von Nutzern haben Sie etwas weniger Möglichkeiten, auf die Seiten der Benutzeroberfläche zuzugreifen – sie können nur Look-, Dashboard- und Explore-URLs mit dem Präfix /embed aufrufen. Sie können jedoch weiterhin manuell zu jedem Dashboard wechseln, auf das sie über die Details ihres Nutzerkontos Zugriff haben. Angenommen, die ursprüngliche signierte Embed-URL leitet dich in einem Browsertab zu https://mylookerinstance.cloud.looker.com/embed/dashboards/17 weiter. Öffnen Sie dann einen neuen Browsertab und laden Sie ein anderes eingebettetes Dashboard aus demselben Ordner (mit denselben Zugriffsbeschränkungen) herunter: https://mylookerinstance.cloud.looker.com/embed/dashboards/19.

Obwohl die in der ursprünglichen signierten Einbettungs-URL angegebene Weiterleitungs-URL für Dashboard 17 angegeben wurde, können Sie sehen, dass Dashboard 19 wie erwartet geladen wird, wenn Sie die URL manuell in einen Browsertab eingeben. Zum Laden eines anderen Dashboards war keine signierte Einbettungs-URL erforderlich.

Die wichtigste Erkenntnis hier ist, dass alle in der URL festgelegten Nutzerkontodetails (Berechtigungen, Nutzerattribute usw.) auf die gesamte Nutzersitzung und nicht nur auf das Dashboard angewendet werden, das in der ursprünglichen signierten URL angegeben ist. Mit anderen Worten, wie der Name schon sagt, sind Benutzerattribute eine Funktion des Benutzers und nicht eine Funktion des Dashboards. Sie sollten verwendet werden, um die Zugriffsebenen eines bestimmten Benutzers in der gesamten Anwendung und nicht nur in einem bestimmten Tab zu bestimmen.

Gleichzeitig auf mehrere Marken zugreifen

Bedenke, dass du auch externe Partner hast, die mehrere Marken besitzen oder verwalten. In diesem Beispiel verwaltet ein Partner sowohl die Marke Pied Piper als auch die Marke Hooli.

Der Ansatz aus der Perspektive von nicht eingebetteten Inhalten

Signierte Benutzersitzungen mit Einbettungen funktionieren im Grunde genauso wie normale, nicht eingebettete Looker-Benutzersitzungen. Daher kann es hilfreich sein, den zuvor beschriebenen problematischen Ansatz im Kontext einer regulären Looker-Benutzersitzung ohne Einbettung neu zu formulieren und diese Schritte aufzuschlüsseln, um zu verstehen, wie diese Lösung robuster implementiert werden kann. So würde dieser Workflow aussehen, wenn Sie einem Standard-BI-Nutzer, der Zugriff auf die Looker-Benutzeroberfläche hat, Anweisungen geben würden:

  1. Sie erstellen auf der Seite „Verwaltung“ unter „Nutzer“ zwei verschiedene Nutzerkonten.
    1. Auf der Bearbeitungsseite für das erste Nutzerkonto legen Sie den Wert des Nutzerattributs brand auf pied_piper fest.
    2. Auf der Bearbeitungsseite für das zweite Nutzerkonto legen Sie den Wert des Nutzerattributs Marke auf hooli fest.
  2. Sie senden E-Mails zur Kontoeinrichtung für beide Nutzerkonten an den Partner.
  3. Der Partner richtet für jedes Konto separate E-Mail- und Passwort-Anmeldedaten ein.
  4. Sie geben dem Partner den Link zum Dashboard. (https://mylookerinstance.cloud.looker.com/dashboards/17) und teile ihm mit, dass er zum Wechseln des Dashboards zwischen Marken auf einem anderen Tab zur Anmeldeseite zurückkehren und dort die E-Mail-Adresse und das Passwort für das andere Nutzerkonto eingeben muss. Anschließend muss er das Dashboard noch einmal auf diesem Tab laden.

Der Partner folgt der Anleitung. Nachdem er jedoch den Nutzernamen und das Passwort des Hooli-Nutzerkontos im zweiten Browsertab eingegeben und dann zum ersten Tab zurückgekehrt ist, in dem das Rattenfänger-Dashboard bereits geladen war, klickt der Partner auf die Schaltfläche Aktualisieren. Zu seiner Überraschung zeigt das Dashboard die Hooli-Daten an.

Sie fragen sich jetzt vielleicht:

Moment…das ist sehr ärgerlich. Wie gehen Sie dann am besten vor?

Natürlich! Diese Szenarien veranschaulichen ein Prinzip, das im nicht eingebetteten Kontext bereits trivial ist, aber durch die Abstraktion des eingebetteten Kontexts verdeckt werden kann: Ein einzelner Nutzer sollte einem einzelnen Looker-Nutzerkonto mit einem einzelnen Satz von Benutzerattributwerten zugeordnet sein. Das wird auch in unserer Erklärung der external_user_id in der Dokumentation zu signierten Einbettungen deutlich gemacht.

Looker verwendet external_user_id, um Nutzer signierter Einbettungen zu unterscheiden. Daher muss jedem Nutzer eine eindeutige ID zugewiesen sein.

Sie können ein external_user_id-Objekt mit einem beliebigen String für einen Nutzer erstellen, solange er für diesen Nutzer eindeutig ist. Jede ID ist mit einer Reihe von Berechtigungen, Nutzerattributen und Modellen verknüpft. Ein einzelner Browser kann jeweils nur eine external_user_id oder Nutzersitzung unterstützen. Während einer Sitzung können keine Änderungen an den Berechtigungen oder Nutzerattributen eines Nutzers vorgenommen werden.

Gleichzeitig Zugriff auf mehrere Marken – was du NICHT tun solltest

Wie bei jeder anpassbaren Lösung gibt es bestimmte Ansätze, die Sie vermeiden sollten. Beispiel: Bei einer Implementierung, bei der Ihre App die URLs für beide external_user_ids mithilfe derselben Eingaben im zuvor gezeigten create_sso_embed_url-Aufruf generiert und in der App einen neuen Tab erstellt, um alle Dashboards zu laden, auf die der Partner zugreifen muss. Wir haben häufig gesehen, dass Entwickler Lösungen wie diese implementieren, was zu einem falschen Workflow für den Nutzer führt:

  1. Navigieren Sie zum Tab mit dem Pied Piper-Dashboard.
  2. Rufen Sie den Tab „Hooli-Dashboard“ auf.
  3. Gehen Sie zurück zum Tab mit dem Pied Piper-Dashboard.
  4. Klicke auf dem Pied Piper-Dashboard auf die Schaltfläche Aktualisieren.

...das Rattenfänger-Dashboard zeigt die Hooli-Daten an!

Sie können einen ähnlichen Ansatz ausprobieren, aber stattdessen denselben external_user_id-test_user für beide create_sso_embed_url-Aufrufe verwenden. Das Verhalten ist jedoch genau das gleiche: Sobald der Tab mit dem Pied Piper-Dashboard neu geladen wird, werden stattdessen die Daten für Hooli angezeigt.

Wie kann ich dafür sorgen, dass im Dashboard jeder Marke nur die Daten für diese Marke angezeigt werden?

Best Practices anwenden

Wenn Sie den im Abschnitt Der Ansatz aus der Perspektive von nicht eingebetteten Apps beschriebenen Ansatz anwenden möchten, benötigen Sie einen einzelnen Wert für das Nutzerattribut, der Zugriff auf ALLE Daten gewährt, auf die der Partner in der gesamten Anwendung Zugriff haben soll. Dazu können Sie einen kommagetrennten Wert für das Attribut „Marke“ Pied Piper,Hooli verwenden:

{
  "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"}
}

Damit diese Syntax funktioniert, muss Ihr Nutzerattribut als Stringfilter (erweitert) festgelegt sein:

Hinweis: Sie können die Gruppe der Nutzerattribute weiterhin ändern, wenn sich bei den Datenzugriffsebenen etwas ändert. Wenn der Partner beispielsweise die Inhaberschaft einer dritten Marke übernimmt, können Sie diese Marke der durch Kommas getrennten Liste hinzufügen, die Sie als Nutzerattribut brand angegeben haben. So werden die Änderungen übernommen, wenn sich der Nutzer abmeldet und wieder anmeldet.

Dashboard-Ergebnisse filtern

Ich verstehe, dass die Nutzerattribute alle Daten angeben müssen, auf die ein Nutzer in der Anwendung zugreifen kann. Wenn ich die Nutzerattribute jedoch so angeben, werden die Daten für alle diese Marken in meinem Dashboard angezeigt. Wie schränke ich die Ergebnisse in einem bestimmten Dashboard auf eine bestimmte Marke ein?

Die korrekte Methode zum Filtern eines bestimmten Dashboards ist die Verwendung des regulären ol' Dashboard-Filter. Das mag jetzt offensichtlich erscheinen, aber einige Nutzer haben sich darauf verlassen, dass Nutzerattribute die einzige Möglichkeit sind, Filter im Einbettungskontext anzuwenden. Das liegt möglicherweise daran, dass user_attributes ein Parameter in der signierten Einbettungs-URL ist und Filter nicht.

Achten Sie darauf, dass ein Filterwert erforderlich ist, und verwenden Sie eine der Steuerelementoptionen für die Einzelauswahl, z. B. ein Drop-down-Menü:

Stellen Sie sicher, dass der Filter auf alle erforderlichen Tiles auf das richtige Feld angewendet wird:

Nun kann Ihr Partner zwischen diesen beiden (und nur diesen beiden) Werten auswählen, da die verfügbaren Optionen im Drop-down-Menü durch die Nutzerattribute begrenzt werden:

Dashboard-Filter vorab ausfüllen

Das Dashboard kann jetzt nach einer bestimmten Marke gefiltert werden, aber ich möchte, dass der Filterwert bereits auf eine bestimmte Marke festgelegt wird, wenn der Nutzer das Dashboard für diese Marke in meiner App lädt.

Auch hier ist es hilfreich, darüber nachzudenken, wie dies ohne Einbettungskontext funktioniert. Wie senden Sie einem Nutzer einen Link zu einem Dashboard, auf das bereits ein bestimmter Filterwert angewendet wurde? Wenn Sie einen Filterwert auswählen, wird dieser Filterwert in der URL für das Dashboard angezeigt:

Füge diesen Teil der URL für den create_sso_embed_url-Aufruf in dein target_url ein:

{
  "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"}
}

Wenn du das Embed SDK verwendest, kannst du mit withFilters die ersten Filter angeben, die auf die eingebetteten Inhalte angewendet werden sollen:

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

Wenn Sie ein eigenes benutzerdefiniertes Script verwenden, müssen Sie den Filter der URL hinzufügen, bevor der Pfad codiert wird. Einige Werte sind möglicherweise bereits im Filterstring codiert (z. B. ein Leerzeichen als „+“ in ?Brand=Pied+Piper). Diese Werte werden in der finalen URL also doppelt codiert. Sie können sich den Abschnitt SO eingebettetes Dashboard - Dashboard-Filter als Teil der URL festlegen? ansehen. In diesem Beitrag in der Looker-Community werden diese Nuancen erläutert. Wenn Sie weiterhin Probleme haben, die Filter anzuwenden, können Sie in diesem Communitybeitrag auch Fragen stellen.

Dashboard-Filter ausblenden

Okay, ich weiß, wie ich die anfänglichen Filter in meinen Dashboards einstelle, möchte aber auch nicht, dass der Partner die Dashboard-Filter selbst ändert. Der Filterwert sollte NUR anhand des Dashboards bestimmt werden, zu dem der Partner in meiner App navigiert ist. Wie kann ich die Dashboard-Filter ausblenden?

Dazu können Sie Designs verwenden. Themen sind eine kostenpflichtige Funktion. Wenn diese Funktion in Ihrer Looker-Instanz noch nicht aktiviert ist, wenden Sie sich bitte an Ihr Looker-Vertriebsteam, um sie aktivieren zu lassen.

Nachdem Sie diese Funktion aktiviert haben, rufen Sie auf der Seite „Verwaltung“ unter „Designs“ den Bereich Dashboard-Steuerelemente auf. Dort können Sie die Option Filterleiste anzeigen deaktivieren:

Dann können Sie entweder das Design als Standarddesign festlegen oder das Design in der URL Ihrer spezifischen Dashboards anwenden. Auch hier wird der Wert in die target_url des create_sso_embed_url-Aufrufs eingefügt:

{
  "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"}
}

Weitere Informationen zum Ausblenden von eingebetteten Dashboard-Filtern, einschließlich einiger Code-Snippets für das eingebettete SDK, finden Sie in diesem YouTube-Tutorial: Looker mit benutzerdefinierten Filtern einbetten.

Das Endergebnis sollte der User Experience aus der ursprünglichen Frage entsprechen:

Da die Filterwerte jetzt jedoch in den jeweiligen Ziel-URLs codiert sind, die in die App eingebettet sind, zeigt das Dashboard der einzelnen Marken immer das nach der richtigen Marke gefilterte Dashboard an, auch wenn Sie zwischen den Tabs wechseln.

Als andere Nutzer testen

Jetzt sieht die Nutzererfahrung sehr ähnlich aus, was ich ursprünglich erwartet hatte. In meinem Anwendungsfall hat der Partner jedoch andere Berechtigungen und andere Nutzereinstellungen als die einzelnen Nutzer mit external_user_id=pied_piper und external_user_id=hooli. Das führt zu unterschiedlichen Optionen in der Benutzeroberfläche und insgesamt zu einer etwas anderen Nutzererfahrung. Ich möchte zulassen, dass ein Nutzer alles genau so sieht wie pied_piper und hooli Nutzer, so als ob die Person tatsächlich als diese Nutzer angemeldet wäre. Wie kann ich das erreichen?

Wenn ein Nutzer als jeder der einzelnen Markennutzer testen soll, können Sie in Ihrer App eine ähnliche Sudo-Funktion erstellen, die die Einbettungs-URLs für external_user_id=pied_piper lädt, wenn der Nutzer als Pied Piper-Nutzer Sudo verwendet, und die Einbettungs-URLs für external_user_id=hooli, wenn der Nutzer als Hooli-Nutzer Sudo verwendet. Wenn Ihre App die API verwendet, können Sie auch den API-Endpunkt login_user verwenden, um im SUDO-Status als Markennutzer mit der API zu arbeiten.

Denken Sie jedoch noch einmal an den nicht eingebetteten Kontext: Auf der Seite „Verwaltung“ - „Nutzer“ können Sie nicht gleichzeitig als mehrere nicht eingebettete Nutzer auf mehreren Tabs „sudo“ ausführen. Die „sudo“-Sitzung gilt wie alle anderen Nutzersitzungen für das gesamte Browserfenster. Daher sollten Sie „sudo“ so konfigurieren, dass immer nur ein Nutzer gleichzeitig „sudo“ ausführen kann. Und wenn Sie darüber nachdenken, ist dieses Design einheitlicher, da es die User Experience perfekt nachahmt. Der Nutzer pied_piper hat beispielsweise nur Zugriff auf das Pied Piper-Dashboard und kann keine zusätzlichen Dashboards in zusätzlichen Tabs öffnen. Daher sollten Sie auch nicht in der Lage sein, verschiedene Dashboards in verschiedenen Tabs zu öffnen, wenn Sie als dieser Benutzer im SUDO-Status arbeiten.

Fazit

Wir hoffen, dass dieser Leitfaden hilfreich war und dass Sie nun gut gerüstet sind, um mit der Erstellung Ihrer eingebetteten Looker-Inhalte fortzufahren. Wir arbeiten ständig daran, Looker zum flexibelsten und robustesten eingebetteten Analysetool für Daten zu machen. Wir freuen uns über Ihr Feedback. Wenn Sie Fragen haben oder mehr erfahren möchten, können Sie sich in der Looker-Community mit uns austauschen und an unseren Community-Veranstaltungen teilnehmen.