A first, simple picture, and a warning about two similar names.

Business intelligence, often shortened to BI, means turning raw data into charts, tables and reports that help people make decisions. A dashboard is a single screen that shows the most important numbers and charts, like the instrument panel of a car. BI tools connect to data, let people explore it, and show the results in a way that is quick to understand.

Looker Studio is a free, web-based tool for creating reports and dashboards. You connect it to a data source such as a spreadsheet or Google’s data warehouse, drag charts onto a page, and share the result with a link, much as you share a document. It was previously called Google Data Studio and was renamed in 2022. It is quick to learn and ideal for individuals, small teams and marketing reports.

Looker is a larger enterprise platform. Its main idea is a semantic layer, a central place where the company’s data experts define what each business term means, such as “revenue” or “active customer,” once and in code. Everyone who then builds a chart in Looker automatically uses that same definition. Looker also offers governed dashboards, embedded analytics for customer-facing products, and powerful tools for developers and administrators.

A short history

Looker was founded in 2012 and became known for a modelling language called LookML and for running queries inside the customer’s own database instead of copying data elsewhere. Google announced that it would acquire Looker in 2019, and the purchase was completed in early 2020. Since then Looker has been rebuilt to run natively in Google Cloud, with Google Cloud security, networking and billing options. Looker Studio began life as Google Data Studio in 2016 as a free product built on Google’s marketing and analytics tools, and grew into a general reporting tool with hundreds of data connectors.

Why companies with plenty of data still argue about the answer.

Step 1: The spreadsheet era

Many companies start with spreadsheets. Someone exports data from a system, adds formulas and emails the file. Spreadsheets are flexible and familiar, but every copy becomes its own version of the truth. When the formulas differ slightly or the data was exported on different days, two people can reach different answers from the same source.

Step 2: Dashboards everywhere

The next stage is that each team builds its own dashboards in its own tool. Marketing counts a “customer” when someone signs up, finance counts only people who have paid, and support counts anyone who has ever opened a ticket. All three charts are labelled “customers” and all three are correct for their own definition, yet nobody can compare them.

Step 3: Slow requests to the data team

When trust breaks down, people ask a small data team to produce every report. That team becomes a bottleneck with a long queue of requests, while business users wait days for simple answers. The result is slow decisions, frustrated analysts and many one-off reports that nobody maintains.

A small data vocabulary that makes the rest of the guide easy.

Data warehouse and source systems

Companies keep data in many source systems, such as a sales application, a payments service, a website analytics tool and an advertising account. Teams usually copy this data into a data warehouse, a big database built for analysis. In Google Cloud the main data warehouse is BigQuery, a service that can scan huge tables quickly using ordinary SQL, the standard language for asking questions of data.

Two ways to use data: copy it or query it live

Some BI tools first copy data into their own storage, called an extract, and answer questions from the copy. Copies are fast but can go stale and create another place to secure. Other tools send a fresh question to the original database each time, called a live query. This keeps data current and avoids copying, but the database must be able to answer quickly. Looker is built around live queries. Looker Studio can do both: it queries live by default and also offers cached results and optional extracts.

Data flows from your sources, into a warehouse, and out through the BI tools to people and applications.

flowchart LR
  SRC["Data sources: apps, files, ads, analytics"] --> BQ["BigQuery and other databases"]
  BQ --> LK["Looker: governed semantic layer and dashboards"]
  BQ --> LS["Looker Studio: quick self-service reports"]
  LK --> LS
  LK --> EMB["Embedded analytics in your applications"]
  LK --> USR["Business users"]
  LS --> USR
    

Reading the diagram

On the left are the places where data is born. A data pipeline brings it into BigQuery or another database, where it is cleaned and organised. From there, two roads lead to people. The first goes through Looker, where central definitions turn raw tables into trustworthy business terms. The second goes directly into Looker Studio for fast, flexible reports. A third line shows that Looker can also feed Looker Studio, so team-level reports can reuse the governed definitions. Looker can also place charts inside your own customer-facing products, which is called embedded analytics.

The role of each Google Cloud piece

The fast road from data to a shareable dashboard.

Three building blocks

Looker Studio has three main objects. A connector is the bridge that knows how to talk to one type of data, such as BigQuery, Google Sheets or Google Analytics. A data source is a saved connection to one particular table or file, together with a list of its fields and their types. A report is the canvas that holds pages, charts, filters and text, and it reads from one or more data sources.

flowchart LR
  C1["Connectors: BigQuery, Sheets, Analytics, Ads, files"] --> DS["Data source: fields and credentials"]
  C2["Partner connectors for other applications"] --> DS
  DS --> RP["Report: pages, charts, filters, controls"]
  RP --> V["Viewers: shared link, email, embed"]
  DS -.-> CR["Credentials: owner or viewer"]
    

The connector families

From zero to a first report

The features that separate a quick chart from a reliable report.

Calculated fields and parameters

A calculated field is a new column created inside the report by a formula, such as profit equal to revenue minus cost. It is quick, but remember that the formula lives only in that data source. If ten reports need profit, ten people may write it ten slightly different ways, which is exactly the problem Looker’s semantic layer addresses. A parameter is a value that viewers can change, such as an exchange rate or a target, and formulas can use it.

Blending data

A blend joins data from several data sources inside the report, such as ad spend from one connector and sign-ups from another, matched by date or campaign. Blends are handy for quick comparisons, but they are done by the tool at view time, so large or complex blends can be slow and hard to check. For repeated, important joins, it is usually better to prepare the joined table in the warehouse.

Freshness and caching

When someone opens a report, Looker Studio asks the data source for numbers. To avoid asking again and again, it keeps a short-lived cache, a saved copy of recent results. A data freshness setting decides how long cached results may be reused before a new question is sent. A short time means newer numbers but more load and cost, while a longer time is faster and cheaper. For BigQuery sources, a feature called BI Engine can keep hot data in memory to speed up dashboards further.

Credentials: whose permission is used?

This is one of the most important ideas in Looker Studio. Each data source has a credential setting that decides whose access is used when someone views the report.

Handy extras

• Community visualizations add new chart types made by other developers.
• Embedding places a report inside a web page or internal portal.
• Scheduled emails send a PDF of the report to chosen people on a regular schedule.
• Templates let you copy a good design and replace its data source in a few clicks.

When a free personal tool needs to behave like an organisation tool.

Why Pro exists

The free version ties reports to the personal accounts of their creators. When an employee leaves, their reports can be lost or become orphaned, and administrators have limited control. Looker Studio Pro is a paid subscription that adds organisational features: reports and data sources can be owned by a team workspace or a Google Cloud project instead of a single person, administrators can manage access centrally, and support options are included.

Governance habits even for the free tool

The parts of a Looker instance, and how they work together.

A Looker deployment is called an instance. It is a web application that people open in a browser or reach through embedded pages and programs. The key design decision is that Looker does not keep a big copy of your business data. Instead, it holds the instructions for how to ask your database questions, and it sends those questions live, every time. Think of Looker as a very skilled translator standing between business people and the database.

flowchart TD
  U["User browser or embedded application"] --> LS["Looker server application"]
  LS --> ML["LookML project in Git: models and views"]
  LS --> BD["Looker internal database: users, content, settings"]
  LS -->|"generated SQL over a database connection"| DB["Your database: BigQuery, Cloud SQL, others"]
  DB -->|"result rows"| LS
  LS --> CA["Query cache"]
    

The components

Looker as a Google Cloud service

The current Google Cloud edition is often called Looker (Google Cloud core). You create an instance from the Google Cloud console, choose an edition and region, and configure how it is reached from the network. Google operates the underlying machines, handles patching and keeps the internal database healthy, while you manage the model, users and content. Older Looker deployments hosted outside Google Cloud still exist, so documentation sometimes distinguishes between the two.

The language that makes every number mean the same thing.

LookML is Looker’s modelling language. It is not used to draw charts. It is used to describe your data: which tables exist, how they connect, which columns are dimensions, and how each measure is calculated. Because it is plain text, it can be reviewed, versioned and tested like software. Once a measure such as “total revenue” is defined in LookML, every chart, dashboard and report in Looker uses that same definition.

flowchart TD
  P["LookML Project"] --> MD["Model file: which database connection and which explores"]
  MD --> E["Explore: starting table plus joins"]
  E --> V1["View: orders"]
  E --> V2["View: customers"]
  V1 --> DM1["Dimensions: order date, status"]
  V1 --> MS1["Measures: total revenue, order count"]
  V2 --> DM2["Dimensions: country, segment"]
    

The main LookML objects

Why this approach is powerful

• Define once, use everywhere: fix a formula in one place and every dashboard updates.
• DRY principle: short for “do not repeat yourself.” Shared pieces avoid copies that drift apart.
• Human-friendly names: technical column names become labels and descriptions that business people understand.
• Reviewable: a change to how revenue is calculated goes through a code review, with a history of who changed it and why.
• Reusable packages: prebuilt models, called blocks, can be imported for common sources.

The three everyday objects of a Looker user.

Explore: ask your own questions

An Explore is a point-and-click workspace. On the left is a list of fields, grouped by view, with plain descriptions. The user ticks the dimensions and measures they want, adds filters, and chooses a chart. Behind the scenes Looker writes the SQL. The user never sees joins or table names, only business terms.

Look: a saved question

A Look is a single saved query with its chart. It is like bookmarking a favourite search. Looks can be shared, scheduled for email delivery and reused as tiles on dashboards.

Dashboard: a collection of tiles

A dashboard arranges many tiles on one screen. Dashboard-level filters, such as a date range or a region, can apply to all tiles at once. Users can click a number to drill into the details behind it, which is called drilling. Dashboards can be refreshed automatically and delivered on a schedule.

Handy features for users

Follow one click from the browser to the database and back.

sequenceDiagram
  participant U as Business User
  participant L as Looker Server
  participant M as LookML Model
  participant DB as Database
  U->>L: Choose fields and filters in an Explore
  L->>M: Look up definitions and join rules
  M-->>L: Field SQL and access rules
  L->>L: Build SQL and apply user permissions
  L->>DB: Run the generated SQL
  DB-->>L: Return result rows
  L-->>U: Show chart or table and keep in cache
    

Why the generated SQL matters

The SQL that Looker writes is visible to developers and analysts through a SQL tab on every query. This transparency builds trust, because experts can see exactly what was asked, and helps with tuning, because slow queries can be copied into the database tools for inspection. Since the heavy work happens in the database, a powerful warehouse such as BigQuery lets Looker handle very large data sets without Looker itself needing to be large.

How Looker avoids a famous mistake that silently doubles numbers.

The fan-out problem

Suppose one order contains three items. If you join an orders table to an items table, the order now appears three times, one for each item. If each order row has a shipping fee of ten dollars, adding up the fee across the joined rows reports thirty dollars instead of ten. This silent double counting is called fan-out, and it has misled many reports in many tools.

Symmetric aggregates

Looker prevents fan-out using a technique called symmetric aggregates. If the model says which column uniquely identifies each row, called a primary key, Looker automatically adjusts its SQL so that each original row is counted only once, even after joins. As a result, business users get the right number without needing to understand joins at all. The key requirement for developers is to define primary keys correctly.

Derived tables

Sometimes the data is not in the shape you need. A derived table is a table that Looker builds from a query instead of reading directly. For example, a table that lists each customer with their first order date and lifetime value is a good derived table. There are two kinds.

Persistent derived tables

A normal derived table is calculated every time it is used. A persistent derived table, or PDT, is calculated once and stored in a scratch area of the database, then rebuilt on a schedule or when new data arrives. PDTs make expensive logic fast for users. The trade-off is storage cost, the need to manage rebuild timing, and the risk of stale numbers if rebuilds are missed.

Making dashboards feel instant without making data stale.

Looker’s cache

By default, Looker keeps query results for a limited time, often an hour, and reuses them for identical questions. You can control this with datagroups, which tie caching and rebuilds to real events. A datagroup might check a small query such as “what is the latest load timestamp in the sales table?” When the answer changes, because new data arrived, Looker empties the related cache and rebuilds the related PDTs. Between loads, users get lightning-fast answers. After a load, the next user sees fresh numbers.

Aggregate awareness

Many questions ask for totals by month or by country, and scanning every individual order to answer them is wasteful. Aggregate awareness lets developers define small summary tables, and Looker automatically uses the smallest summary that can answer a question. Users do not choose anything. They simply experience faster dashboards.

Speed-up tools

Performance habits for Looker Studio

• Prefer one prepared table or view in BigQuery over many blends inside the report.
• Choose a sensible data freshness period rather than the shortest one.
• Limit the number of charts on one page, because each chart can send its own query.
• Set a default date range so the first view does not scan all history.
• Use extracted data for small, rarely changing sources.

How a team changes the model without breaking dashboards that everyone relies on.

Development mode and production mode

Looker lets each developer switch into development mode, where they work on a private copy of the model. Users in normal production mode do not see these changes. When the developer is happy, they commit the changes to Git, ask for review if the team uses a review process, and deploy to production. This separation means that experiments never disturb the numbers on the executive dashboard.

Practices that keep models healthy

Taking analytics out of the Looker website and into the places where people already work.

Embedded analytics

Embedded analytics means placing Looker charts and dashboards inside another application, such as a customer portal or a software product. A shipping company might show each customer a dashboard of their own deliveries inside the company’s own website. The customer never sees the name Looker, and sees only their data.

sequenceDiagram
  participant C as Customer in Your App
  participant A as Your Application Server
  participant L as Looker
  C->>A: Open the analytics page
  A->>A: Build signed embed URL with user identity and attributes
  A-->>C: Return signed URL
  C->>L: Load embedded dashboard using the URL
  L->>L: Verify signature and apply row-level rules
  L-->>C: Show only that customer's data
    

Ways to embed

The programming interface

Looker offers an API, a way for other programs to ask Looker to do things automatically: run queries, create users, update content or trigger schedules. Official client libraries exist for popular languages. Teams use the API to create users automatically when customers sign up, to download data on a schedule, and to build custom tools.

Actions and the scheduler

• Scheduled delivery sends dashboards and Looks to email, chat tools, file stores or web addresses on a timetable or when a condition is met.
• Actions let users send data from Looker to another service, such as creating a task, updating a customer record or sending a message, directly from a chart.
• Webhooks notify other systems whenever a scheduled result is ready.

How a Looker instance is created, reached and kept running in Google Cloud.

Creating an instance

In the Google Cloud console you create a Looker (Google Cloud core) instance by choosing a name, a region and an edition. Editions bundle features and user types, and they usually include a standard level for internal reporting, an enterprise level with extra scale and security options, and an embed level for customer-facing analytics. Because packaging and names change, always confirm the current list on Google’s website. After creation, you set up sign-in and invite your first administrators.

Network access options

What Google manages and what you manage

Analytics tools see sensitive data, so they need layers of protection.

Looker’s permission layers

Looker uses several layers that work together. Authentication proves who a person is, using Google sign-in, SAML or OpenID Connect. Groups and roles then decide what that person may do. A role combines a permission set, which lists actions such as “create dashboards” or “develop LookML,” with a model set, which lists which models the person may use. Finally, row and field rules decide which data appears inside the content.

Row-level security example

A company has regional managers. In the model, a user attribute called “region” is set for each manager, and an access filter links the sales table’s region column to that attribute. When the manager for Europe opens any sales dashboard, Looker silently adds “region equals Europe” to every query. The same dashboard shows different numbers to different people, and nobody can remove the rule from the screen.

Protecting the instance itself

• Encryption: data is encrypted at rest and in transit by default. Customer-managed encryption keys are available for organisations that must control their own keys.
• Network controls: private access, allowed ranges and perimeter controls such as VPC Service Controls reduce exposure.
• Service accounts: the database connection should use an account with the narrowest access that still works.
• Audit trails: Looker’s built-in activity data and Google Cloud audit logs show who did what.
• Download and sharing limits: restrict exports for highly sensitive data.

Security in Looker Studio

Looker Studio relies on sharing settings and credentials. Share with named people or groups rather than public links for any private data. When using viewer credentials with BigQuery, row access policies, authorized views and column-level controls in BigQuery enforce what each viewer sees. Administrators in Google Workspace and Google Cloud can limit external sharing and control which community connectors are allowed.

Making sure the numbers are not only available, but right and trusted.

What governance really means

Data governance means agreeing who owns each piece of data, what it means, who may use it and how its quality is checked. It sounds heavy, but in BI it comes down to a few daily habits: one definition per metric, clear owners, visible quality checks and a way to find trusted content.

Tools that support governance

The “single source of truth” idea

A single source of truth does not mean one dashboard for everything. It means one agreed definition for each important number, wherever it appears. Looker’s model is a natural home for these definitions. Looker Studio can then read from Looker’s models, so that team-level reports still use company-level meaning.

Asking questions in plain language, with the semantic layer keeping the answers honest.

Google has added generative AI features, under the Gemini name, to both Looker and Looker Studio. Features differ by product, edition and release stage, and they change quickly, so treat the following as the general shape rather than a final list.

Conversational analytics

With conversational analytics, a person types a question such as “What were sales by region last quarter, and which region grew fastest?” The AI turns the question into a query against Looker’s governed model. Because the model already defines what “sales” means and who may see which rows, answers use the company’s official definitions and respect permissions. This is a big advantage compared with AI tools that guess table meanings from column names alone.

Assistants for builders

Using AI wisely

• Treat AI answers as a starting point. Check important numbers against a trusted dashboard.
• Keep field descriptions clear, because the AI reads them to understand meaning.
• Rely on row-level and field-level rules so that AI questions cannot reveal data a user could not see otherwise.
• Check admin controls to see who may use AI features and how data is handled, in line with your policies.

Knowing who uses what, what is slow and what is costly.

Looker’s own activity data

Looker records its own activity in a built-in set of Explores called System Activity. Administrators can ask questions such as which dashboards are opened most, which queries are slowest, who logged in this week and which scheduled deliveries failed. This data helps retire unused content, find heavy queries and prove the value of the platform to leaders.

Google Cloud tools

A weekly monitoring routine

What you pay for, and where bills tend to grow.

The pieces of the bill

How to keep costs under control

• Use licences wisely: give viewer-level licences to people who only read dashboards, and keep developer licences for the few who build models.
• Cache and summarise: datagroups, aggregate tables and BI Engine reduce repeated scanning.
• Partition tables by date and always filter by date in default dashboard views.
• Limit auto-refresh: match refresh to decision speed.
• Set quotas and alerts in BigQuery so a runaway query does not create a surprise bill.
• Use reservations for steady, predictable BI workloads when on-demand pricing becomes uneconomic.
• Clean up unused dashboards that keep running scheduled queries.

A practical guide, and the case for using both together.

flowchart TD
  S["What do you need?"] --> Q1{"One governed definition of metrics for the whole company?"}
  Q1 -->|"Yes"| LK["Use Looker"]
  Q1 -->|"No"| Q2{"A quick, free dashboard from a few sources?"}
  Q2 -->|"Yes"| LS["Use Looker Studio"]
  Q2 -->|"No"| Q3{"Analytics inside a customer-facing product?"}
  Q3 -->|"Yes"| EM["Use Looker embedding"]
  Q3 -->|"No"| BT["Start with Looker Studio and grow later"]
    

Using them together

The two tools complement each other. A common design puts governed definitions in Looker and lets people who prefer a simple canvas build their own reports in Looker Studio on top of Looker’s models, using a connector that reads the Looker semantic layer. Finance gets governed dashboards in Looker, while a regional team builds a custom summary in Looker Studio, and both use the same definition of revenue.

flowchart TD
  W["Warehouse: BigQuery"] --> LM["Looker semantic layer: LookML models"]
  LM --> LD["Looker dashboards for governed reporting"]
  LM --> LC["Looker connector in Looker Studio"]
  LC --> SR["Studio reports for team-level needs"]
  LM --> API["Looker API and embedding"]
  API --> APP["Customer-facing application"]
    

Putting every idea together in one realistic story.

A retail company with online and physical stores has a data team of five people and about two hundred business users. Marketing, finance and store operations each keep their own spreadsheets, and leaders are tired of arguing about numbers. The team decides to modernise.

The result after six months

Leaders open one dashboard and trust the revenue figure. Store managers see only their store. Marketing reports are quick to build and use the same definition of revenue. Suppliers see their data without emailing spreadsheets. The data team spends less time answering routine requests and more time improving the model, and the number of arguments about “whose number is right” falls sharply.

An honest look at both products.

The trade-offs in plain words

• Speed versus trust: quick reports come first in Looker Studio, but trusted shared definitions come from Looker.
• Freedom versus control: open canvases allow creativity, and governed models prevent chaos.
• Upfront work versus long-term savings: modelling takes time at the start but saves rework every month afterwards.
• Live versus cached: live queries are current and cost warehouse compute, while caching saves cost and may show slightly older numbers.

Habits that work, and traps that catch many teams.

Patterns that work

Anti-patterns to avoid

A checklist for a healthy analytics practice.

Best practices

Common mistakes

A troubleshooting path

Where these tools show up in practice. These are illustrative patterns, not named customer claims.

A quick reference to return to whenever a word feels unfamiliar.

Quick answers to the questions that beginners ask most often.

No. Looker Studio is a free, quick reporting tool. Looker is an enterprise platform built around a governed semantic layer. They are separate products that can work together.

It was renamed Looker Studio in 2022. It remains a free reporting tool, with a paid Pro tier added for organisations.

Looker stores model definitions, users and saved content, plus short-lived cached results. Your business data stays in your own database, which Looker queries live.

Business users do not. Developers who write LookML benefit from knowing SQL. Looker Studio users can build charts without SQL, though calculated fields and blends are easier with some SQL knowledge.

Looker connects to many popular databases and warehouses, with BigQuery being the most common on Google Cloud. Check the current list of supported dialects before planning.

Yes. A Looker connector lets Looker Studio read from Looker’s governed models, so reports use the same metric definitions.

Use Looker’s embedding with user attributes and access filters. Your application passes the customer’s identity in a signed address, and Looker adds the filter to every query.

A join is probably multiplying rows, called fan-out. In Looker, check primary keys so symmetric aggregates can work. In Looker Studio, check blends and the level of detail of your data.

Reduce data scanned with partitioning and default date filters, use caching and summary tables, consider BI Engine on BigQuery, and keep the number of charts per page reasonable.

It can be, if you share with named people, use viewer credentials where needed and enforce row and column rules in the warehouse. Avoid public links and owner credentials for sensitive data.

Gemini-based features can answer questions in plain language and help build content. They work best on well-described, governed models, and their results should be checked for important decisions.

Start with Looker Studio on a prepared BigQuery table to learn the basics. When metrics and teams multiply and numbers begin to conflict, introduce Looker and a semantic layer.

The whole story in a few lines before you go.

Looker and Looker Studio solve the same human problem from two directions. One gives teams a fast, friendly canvas for turning data into reports. The other gives the whole company a trusted dictionary of metrics, strong security and the power to embed analytics inside products. Used together on top of a clean warehouse such as BigQuery, they let people move quickly without arguing about whose number is right.