Data Panda lands the data from your CRM, ERP, ecommerce and finance systems in one warehouse, then lets your Looker LookML project sit on top as the semantic layer. Dashboards, Looks and embedded views read one definition of revenue, and the git history shows who changed it.
Looker was founded in January 2012 in Santa Cruz by Lloyd Tabb and Ben Porterfield, built around LookML: a modelling language that puts dimensions, measures and joins in version-controlled files instead of inside individual reports. Google acquired the company in February 2020 (announced June 2019, $2.6 billion) and folded it into Google Cloud as the modelled, enterprise side of the BI portfolio. Looker Studio is the separate free dashboarding tool from the same Google family; the two products share branding but not the LookML semantic layer or the developer workflow.
The platform splits into the Looker IDE for LookML authoring, the web app for Explores, Looks and dashboards, scheduled deliveries to email and Slack, and an embedded SDK for customer-facing analytics. It connects to roughly 40 databases, with BigQuery, Snowflake, Redshift and Postgres as the typical landing spots. The strength is that one LookML project becomes the source of truth for how a metric is calculated, with branches, pull requests and a history of who changed what. The weakness is the same one that hits Power BI and Tableau pages: if the underlying warehouse is messy, every Explore inherits the mess and BigQuery slot spend climbs with it. We curate the warehouse so the LookML layer stays declarative and compute stays in budget.
A single LookML project on a curated warehouse, feeding every Explore, Look and dashboard.
Curated warehouse tables and persistent derived tables instead of dashboards firing live joins.
Looker's AI features and Gemini in Looker answer from LookML, not from raw tables.
Embedded Looker views and the internal dashboards read the same warehouse and the same LookML.
A list of concrete reports, automations and AI features we have built on Looker data. Pick the one that matches your situation.
Why does the same measure return different numbers across our Looker dashboards?
Almost always because two LookML branches have drifted, or because one Explore reads a raw source table while another reads a curated version. With one warehouse feeding one LookML project, a measure is defined once in a view file and every Explore that uses it gets the same answer. The git history then shows when and why it last changed.
Our BigQuery bill jumped after Looker rolled out. How do we get it back in line?
Looker bills BigQuery slots for every Explore query and every PDT rebuild, so a model that joins live source tables on every click adds up fast. Moving the heavy joins into curated warehouse tables means Explores read narrow, indexed marts instead of replaying joins, and PDT refresh runs on a schedule you control. Slot usage then tracks to dashboard usage rather than to surprise traffic.
How do we keep our embedded customer dashboards in sync with the internal team's Looker?
Same warehouse, same LookML project, different Explores and access controls. Customer embeds read row-level filtered views off the same curated facts the internal team uses, so a metric change ships to both at once. The alternative, a separate model for the embedded product, is where the two stories drift and customers see one number while support sees another.
Finance gets a Looker model where revenue, margin and AR carry one definition tied back to the boekhouding. The board pack and the analyst Explore show the same number, and a measure change leaves a git diff so the next quarter does not start with a debate about who changed what.
Sales sees pipeline, win rate and forecast in one Explore that joins Salesforce or HubSpot to billing and product usage. The same numbers travel from the dashboard to the embedded view in the customer portal, so internal QBRs and customer-facing scorecards do not contradict each other.
Operations leads see throughput, SLA and cost-to-serve from the same warehouse Finance reads, and BigQuery slot usage becomes predictable instead of a monthly surprise. Looker schedules and PDT refresh land alongside the warehouse loads, not on top of live source systems.
You keep the reporting tool you already have. We connect it to the warehouse where your Looker data lives.
OAuth authentication. Read-only by default. We sign a DPA and your admin keeps the keys.
Data flows into your warehouse on your schedule. Near real time or nightly, your call. You own the data.
We build the first dashboard, workflow or AI feature with you, then hand over the keys. Or we stay on for ongoing delivery.
We set up the foundation. Your team builds on top.
Best fit Teams that already have a BI analyst or data engineer and want to own the build.
We build the whole thing, end to end.
Best fit Teams without in-house BI or dev capacity. You tell us what you need and we deliver it.
You do. It lands in your warehouse, on your cloud account. We don't resell or aggregate it. If you stop working with us, the warehouse stays yours and keeps running.
Near real time for most operational systems. For heavier sources we schedule hourly or nightly. You pick based on what the reports need.
No. If you don't have one, we help you pick one and set it up as part of the first delivery. Common starting points are Snowflake, Microsoft Fabric, or a small Postgres start.
Two different products from Google. Looker (originally founded in 2012, acquired by Google in 2020) is the modelled, paid enterprise BI with the LookML semantic layer, the developer workflow and embedded analytics. Looker Studio is the free, self-service dashboarding tool, formerly Data Studio, with no LookML. This page is about Looker. Both can read the same warehouse Data Panda builds, often side by side.
No. Looker connects to roughly 40 databases, with BigQuery, Snowflake, Redshift, Postgres and others as common landing spots. BigQuery is the most native fit since the Google acquisition, and we use it often for the BE/NL mid-market, but the LookML model itself is database-agnostic. The choice of warehouse is a separate conversation from the choice of BI tool.
Your team owns the LookML, in your git repository, with your branching model. We provide the curated warehouse views and dimensions that LookML reads from, plus the conventions for how to wire them into LookML so the developer flow stays clean. Most BE/NL clients keep an analyst or data engineer in-house as the LookML maintainer once the model is in place.
We review your Looker setup and the systems around it. Together we pick the first thing worth building.