Prepare and test your skills
Prepare and test your skills
Create, modify, and share dashboards to answer business questions is the workflow that turns saved queries into interactive pages for stakeholders. Data flows from an Explore query into a saved Look or tile, and from one or more tiles into a Looker (opens in a new tab) dashboard where viewers filter and explore. Dashboards combine charts, text, filters, and layout so one page can answer the same business question from different angles.
A left-to-right process flow showing an Explore query saved as a Look, added as query or Look-linked tiles, assembled into a dashboard, then filtered by a viewer to answer a business question.
A Look is a saved Explore query plus its chart that can be reused later or added to dashboards. The flow moves from an Explore query to a saved Look, and then from the Look to one or more dashboard tiles. Saving a Look preserves both the query and the visualization, so teams reuse the same definition without rebuilding it.
A user-defined dashboard is a dashboard created and edited in the Looker interface and stored in a folder. A LookML dashboard is a dashboard defined in code in a .dashboard.lookml file, which keeps the definition in version control alongside the data model. To view either type, a person needs View access for its folder and access to the models behind its tiles.
A blank user-defined dashboard is created from a folder where you have Manage Access, Edit access:
A dashboard can also be created directly from a Look or Explore by opening it, clicking Save, and choosing As a new dashboard. In that flow you enter a title for both the dashboard and its first tile, select a folder, and choose whether to use the Look or Explore filters as dashboard filters.
Dashboard tiles are the building blocks that display queries, Looks, text, or custom apps on a dashboard. The first tile takes the full page width, and later tiles are sized to one-third width and placed in rows underneath. Tiles can be moved by dragging, resized, renamed, or edited to change the visualization or query.
| Tile type | What it holds | Choose when |
|---|---|---|
| Query tile | Independent query that belongs to the dashboard | You want the tile to survive if the source Look is deleted and to avoid cluttering folders |
| Look-linked tile | Query linked to a saved Look in the same folder | You want one Look to feed many dashboards so all linked tiles update together |
| Text tile | Heading or explanation built with Text or Markdown | You want to label sections or guide viewers through the page |
| Extension tile | Custom application that runs inside the tile | You want interactive custom behavior beyond a chart or table |
User-defined dashboards and LookML dashboards share the same goal but differ in maintenance. User-defined dashboards are rearranged and edited in the interface, while LookML dashboards are updated by editing dashboard and element parameters in code. A LookML dashboard can be copied to a folder as a user-defined dashboard, and a user-defined dashboard can generate LookML for a LookML dashboard.
Dashboard filters and cross-filters are the controls that let one dashboard serve many questions. A creator adds a dashboard filter in edit mode, chooses which field it controls, and uses Tiles to Update to choose which tiles it applies to. Because the filter sits above individual tiles, a viewer selection flows from the filter control to each connected tile, such as narrowing by date, region, or product.
Cross-filtering is ad hoc filtering where a viewer clicks a data point in one tile and all other tiles filter to that value. Cross-filters cannot be saved to the dashboard, but they can be shared by sharing the URL of the cross-filtered dashboard. Tiles also support drilling, which lets a viewer click a point to see granular detail, open Explore rows, follow links to other content, or run data actions.
Customizing layout means arranging tiles and styling the page so answers are easy to find. Creators work in edit mode with Add, Filters, Settings, Quick layout, Style, Cancel, and Save options, and they drag tiles by the six-dot handle while grid guides show size. Text tiles add headings, tabs group related tiles into focused views, and themes change fonts and colors. Dashboards with slow rendering should be split into smaller dashboards because more tiles require more browser resources.
Exam tip: A query tile is independent and survives if its source Look is deleted, while a Look-linked tile stays connected and shows an error if its source Look is deleted.
The Looker Scheduler sends instant or recurring deliveries from dashboards, Looks, and Explore queries to destinations inside and outside Looker. A schedule can run after a datagroup triggers and rebuilds relevant persistent derived tables (PDTs), so recipients get fresh data after the update completes. Delivery also depends on data access, because a user can only schedule models and data they are allowed to see.
The built-in destinations supported by the Scheduler are:
Dashboards deliver as PDF for a formatted view, visualization (PNG) for tile images, or CSV ZIP for data files. Looks and Explores deliver as CSV, XLSX, JSON variants, Text, or HTML. To send an Explore as PDF or PNG, save it first as a Look, add that Look to a dashboard, and schedule the dashboard. Deliveries without the schedule_without_limit permission (opens in a new tab) are limited to 5,000 rows, and the Email domain allowlist limits which domains can receive email.
Data-driven alerts watch a dashboard tile for a change in data. An alert starts owned by its creator, who can view, edit, disable, and enable it, while other users can see and duplicate alerts marked Public. Creating alerts requires the create_alerts permission plus access to the tile and its data, and email notification also requires a scheduling permission. Folder access is separate from data access: View lets a user open folder content, while Manage Access, Edit lets a user change content and manage who else can access it.
Continue with this study guide: Create, modify, and share dashboards to answer business questions
Compare Looker and Looker Studio for different analytics use cases means choosing the right tool for governance, speed, and sharing needs. Looker (opens in a new tab) is a governed enterprise business intelligence platform that defines metrics once in a central model. Looker Studio is a no-cost, self-service reporting tool that builds fast, flexible reports directly from data sources.
Governed enterprise BI with Looker is a controlled approach where modelers define fields, metrics, and relationships once in LookML. Business users then explore data and build dashboards from those governed definitions, while developers use embedding and application programming interface (API) features to integrate analytics into tools. In every deployment, data remains in-database and is not copied to the Looker instance.
Looker combines self-serve analysis, an integrated development environment for modelers, and embedding and API features for developers. Looker is the right choice when the work needs:
Looker can be customer-managed in Google Cloud, hosted in another cloud, or hosted on customer servers. Looker (Google Cloud core) offers the same features as original Looker with deeper Google Cloud integration, including provisioning from the Google Cloud console.
Ad hoc reporting with Looker Studio is rapid, self-service reporting through a drag-and-drop editor available to anyone with a Google account. A report (opens in a new tab) is a multi-page asset that can contain charts, controls, text areas, shapes, and images. Each chart connects to a data source, and report authors define fields and aggregations inside the report or data source.
Looker Studio is the right choice when speed and flexibility matter more than central governance:
Data sources can be embedded or reusable. Embedded sources are created while editing a report and can be edited by anyone who can edit the report. Reusable sources are created from the home page, can be shared across reports, and can only be edited by people with whom the source is shared.
Looker connects to Google Cloud databases as a governed modeling layer that queries live data without storing a copy. Data flows from the database to Looker when a user runs an Explore, and Looker generates SQL against the source instead of copying tables. The Looker model in the middle defines joins, aggregates, and permissions, so every query inherits the same business logic.
Looker supports direct connections to several database services:
Looker also sends modeled results outward. Data flows from a dashboard, Look, or Explore to a Cloud Storage bucket through the Send to Google Cloud Storage action after an admin enables it. Data can also flow to Google Ads to build audiences and to Google Analytics for web and app analysis.
Looker Studio connects as a lightweight reporting layer that attaches directly to sources through named connectors. Data flows from the source directly to the report when the connector runs, which makes setup fast for ad hoc dashboards. Native connectors include BigQuery, Cloud SQL for MySQL, Spanner, Cloud Storage, Google Sheets, CSV upload, and marketing sources such as Google Analytics, Google Ads, and YouTube Analytics.
| Option | Data path | Best when |
|---|---|---|
| Looker to BigQuery, Spanner, or Cloud SQL | Database to Looker model to Explore | The use case needs shared definitions, complex joins, and controlled access |
| Looker Studio direct connector | Source system to report | The use case needs a fast dashboard with minimal setup |
| Looker Studio with Looker connector | Database to Looker model to Explore to report | The use case needs self-service charts on trusted, modeled data |
Using governed Looker models inside Looker Studio means letting a single Looker Explore become a Looker Studio data source. Data flows from the underlying database to the Looker model, then from the Explore to Looker Studio, and Looker Studio inherits the definitions and permissions from Looker. Each data source represents one Explore, but one report can combine multiple Explores even from different models.
Creating the connection follows an ordered flow with dependencies on both sides:
explore permission for the model.Explore — model.This path has strict viewer and service limits. Every viewer needs access_data and clear_cache_refresh permissions, default data freshness is 12 hours, queries time out after 5 minutes, charts are limited to 5,000 rows, and exports are limited to 75,000 rows. The connector requires a Looker-hosted instance and does not support customer-hosted instances. Every query from Looker Studio to BigQuery carries the job label requestor:looker_studio for tracking volume and billing.
Exam tip: Choose Looker when different teams must use the same governed definition of a metric, and choose Looker Studio when one person or team needs a rapid, independent report.
Continue with this study guide: Compare Looker and Looker Studio for different analytics use cases
Manipulate simple LookML parameters to modify a data model means editing settings that control what users see and how Looker queries the database. LookML parameters define views, Explores, dimensions, measures, and filters, and every change alters the SQL that Looker generates. A small edit therefore changes both the field picker experience and the rows and calculations in reports.
A dimension is a groupable field that describes a row-level attribute, such as product name, order status, user ID, or created date. Dimensions are declared inside a view with dimension: field_name plus type and sql settings, and base dimensions use sql: ${TABLE}.column_name ;; to point to a table column. In generated SQL, Looker places dimensions in SELECT and GROUP BY, and dimension filters limit rows in the WHERE clause.
A measure is a field that aggregates many rows with a SQL aggregate function, and any field computed from other measures is also a measure. Measures are declared with measure: field_name plus type and sql, and the sql often reuses a dimension with ${field_name}, such as sql: ${amount} ;; with type: sum. In generated SQL, Looker places measures in SELECT as aggregates and places filters on grouped values in the HAVING clause.
Measures commonly use these aggregate types:
COUNT for counting rows, such as total items soldSUM for totaling values, such as total sale priceAVG for averaging values, such as average sale priceMIN for finding the smallest valueMAX for finding the largest valueOther types include count_distinct and percent_of_previous. A dimension group is a shortcut that creates multiple time dimensions from one date column, such as date, week, month, quarter, and year from created_at.
| Field kind | What it describes | Main SQL effect |
|---|---|---|
| Dimension | Row-level attribute for grouping and filtering | Adds column to SELECT and GROUP BY, filters in WHERE |
| Measure | Aggregation such as count, sum, or average | Adds aggregate to SELECT, filters in HAVING |
| Filter | Limit on rows or grouped values, including filter-only input | Adds conditions to WHERE or HAVING without always adding a column |
An Explore provides the starting point for a query that users can run, and it serves as the FROM in SQL terms. Explores are listed in the Explore menu under their model name, and users build queries by selecting that Explore's dimensions and measures in the field picker. Not every view should be an Explore, because lookup views such as States are only useful when joined to a business entity like Orders.
Explores are declared in a model file with the explore parameter, which also sets the database connection and included view files. The declaration explore: orders makes Orders queryable, and nested join blocks define how other views attach to it. Each join names a view and defines its condition with sql_on, such as sql_on: ${orders.customer_id} = ${customers.id} ;;, so Looker can generate the correct LEFT JOIN only when selected fields require that view.
The full flow from LookML to SQL uses fixed components. The model selects the target database, the Explore supplies FROM, chosen dimensions and measures supply SELECT, filters supply WHERE and HAVING, and sort supplies ORDER BY. Users can inspect the result in an Explore by opening the SQL tab in the Data panel to see the exact clauses Looker sent.
Optimizing field presentation means using LookML parameters to control how values look and how fields are organized without changing the underlying data. A label controls the friendly name users see in Explores and deliveries, while a description explains what a field means and a group label places related fields under a shared heading. Together the label names the field, the description guides its use, and the group gives it a place in the picker.
value_format (opens in a new tab) is the LookML parameter that formats a type: number field with an Excel-style string. A developer adds the string to a dimension or measure, and Looker renders the stored value in that format in tables and visualizations. For example, value_format: "$#,##0.00" on total_order_amount renders 1234 as $1,234.00.
value_format_name applies a built-in or custom named_value_format instead of writing the string directly, such as value_format_name: usd on the same measure. The choice depends on reuse: use value_format for a one-time format on one field, and use value_format_name when the same named format should be shared across fields.
| Format option | How the format is defined | Example use |
|---|---|---|
| value_format | Excel-style string written in the field | value_format: "$#,##0.00" on total_order_amount |
| value_format_name | Name of a built-in or custom named_value_format | value_format_name: usd on total_order_amount |
Exam tip: Dimension filters limit individual rows in WHERE and dimensions group rows in GROUP BY, while measure filters limit grouped results in HAVING.
Continue with this study guide: Manipulate simple LookML parameters to modify a data model
GROUP BY with filters in WHERE, while measures aggregate rows with filters in HAVING.A query tile is an independent query that belongs to its dashboard and survives if its source Look is deleted, while a Look-linked tile stays connected to a saved Look in the same folder and shows an error if that Look is deleted. Choose a query tile to avoid cluttering folders and keep the tile independent, and choose a Look-linked tile when one Look should feed many dashboards so all linked tiles update together.
Use Looker for governed enterprise business intelligence with metrics defined once in a central model, and use Looker Studio for rapid self-service reporting directly from data sources without a central model. Looker is the right choice when work needs governance for key metric definitions, robust data access permissions, sharing, scheduling, and alerting, while Looker Studio is the right choice for flexible ad hoc reporting, access to more than 1,000 data sources, and one-off visualizations or reports.
A Looker Explore used as a Looker Studio data source has 12-hour default freshness, a 5-minute query timeout, a 5,000-row chart limit, and a 75,000-row export limit. Every viewer needs access_data and clear_cache_refresh permissions, the connector requires a Looker-hosted instance and does not support customer-hosted instances, and every query from Looker Studio to BigQuery carries the job label requestor:looker_studio for tracking volume and billing.
In LookML, a dimension is a groupable field that describes a row-level attribute while a measure is a field that aggregates many rows with a SQL aggregate function. Dimensions add a column to SELECT and GROUP BY with filters in WHERE, while measures add an aggregate to SELECT with filters on grouped values in HAVING.
Last updated