Looker Studio Dashboards

What Looker Studio actually is

Looker Studio (formerly Google Data Studio, not to be confused with the enterprise Looker/LookML product) is a free report-building tool that connects to data sources — GA4, Google Ads, Google Sheets, BigQuery, and hundreds of third-party connectors — and lets you build interactive charts, tables, and scorecards without writing frontend code. Its core unit is the data source: a connection to one dataset with a defined schema of dimensions and metrics, which one or more report pages then visualize. A report can pull from multiple data sources simultaneously, but each chart on a page is normally bound to exactly one data source unless you explicitly blend them.

Blending data sources

Blending lets a single chart combine data from up to five different data sources by joining them on a shared key dimension — the classic use case is blending GA4 session data with Google Ads cost data on the shared campaign dimension, so a single table can show sessions, conversions, *and* ad spend side by side even though GA4 and Google Ads are structurally separate data sources with no native shared schema.

Blends behave like a SQL LEFT JOIN: you designate a join key per source, and Looker Studio joins matching rows. The most common blending failure is a join key mismatch — GA4's campaign name field and Google Ads' campaign name field differing by even a trailing space or casing difference causes rows to silently fail to match, undercounting the blended metric with no error shown.

blend_config.txt

text

Blended data source: "Paid Campaign Performance"

Source 1: GA4 (BigQuery export)
  Join key: campaign_name
  Metrics: sessions, conversions, conversion_value

Source 2: Google Ads
  Join key: campaign_name
  Metrics: cost, clicks, impressions

Join type: LEFT OUTER JOIN on campaign_name
Result fields: sessions, conversions, cost, clicks
  -> Calculated field: ROAS = conversion_value / cost

Blends don't validate join keys for you

If a campaign name in Google Ads doesn't exactly match the campaign string GA4 recorded (common when naming conventions drift between platforms), that campaign's rows simply don't join — the blended table shows lower totals with no error or warning. Always spot-check blended totals against each individual data source's own total before trusting a blended dashboard.

Calculated fields

Calculated fields let you derive new metrics or dimensions from existing ones using Looker Studio's formula syntax (similar to spreadsheet functions), computed either at the data-source level (available to every report using that source) or the chart level (scoped to one chart only). Common patterns include ratio metrics (conversion rate, ROAS, CTR), conditional buckets (CASE WHEN sessions > 1000 THEN "High" ELSE "Low" END), and regex-based dimension extraction (pulling a campaign type out of a UTM string).

calculated_fields.txt

text

// Conversion rate
Conversions / Sessions

// ROAS (blended field)
SUM(conversion_value) / SUM(cost)

// Channel bucket from utm_medium
CASE
  WHEN REGEXP_MATCH(utm_medium, "cpc|ppc|paid.*") THEN "Paid"
  WHEN utm_medium = "email" THEN "Email"
  WHEN utm_medium = "organic" THEN "Organic Search"
  ELSE "Other"
END

// Week-over-week change
(This_Week_Sessions - Last_Week_Sessions) / Last_Week_Sessions

Connecting BigQuery directly

For anything beyond GA4's native connector limits — custom joins across multiple tables, pre-aggregated rollups, or event-level analysis that would be too slow to compute live in Looker Studio's UI layer — the BigQuery connector lets you point a data source directly at a SQL query or a view. This shifts the heavy computation to BigQuery (fast, scalable, and billed by data scanned) instead of Looker Studio's own query engine, which struggles with row-level GA4 export tables at any real volume.

The standard pattern for high-traffic properties: build a scheduled BigQuery view or a materialized daily aggregate table (via a scheduled query) that pre-computes the metrics a dashboard needs, then connect Looker Studio to that small aggregate table rather than the raw multi-million-row events_* tables directly — this keeps both dashboard load time and BigQuery query cost under control.

Live connection vs extract mode

Looker Studio's BigQuery connector defaults to a live connection, re-running your query on every viewer's page load — fine for small aggregate tables, expensive and slow against raw event tables. Use 'Extract Data' mode to snapshot a query result into Looker Studio's own cache on a schedule when the underlying query is expensive or doesn't need to be truly real-time.

Dashboard design principles for stakeholder reporting

Principle	Why it matters
Lead with the decision metric, not everything you have	Executives scan the top-left first — put the number they actually act on there
Cap it at one screen, no scrolling for the summary view	A dashboard nobody scrolls to the bottom of might as well not have that data
Compare against a baseline (last period, target)	A raw number without context ('12,000 sessions') tells a stakeholder nothing
Use consistent time filters across all charts	Mismatched date ranges between charts on one page cause misread comparisons
Avoid more than 5-6 colors per chart	Beyond that, color stops encoding meaning and starts just decorating
Document data source and last-refresh time on the page	Stakeholders need to know if they're looking at yesterday's or last month's data

What's next

The BigQuery layer underneath most serious Looker Studio dashboards is fed by GA4's export — understanding that raw event schema is what makes writing efficient aggregate queries possible in the first place.

Next: GA4 Architecture →