Looker Studio

Looker Studio's value proposition is precise: it's the free dashboarding layer for BigQuery data that non-technical stakeholders can access via URL. For this specific use case — making dbt-modelled analytics data visible and filterable without SQL access — it's the most efficient option in Google's ecosystem. Don't try to make it do analysis; that's not what it's for.

The critical architectural decision: always use Custom Query as your data source, never the native GA4 connector. The native connector is slow, limited to the GA4 API's predefined dimensions and metrics, subject to data thresholding, and unable to access your dbt-transformed models. A custom SQL query against your BigQuery dbt marts gives you full control: exact metric definitions, pre-aggregated for performance, and consistent with every other reporting surface in your organisation.

BI Engine is essential for production dashboards. Without it, every interaction with a Looker Studio report triggers a live BigQuery query — which is slow (2-5 seconds per interaction) and expensive (bytes scanned on every filter change). BI Engine caches query results in memory, delivering sub-second response times. For a dashboard accessed by 50 stakeholders daily, BI Engine transforms the experience from 'frustratingly slow' to 'acceptably fast'. Configure it per-project in BigQuery settings; the cost is based on reserved memory, not queries.

Data blending — joining data from multiple sources within Looker Studio — is useful but architecturally inferior to joining in BigQuery. Looker Studio blends are performed client-side with limited join types and poor performance on large datasets. The correct pattern: join your analytics data with CRM, ad spend, and product data in BigQuery (via federated queries or dbt models), then connect Looker Studio to the pre-joined result. This gives you better performance, SQL-level join flexibility, and a tested data model.

Calculated fields in Looker Studio are limited to a subset of functions that don't include window functions, subqueries, or conditional aggregation beyond basic CASE WHEN. Any metric that requires non-trivial computation should be computed in your dbt models, not in Looker Studio. This keeps your metric definitions version-controlled, tested, and consistent. Looker Studio should display metrics, not compute them.

For teams outgrowing Looker Studio — needing row-level security, version-controlled dashboards, metric governance, or embedded analytics — the upgrade path is Looker (the full product, now part of Google Cloud) or a third-party BI platform. Looker Studio is deliberately limited to maintain simplicity. Recognise when you've hit those limits and invest in a proper BI layer rather than working around Looker Studio's constraints with increasingly complex calculated fields.