Build Looker Studio data source configurations with BigQuery connectors, custom queries, and calculated fields.
Build Looker Studio data source configurations with BigQuery connectors, custom queries, calculated fields, and caching settings.
Required Fields
dataSource.namedataSource.typedataSource.connectorConfig.projectIdfieldsOutput will appear here...Build a Looker Studio data source pointing at BigQuery, including an optional customQuery that overrides the default table connector with hand-written SQL, calculated fields with their own formula expressions (ctr, roas in the example), and query parameters like DS_START_DATE/DS_END_DATE that let report viewers control the date range without editing the underlying query. caching.maxAge and prefetchCacheEnabled directly trade off dashboard freshness against BigQuery query cost, since every uncached page load re-runs the underlying query and gets billed for bytes scanned.
Not necessarily, it depends on caching. If caching.enabled is true and the report is viewed within maxAge of the last query execution, Looker Studio serves the cached result instead of re-running the query. Without caching, or once the cache expires, every view triggers a fresh BigQuery query, which is billed for bytes scanned, so an uncached, unfiltered customQuery on a huge table can get expensive fast under heavy report traffic.
Calculated fields evaluate per-row using the field names available in the data source at query time, if a formula references a field that's null or zero for some rows (like clicks / impressions when impressions is 0), it produces null or an error for those rows rather than skipping them silently. Wrap division-based formulas with a conditional check for the denominator being zero if that's a real possibility in your data.
projectId identifies which project's dataset/table the connector reads from; billingProjectId identifies which project's quota and billing account absorbs the query cost, they're often the same but can differ when a shared analytics dataset lives in one project while report viewers' queries are billed to their own team's project.
The builder requires dataSource.name, dataSource.type, dataSource.connectorConfig.projectId, and fields to resolve before accepting the config, the minimum needed to know which BigQuery project to query and what shape of fields the resulting data source exposes to reports built on top of it.
prefetchCacheEnabled pre-warms the cache proactively rather than waiting for the first viewer to trigger a query, which smooths out the 'first viewer of the day waits ten seconds' problem but means the query runs (and is billed) on a schedule regardless of whether anyone actually opens the report that day.
A customQuery with parameters needs the parameter's defaultValue to be sensible on its own, since a newly-shared report renders with defaults before any viewer has touched the date controls, a bad default silently shows misleading numbers to first-time viewers.
sharing.allowEditors: false doesn't prevent someone from making their own copy of the report and editing that freely, it only protects the original data source's query and calculated fields from in-place edits by report viewers.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.