git:20260306.b04d94a to v2.0.0

219 added, 415 removed. Audit A to A.

---
name: looker-studio-bigquery
- description: Design and configure Looker Studio dashboards with BigQuery data sources. Use when creating analytics dashboards, connecting BigQuery to visualization tools, or optimizing data pipeline performance. Handles BigQuery connections, custom SQL queries, scheduled queries, dashboard design, and performance optimization.
+ description: >
+ Build BigQuery-backed Looker Studio dashboards for stakeholder reporting: KPI
+ scorecards, funnel and retention boards, marketing / GTM reporting, PM/ops
+ review dashboards, and game/business telemetry views. Use when the real job is
+ shaping the presentation layer, refresh strategy, and dashboard interaction on
+ top of curated BigQuery data — not generic dataset analysis or broad data
+ engineering. Triggers on: Looker Studio, Data Studio, BigQuery dashboard,
+ marketing dashboard, KPI board, exec dashboard, PM review dashboard, funnel
+ dashboard, retention dashboard, live-ops dashboard, scheduled-query reporting,
+ BI Engine, Connected Sheets handoff.
+ allowed-tools: Read Write Edit Glob Grep
+ compatibility: >
+ Best when the workspace can edit SQL, dashboard specs, and repo files for
+ reporting definitions. This skill assumes BigQuery is already available or can
+ be referenced conceptually; it is not a full GCP project bootstrap skill.
+ license: MIT
metadata:
- tags: Looker-Studio, BigQuery, dashboard, analytics, visualization, GCP, data-studio, SQL
- platforms: Claude, ChatGPT, Gemini
+ tags: looker-studio, bigquery, dashboard, kpi, analytics, reporting, marketing, pm-ops, live-ops, bi-engine
+ platforms: Claude, ChatGPT, Gemini, Codex
+ version: "2.0.0"
+ modernization: 2026-04-15
---
-
- # Looker Studio BigQuery Integration
-
- ## When to use this skill
-
- - **Analytics dashboard creation**: Visualizing BigQuery data to derive business insights
- - **Real-time reporting**: Building auto-refreshing dashboards
- - **Performance optimization**: Optimizing query costs and loading time for large datasets
- - **Data pipeline**: Automating ETL processes with scheduled queries
- - **Team collaboration**: Building shareable interactive dashboards
-
- ## Instructions
-
- ### Step 1: Prepare GCP BigQuery Environment
-
- **Project creation and activation**
-
- Create a new project in Google Cloud Console and enable the BigQuery API.
-
- ```bash
- # Create project using gcloud CLI
- gcloud projects create my-analytics-project
- gcloud config set project my-analytics-project
- gcloud services enable bigquery.googleapis.com
- ```
-
- **Create dataset and table**
-
- ```sql
- -- Create dataset
- CREATE SCHEMA `my-project.analytics_dataset`
- OPTIONS(
- description="Analytics dataset",
- location="US"
- );
-
- -- Create example table (GA4 data)
- CREATE TABLE `my-project.analytics_dataset.events` (
- event_date DATE,
- event_name STRING,
- user_id INT64,
- event_value FLOAT64,
- event_timestamp TIMESTAMP,
- geo_country STRING,
- device_category STRING
- );
- ```
-
- **IAM permission configuration**
-
- Grant IAM permissions so Looker Studio can access BigQuery:
-
- | Role | Description |
- |------|------|
- | `BigQuery Data Viewer` | Table read permission |
- | `BigQuery User` | Query execution permission |
- | `BigQuery Job User` | Job execution permission |
-
- ### Step 2: Connecting BigQuery in Looker Studio
-
- **Using native BigQuery connector (recommended)**
-
- 1. On Looker Studio homepage, click **+ Create** → **Data Source**
- 2. Search for "BigQuery" and select Google BigQuery connector
- 3. Authenticate with Google account
- 4. Select project, dataset, and table
- 5. Click **Connect** to create data source
-
- **Custom SQL query approach**
-
- Write SQL directly when complex data transformation is needed:
-
- ```sql
- SELECT
- event_date,
- event_name,
- COUNT(DISTINCT user_id) as unique_users,
- SUM(event_value) as total_revenue,
- AVG(event_value) as avg_revenue_per_event
- FROM `my-project.analytics_dataset.events`
- WHERE event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
- GROUP BY event_date, event_name
- ORDER BY event_date DESC
- ```
-
- **Advantages:**
- - Handle complex data transformations in SQL
- - Pre-aggregate data in BigQuery to reduce query costs
- - Improved performance by not loading all data every time
-
- **Multiple table join approach**
-
- ```sql
- SELECT
- e.event_date,
- e.event_name,
- u.user_country,
- u.user_tier,
- COUNT(DISTINCT e.user_id) as unique_users,
- SUM(e.event_value) as revenue
- FROM `my-project.analytics_dataset.events` e
- LEFT JOIN `my-project.analytics_dataset.users` u
- ON e.user_id = u.user_id
- WHERE e.event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 90 DAY)
- GROUP BY e.event_date, e.event_name, u.user_country, u.user_tier
- ```
-
- ### Step 3: Performance Optimization with Scheduled Queries
-
- Use **scheduled queries** instead of live queries to periodically pre-compute data:
-
- ```sql
- -- Calculate and store aggregated data daily in BigQuery
- CREATE OR REPLACE TABLE `my-project.analytics_dataset.daily_summary` AS
- SELECT
- CURRENT_DATE() as report_date,
- event_name,
- user_country,
- COUNT(DISTINCT user_id) as daily_users,
- SUM(event_value) as daily_revenue,
- AVG(event_value) as avg_event_value,
- MAX(event_timestamp) as last_event_time
- FROM `my-project.analytics_dataset.events`
- WHERE event_date = CURRENT_DATE() - 1
- GROUP BY event_name, user_country
- ```
-
- Configure as **scheduled query** in BigQuery UI:
- - Runs automatically daily
- - Saves results to a new table
- - Looker Studio connects to the pre-computed table
-
- **Advantages:**
- - Reduce Looker Studio loading time (50-80%)
- - Reduce BigQuery costs (less data scanned)
- - Improved dashboard refresh speed
-
- ### Step 4: Dashboard Layout Design
-
- **F-pattern layout**
-
- Use the F-pattern that follows the natural reading flow of users:
-
- ```
- ┌─────────────────────────────────────┐
- │ Header: Logo | Filters/Date Picker │ ← Users see this first
- ├─────────────────────────────────────┤
- │ KPI 1 │ KPI 2 │ KPI 3 │ KPI 4 │ ← Key metrics (3-4)
- ├─────────────────────────────────────┤
- │ │
- │ Main Chart (time series/comparison) │ ← Deep insights
- │ │
- ├─────────────────────────────────────┤
- │ Concrete data table │ ← Detailed analysis
- │ (Drilldown enabled) │
- ├─────────────────────────────────────┤
- │ Additional Insights / Map / Heatmap │
- └─────────────────────────────────────┘
- ```
+ # Looker Studio + BigQuery
- **Dashboard components**
+ Use this skill when the real deliverable is a **trustworthy stakeholder dashboard layer on top of BigQuery**.
- | Element | Purpose | Example |
- |---------|------|------|
- | **Header** | Dashboard title, logo, filter placement | "2026 Q1 Sales Analysis" |
- | **KPI tiles** | Display key metrics at a glance | Total revenue, MoM growth rate, active users |
- | **Trend charts** | Changes over time | Line chart showing daily/weekly revenue trend |
- | **Comparison charts** | Compare across categories | Bar chart comparing sales by region/product |
- | **Distribution charts** | Visualize data distribution | Heatmap, scatter plot, bubble chart |
- | **Detail tables** | Provide exact figures | Conditional formatting to highlight thresholds |
- | **Map** | Geographic data | Revenue distribution by country/region |
+ `looker-studio-bigquery` is the dashboard/reporting handoff for:
+ - PM and ops KPI review boards
+ - product funnel, retention, and cohort dashboards already modeled in BigQuery
+ - marketing / GTM channel and revenue reporting
+ - game / live-ops / monetization dashboards for studio review
+ - refresh, cost, and interaction decisions for Looker Studio on curated warehouse data
- **Real example: E-commerce dashboard**
+ Read these support docs before choosing the workflow:
+ - [references/modes-and-routing.md](references/modes-and-routing.md)
+ - [references/modeling-refresh-and-cost.md](references/modeling-refresh-and-cost.md)
+ - [references/dashboard-delivery-checklist.md](references/dashboard-delivery-checklist.md)
- ```
- ┌──────────────────────────────────────────────────┐
- │ 📊 Jan 2026 Sales Analysis | 🔽 Country | 📅 Date │
- ├──────────────────────────────────────────────────┤
- │ Total Revenue: $125,000 │ Orders: 3,200 │ Conversion: 3.5% │
- ├──────────────────────────────────────────────────┤
- │ Daily Revenue Trend (Line Chart) │
- │ ↗ Upward trend: +15% vs last month │
- ├──────────────────────────────────────────────────┤
- │ Sales by Category │ Top 10 Products │
- │ (Bar chart) │ (Table, sortable) │
- ├──────────────────────────────────────────────────┤
- │ Revenue Distribution by Region (Map) │
- └──────────────────────────────────────────────────┘
- ```
+ ## When to use this skill
+ - The user explicitly wants **Looker Studio / Data Studio + BigQuery** help.
+ - The dataset already lives in BigQuery, or the reporting layer will clearly sit on BigQuery tables/views.
+ - The main job is dashboard structure, refresh strategy, filter behavior, audience-specific scorecards, or stakeholder-ready delivery.
+ - The request is about KPI boards, funnel/retention dashboards, exec reporting, marketing performance dashboards, or game/business telemetry dashboards.
+ - The real risk is dashboard trust, refresh cost, or interaction design rather than raw SQL analysis alone.
- ### Step 5: Interactive Filters and Controls
+ ## When not to use this skill
+ - **The main job is interpreting a CSV/export, experiment result, or KPI drop** → use `data-analysis`
+ - **The main job is repeated anomaly/rule hunting across metrics or events** → use `pattern-detection`
+ - **The main job is telemetry reliability, monitoring coverage, or alert design** → use `monitoring-observability`
+ - **The main job is full semantic modeling / governed BI platform design across many teams** → use `survey` or a warehouse / BI architecture workflow first
+ - **The main job is broad GCP/bootstrap/deploy work** → use the relevant infrastructure or cloud skill first
- **Filter types**
+ ## Instructions
- **1. Date range filter** (required)
- - Select specific period via calendar
- - Pre-defined options like "Last 7 days", "This month"
- - Connected to dataset, auto-applied to all charts
+ ### Step 1: Classify the reporting job before designing charts
+ Normalize the request first.
- **2. Dropdown filter**
- ```
- Example: Country selection filter
- - All countries
- - South Korea
- - Japan
- - United States
- Shows only data for the selected country
+ ```yaml
+ looker_studio_bigquery_mode:
+ primary_mode: dashboard-build | performance-hardening | refresh-cost | audience-routing | migration-review
+ audience: executive | pm-ops | product-analytics | marketing-gtm | game-liveops | mixed | unknown
+ data_shape: curated-table | view | scheduled-query-output | raw-fact-table | mixed | unknown
+ freshness_need: near-real-time | hourly | daily | weekly | unknown
+ interaction_need: scorecard | trend | drilldown | filters | export-handoff | mixed
+ trust_risk: low | medium | high
```
- **3. Advanced filter** (SQL-based)
- ```sql
- -- Show only customers with revenue >= $10,000
- WHERE customer_revenue >= 10000
- ```
+ Choose exactly one primary mode for the run:
+ - `dashboard-build` → new or revised stakeholder dashboard on top of curated BigQuery data
+ - `performance-hardening` → dashboard is too slow, too expensive, or too brittle
+ - `refresh-cost` → the real question is live query vs scheduled table vs extract/snapshot behavior
+ - `audience-routing` → one dashboard is trying to serve conflicting stakeholders
+ - `migration-review` → compare Looker Studio with a heavier BI/semantic option instead of blindly staying here
- **Filter implementation example**
+ ### Step 2: Verify that the dashboard should stay thin
+ Before editing dashboard structure, answer these:
+ 1. **What decision or review ritual does the dashboard support?**
+ 2. **What table/view should be the source of truth?**
+ 3. **Which metrics must be precomputed in BigQuery instead of report-level formulas?**
+ 4. **Who owns the data refresh and trust checks?**
- ```sql
- -- 1. Date filter
- event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL @date_range_days DAY)
+ If the request still depends on raw event tables, ad hoc joins, or unstable metric definitions, push that modeling work upstream before overdesigning the report.
- -- 2. Dropdown filter (user input)
- WHERE country = @selected_country
+ ### Step 3: Choose the right mode
- -- 3. Composite filter
- WHERE event_date >= @start_date
- AND event_date <= @end_date
- AND country IN (@country_list)
- AND revenue >= @min_revenue
- ```
+ #### A. Dashboard-build
+ Use when the user needs a new dashboard or a serious redesign.
- ### Step 6: Query Performance Optimization
+ Output packet should include:
+ - dashboard purpose and audience
+ - page/section structure
+ - KPI scorecards and definitions
+ - required filters and drill paths
+ - chart-to-question mapping
+ - BigQuery source tables/views
+ - trust and freshness notes
- **1. Using partition keys**
+ Recommended structure:
+ 1. top-line scorecards
+ 2. one main trend or comparison area
+ 3. segment or drilldown view
+ 4. detail table or export surface
+ 5. caveats / freshness / owner metadata
- ```sql
- -- ❌ Inefficient query
- SELECT * FROM events
- WHERE DATE(event_timestamp) >= '2026-01-01'
+ #### B. Performance-hardening
+ Use when dashboards feel slow, expensive, or fragile.
- -- ✅ Optimized query (using partition)
- SELECT * FROM events
- WHERE event_date >= '2026-01-01' -- use partition key directly
- ```
+ Check in this order:
+ 1. Is the dashboard reading raw fact tables instead of curated marts/views?
+ 2. Are joins or expensive calculations happening too late?
+ 3. Can a scheduled query or materialized view precompute the repeated work?
+ 4. Does the audience really need live freshness?
+ 5. Is BI Engine or caching worth enabling for this workload?
- **2. Data extraction (Extract and Load)**
+ Do not treat chart cosmetics as the fix for a warehouse-shape problem.
- Extract data to a Looker Studio-dedicated table each night:
+ #### C. Refresh-cost
+ Use when the real question is **live vs scheduled vs snapshot**.
- ```sql
- -- Scheduled query running at midnight every day
- CREATE OR REPLACE TABLE `my-project.looker_studio_data.dashboard_snapshot` AS
- SELECT
- event_date,
- event_name,
- country,
- device_category,
- COUNT(DISTINCT user_id) as users,
- SUM(event_value) as revenue,
- COUNT(*) as events
- FROM `my-project.analytics_dataset.events`
- WHERE event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 90 DAY)
- GROUP BY event_date, event_name, country, device_category;
- ```
+ Compare:
+ - direct query against curated table/view
+ - scheduled-query output table
+ - materialized view
+ - BI Engine acceleration
+ - export / Connected Sheets handoff for the last mile
- **3. Caching strategy**
+ Default bias:
+ - hourly/daily stakeholder reporting usually prefers precomputed tables
+ - only keep dashboards closer to live when the review ritual truly needs it
- - **Looker Studio default caching**: Automatically caches for 3 hours
- - **BigQuery caching**: Identical queries reuse previous results (6 hours)
- - **Utilizing scheduled queries**: Pre-compute at night
+ #### D. Audience-routing
+ Use when one dashboard is trying to serve incompatible readers.
- **4. Dashboard complexity management**
+ Common split:
+ - **exec / leadership** → fewer charts, higher stability, stronger freshness/trust labels
+ - **PM / analyst / ops** → more filters, segment views, and detail tables
+ - **marketing / growth** → channel dimensions, pacing, targets, and export handoffs
+ - **game / live-ops** → cohort/time windows, regional splits, event/state segmentation, anomaly callouts
- - Use a maximum of 20-25 charts per dashboard
- - Distribute across multiple tabs (pages) if many charts
- - Do not group unrelated metrics together
+ If the dashboard keeps accumulating exceptions, split it by audience rather than forcing one artifact to do everything.
- ### Step 7: Community Connector Development (Advanced)
+ #### E. Migration-review
+ Use when the user is really asking whether Looker Studio should remain the surface at all.
- Develop a Community Connector for more complex requirements:
+ Escalation signs:
+ - many teams need governed reusable metrics
+ - row-level access and semantic reuse dominate the work
+ - dashboard logic is duplicated across many reports
+ - stakeholders want stronger self-serve exploration than thin dashboards can provide
- ```javascript
- // Community Connector example (Apps Script)
- function getConfig() {
- return {
- configParams: [
- {
- name: 'project_id',
- displayName: 'BigQuery Project ID',
- helpText: 'Your GCP Project ID',
- placeholder: 'my-project-id'
- },
- {
- name: 'dataset_id',
- displayName: 'Dataset ID'
- }
- ]
- };
- }
+ If those dominate, compare Looker Studio with a heavier BI/semantic route instead of pretending a dashboard tweak will solve it.
- function getData(request) {
- const projectId = request.configParams.project_id;
- const datasetId = request.configParams.dataset_id;
+ ### Step 4: Define the BigQuery contract for the dashboard
+ For each dashboard page or section, specify:
+ - source table/view name
+ - grain
+ - primary dimensions
+ - primary metrics
+ - freshness source and expected lag
+ - owner
+ - known caveats
- // Load data from BigQuery
- const bq = BigQuery.newDataset(projectId, datasetId);
- // ... Data processing logic
+ Example packet:
- return { rows: data };
- }
+ ```yaml
+ dashboard_contract:
+ source: analytics.reporting_daily_kpis
+ grain: date x segment
+ dimensions: [date, segment, country, platform]
+ metrics: [active_users, revenue, conversion_rate]
+ freshness: daily at 08:00 UTC
+ owner: analytics
+ caveats:
+ - excludes sandbox traffic
+ - conversion uses paid-checkout definition v2
```
- **Community Connector advantages:**
- - Centralized billing (using service account)
- - Custom caching logic
- - Pre-defined query templates
- - Parameterized user settings
-
- ### Step 8: Security and Access Control
-
- **BigQuery-level security**
-
- ```sql
- -- Grant table access permission to specific users only
- GRANT `roles/bigquery.dataViewer`
- ON TABLE `my-project.analytics_dataset.events`
- TO "user@example.com";
+ If you cannot state this contract clearly, the dashboard is not ready for stakeholder trust.
- -- Row-Level Security
- CREATE OR REPLACE ROW ACCESS POLICY rls_by_country
- ON `my-project.analytics_dataset.events`
- GRANT ('editor@company.com') TO ('KR'),
- ('viewer@company.com') TO ('US', 'JP');
- ```
+ ### Step 5: Map questions to dashboard components
+ Build charts from decision questions, not from widget inventory.
- **Looker Studio-level security**
+ Typical mapping:
+ - **Are we up or down?** → KPI scorecards + trend line
+ - **Where is the change coming from?** → segmented bar / breakdown table
+ - **Which slice needs action?** → filtered comparison + detail table
+ - **What should leadership trust?** → freshness stamp + caveats + owner
+ - **What needs external distribution?** → export or Connected Sheets handoff plan
- - Set viewer permissions when sharing dashboards (Viewer/Editor)
- - Share with specific users/groups only
- - Manage permissions per data source
+ Prefer fewer charts with a clear narrative over a dense wall of widgets.
- ## Output format
+ ### Step 6: Design refresh, cost, and reliability intentionally
+ Use this order:
+ 1. decide freshness target from the business ritual
+ 2. precompute repeated heavy logic in BigQuery when possible
+ 3. minimize report-level calculated-field sprawl
+ 4. separate stakeholder pages from analyst/debug pages
+ 5. document the refresh and ownership contract in the deliverable
- ### Dashboard Setup Checklist
+ Common patterns:
+ - daily exec dashboard → scheduled-query table + thin Looker Studio page
+ - marketing performance board → scheduled-query funnel/channel mart + export/sheet handoff
+ - game live-ops board → curated telemetry table + segmented trend pages + explicit freshness note
+ - PM review board → KPI scorecards, trend, drilldown, and a detail table tied to one review cadence
- ```markdown
- ## Dashboard Setup Checklist
+ ### Step 7: Produce the dashboard packet, not just chart notes
+ Default output should include:
+ - recommended mode
+ - dashboard sections/pages
+ - chart-to-question mapping
+ - BigQuery contract summary
+ - refresh/cost strategy
+ - route-outs for upstream modeling or downstream handoff
- ### Data Source Configuration
- - [ ] BigQuery project/dataset prepared
- - [ ] IAM permissions configured
- - [ ] Scheduled queries configured (performance optimization)
- - [ ] Data source connection tested
+ Good deliverables:
+ - dashboard spec markdown
+ - metric dictionary for report fields
+ - SQL handoff list for upstream modeling
+ - stakeholder delivery checklist
- ### Dashboard Design
- - [ ] F-pattern layout applied
- - [ ] KPI tiles placed (3-4)
- - [ ] Main charts added (trend/comparison)
- - [ ] Detail table included
- - [ ] Interactive filters added
+ ### Step 8: Route out honestly
+ - If the user really needs **dataset reasoning or KPI interpretation**, route to `data-analysis`.
+ - If the user really needs **repeated anomaly detection**, route to `pattern-detection`.
+ - If the user really needs **telemetry/alerting coverage**, route to `monitoring-observability`.
+ - If the user really needs **full BI stack comparison or semantic-platform choice**, route to `survey` before pretending Looker Studio is the answer.
- ### Performance Optimization
- - [ ] Partition key usage verified
- - [ ] Query cost optimized
- - [ ] Caching strategy applied
- - [ ] Chart count verified (20-25 or fewer)
+ ## Examples
- ### Sharing and Security
- - [ ] Access permissions configured
- - [ ] Data security reviewed
- - [ ] Sharing link created
- ```
+ ### Example 1: PM / ops dashboard build
+ Input:
+ - BigQuery table of product events and weekly KPI definitions
+ - request for a leadership-ready PM review dashboard
- ## Constraints
+ Output:
+ - dashboard-build mode
+ - KPI + trend + segment drilldown structure
+ - daily refresh contract
+ - route-out for any metric that still needs upstream SQL modeling
- ### Mandatory Rules (MUST)
+ ### Example 2: Marketing funnel report with cost issues
+ Input:
+ - BigQuery funnel model
+ - request to make a slow Looker Studio dashboard cheaper and more reliable
- 1. **Date filter required**: Include date range filter in all dashboards
- 2. **Use partitions**: Directly use partition keys in BigQuery queries
- 3. **Permission separation**: Clearly configure access permissions per data source
+ Output:
+ - performance-hardening or refresh-cost mode
+ - recommendation to precompute funnel stages in scheduled tables
+ - clear split between stakeholder dashboard and export/sheet handoff
- ### Prohibited (MUST NOT)
+ ### Example 3: Game live-ops reporting
+ Input:
+ - BigQuery telemetry tables for payer behavior and regional retention
+ - request for a live-ops review dashboard
- 1. **Excessive charts**: Do not place more than 25 charts on a single dashboard
- 2. **SELECT ***: Select only necessary columns instead of all columns
- 3. **Overusing live queries**: Avoid directly connecting to large tables
+ Output:
+ - audience-specific dashboard packet
+ - freshness note matched to the studio ritual
+ - chart plan for retention, payer mix, and region/event slices
## Best practices
-
- | Item | Recommendation |
- |------|---------|
- | **Data refresh** | Use scheduled queries, run at night |
- | **Dashboard size** | Max 25 charts, distribute to multiple pages if needed |
- | **Filter configuration** | Date filter required, limit to 3-5 additional filters |
- | **Color palette** | Use only 3-4 company brand colors |
- | **Title/Labels** | Use clear descriptions for intuitiveness |
- | **Chart selection** | Place in order: KPI → Trend → Comparison → Detail |
- | **Response speed** | Target average loading within 2-3 seconds |
- | **Cost management** | Keep monthly BigQuery scanned data within 5TB |
+ 1. Keep Looker Studio thin; do the heavy logic in BigQuery whenever possible.
+ 2. Start from the review ritual and decision question, not from chart types.
+ 3. Treat freshness, cost, and trust as first-class design constraints.
+ 4. Split dashboards by audience when one artifact keeps absorbing conflicting needs.
+ 5. Make source grain, owner, and caveats explicit in every serious dashboard handoff.
+ 6. Use route-outs instead of pretending every reporting problem belongs in this skill.
## References
-
- - [Looker Studio Help](https://support.google.com/looker-studio)
- - [BigQuery Documentation](https://cloud.google.com/bigquery/docs)
- - [Connect to BigQuery](https://cloud.google.com/looker/docs/studio/connect-to-google-bigquery)
- - [Community Connectors](https://developers.google.com/looker-studio/connector)
- - [Dashboard Design Best Practices](https://lookercourses.com/dashboard-design-tips-for-looker-studio-how-to-build-clear-effective-reports/)
-
- ## Metadata
-
- ### Version
- - **Current Version**: 1.0.0
- - **Last Updated**: 2026-01-14
- - **Compatible Platforms**: Claude, ChatGPT, Gemini
-
- ### Related Skills
- - [monitoring-observability](../monitoring-observability/SKILL.md): Data collection and monitoring
- - [database-schema-design](../../backend/database-schema-design/SKILL.md): Data modeling
-
- ### Tags
- `#Looker-Studio` `#BigQuery` `#dashboard` `#analytics` `#visualization` `#GCP`
-
- ## Examples
-
- ### Example 1: Creating a Basic Dashboard
-
- ```sql
- -- 1. Create daily summary table
- CREATE OR REPLACE TABLE `my-project.looker_data.daily_metrics` AS
- SELECT
- event_date,
- COUNT(DISTINCT user_id) as dau,
- SUM(revenue) as total_revenue,
- COUNT(*) as total_events
- FROM `my-project.analytics.events`
- WHERE event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
- GROUP BY event_date;
-
- -- 2. Connect to this table in Looker Studio
- -- 3. Add KPI scorecards: DAU, total revenue
- -- 4. Visualize daily trend with line chart
- ```
-
- ### Example 2: Advanced Analytics Dashboard
-
- ```sql
- -- Prepare data for cohort analysis
- CREATE OR REPLACE TABLE `my-project.looker_data.cohort_analysis` AS
- WITH user_cohort AS (
- SELECT
- user_id,
- DATE_TRUNC(MIN(event_date), WEEK) as cohort_week
- FROM `my-project.analytics.events`
- GROUP BY user_id
- )
- SELECT
- uc.cohort_week,
- DATE_DIFF(e.event_date, uc.cohort_week, WEEK) as week_number,
- COUNT(DISTINCT e.user_id) as active_users
- FROM `my-project.analytics.events` e
- JOIN user_cohort uc ON e.user_id = uc.user_id
- GROUP BY cohort_week, week_number
- ORDER BY cohort_week, week_number;
- ```
+ - [BigQuery: Visualize data in Looker Studio](https://cloud.google.com/bigquery/docs/visualize-looker-studio)
+ - [BigQuery scheduled queries](https://cloud.google.com/bigquery/docs/scheduling-queries)
+ - [BigQuery materialized views](https://cloud.google.com/bigquery/docs/materialized-views-intro)
+ - [BigQuery BI Engine](https://cloud.google.com/bigquery/docs/bi-engine-intro)
+ - [Connected Sheets for BigQuery](https://cloud.google.com/bigquery/docs/connected-sheets)