How to Export BigQuery Data to Power BI, Tableau and Looker

Most guides show you how to get your GA4 data into BigQuery. Nobody tells you how to get it back out. Yet that’s where the real question sits: once your events are neatly stored in BigQuery, how do you plug them into Power BI, Tableau or Looker Studio without spending a week on it, and without triggering a bill that stings? This guide covers the three concrete ways to export BigQuery data into a data viz tool, the trap that’s specific to GA4 data, and a bonus almost nobody does yet: shipping a table to an LLM to analyze it in plain language.

If the previous step is missing, GA4-to-BigQuery ingestion is covered in detail in the guide on working with the GA4 BigQuery export. Here, we assume your events_* tables are already there.

Why export BigQuery data to a BI tool

BigQuery is excellent at storing and querying, and far less good at telling a story to an executive. Your decision makers aren’t going to open the GCP console to read SQL. They want a dashboard, a trend line, a number that moves. That’s exactly what a BI tool is for.

The other reason is blending. Your GA4 data lives in BigQuery, but your CRM, your ad spend and your product data live elsewhere. A tool like Power BI or Tableau becomes the meeting point where everything joins up. BigQuery stays the source of truth, BI becomes the presentation layer.

So the real question isn’t “is it possible” (it is, all three tools ship a native connector), but “how do I do it cleanly”. Two decisions actually matter: the shape of the table you expose, and the connection mode. We’ll handle both.

The GA4 trap: nested tables

Here’s the mistake I see most often. People plug the raw GA4 events_* table straight into Power BI, and it all falls apart. GA4 data in BigQuery is event-level and nested: event_params and items are RECORD / REPEATED columns, meaning arrays inside arrays. A BI tool can’t read them correctly. The result is an unreadable data model, joins that blow up, and queries that cost a fortune.

The fix isn’t to hack around it on the BI side, but to flatten upstream, inside BigQuery, with a dedicated view or table:

CREATE OR REPLACE TABLE `project.dataset.bi_events` AS
SELECT
  event_date,
  event_name,
  user_pseudo_id,
  -- Pull nested params out into flat columns
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'page_location') AS page_location,
  (SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'source')        AS source,
  (SELECT value.int_value    FROM UNNEST(event_params) WHERE key = 'ga_session_id') AS session_id,
  traffic_source.medium,
  device.category AS device
FROM `project.dataset.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20260601' AND '20260630'

This bi_events table is flat, clean, and the BI tool reads it without complaint. For the UNNEST techniques and common query patterns, I’ve detailed the usual cases in the 10 essential BigQuery queries for GA4. Keep the rule in mind: never expose raw tables to a BI tool, expose a flattened, aggregated table.

Path 1: BigQuery to Looker Studio

This is the fastest, and it makes sense: Looker Studio and BigQuery are both Google products. The connector is native, free, and it auto-enriches the fields (types, default aggregations).

In practice: in Looker Studio, add a data source, pick the BigQuery connector, then point it either at your bi_events table or at a custom SQL query. That second option is the smart one: you control exactly what gets scanned, and therefore what gets billed.

A small bonus if you start from the BigQuery console: the “Explore in Looker Studio” button spins up a one-click report on a query result. Perfect for a quick look. For recurring, automated reporting, the clean setup is described in the guide on automating your reporting with Looker Studio and BigQuery.

Path 2: BigQuery to Power BI

Power BI has a native Google BigQuery connector (Get Data, then Google BigQuery, authenticate with your Google account). No third-party tool needed to get going. The real decision here is the connection mode, and it hits your bill directly:

• Import: Power BI copies the data into its model. The BigQuery query runs only on refresh. Fast to use, predictable cost, ideal for reasonable volumes.
• DirectQuery: Power BI queries BigQuery live on every interaction. Data is always fresh, but every filter a user clicks can trigger a billed query. On a large GA4 dataset, it’s the best way to watch costs spiral.

My practitioner’s advice: start in Import mode on an already-aggregated table. Only move to DirectQuery if real-time freshness is a genuine business need, not a nice-to-have. If the native connector limits you (fine-grained scheduling, transforms), third-party tools like Coupler.io bridge the gap, but you’re adding one more dependency and one more cost. Reserve it for cases where native isn’t enough.

Path 3: BigQuery to Tableau

Tableau also ships a native BigQuery connector. The thing to watch is the same as Power BI, with different wording: extracts. An extract is a snapshot of the data stored on the Tableau side, the equivalent of Import mode. A live connection, by contrast, queries BigQuery directly like DirectQuery.

Here too, favor the extract over a flattened, aggregated table. You refresh the extract on a schedule (once a night, say), and your users explore the dashboard without triggering a billed query on every click.

The three paths compared

For a quick decision, here’s the gist:

The logic is the same whatever the tool: flatten and aggregate upstream, prefer “snapshot” over “live”, and reach for real-time freshness only when the business truly requires it.

Keeping BigQuery costs under control on the BI side

BigQuery bills on the volume of data scanned, not the number of rows displayed. A badly tuned live connection can rescan gigabytes on every click. A few habits that genuinely move the needle:

• Expose an aggregated intermediate table, never the raw events_* tables. You scan what BI needs, nothing more.
• Use materialized views for recurring aggregations: BigQuery only recomputes the delta.
• Partition and cluster your derived tables (by date, for example) so filters scan only what’s needed.
• Always filter on the period (_TABLE_SUFFIX or a partition column) in the source query, not just in the dashboard.
• Set quotas and cost alerts at the GCP project level. That’s your safety net the day a misconfigured dashboard loops.

Bonus: export a BigQuery table to an LLM

Here’s the angle almost nobody uses. A BI tool answers “what” (what’s the trend), but not always “why”. To explore, form hypotheses and blend data freely, an LLM like Claude or Gemini is formidable, provided you feed it a clean table.

The principle is simple. You export the result of an aggregated query (not the raw multi-gigabyte table, an LLM neither needs nor can handle it) as CSV, then hand it to the model with a real business question: “compare conversion rate by source over the last two months and tell me what’s slipping”. The CSV export is a one-liner from the console or via bq:

bq extract --destination_format=CSV \
  'project:dataset.bi_events_aggregated' \
  gs://my-bucket/export.csv

Better still: instead of exporting by hand, you can point the agent straight at BigQuery. That’s exactly what Claude Code for data analysts enables, querying GA4 and BigQuery in plain English, or a GA4 MCP server that connects your data to your AI agents. Classic BI and the LLM don’t compete: the dashboard watches, the LLM investigates.

Frequently asked questions

Do I have to go through BigQuery to connect GA4 to Power BI? No. GA4 has a direct connector to Looker Studio, and third-party connectors exist for Power BI. But as soon as you want long history, unsampled data and blending with other sources, BigQuery becomes the near-mandatory path: it’s the only place your GA4 data sits raw and complete.

DirectQuery or Import, which should I pick? Import by default. Only move to DirectQuery if your users need data refreshed by the minute, and you accept the query cost that comes with it. In the large majority of marketing reporting cases, an Import refreshed each night is more than enough.

How do I stop my BigQuery bill from exploding because of a dashboard? Three habits: expose an aggregated table rather than the raw tables, partition by date, and set a cost alert on the GCP project. The number-one trap is a live connection pointed at months of GA4 event data.

Key takeaways

Exporting your BigQuery data to a BI tool isn’t technically hard, all three connectors are native. The real work is upstream: flatten the nested GA4 data into a clean table, expose an aggregated version rather than the raw tables, and pick a snapshot mode (Import, extract, targeted query) over live by default. Do that and you’ll get fast dashboards with a predictable bill. And if you want to go beyond the “what”, plug a clean table into an LLM to attack the “why”. Start by building your flattened bi_events table today: it’s the brick all three paths depend on.