Backfilling GA4 data in BigQuery means importing historical GA4 data into your BigQuery project.
If you are like me, you may have been collecting data in your GA4 property for years.
But if you have only recently connected GA4 with BigQuery, you may not have all the historical data in your BigQuery project.
This is because, by default, the GA4 data is imported to BigQuery only from the date you first connected your GA4 property to your BigQuery project.
If you want historical GA4 data in your BigQuery project, you will need to backfill GA4 data in BigQuery by creating a new data transfer.
Google native feature for backfilling GA4 data in BigQuery.
Google provides a native feature for backfilling GA4 data into BigQuery. However, this setup exports pre-aggregated, report-style GA4 tables and is still not a replacement for raw data exports.
You still can’t backfill historical events_* data tables, only the new summary tables. So, if you didn’t link GA4 to BigQuery a year ago, you still can’t recover that raw event-level data.
When you create a new data transfer, it does not affect your existing raw data exports.
Instead, it creates new summary tables and views like the one below (check the top part of the screenshot), which reflect standard GA4 UI reports and are transformed versions of Google’s internal reporting logic.
>> These are summarized tables. You don’t get raw event timestamps, event parameters, or full user/session flows.
>> These tables only include what Google chooses. No custom dimensions, custom events, or custom joins unless they have been pre-modelled.
>> Many tables lack user_pseudo_id or session_id, which limits advanced modeling like session stitching, pathing, or attribution.
>> These tables inherit the same limitations as the GA4 UI, thresholding, sampling (possibly), and lack of control.
>> The aggregated tables are built from GA4 report data, not from raw event data. Since these tables are meant to mirror GA4 UI reports, it’s likely they inherit the same privacy threshold logic.
Most of the ga4_* tables are actually views on top of base tables (p_ga4_), which may slow down queries or cost more over time.
If you want to backfill historical events_ data tables, the recommended approach is still a paid connector like ‘Supermetrics for BigQuery. ‘
If you have never linked GA4 to BigQuery before and you don’t want to use a paid connector, you can now backfill some historical data via the native feature.
Even though it’s aggregated, you at least get directional trends and reporting baselines.
The main downside of using multiple summary tables and views in BigQuery is a combination of higher query costs, slower performance, and complexity in managing inconsistent logic across views.
>> More views = more data scanned = higher costs.
>> If the views join or aggregate large datasets (even if they’re pre-aggregated), this can slow dashboard performance or increase latency for real-time querying. This is especially noticeable in Looker Studio or scheduled report jobs.
>> Having many narrow, summary-specific tables leads to fragmented reporting logic, duplicate metrics, overlapping metrics, inconsistent definitions, and hard-to-maintain SQL.
>> More tables = more clutter = harder governance.
Therefore, I am unlikely to use/recommend summary tables. But your call.
Prerequisites for backfilling GA4 data in BigQuery.
Before you can backfill GA4 data in your BigQuery project: