Data warehouse
BigQuery for ecommerce stores
BigQuery is where a store keeps the raw version of its numbers: every analytics event unsampled, every order and refund, and the cost side from the ad platforms, all queryable together. Cohort behaviour, contribution by customer age and repeat purchase timing are rarely questions a reporting interface was designed to answer. We land the data and model the tables a store actually asks questions of.
BigQuery
Data warehouse · by Google. A text wordmark, not a logo: we are not affiliated with the vendor and make no claim to its trademarks.
What we do with it
The work inside BigQuery
The GA4 export as the event record
GA4 offers a native export to BigQuery that writes event-level rows with their parameters and item arrays intact. That removes the thresholds and card-level aggregation of the interface, so a store can count sessions to a specific collection or the path to a specific product without the report deciding what is too small to show.
Orders, refunds and customers alongside
Store data is loaded from the platform so the warehouse holds what actually happened financially: order value net of refunds, discount used, first versus repeat order, product mix and shipping destination. Once orders sit beside behaviour, revenue questions stop depending on whichever tag was firing that week.
Ad cost and platform data in the same place
Spend, impressions and platform-reported conversions are loaded per channel so profitability can be calculated on the store's own margin, not on a platform's return figure. Google Ads has a documented transfer path; other platforms need a connector, and we pick the simplest one that keeps running unattended.
Modelled tables the team can query
Raw exports are awkward to query directly, so we build a modest set of scheduled tables: sessions with channel, orders with customer sequence, a customer table with first order date, and a daily channel summary. Reports and dashboards read those, which keeps definitions consistent and scans small.
Cohorts, repeat purchase and payback
With order sequence and acquisition date in one table, the questions that decide budget become answerable: how quickly a cohort places a second order, what a customer acquired through a discount is worth by month six, and how long acquisition cost takes to come back by channel and category.
Feeding reporting and audiences back out
The warehouse is not the destination. Modelled tables feed the reporting layer, and segments built there can be pushed back to the tools that act on them, so a group such as customers overdue for a reorder becomes a campaign rather than a slide.
When it fits
BigQuery is the right tool when
Stores selling through more than one storefront or channel
Two Shopify stores, a marketplace and a wholesale channel cannot be added up inside any one interface. A warehouse is the only place the total exists in a form somebody can check.
Merchants who keep hitting the limits of a report
When the answer needs two dimensions the interface will not combine, or a segment defined by order history rather than sessions, the question is a query rather than a report.
Brands making retention and acquisition trade-offs
Deciding between spending on new customers and spending on repeat purchase needs cohort and payback numbers. Those come from order-level history, which is exactly what a warehouse holds.
What to watch
Where accounts drift
Facts about defaults and costs, not criticism. These are the settings we check on every account.
Query cost follows the data each query reads
Billing is driven by storage and by how much data a query scans, so partitioning by date, clustering sensibly and querying modelled tables instead of raw exports is the difference between an affordable warehouse and a surprising invoice.
The GA4 export has no history
The export begins writing from the day it is linked and does not backfill earlier data. Linking it early, even before anyone plans to query it, is the cheapest decision available in analytics.
Event data needs governance
Raw exports can carry identifiers that count as personal data. Access, retention and what is hashed or excluded should be decided when the project starts, not when someone asks whether an address ended up in a table.
Models drift when tracking changes
A renamed event or a new checkout flow quietly breaks a query that still returns a number. Every model needs an owner and a check that runs when the tracking layer changes.
Is a data warehouse worth it for a store doing modest volume?
Often not yet. If the questions being asked can be answered in GA4 and the store's own reports, the warehouse adds cost and maintenance for no new decision. The point at which it pays is when a real budget question cannot be answered any other way.
Does moving data into BigQuery fix attribution?
It does not create identity a store never collected, but it lets you compare models on the same rows rather than trusting each platform's own view. You can also hold platform-reported conversions next to actual orders and see how the difference behaves over time.
Do we need a data engineer to keep this running?
For an ecommerce warehouse of this size, no. Scheduled queries and a small set of documented tables are maintainable by whoever owns analytics, provided the models are kept few and named clearly. Complexity, not volume, is what creates a staffing problem.
What does it cost to run for an online store?
It depends on how much event data the store generates and how often queries scan it. Storage is the small part. We size it by estimating scan volume for the reports that will actually run, then design tables so the daily dashboard reads a summary rather than years of raw events.
Delivered through
Works alongside
Find the leak.
A free Growth Analysis ranks what your store should fix first, by revenue at stake.