Prepare and test your skills
Prepare and test your skills
Integration capabilities with Google Cloud Platform (GCP) describe how Looker (opens in a new tab) and Looker Studio connect to cloud data services such as BigQuery and Cloud Storage. Looker connects as a governed modeling layer that queries live databases and then sends results outward through actions. Looker Studio connects as a lightweight reporting layer that attaches directly to data through named connectors, including a special connector that can reuse a Looker model.
Looker live connections to GCP databases are modeled connections that query source 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 and access rules.
Looker supports direct connections to several GCP database services:
Choose a Looker database connection when the use case needs centralized modeling, consistent metrics, and controlled access to large or complex cloud data.
Looker outbound integrations to storage and marketing services move modeled results from Looker to other Google services. Data flows from a Looker dashboard, Look, or Explore to a Cloud Storage bucket when a user sends or schedules content with the Send to Google Cloud Storage action. A Looker admin must enable the action on the Actions page in the Admin panel, so the admin controls which destinations are available to users.
Looker also sends modeled results to Google Ads and Google Analytics for activation and analysis. Once Google Ads Customer Match is enabled in the Admin panel and authenticated with Google credentials, data flows from Looker directly to Google Ads to build data-driven audiences, which requires Looker 7.4 or later. For web and app behavior, Looker can model and visualize Google Analytics data, including Google Analytics 4 through BigQuery and Looker Blocks, and then distribute the reports to audiences without requiring every viewer to have Analytics access.
Looker Studio native connectors to GCP data are direct links from a source system to a report without a central data model. Data flows from the source system directly to the report when the connector runs a query, which makes setup fast for ad hoc dashboards and live metrics. Because there is no central modeling layer, each report owner selects fields, blends sources, and manages sharing in the report itself.
Looker Studio provides native connectors for common GCP and Google marketing sources:
Choose a direct Looker Studio connector when the priority is speed and ease of use, especially for small teams, prototypes, and marketing reports that do not need a shared semantic model.
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 Looker Studio data source represents one Explore, but one report can combine multiple Explores even from different models.
A left-to-right process flow showing how a governed Looker Explore becomes a Looker Studio data source, from admin enablement to report building with inherited definitions.
Creating the connection follows an ordered flow with dependencies on both sides:
explore permission for the model.Explore — model.This path depends on viewer credentials and service limits (opens in a new tab). Every viewer must have access_data and clear_cache_refresh permissions in Looker, the default data freshness for a Looker data source 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 also requires a Looker-hosted instance and does not support customer-hosted instances, and very large models with more than about 100 Explores can cause delays or timeouts.
Exam tip: Use the direct BigQuery connector in Looker Studio for fast, unmodeled reporting, and use the Looker connector when the report must reuse the governed fields and permissions from a Looker Explore.
Choosing an integration path in the GCP ecosystem means matching governance and effort to the analytics need. Looker database connections centralize logic and security before any visualization happens, while Looker Studio connectors prioritize direct access and quick composition across many sources. The table below compares the three main paths by data movement and fit.
| 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 | GCP source 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 top of trusted, modeled data |
In practice the paths can combine in one workflow. BigQuery stores and processes the data, Looker models it once for consistent analysis, Cloud Storage receives scheduled extracts for archiving or downstream use, and Looker Studio delivers quick or customized views either directly from BigQuery or through a Looker Explore.
Differences between governed enterprise business intelligence (BI) and ad-hoc reporting explain when to use Looker (opens in a new tab) and when to use Looker Studio. Governed enterprise BI uses Looker to create one consistent, controlled definition of metrics for the whole organization. Ad-hoc reporting uses Looker Studio, formerly Data Studio, to let individuals quickly build flexible reports and visualizations on their own.
Governed enterprise BI with Looker is a controlled approach where data modelers define fields, metrics, and relationships once in a modeling layer. Business users then explore data and build dashboards from those governed definitions, while developers can use embedding and application programming interface (API) features to integrate analytics into tools and custom applications. In every deployment, data always remains in-database and is not copied to the Looker instance.
Looker combines self-serve analysis for users, an integrated development environment (IDE) for data modelers, and embedding and API features for developers. Looker is the right choice when an organization needs control, consistency, and scale:
Looker can be managed for the customer in Google Cloud, hosted in another cloud service, or hosted on the customer's own servers. Looker (Google Cloud core) (opens in a new tab) offers all the same features as the original Looker, but with deeper Google Cloud integration, including the ability to provision and administer instances from the Google Cloud console.
Ad-hoc reporting with Looker Studio is rapid, self-service reporting through a no-cost tool with a drag-and-drop editor. Looker Studio is a Google Cloud service that is available to anyone with a Google account, so a user can connect data and build a report without a centrally managed BI instance. Each report is built from components (opens in a new tab) such as pages, charts, controls, text, shapes, and images that can be styled or associated with a data source.
Looker Studio is the right choice when speed and flexibility matter more than central governance:
Data sources in Looker Studio can be embedded or reusable. Data sources created while editing a report are embedded in that report, and anyone who can edit the report can also edit the data source and its connection. Data sources created from the home page are reusable across different reports, which helps share a consistent data model, and only people with whom the reusable data source is shared can edit it.
Choosing between Looker and Looker Studio depends on who defines the logic, how consistency is enforced, and how the result is shared. Looker centralizes definitions and permissions before users explore, while Looker Studio lets report authors define fields and aggregations inside the report or data source. The comparison below shows the decision in terms of logic and fit.
| Platform | How logic is defined | Choose when |
|---|---|---|
| Looker | Data modelers define metrics and access rules centrally, and users explore from those definitions with data staying in-database | The work needs a single source of truth, controlled permissions, scheduled sharing and alerting, or embedded and operational analytics |
| Looker Studio | Report authors connect directly to one or more sources and define fields and aggregations inside the report or data source | The work needs a fast, one-off visualization, an interactive dashboard, or exploration across many different sources |
The ownership boundary is the key difference. Looker ownership sits with modelers who govern definitions for all teams, while Looker Studio ownership sits with the individual report author who controls one report.
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 from a single or pre-aggregated source.
Evaluation of core features and user interfaces compares how Looker (opens in a new tab) and Looker Studio build and share visualizations. Looker is a governed business intelligence platform that builds visualizations from centralized data models, while Looker Studio is a self-service reporting tool that builds flexible, multi-page reports from one or more data sources. The two tools connect through the Looker connector, which lets a Looker Explore serve as a data source inside a Looker Studio report.
Looker core features organize analysis around a modeled layer that controls how data is defined and queried. LookML (Looker Modeling Language) is a language for describing dimensions, aggregates, calculations, and data relationships in a SQL database, and the Looker app uses a model written in LookML to construct SQL queries against a particular database. A database connection defined in the Admin section supplies the underlying data, and the LookML model determines which fields and joins are available to users.
Analysis in Looker flows from the model to the user in a fixed order. First, a user opens an Explore and selects dimensions and measures from the field picker to build a query. Then, the user can save that single query table or visualization as a Look. Finally, one or more Looks can be added to a dashboard, which is a collection of saved queries displayed as visualization or text tiles together on one page. Any change made to a Look is reflected in any dashboards that contain it, so the Look remains the single source for that visualization.
Looker Studio core features center on reports (opens in a new tab) that present information and insights derived from data. A report is a Data Studio asset that can contain multiple pages, charts, and other components such as controls, text areas, shapes, and images. Reports derive their data from one or more data sources, including BigQuery data sources and Looker Explores added through the Looker connector.
When a Looker Explore is added as a data source, data flows from the Explore in Looker to the report in Looker Studio. Data Studio displays the list of fields associated with that Explore, and report editors work with those fields to build charts. From that field list, editors can perform related management tasks:
Reports can be shared with view-only access or with edit access that allows others to change the report structure. Every query sent from Looker Studio to BigQuery includes the job label requestor:looker_studio, which allows administrators to track query volume and billing costs for Studio activity.
User interfaces and usability differ because Looker is built for governed exploration and Looker Studio is built for free-form visual storytelling. The Looker user interface lets business users and developers browse Explores, pick fields, filter queries, and assemble user-defined dashboards by adding query tiles, Look-linked tiles, or text in the interface and arranging them with drag-and-drop operations. Developers also use Development Mode and version-controlled project files to create and test LookML, so modeling changes do not affect other users until they are deployed to production.
The Looker Studio user interface centers on a free-form report canvas where editors add pages, place charts and controls, add text, shapes, and images, and connect each chart to a data source. Sharing is simple: a report can be viewed by others or opened for collaborative editing of its structure. This makes Looker Studio easier for quick, visual storytelling across multiple pages, while Looker provides more structure for consistent metrics and reusable content.
Looker supports two dashboard types that reflect this split between self-service and developer control:
| Characteristic | User-Defined Dashboard | LookML Dashboard |
|---|---|---|
| Generally created by | Business users and Looker developers | A select group of LookML developers |
| Defined in | User interface with drag-and-drop tiles, filters, and options | YAML-based dashboard file written in LookML |
| Stored in | Personal folder or shared folder for collaboration | Version-controlled files in a Git repository |
Choosing a tool for visualizations and dashboards depends on governance needs, creator skills, and report structure. Looker fits teams that need centralized definitions, reusable Looks, and dashboards where every tile follows the same LookML logic. Looker Studio fits teams that need multi-page reports, mixed layouts with text and images, and fast sharing with view or edit access.
Use Looker when the priority is a governed Explore and consistent dashboards built from saved Looks. Use Looker Studio when the priority is a flexible report that combines charts, controls, and narrative elements from one or more data sources. When both are needed, keep the definitions in Looker and use the Looker connector (opens in a new tab) to bring that governed Explore into Studio for presentation.
Exam tip: A Look is one saved query or visualization, a Looker dashboard is a collection of Looks and query tiles, and a Looker Studio report is a separate multi-page asset that can use a Looker Explore as a data source.
Use Looker when the work needs a single source of truth, controlled permissions, scheduled sharing and alerting, or embedded and operational analytics. Use Looker Studio when the work needs a fast, one-off visualization, an interactive dashboard, or exploration across many different sources.
Looker queries Google Cloud Platform (GCP) databases live by generating SQL from a central Looker Modeling Language (LookML) model, so data stays in-database and every Explore inherits the same joins, metrics, and permissions. Direct connections are supported for BigQuery, Spanner, Cloud SQL for MySQL, and Cloud SQL for PostgreSQL.
A single Looker Explore can become a Looker Studio data source through the Looker connector, with data flowing from the underlying database to the Looker model and then to Looker Studio while inheriting definitions and permissions from Looker. The creator selects the Looker connector, enters the instance URL, selects a model and Explore, and adds the resulting source to a report. The Looker data source has a default data freshness of 12 hours, a 5-minute query timeout, a 5,000-row chart limit, and a 75,000-row export limit.
A Look is one saved query table or visualization, a Looker dashboard is a collection of saved Looks and query tiles displayed together on one page, and a Looker Studio report is a separate multi-page asset that can use a Looker Explore as a data source. Any change made to a Look is reflected in any dashboards that contain it, while Looker Studio reports derive data from one or more data sources and present information with pages, charts, controls, text, shapes, and images.
An enterprise organization wants to standardize key business metrics—such as total revenue and customer churn—across all departments. The data analytics team needs a platform that provides a centralized, version-controlled semantic modeling layer to define dimensions and measures in code, establishing a single source of truth and enforcing robust data governance.
Which business intelligence tool should the organization implement?
Last updated