Looker
Also known as: LookML, Google Looker, Looker Studio, Google Data Studio, Looker BI
Looker is a business intelligence and data analytics platform acquired by Google in 2020, now part of Google Cloud.
Its defining characteristic is LookML: a modelling layer where data engineers define metrics, dimensions, and relationships in code. All Looker reports and dashboards are built on top of this centralized model, ensuring every user is looking at consistent, governance-controlled definitions of key metrics. Looker's data-model-first approach contrasts with drag-and-drop BI tools: it is more code-forward and requires more upfront model development, but provides stronger metric governance in return. It is primarily adopted by data-mature, cloud-first organizations.
Looker, explained at three levels
At home
Looker is a business intelligence tool that business users access through a web browser to explore data and create reports. Unlike some BI tools where anyone can define metrics however they want, Looker works from a central data model where data engineers have pre-defined what 'revenue', 'active user', or 'conversion rate' means for your company. This means every report uses the same definitions: when the CEO and the product manager both look at 'monthly active users', they're seeing the same number calculated the same way.
At work
Looker is most commonly found in cloud-first technology companies with established data engineering teams. Its strength is metric consistency: one data team defines how metrics are calculated in LookML, and everyone in the company explores data within those guardrails. This eliminates the common organizational problem of different teams reporting different numbers for the same metric because they built their own reports with their own definitions. Looker is typically implemented by companies who have invested in a cloud data warehouse (Snowflake, BigQuery, Redshift) as their analytics foundation.
At home
LookML is the modelling layer at Looker's core: a SQL-adjacent language where data engineers define dimensions (attributes), measures (aggregations), and explores (joinable tables) that business users can drag into Looker's report builder. A LookML dimension might define 'is_active_user' as a user who has logged in within the past 30 days; every report that uses 'active users' will use this exact definition. Version-controlling LookML in git provides auditability for metric definition changes, a powerful governance capability absent from click-and-build BI tools.
At work
Looker's embedding and API capabilities are advanced: the Looker API exposes virtually every Looker function programmatically (run queries, download results, create users, manage content). This is used for: embedding Looker dashboards in customer-facing products (white-labelling analytics), automating report distribution, building custom data applications on top of Looker's query engine, and integrating Looker outputs with other business workflows. Looker's API richness makes it a popular choice for engineering-led organizations building data products.
At home
Looker's performance model queries the underlying data warehouse live (rather than using a local data extract like Tableau). This means Looker inherits the performance of the data warehouse: a well-optimized BigQuery or Snowflake environment provides fast Looker queries; a poorly optimized warehouse makes Looker slow. Aggregate awareness in LookML allows Looker to automatically route queries to pre-aggregated summary tables when the query matches, dramatically improving performance for common queries. PDTs (Persistent Derived Tables) are LookML-defined computed tables that are materialized in the warehouse for performance.
At work
The Looker vs. semantic layer debate: Looker pioneered the 'semantic layer' concept (centralized metric definitions in code). The broader industry has adopted this concept with standalone semantic layer tools (the dbt Semantic Layer, AtScale, Cube) that sit between the data warehouse and any BI tool. These tools allow organizations to use any BI tool (Power BI, Tableau, Looker, Excel) on top of a centralized metric definitions layer, avoiding vendor lock-in to Looker's LookML. The semantic layer concept has arguably had more influence on the industry architecture than Looker's market share alone would suggest.
Real-world examples
At home
Nadia worked at a SaaS startup that had grown to the point where sales and product were reporting different monthly active user numbers from different dashboards. After implementing Looker with a LookML model that defined 'active user' precisely (logged in within 30 days, not a test account, subscription active), every dashboard that used the 'active users' metric pulled from the same definition. The numbers aligned across all reports, and the Monday board meeting stopped starting with 'which number is right.'
At work
Sophie was a data engineer at a company with 150,000 customers. She built a Looker embedded analytics product: each customer logged into the company's web app and saw a Looker dashboard showing their own account metrics, embedded directly in the product UI. Looker's user attributes feature scoped each customer's view to their own data. The data team maintained one LookML model; the product team maintained the embedding integration. The company launched a premium analytics tier using this infrastructure without building a custom visualization layer.
Common confusions
- Many people confuse Looker and Looker Studio (formerly Google Data Studio) as the same product — Looker and Looker Studio are two distinct Google analytics products at different price points and for different use cases. Looker is the enterprise BI platform with LookML semantic modelling, governed by Google Cloud, and priced at enterprise contract rates. Looker Studio is a free, consumer-grade dashboard builder for simple visualizations connected to Google Sheets, Google Analytics, BigQuery, and other sources. Looker Studio is appropriate for simple marketing dashboards; Looker is appropriate for enterprise analytics governance. The shared 'Looker' branding creates persistent confusion.
- Some data teams assume Looker replaces the data warehouse transformation layer (dbt, Spark) — Looker queries the data warehouse; it does not replace the data preparation and transformation work that happens in the warehouse. LookML defines how to query data that already exists in the warehouse; it does not transform raw source data into analytics-ready tables. A modern data stack uses dbt (or Spark) to transform raw data into clean, modelled tables in the warehouse, then uses Looker (or another BI tool) to query those clean tables. LookML handles the final metric definition layer; dbt handles the upstream data modelling.
For analysts
When a client is evaluating Looker, the prerequisites to check are: cloud data warehouse in place (Snowflake, BigQuery, or Redshift; Looker's performance and integration is optimized for modern column-store databases, not legacy MySQL or SQL Server); data engineering capacity to build and maintain LookML (Looker requires ongoing model maintenance as business logic evolves); and a real metric governance problem that justifies Looker's complexity over simpler alternatives. Looker is the right choice for data-mature organizations with metric consistency problems; it is over-engineered for organizations that just need dashboard sharing.
History & origin
Looker was founded in 2012 by Lloyd Tabb (previously an engineer at Netscape and CTO of LiveOps) with a core thesis that BI tools should be built around a governed semantic model, not individual report builders. LookML (Looker Modeling Language) defined this model-first approach: data engineers define business logic in LookML, and business users explore the data within those defined parameters. Looker grew to become the preferred BI tool for companies with sophisticated data engineering teams and modern cloud data warehouses (Snowflake, BigQuery, Redshift). Google acquired Looker for $2.6 billion in 2020, integrating it with Google Cloud's data platform (BigQuery). The post-acquisition period focused on integrating Looker with the Google ecosystem and building a Looker Studio (formerly Google Data Studio) integration. As of 2023-2025, Looker and Looker Studio serve different segments of Google's BI strategy.