Looker Studio has no Shopify connector, and Shopify has no database to connect. Everything here is about what you put in the middle.
Google's built-in connectors cover databases and its own products: BigQuery, Sheets, MySQL, PostgreSQL. Shopify is none of those. So a Shopify dashboard always involves a third thing — a community connector, a warehouse you loaded, or a spreadsheet someone maintains.
Community connectors are the quick answer and they work, but they inherit the Admin API's limits. Long date ranges get slow, some hit quotas mid-refresh and simply return less data than you asked for, and a chart that silently under-reports is worse than one that errors. They're also almost all paid, per store.
The alternative is to land the data somewhere Looker Studio speaks natively and point at that. This is the route that keeps working as the store grows, because the dashboard is then querying a database rather than an e-commerce API — but it means you've taken on the warehouse or the copy first, which is a bigger decision than picking a connector.
All three put a Shopify dashboard in Looker Studio. They differ in what sits between the store and the chart.
A third-party Shopify connector from the Looker Studio gallery, reading the Admin API directly.
Load Shopify into BigQuery with ETL or the Bulk Operations API, then use Looker Studio's native BigQuery connector.
Keep a sheet current with an add-on or export, and use Sheets as the Looker Studio data source.
How we serve MySQL stores: an isolated copy Looker Studio reads with its built-in PostgreSQL connector, no export step. Shopify needs an API connector, in development.
Connector for speed, warehouse for durability, spreadsheet for cheapness. This is the whole decision — everything after it is mechanical.
Whichever route you chose, pin down which financial and fulfilment statuses count as revenue before anything is charted. Doing it here means every chart inherits one definition.
Community connector, BigQuery or Sheets — each is a few clicks once the data exists. Prefer a custom query or a modelled view over a raw table so the report reads a summary.
Charts pointed at line-item-level data re-aggregate on every interaction, which is where Shopify dashboards get slow. Point them at something already grouped by day, product or customer.
The quick route is genuinely fine for a lot of stores. It's worth knowing in advance which side of the line you're on, because migrating a built dashboard is the expensive way to find out.
No. Google's built-in connectors cover its own products and databases — BigQuery, Sheets, MySQL, PostgreSQL — and Shopify is none of them. Everything available is a third-party community connector, or a database you loaded Shopify into first.
Usually a connector hitting Shopify's rate limits mid-pull and returning what it managed to fetch. It's the strongest practical argument for putting a warehouse or a database in the middle: a chart reading a table gets the same answer twice, and a chart reading an API under quota does not.
For PrestaShop, WooCommerce and Magento, yes — that's exactly how it works today, using Looker Studio's native PostgreSQL connector with no export step. For Shopify it needs the API connector we're building; there's an early-access list on the Shopify page.
BeQuery works today on stores with a MySQL database — PrestaShop, WooCommerce and Magento. Shopify is API-only, so it needs a dedicated connector, and that's in development. Put your email down and we'll tell you the day it opens.