TL;DR
GA4's standard reports are aggregated, sampled at high volumes, and limited to the dimensions Google chooses to surface. The BigQuery export removes those constraints by streaming the raw event data into Google Cloud, where you can query it with SQL. For Shopify merchants, this means access to every purchase event with its transaction_id, client_id, session_id, currency, traffic source, and all custom parameters. The cost is minimal for most stores (under $1/month for storage). The question is not whether you can afford it. The question is whether you need it, and the answer depends on your ad spend, attribution complexity, and willingness to write SQL or hire someone who does.
Key Takeaways
- The BigQuery export creates one table per day in your GCP project containing every GA4 event as a row, with all event parameters, user properties, and traffic source data preserved.
- Setup requires a Google Cloud Platform project with billing enabled and takes about five minutes: GA4 Admin > BigQuery Links > Link.
- Cost is low for most Shopify stores. BigQuery charges $0.02/GB/month for storage and $5/TB scanned for queries. A store with 50K events/month stores roughly 500MB/year, well under $1/month.
- Server-side events sent via the Measurement Protocol appear in BigQuery with collected_traffic_source populated by the campaign_details event. Events using synthetic client_ids (admin/POS orders) appear as separate user_pseudo_id values.
- The decision to set up BigQuery export depends on ad spend and attribution complexity, not store size.
What is the GA4 BigQuery export?
The BigQuery export is a one-way data pipeline from your GA4 property to a Google BigQuery dataset. Once linked, GA4 streams every event it collects into BigQuery as structured data. One table is created per day (named events_YYYYMMDD), and each row represents one event.
Every event parameter, user property, and traffic source field is included. Nothing is aggregated. Nothing is sampled. Nothing is dropped by data retention settings (BigQuery data persists until you delete it, unlike GA4's standard 14-month retention limit).
This is the same data that powers GA4's standard reports, but in raw form. Instead of clicking through pre-built dashboards, you write SQL queries to extract exactly what you need.
For Shopify merchants, the practical value is access to purchase-level data with full context: which traffic source, which client_id, which session, what currency, what items, and every custom parameter your tracking sends.
How to set it up
The setup is straightforward and takes about five minutes.
Prerequisites:
- A Google Cloud Platform (GCP) project with billing enabled. You can use the same Google account that owns your GA4 property.
- Editor or Admin access to the GA4 property.
- BigQuery API enabled in your GCP project (it is enabled by default on new projects).
Steps:
- In GA4, go to Admin > Product Links > BigQuery Links.
- Click "Link."
- Select your GCP project.
- Choose a data location (pick the region closest to you for lowest latency, though this rarely matters for analytics queries).
- Select "Daily" export (sufficient for most use cases). "Streaming" export sends data in near-real-time but costs more.
- Choose which events to export. The default is all events, which is correct for most setups.
- Click "Submit."
Data begins flowing within 24 hours. The first table (events_YYYYMMDD) appears in your BigQuery dataset the next day.
What does it cost?
BigQuery pricing has two components: storage and queries.
Storage: $0.02 per GB per month for active storage. A Shopify store generating 50,000 GA4 events per month produces roughly 500MB of data per year. That is about $0.01/month. Even a high-traffic store generating 500,000 events per month stays under $0.10/month for storage.
Queries: $5 per TB scanned. A typical analytics query scans 10-100MB of data, costing fractions of a cent. Running 100 queries per month on a year of data for a mid-size store costs under $1.
Streaming export: If you choose the real-time streaming option instead of daily, there is an additional per-row charge. For most Shopify merchants, the daily export is sufficient and streaming is unnecessary.
The bottom line: the BigQuery export is effectively free for stores under 100K events/month. It becomes a rounding error in your GCP bill for stores at 10x that volume.
Do you actually need it?
Not every store benefits from raw event data. Here is a practical decision framework.
Ad spend under $5K/month: GA4's standard reports are almost certainly sufficient. The Acquisition, Monetization, and Exploration reports give you channel performance, purchase attribution, and funnel analysis without writing SQL. Unless you have a specific question that standard reports cannot answer, the BigQuery export adds complexity without proportional value.
Ad spend $5K-$20K/month with cross-channel attribution needs: Consider it. At this spend level, you likely run campaigns across Google, Meta, and possibly TikTok. Each platform reports its own attributed revenue using its own model and window. GA4's standard cross-channel reports help, but they are limited by the dimensions Google exposes. BigQuery lets you build custom attribution models, compare platform-reported conversions against GA4's data-driven attribution at the event level, and calculate blended ROAS with your own logic.
Ad spend above $20K/month, or custom LTV modeling, or data warehouse integration: Likely worth it. At this level, you probably have (or need) a data analyst, a BI tool (Looker, Tableau, Power BI), or a custom data pipeline. BigQuery is the standard feed for these workflows. Customer LTV calculations that factor in repeat purchase behavior, subscription renewals, and refund rates require event-level data that GA4's UI does not expose in sufficient granularity.
Stores with subscription revenue or complex order types: Worth considering regardless of ad spend. If you need to separate first-purchase attribution from renewal attribution, or analyze customer cohorts by acquisition channel across multiple order types, the BigQuery export gives you the raw data to build those analyses.
How server-side events appear in BigQuery
Events sent via the GA4 Measurement Protocol (server-side) appear in BigQuery alongside browser-collected events. The key fields to understand are:
user_pseudo_id: This is the client_id value. For browser-collected events, it comes from the _ga cookie. For server-side events, it is whatever client_id the tracking app sent. If the app uses a synthetic client_id for admin or POS orders (like server.{customerId}), those events appear as separate user records in BigQuery. They do not merge with the customer's browser sessions.
collected_traffic_source: This field is populated by the campaign_details event. When a tracking app sends a campaign_details event before the purchase event (as WeltPixel Conversion Tracking does), the traffic source data appears in this field on subsequent events in the same session. For orders with no real attribution, this shows source: (direct) and medium: (none).
event_params: All event parameters are stored as key-value pairs in a repeated record. For purchase events, this includes transaction_id, value, currency, and any custom parameters the tracking sends. WeltPixel Conversion Tracking sends transaction_id, client_id, session_id, and currency on every purchase event, all of which are accessible in BigQuery.
A practical BigQuery query to pull purchase events with their attribution:
SELECT
event_date,
user_pseudo_id,
(SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'transaction_id') AS transaction_id,
(SELECT value.double_value FROM UNNEST(event_params) WHERE key = 'value') AS revenue,
(SELECT value.string_value FROM UNNEST(event_params) WHERE key = 'currency') AS currency,
collected_traffic_source.manual_source AS source,
collected_traffic_source.manual_medium AS medium
FROM `your-project.analytics_PROPERTY_ID.events_*`
WHERE event_name = 'purchase'
AND _TABLE_SUFFIX BETWEEN '20260501' AND '20260531'
ORDER BY event_date
This gives you one row per purchase event with the transaction ID, revenue, currency, and traffic source for the session. You can join this with your Shopify order data (exported separately) to reconcile GA4 attribution against Shopify's order records.
Multi-pixel setups and BigQuery
If your store runs multiple GA4 pixels (for example, one for production reporting and one for testing or agency access), each property has its own BigQuery export. This means you can dedicate a separate GA4 property to BigQuery analysis without affecting your production property's settings, filters, or user access.
WeltPixel Conversion Tracking on the Plus plan supports multi-pixel configuration, allowing you to send events to multiple GA4 properties simultaneously. One common use case is a primary property for day-to-day reporting in GA4's UI and a secondary property linked to BigQuery for raw data analysis. The multi-pixel tracking guide covers when this makes sense and when it is unnecessary overhead.
BigQuery export vs GA4 data retention
GA4's free tier retains detailed event data for a maximum of 14 months. After that, event-level data is deleted and only aggregated reports remain. The data retention guide explains this limitation in detail.
BigQuery has no retention limit. Data stays in your dataset until you explicitly delete it. This is the most straightforward solution to GA4's 14-month retention constraint. Once the export is active, every event is preserved permanently in your GCP project. You own the data, and it does not expire.
If you set up the BigQuery export today, you start collecting from today forward. It is not retroactive. You cannot backfill the historical data that GA4 has already deleted. This is why setting it up early matters even if you do not plan to query it immediately.
Common mistakes
Not setting up early enough. The export only captures data from the date you link it. Every day without the link is data you cannot recover. If you think you might need raw event data in six months, link it now. The cost is negligible and the data accrues automatically.
Using streaming export when daily is sufficient. The streaming export is more expensive and adds complexity. Unless you are building real-time dashboards or alerts, the daily export covers all standard analytics and reporting use cases.
Querying without partition filters. BigQuery tables are date-partitioned. Queries without a date filter (_TABLE_SUFFIX clause) scan all tables, which increases cost. Always include a date range.
Assuming BigQuery data matches GA4 UI exactly. The BigQuery export is raw, unfiltered data. GA4's UI applies bot filtering, data thresholds (for privacy), and attribution modeling. Your BigQuery query results will not match GA4's reports exactly. They are the same raw events, but the UI applies transformations that BigQuery does not.
FAQ
Can I use BigQuery with GA4's free tier?
Yes. The BigQuery export is available on all GA4 properties, including free ones. You pay Google Cloud for BigQuery storage and queries, but the GA4 side has no additional cost.
Do I need to know SQL?
To query BigQuery directly, yes. Alternatively, you can connect BigQuery to a BI tool (Looker Studio is free and connects natively) and build reports with a drag-and-drop interface. But the initial setup and custom queries require SQL.
How does this relate to the Measurement Protocol?
The Measurement Protocol sends events to GA4. The BigQuery export receives events from GA4. They are different ends of the pipeline. Events sent via the Measurement Protocol (server-side) appear in BigQuery just like browser-collected events. The Measurement Protocol guide covers the sending side.
Read Next
- GA4 Data Retention on Shopify: Why You Lose Data After 14 Months explains the retention limits that make BigQuery export valuable as a long-term data store.
- Multi-pixel Tracking for Shopify covers when running a dedicated GA4 property for BigQuery makes sense.
- GA4 Measurement Protocol on Shopify explains how server-side events reach GA4 and how they appear in BigQuery.
- GA4 (not set) on Shopify covers why some BigQuery purchase rows have empty traffic source fields.
Sources
(No external sources cited.)