Beachten Sie, dass Sie sich gerade die Looker-Dokumentation ansehen. Die Looker Studio-Dokumentation finden Sie unter https://support.google.com/looker-studio.

Diese Seite wurde von der Cloud Translation API übersetzt.

Segmentierung auf Zeilenebene für eingebettete Looker-Inhalte implementieren

Autor: Christopher Seymour (Sr. 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:

Einführung <ph type="x-smartling-placeholder">
- Anwendungsfall – Übersicht
- Ausführlichere Analysen
Grundlagen der signierten Einbettung von Looker <ph type="x-smartling-placeholder">
- Struktur der signierten Einbettungs-URL
Gleichzeitiger Zugriff auf mehrere Marken <ph type="x-smartling-placeholder">
- Der Ansatz ohne Einbettung
- Gleichzeitiger Zugriff auf mehrere Marken – was du NICHT tun solltest
Best Practices in der Praxis <ph type="x-smartling-placeholder">
Fazit

Einleitung

Die Einbettungsfunktion von Looker ist eine der leistungsstärksten und wertvollsten Funktionen von Looker. Wenn Sie diesen Leitfaden lesen, betten Sie wahrscheinlich bereits Looker-Inhalte in Ihre Anwendung ein 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. Um das Thema näher zu betrachten, ist es ein wenig langwierig. Denken Sie also daran, dass dieser Leitfaden nicht als schnelle Lösung für ein einfaches Problem gedacht ist, sondern als Baustein für die bessere Verwaltung Ihres gesamten Anwendungsfalls mit Looker-Einbettungen.

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.

Nehmen wir für diesen Anwendungsfall mit signierter Einbettung an, dass Sie der Administrator Ihrer Looker-Instanz sind. 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 Rittenfä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 hat: Eine zeigt den Namen der Marke und die andere 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 dem 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 wird:

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

Die für Hooli generierte URL zeigt das Dashboard wie folgt an:

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

Weitere Details

Sehr gut! 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.

Sicherzustellen, dass Data Governance luftdicht ist, ist von entscheidender Bedeutung, um diese leistungsstarke Datenerfahrung 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.

Grundlagen der von Looker signierten Einbettung

Beachten Sie, dass die Benutzerauthentifizierung und -verwaltung von Looker im Einbettungskontext im Grunde genauso funktioniert wie im Nicht-Einbettungskontext und im Grunde auf die gleiche Weise wie die 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 es Ihnen erheblich zum Erfolg beim Aufbau großartiger Datenerlebnisse verhelfen.

Struktur der signierten Einbettungs-URL

Dies 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:

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.
Die Kontodetails des vorhandenen Nutzers, einschließlich Berechtigungen, Modelle, Gruppen (falls angegeben) und Nutzerattributwerte (falls angegeben), werden mit den Kontodetails überschrieben, die in der URL angegeben sind.
Looker authentifiziert den Nutzer und richtet eine Sitzung für diesen Nutzer ein, indem ein Sitzungscookie im Browser gespeichert wird.
Looker leitet sie dann an die 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

Obwohl die Schritte 1 bis 3 automatisch im Hintergrund ausgeführt werden und der Endnutzer nur das Endergebnis sieht (das Dashboard selbst), sind diese Schritte im Wesentlichen mit den Schritten identisch, bei denen sich ein normaler, nicht eingebetteter Looker-Benutzer authentifiziert. Angenommen, Sie möchten, dass sich ein Nutzer mit Nutzer- und Passwortanmeldedaten anmeldet. Der Vorgang würde in etwa so aussehen:

Sie (der Looker-Administrator) gehen zum Bereich „Admin – Benutzer“ und verwenden die Suchleiste, um zu prüfen, ob für diesen Benutzer bereits ein Benutzerkonto vorhanden ist. Ist dies nicht der Fall, erstellen Sie ein neues Nutzerkonto.
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.
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 richtet eine Sitzung für diesen Nutzer ein, indem ein Sitzungscookie im Browser gespeichert wird.
Looker leitet 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 am https://mylookerinstance.cloud.looker.com/browse startet, einen neuen Browsertab öffnet und eine beliebige Seite aufruft, auf die er durch seine Berechtigungen Zugriff erhält, wird die Seite wie erwartet mit dem Sitzungscookie geladen, das bereits auf dem ursprünglichen Browsertab festgelegt wurde.

Dasselbe gilt für eingebettete Nutzer. 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 navigieren, auf das sie mit den Details ihres Nutzerkontos Zugriff haben. Angenommen, Sie werden von der ursprünglich signierten Einbettungs-URL auf einem Browsertab zu https://mylookerinstance.cloud.looker.com/embed/dashboards/17 weitergeleitet. Sie öffnen dann einen neuen Browsertab und laden ein anderes eingebettetes Dashboard, das sich im selben Ordner befindet und daher dieselben Zugriffsbeschränkungen hat: 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.

Gleichzeitiger Zugriff auf mehrere Marken

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

Ansatz ohne Einbettung

Signierte Benutzersitzungen mit Einbettungen funktionieren im Grunde genauso wie normale Looker-Benutzersitzungen ohne Einbettung. 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:

Sie erstellen zwei unterschiedliche Nutzerkonten auf der Seite "Admin - Nutzer".
1. Auf der Bearbeitungsseite für das erste Nutzerkonto setzen Sie den Nutzerattributwert brand auf pied_piper.
2. Auf der Bearbeitungsseite für das zweite Nutzerkonto setzen Sie den Nutzerattributwert brand auf hooli.
Sie senden E-Mails zur Kontoeinrichtung für beide Nutzerkonten an den Partner.
Der Partner richtet für jedes Konto separate Anmeldedaten mit E-Mail-Adresse und Passwort ein.
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. Zur Überraschung des Partners zeigt das Dashboard die Hooli-Daten an!.

Vielleicht denken Sie jetzt:

Moment, das ist sehr umständlich. Wie gehen Sie dabei am besten vor?

Natürlich! Diese Szenarien veranschaulichen ein Prinzip, das im nicht eingebetteten Kontext bereits trivial ist, aber durch die Abstraktionen des Einbettungskontexts verdeckt werden kann: Ein einzelner menschlicher Nutzer sollte mit einem einzelnen Looker-Nutzerkonto mit einer einzigen Gruppe von Nutzerattributwerten verknüpft werden. Dies wird auch in unserer Erläuterung zu external_user_id in unserer Dokumentation zu signierten Einbettungen deutlich.

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. Jeder ID ist eine Reihe von Berechtigungen, Nutzerattributen und Modellen zugeordnet. Ein einzelner Browser kann jeweils nur eine external_user_id oder eine Nutzersitzung unterstützen. Während der Sitzung können keine Änderungen an den Berechtigungen oder Attributen 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. Entwickler implementieren häufig Lösungen wie diese, die zu einem falschen Workflow für Nutzer führen:

Navigieren Sie zum Tab mit dem Pied Piper-Dashboard.
Gehen Sie zur Registerkarte mit dem Hooli-Dashboard.
Gehen Sie zurück zum Tab mit dem Pied Piper-Dashboard.
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 gleich: Sobald der Tab mit dem Rattenfänger-Dashboard neu geladen wurde, werden stattdessen die Daten für Hooli angezeigt.

Wie kann ich dafür sorgen, dass auf dem Dashboard einer Marke nur die Daten für diese Marke angezeigt werden?

Best Practices anwenden

Um den im Abschnitt Der Ansatz ohne Einbettung beschriebene Ansatz anzuwenden, benötigen Sie einen einzelnen Nutzerattributwert, der Zugriff auf ALLE Daten gewährt, auf die der Partner in der gesamten Anwendung Zugriff haben sollte. Verwenden Sie dazu einen durch Kommas getrennten Wert für das Attribut brand [Marke] 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"}
}

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 für das Nutzerattribut brand angegeben haben. Auf diese Weise werden die Änderungen übernommen, wenn sie sich ab- und wieder anmelden.

Dashboard-Ergebnisse filtern

Ich verstehe, dass die Nutzerattribute alle Daten angeben müssen, auf die ein Nutzer in der Anwendung zugreifen kann. Aber wenn ich die Benutzerattribute auf diese Weise angebe, werden die Daten für all diese Marken auf 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 wir haben festgestellt, dass einige Nutzer bei der Anwendung von Filtern im Einbettungskontext nur noch bei Nutzerattributen hängen geblieben sind – möglicherweise, weil user_attributes ein Parameter in der signierten Einbettungs-URL ist und dies nicht der Fall ist.

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

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 die 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 Anfangsfilter angeben, die auf die eingebetteten Inhalte angewendet werden sollen:

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

Wenn Sie Ihr eigenes benutzerdefiniertes Skript verwenden, sollten Sie darauf achten, dass Sie den Filter zur 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 einem Looker-Communitybeitrag werden diese Nuancen diskutiert. Sollten 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. Designs sind eine kostenpflichtige Funktion. Wenn Sie diese Funktion auf Ihrer Looker-Instanz noch nicht aktiviert haben, sollten Sie sich an Ihr Looker-Vertriebsteam wenden, um sie aktivieren zu lassen.

Sobald diese Funktion aktiviert ist, gehen Sie auf der Seite „Verwaltung“ > „Designs“ zum Abschnitt Dashboard-Steuerelemente. 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 dies würde in den target_url des create_sso_embed_url-Aufrufs aufgenommen werden:

{
  "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 Filtern für eingebettete Dashboards, einschließlich einiger eingebetteter SDK-Code-Snippets, finden Sie im 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 entsprechenden Ziel-URLs codiert sind, die in die App eingebettet sind, zeigt das Dashboard jeder Marke immer das nach der richtigen Marke gefilterte Dashboard an, auch wenn Sie zwischen den Tabs wechseln.

Mit anderen Nutzern 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 pied_piper Nutzer, so als ob die Person tatsächlich als diese Nutzer angemeldet wäre. Wie kann ich das erreichen?

Wenn Sie möchten, dass ein Nutzer für jeden einzelnen Markennutzer testen kann, können Sie eine ähnliche sudo-Funktion in Ihrer App erstellen, die die Einbettungs-URLs für external_user_id=pied_piper lädt, wenn der Nutzer im SUDO-Nutzer als Pied Piper-Nutzer arbeitet, und die Einbettungs-URLs für external_user_id=hooli, wenn der Nutzer als Hooli-Nutzer einen sudo-Vorgang durchführt. 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 Kontext ohne Einbettung: Auf der Seite „Admin - Users“ können Sie im sudo-Modus nicht gleichzeitig mehrere Benutzer ohne Einbettung in mehreren Registerkarten im sudo-Modus verwenden. Die sudo-Sitzung gilt wie alle anderen Benutzersitzungen für das gesamte Browserfenster. Daher sollten Sie sudo to sudo immer nur für einen Benutzer entwickeln. 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 nicht, um zusätzliche Dashboards in zusätzlichen Tabs zu ö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 Sie diesen Leitfaden hilfreich fanden und gut vorbereitet sind, um mit der Erstellung Ihrer von Looker signierten Einbettungsinhalte fortzufahren! Wir arbeiten kontinuierlich daran, Looker zu einem der flexibelsten und stabilsten integrierten Datenanalyse-Angebote zu machen, und freuen uns auf 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.