Best Practice: Für Looker-Nutzer eine positive Erfahrung schaffen
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
Diese Best Practices spiegeln die Empfehlungen eines interdisziplinären Teams erfahrener Looker wider. Diese Erkenntnisse basieren auf jahrelanger Erfahrung in der Zusammenarbeit mit Looker-Kunden, von der Implementierung bis hin zum langfristigen Erfolg. Die Best Practices sind so konzipiert, dass sie für die meisten Nutzer und Situationen funktionieren. Bei der Implementierung sollten Sie jedoch nach bestem Wissen und Gewissen vorgehen.
LookML-Entwickler können mit diesen Tipps die Nutzerfreundlichkeit von Looker verbessern:
Diese Empfehlungen werden in den folgenden Abschnitten ausführlicher erläutert.
Geben Sie Nutzern aussagekräftige Feldnamen.
Mit dem Parameter label können Sie Dimensionen oder Messwerten nutzerfreundliche Namen zuweisen und gleichzeitig datenbankfreundliche Namen in den Ansichts- und Modelldateien beibehalten. Sie können einige gängige Begriffe umbenennen, z. B. Anzahl in Anzahl von und Summe in Summe. Wenn Sie nicht sicher sind, welche Wörter für Nutzer relevant sind, arbeiten Sie mit einem geschäftlichen Nutzer zusammen, um einige gängige Abfragen zu erstellen. So können Sie herausfinden, mit welchen Begriffen dieser Nutzer bestimmte Dinge beschreibt. Angenommen, die Datenansichten Inventarelemente, Bestellelemente, Bestellungen und Produkte haben jeweils den Messwert Anzahl. Mit dem Parameter label können Sie jedem dieser Messwerte einen eindeutigen und aussagekräftigen Namen geben, z. B. Anzahl der Inventarelemente, Anzahl der Bestellelemente, Anzahl der Bestellungen und Anzahl der Produkte.
Vermeiden Sie es, mehrere Felder mit demselben Namen zu verwenden. So werden beispielsweise Messwerte für type: count automatisch in Looker mit dem Namen Anzahl erstellt. Daher enthalten die meisten Ansichtsdateien ein Zählmaß mit demselben Namen. Mehrere Felder mit demselben Namen können Nutzer verwirren. Wenn Sie Labels hinzufügen oder Zählungsmesswerte umbenennen, um das gezählte Objekt anzugeben, können Sie Verwechslungen vermeiden. Weitere wichtige Felder sind Erstellungsdatum und Datum der letzten Aktualisierung, z. B. in Dimensionsgruppen.
Geben Sie eindeutige Namen für Felder von type: yesno an. Verwenden Sie beispielsweise Wurde der Artikel zurückgegeben? anstelle von Zurückgegeben, um ein Feld zu benennen, das angibt, ob ein Artikel zurückgegeben wurde.
Geben Sie die Proportionen aussagekräftig an. Bestellungen pro kaufkräftigen Kunden ist beispielsweise verständlicher als Prozentsatz der Bestellungen.
Benennen Sie Felder und geben Sie Werte im gesamten Modell einheitlich an. Wenn Sie den Parameter value_format oder value_format_name verwenden, um numerische Felder zu formatieren, z. B. mit Währungssymbolen, Prozentsätzen und Dezimalstellen, wird die Übersichtlichkeit für Ihre Nutzer erhöht.
Ähnliche Felder für eine einfachere Navigation gruppieren
Verwenden Sie den Parameter group_label, um Dimensionen und Messwerte aus einzelnen oder mehreren verknüpften Datenansichten zusammenzuführen, die miteinander in Beziehung stehen. Sie können beispielsweise alle geografischen Informationen in einer Gruppe Geografie gruppieren, um alle Adress- und Standortinformationen in der Feldauswahl zusammenzuführen, anstatt sie alphabetisch aufzulisten:
dimension: city {
group_label: "Geography"
type: string
sql: ${TABLE}.city ;;
}
dimension: country {
group_label: "Geography"
type: string
map_layer_name: countries
sql: ${TABLE}.country ;;
}
Große, denormalisierte Tabellen mit dem Parameter view_label aufteilen Verwenden Sie den Parameter view_label in Feldern, um Felder logisch in separate Überschriften in der Feldauswahl zu gruppieren. Große, denormalisierte Tabellen mit vielen Feldern können schwer zu bedienen sein. Daher entsteht in der linken Auswahl der explorativen Datenanalysefelder der Eindruck, dass es mehrere Ansichten gibt.
Zeigen Sie Nutzern nicht zu viel auf einmal
Zeigen Sie Nutzern beim ersten Looker-Roll-out nicht zu viel. Fangen Sie klein an, und erweitern Sie dann die Optionen. Sie müssen nicht alle Tabellen oder Dimensionen und Messwerte gleichzeitig einblenden. Sie können zuerst die wichtigsten Felder einblenden und später weitere Funktionen hinzufügen, wenn geschäftliche Nutzer mehr Erfahrung mit der Datenexploration haben.
Dimensionen, die für Nutzer nicht relevant sind, auf der Benutzeroberfläche ausblenden Verwenden Sie den Parameter hidden für Dimensionen, die nie über die Benutzeroberfläche verwendet werden (z. B. ID-Felder oder Datenbankaktualisierungsdaten).
Verwenden Sie den Parameter fields in Explores und Joins, um die Anzahl der für Nutzer verfügbaren Felder zu begrenzen. Es sollten nur Felder enthalten sein, die für das Explore relevant sind. Dies reduziert die Größe der App und sorgt für eine bessere Nutzerfreundlichkeit. Im Gegensatz zum Parameter hidden können mit dem Parameter field Felder für jedes Explore einzeln ein- oder ausgeschlossen werden.
Blenden Sie alle Explores aus, die nur zum Ausfüllen bestimmter Looks, Dashboard-Kacheln oder Filter verwendet werden. Verwenden Sie dazu den hidden-Parameter für Explores. Explorative Datenanalysen, die nicht für die explorative Datenanalyse durch Nutzer gedacht sind, sollten in der Benutzeroberfläche ausgeblendet werden.
Verwenden Sie so wenige Explores wie möglich, damit Nutzer trotzdem ganz einfach auf die benötigten Antworten zugreifen können. Sie können explorative Datenanalysen in verschiedene Modelle für unterschiedliche Zielgruppen unterteilen, um die für jede Nutzergruppe verfügbaren Optionen einzuschränken. Die optimale Anzahl von Explores ist für jedes Unternehmen unterschiedlich. Zu viele Explores verwirren Nutzer jedoch. Verwenden Sie den Parameter group_label für Explores in einem Modell, damit Sie sie im Drop-down-Menü Explore sinnvoll gruppieren können.
Beschreibungen hinzufügen, damit Nutzer wissen, welche Felder und Explores sie verwenden sollen
Verwenden Sie den Parameter description für Dimensionen und Messwerte, um Nutzern zusätzliche Informationen zur Logik oder zu den Berechnungen im Modell zur Verfügung zu stellen. Das ist besonders wichtig für Dimensionen und Messwerte, die komplexe Logik oder Berechnungen nutzen. Es ist jedoch eine gute Idee, auch Beschreibungen für einfachere Felder zu berücksichtigen, damit Nutzer die Definitionen dahinter verstehen.
Definieren Sie Beschreibungen für explorative Datenanalysen für Nutzer. Fügen Sie jedem Explore eine kurze Beschreibung hinzu, um den Zweck des Explores und die Zielgruppe anzugeben, für die es bestimmt ist.
Gängige Workflows in Looker einbinden
Fügen Sie allen relevanten Messwerten drill_fields hinzu. Mit Drilldown-Feldern können Nutzer auf zusammengefasste Werte klicken, um auf Detaildaten zuzugreifen. Mit dem Parameter set können Sie wiederverwendbare Feldsätze erstellen, die dann auf beliebig viele Messwerte in einer Ansicht angewendet werden können.
Fügen Sie allen hierarchischen Dimensionen drill_fields hinzu. Wenn Sie beispielsweise eine drill_field für Ort in eine Bundesland-Dimension einfügen, können Nutzer ein Bundesland auswählen und dann detailliertere Informationen zu den Städten in diesem Bundesland abrufen. Diese hierarchische Aufschlüsselung wird automatisch innerhalb von Zeitdimensionengruppen angewendet.
Richten Sie Links ein, über die Nutzer ganz einfach zu anderen Looker-Dashboards oder zu externen Systemen oder Plattformen wechseln und Filter übergeben können. In der
Dokumentation zum Parameter link finden Sie Beispiele für das Übergeben von Filtern an Drilldowns.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-25 (UTC)."],[],[],null,["# Best practice: Create a positive experience for Looker users\n\n*These best practices reflect recommendations shared by a cross-functional team of seasoned Lookers. These insights come from years of experience working with Looker customers, from implementation to long-term success. The practices are written to work for most users and situations, but you should use your best judgment when implementing.*\n\n\nLookML developers can consider following these tips to improve their users' experience with Looker:\n\n- [Provide users with meaningful field names](#1)\n- [Group similar fields together for easier navigation](#2)\n- [Avoid exposing too much to users initially](#3)\n- [Add descriptions so users know which fields and Explores to use](#4)\n- [Build common workflows into Looker](#5)\n\n\nThese recommendations are explained in further detail in the sections that follow.\n\nProvide users with meaningful field names\n-----------------------------------------\n\n- Use the [`label`](/looker/docs/reference/param-field-label) parameter to apply user-friendly names to dimensions or measures while maintaining database-friendly names within the view and model files. You might consider renaming a couple of common terms, like **Count** to **Number of** and **Sum** to **Total** . If you aren't sure which words are meaningful to users, work with a business user to build some common queries, and see what words the query results use to describe what users are looking for. As an example, suppose the **Inventory Items** , **Order Items** , **Orders** , and **Products** views each have a measure called **Count** . You can use the `label` parameter to give each of these measures a unique and meaningful name, such as **Number of Inventory Items** , **Number of Order Items** , **Number of Orders** , and **Number of Products**.\n- Avoid exposing multiple fields with the same name. For example, measures of `type: count` are automatically created within Looker with the name **Count** . This results in most view files containing a count measure with the same name. Multiple fields with the same name can confuse users. Adding labels or renaming count measures to indicate the object that is being counted will prevent confusion. Other fields to keep in mind include **Created Date** and **Updated Date** , such as in [dimension groups](/looker/docs/reference/param-field-dimension-group).\n- Provide clear names for fields of [`type: yesno`](/looker/docs/reference/param-dimension-filter-parameter-types#yesno). For example, use **Was the Item Returned?** instead of **Returned** to name a field that indicates whether an item has been returned.\n- Name ratios descriptively. For example, **Orders Per Purchasing Customers** is clearer than **Orders Percent**.\n- Name fields and represent values consistently across the model. Using the [`value_format`](/looker/docs/reference/param-field-value-format) or [`value_format_name`](/looker/docs/reference/param-field-value-format-name) parameter to apply formatting such as currency symbols, percentages, and decimal precision to numerical fields will help make everything clearer to your users.\n\nGroup similar fields together for easier navigation\n---------------------------------------------------\n\n- Use the [`group_label`](/looker/docs/reference/param-field-group-label) parameter to consolidate dimensions and measures from individual or multiple joined views that are related. For example, group all geographic information into a **Geography** group to pull all address and location information together within the field picker, rather than having it all listed alphabetically: \n\n ```\n dimension: city {\n group_label: \"Geography\"\n type: string\n sql: ${TABLE}.city ;;\n }\n\n dimension: country {\n group_label: \"Geography\"\n type: string\n map_layer_name: countries\n sql: ${TABLE}.country ;;\n }\n \n ```\n\n\n- Break up large, denormalized tables using the [`view_label`](/looker/docs/reference/param-field-view-label) parameter. Utilize the `view_label` parameter within fields to group fields together logically into separate headings within the field picker. Large, denormalized tables with a lot of fields can be difficult to navigate, so this gives the illusion of multiple views in the left-hand Explore field picker.\n\nAvoid exposing too much to users initially\n------------------------------------------\n\n- Avoid exposing too much to users upon an initial Looker roll-out. Start small, and then expand the options. You don't have to expose all the tables or dimensions and measures at once. You can expose the most important fields at first and then continue to build in more functionality as business users become more confident with data exploration.\n- Hide dimensions that are not relevant to users from the user interface. Use the [`hidden`](/looker/docs/reference/param-field-hidden) parameter on dimensions that will never be used through the user interface (such as ID fields or database update dates).\n- Use the [`fields`](/looker/docs/reference/param-explore-join-fields) parameter within Explores and joins to limit the number of fields that are available to users. Included fields should be only those relevant to the Explore. This reduces bloat and provides a better experience for users. Unlike the `hidden` parameter, the `field` parameter enables fields to be included or excluded on an Explore-by-Explore basis.\n- Hide any Explores that exist solely for populating specific Looks, dashboard tiles, or filters using the [`hidden` parameter for Explores](/looker/docs/reference/param-explore-hidden). Explores that are not meant for exploration by users should be hidden from the user interface.\n- Use the fewest number of Explores possible while still allowing users to easily get access to the answers they need. Consider splitting out Explores into different models for different audiences to [limit the options available for each user group](/looker/docs/access-control-and-permission-management#controlling_feature_and_data_access). The optimal number of Explores is different for every business, but having too many Explores tends to confuse users. Consider using the [`group_label`](/looker/docs/reference/param-explore-group-label) parameter for Explores within a model, which will let you group them in a sensible way within the **Explore** drop-down menu.\n\nAdd descriptions so users know which fields and Explores to use\n---------------------------------------------------------------\n\n- Use the [`description`](/looker/docs/reference/param-field-description) parameter on dimensions and measures to provide additional information to users about the logic or calculations that are used within the model. This is particularly important for dimensions and measures that leverage complex logic or calculations. That being said, it's a good idea to also consider descriptions for simpler fields to be sure that users understand the definitions behind them.\n- Define [Explore descriptions](/looker/docs/reference/param-explore-description) for users. Add a short description to each Explore to specify the purpose of the Explore and the audience who will use it.\n\nBuild common workflows into Looker\n----------------------------------\n\n- Add [`drill_fields`](/looker/docs/reference/param-field-drill-fields) to all relevant measures. Drill fields enable users to click into aggregate values in order to access detailed data. Use the [`set`](/looker/docs/reference/param-view-set) parameter to create reusable sets of fields that can then be applied to any number of measures within a view.\n- Add [`drill_fields`](/looker/docs/reference/param-field-drill-fields) to all hierarchical dimensions. For example, adding a `drill_field` for **City** into a **State** dimension will let users select a state and then drill deeper into the cities within that state. Note that this hierarchical drilling will automatically be applied within time dimension groups.\n- Set up links that enable users to easily navigate and pass filters to other Looker dashboards or to systems or platforms that are external to Looker. See our [documentation on the `link` parameter](https://docs.looker.com/reference/field-params/link?lookml=new#passing_a_querys_filter_values_into_a_link) for examples of passing filters through drills."]]
