Looker Studio Bigquery

Looker Studio + BigQuery

Use this skill when the real deliverable is one trustworthy stakeholder-reporting packet on top of BigQuery.

looker-studio-bigquery owns the reporting layer for:

• PM / ops KPI review boards
• product funnel, retention, and rollout dashboards already modeled in BigQuery
• marketing / GTM channel and revenue reporting
• game / live-ops / business telemetry review boards
• refresh, cost, audience, and export-handoff decisions for Looker Studio on curated data

Read these support docs first when needed:

• references/intake-packets-and-route-outs.md
• references/modeling-refresh-and-cost.md
• references/dashboard-delivery-checklist.md
• references/modes-and-routing.md

When to use this skill

• The user explicitly wants Looker Studio / Data Studio + BigQuery help.
• The data already lives in BigQuery, or the dashboard clearly sits on curated BigQuery tables/views.
• The main job is dashboard structure, refresh/cost shape, audience-specific delivery, or export-ready reporting.
• The request is about KPI boards, PM/ops reviews, marketing/GTM reporting, product summary dashboards, or game/business telemetry dashboards.
• The real risk is dashboard trust, refresh design, or mixed-audience sprawl rather than raw SQL interpretation alone.

When not to use this skill

• The main job is explaining why a KPI moved or what the dataset means → use data-analysis
• The main job is repeated anomaly hunting or reusable rule scans across metrics/events → use pattern-detection
• The main job is telemetry reliability, alerting, or instrumentation coverage → use monitoring-observability
• The main job is choosing a full BI / semantic platform → use survey
• The main job is broad GCP/bootstrap/deploy work → route to the relevant infrastructure skill first

Instructions

Step 1: Pick one primary packet before talking about charts

Normalize the request into one packet.

looker_studio_bigquery_packet:
  primary_packet: dashboard-spec | slow-dashboard | refresh-shape | audience-split | exec-handoff
  audience: executive | pm-ops | product-analytics | marketing-gtm | game-liveops | mixed | unknown
  source_shape: curated-table | view | scheduled-query-output | materialized-view | mixed | unknown
  freshness_need: near-real-time | hourly | daily | weekly | unknown
  trust_risk: low | medium | high

Pick exactly one primary_packet:

• dashboard-spec — build or redesign a stakeholder dashboard
• slow-dashboard — fix a dashboard that is slow, expensive, or brittle
• refresh-shape — decide live vs scheduled vs snapshot vs BI Engine
• audience-split — separate one overloaded report into audience-specific artifacts
• exec-handoff — produce a thin dashboard plus export/sheet/deck handoff for commentary and approvals

If two packets seem plausible, choose the one that removes the biggest delivery risk first.

Step 2: Keep the dashboard thin on purpose

Before designing sections, answer these: 1. What review ritual or decision does this dashboard support? 2. What table/view is the source of truth? 3. Which metrics belong in BigQuery instead of report-level formulas? 4. Who owns freshness, trust checks, and caveats?

If the request still depends on raw fact tables, unstable joins, or fuzzy metric definitions, say so and push modeling work upstream before polishing the dashboard.

Step 3: Shape the packet, not a generic BI essay

Use the packet guidance in references/intake-packets-and-route-outs.md.

Minimum packet expectations:

• dashboard-spec → page structure, KPI set, chart-to-question mapping, and BigQuery contract
• slow-dashboard → bottleneck order, upstream precompute options, and one shortest-path fix
• refresh-shape → live vs scheduled vs snapshot choice tied to the real review cadence
• audience-split → artifact split by stakeholder ritual, trust need, and detail depth
• exec-handoff → thin dashboard plus Connected Sheets / export / slide handoff plan

Do not answer with a generic chart buffet.

Step 4: Return a delivery brief

Use this structure:

# Looker Studio Delivery Brief

## Primary packet
- Packet: ...
- Audience: ...
- Confidence: high | medium | low

## Review ritual and question
- Ritual: ...
- Decisions supported: ...

## BigQuery contract
- Source table/view: ...
- Grain: ...
- Core dimensions: ...
- Core metrics: ...
- Freshness / owner / caveats: ...

## Recommended dashboard shape
- Pages or sections: ...
- KPI and chart-to-question mapping: ...
- Filters / drilldowns / export needs: ...

## Refresh, cost, and trust plan
- Preferred refresh shape: ...
- Heavy logic to move upstream: ...
- Trust or caveat notes: ...

## Recommended next artifact
- Choose one: dashboard spec | SQL handoff list | refresh decision memo | audience split brief | export / Connected Sheets handoff

## Route-outs
- Upstream modeling / KPI interpretation / anomaly hunting / observability / platform comparison as needed

Step 5: Route out honestly

• If the user needs dataset reasoning or KPI explanation, route to data-analysis.
• If the user needs repeated anomaly detection or reusable metric rules, route to pattern-detection.
• If the user needs telemetry coverage, alerting, or instrumentation trust, route to monitoring-observability.
• If the user needs a heavier BI or semantic-platform decision, route to survey.

Examples

Example 1: PM / ops dashboard build

Input

Build a leadership-ready PM review dashboard in Looker Studio on top of BigQuery weekly KPIs.

Output sketch

• Packet: dashboard-spec
• Dashboard shape: KPI scorecards + main trend + one drilldown + owner/freshness notes
• Next artifact: dashboard spec

Example 2: Slow marketing board

Input

Our marketing funnel dashboard is too slow and expensive whenever people touch filters.

Output sketch

• Packet: slow-dashboard or refresh-shape
• Primary recommendation: precompute the repeated funnel logic in BigQuery before styling changes
• Next artifact: refresh decision memo or SQL handoff list

Example 3: Mixed audience dashboard

Input

One board is trying to serve executives, PMs, growth, and live-ops. Should we keep patching it?

Output sketch

• Packet: audience-split
• Recommendation: split the artifact by decision ritual and trust needs
• Next artifact: audience split brief

Example 4: Commentary-friendly handoff

Input

Leadership wants a weekly board, but they still annotate numbers in Sheets before the review.

Output sketch

• Packet: exec-handoff
• Recommendation: keep the dashboard thin and define the export / Connected Sheets handoff explicitly
• Next artifact: export / Connected Sheets handoff

Best practices

1. Start from the current packet, not from chart types. 2. Keep heavy logic in BigQuery whenever possible. 3. Tie freshness to the real review ritual instead of pretending everything must be live. 4. Split dashboards by audience when one artifact keeps absorbing incompatible needs. 5. Name the owner, caveats, and trust contract in every serious dashboard handoff. 6. Prefer route-outs over stuffing analysis, anomaly hunting, or observability into this skill.

References

• BigQuery: Visualize data in Looker Studio
• BigQuery scheduled queries
• BigQuery materialized views
• BigQuery BI Engine
• Connected Sheets for BigQuery

Dashboard delivery checklist

Before building

• Name the audience and the review ritual.
• State the BigQuery source table/view and grain.
• List the KPI definitions that must stay stable.
• Decide the freshness target.
• Note the owner and trust risks.

Before calling the dashboard ready

• Every chart answers a real question.
• Top-line KPIs appear before detail.
• Filters do not hide metric-definition drift.
• Freshness and caveats are visible somewhere in the deliverable.
• The report can survive schema or pipeline changes without silent ambiguity.
• Audience split is explicit if executives and analysts need different surfaces.

Handoff packet

Include:

• dashboard purpose
• audience
• page structure
• chart-to-question map
• BigQuery contract summary
• refresh strategy
• export / Connected Sheets handoff if needed
• route-outs for upstream modeling work

Quality red flags

• too many charts with no narrative order
• report-level formulas nobody can audit
• direct use of raw fact tables for every page interaction
• one dashboard trying to solve both explanation and monitoring
• no owner/freshness/caveat note for decision-critical metrics

Intake packets and route-outs

Use this reference after looker-studio-bigquery has identified the primary packet.

1. dashboard-spec

Use when the main job is building or redesigning a stakeholder dashboard on curated BigQuery data.

Capture:

• review ritual and audience
• page or section structure
• KPI scorecards and exact metric definitions
• chart-to-question mapping
• filters, drilldowns, and export needs
• source table/view, grain, owner, and freshness

Default shape: 1. top-line scorecards 2. one main trend or comparison section 3. one segmented drilldown surface 4. one detail table or export surface 5. caveats / freshness / owner notes

2. slow-dashboard

Use when the dashboard is slow, expensive, or fragile.

Check in this order: 1. raw fact tables vs curated reporting marts/views 2. late joins or heavy report-level calculated fields 3. scheduled query or materialized-view opportunities 4. whether the audience truly needs live freshness 5. BI Engine or caching as an accelerator after upstream shape is fixed

Do not treat chart cosmetics as the answer to a warehouse-shape problem.

3. refresh-shape

Use when the real question is live vs scheduled vs snapshot.

Compare:

• direct query against curated table/view
• scheduled-query output table
• materialized view
• BI Engine acceleration
• export / Connected Sheets handoff for the last mile

Default bias:

• hourly or daily stakeholder reporting usually prefers precomputed tables
• keep near-real-time only when the ritual truly needs it

4. audience-split

Use when one dashboard is trying to serve incompatible readers.

Typical split:

• executive / leadership → fewer charts, more stability, clear freshness/trust labels
• PM / analyst / ops → more filters, more detail, more drilldowns
• marketing / growth → pacing, channel, target, and export-handoff surfaces
• game / live-ops → event, cohort, regional, and time-window slices with explicit caveats

If the dashboard keeps accumulating exceptions, split by audience rather than forcing one artifact to do everything.

5. exec-handoff

Use when the dashboard is only part of the workflow and the real deliverable includes Sheets, slides, or export-ready commentary.

Capture:

• which numbers still need annotations, targets, or approvals
• whether Connected Sheets is enough or a slide/deck handoff is cleaner
• how freshness, owner, and caveats stay attached after export
• which tables or views back the exported artifact

The goal is a thin dashboard plus a clean handoff, not an overloaded mega-report.

Route-outs

• KPI explanation / dataset reasoning → data-analysis
• Repeated anomaly or rule hunting → pattern-detection
• Telemetry reliability / alerting / instrumentation coverage → monitoring-observability
• BI-platform or semantic-layer choice → survey

Reusable questions

• What decision will this dashboard change next week?
• Which table/view is the source of truth?
• What would break trust fastest: stale data, inconsistent metric definitions, or audience overload?
• What should stay in BigQuery instead of report-level formulas?
• Does the last mile need interaction, export, or commentary?

Modeling, refresh, and cost notes

Durable rule

The stack works best when BigQuery owns the heavy lifting and Looker Studio stays thin.

What to push into BigQuery

Push upstream when you see:

• repeated joins across large tables
• derived funnel stages or retention cohorts
• expensive calculated fields used on many charts
• audience-specific KPI definitions that need stable governance
• dashboards depending on raw fact/event tables for every interaction

Good upstream candidates:

• scheduled-query output tables
• reporting marts
• denormalized views for dashboard use
• materialized views for repeated aggregations
• explicit metric dictionaries documented alongside the report

Freshness ladder

Choose the cheapest freshness that still supports the business ritual: 1. Weekly / monthly review → snapshot or scheduled output table 2. Daily leadership / PM / marketing review → daily scheduled-query table or refreshed mart 3. Hourly operations view → hourly materialization or carefully scoped direct query 4. Near-real-time need → justify direct query or BI Engine only when the ritual truly demands it

Cost and performance checks

• Is the report scanning raw history when only a recent slice is needed?
• Can filters operate on curated dimensions instead of expensive expressions?
• Are repeated calculations duplicated in many charts?
• Does the audience need one combined report, or would smaller pages be cheaper and clearer?
• Would BI Engine help, or is the underlying query shape still too messy?

Common decisions

• Exec dashboard → stable precomputed table, fewer filters, explicit freshness label
• Marketing board → scheduled-query funnel/channel mart plus export handoff for final commentary
• PM review board → curated KPI mart with drilldown page for analysts, simplified top page for leadership
• Game live-ops board → segmented telemetry table with controlled freshness note and explicit caveats

Anti-patterns

• Insisting on live freshness for a ritual that only happens weekly
• Hiding business logic in many calculated fields that nobody owns
• Using one dashboard as both the analyst workbench and the stakeholder surface
• Treating export/sheet handoff as failure instead of a normal last-mile workflow

Looker Studio + BigQuery modes and routing

Core boundary

Use looker-studio-bigquery when the real job is BigQuery-backed dashboard/reporting build-out for stakeholders.

Keep the lane split four ways:

• looker-studio-bigquery — dashboard structure, refresh strategy, audience routing, and stakeholder delivery on top of curated BigQuery data
• data-analysis — reasoning from exports, experiments, KPI drops, funnel data, or telemetry evidence
• pattern-detection — repeatable anomaly/rule hunting across metrics or events
• monitoring-observability — telemetry reliability, instrumentation coverage, alerts, and freshness/observability design

Primary modes

1. Dashboard-build

Use when the user needs a new KPI board, funnel dashboard, PM/ops review dashboard, marketing report, or live-ops dashboard.

2. Performance-hardening

Use when the dashboard is slow, expensive, or brittle and the likely fix is a thinner presentation layer over better-shaped BigQuery data.

3. Refresh-cost

Use when the main decision is live query vs scheduled-query table vs materialized view vs BI Engine acceleration vs export handoff.

4. Audience-routing

Use when one report is trying to satisfy incompatible stakeholders and should be split by audience or decision ritual.

5. Migration-review

Use when the user is really asking whether Looker Studio should remain the reporting surface at all.

Fast routing checklist

• Stays here: dashboard structure, KPI scorecards, filter logic, page layout, refresh plan, dashboard packet, stakeholder handoff
• Move to `data-analysis`: KPI explanation, experiment interpretation, export analysis, cohort/funnel reasoning
• Move to `pattern-detection`: repeated anomaly scans, rule-based metric hunting, reusable suspicious-pattern checks
• Move to `monitoring-observability`: alerting, telemetry completeness, instrumentation, service or pipeline visibility
• Move to `survey`: platform comparison, governed semantic BI choice, or whether Looker Studio is still the right surface

Anti-patterns

• Treating Looker Studio as the place to solve raw warehouse modeling problems
• Solving every performance complaint with more charts instead of better table/view design
• Keeping one giant report for executives, analysts, marketers, and operators when the workflows clearly diverge
• Forcing dashboard work when the user really needs a data explanation or platform-choice survey