What you can take out of Google Analytics before you switch
If your GA4 contract is up for renewal, your budget is changing, or a residency decision is pending, start by separating what you can still take out from what is gone. Raw daily event data can be exported through the BigQuery export, and aggregated reports can be pulled through the Data API. Universal Analytics history cannot be recovered: Google states that access to Universal Analytics data ended the week of July 1, 2024, and data not exported by then was permanently deleted. If you still hold UA history, it lives only in files you saved, so check your archives now.
The daily BigQuery export gives you a complete, unsampled set of the previous day's raw events, which is the most useful feed for rebuilding history in another tool. Standard GA4 properties are capped at 1 million events a day through this export, so a busy property can silently lose data unless you filter low-value events or confirm your daily volume against that cap. The streaming export delivers current-day data within minutes but on a best-effort basis that can contain gaps, so do not treat it as a complete record. The Data API is governed by a token quota of 200,000 core tokens per property per day for standard properties, which means long histories pulled through it must be spread across several days. Confirm your event volumes and the Google Cloud project that holds the export before you commit to a timeline.
Retention settings are a common source of confusion. The data retention setting in GA4 limits how long event-level data is kept for explorations, but it does not remove standard reports, so the aggregated numbers you see in standard reports stay available for the period Google keeps them. The practical consequence is that raw event history older than your retention window may be gone from explorations while the BigQuery export remains your only copy of that detail. Export before you change any retention or deletion setting, and record which date ranges you have already secured.
Which GA4 data has a documented export path and what limits apply
This table lists each GA4 data type with a documented export path, its method, format and the limits Google publishes. Use it to see which history you can take out before a switch, and treat the table as a list of documented paths only: confirm current quotas and caps on Google's pages before you plan a bulk export.
| Data type | Export method and format | Documented limits |
|---|---|---|
| Raw daily events | Daily BigQuery export of the previous day's raw event data, complete and unsampled | Standard properties capped at 1 million events a day; Analytics 360 raised to 20 billion a day |
| Current-day raw events | Streaming BigQuery export, delivered within minutes | Best-effort delivery that may contain gaps, so do not treat it as a complete record |
| Aggregated reports | GA4 Data API, returned as report rows through API calls | 200,000 core tokens per property per day for standard properties; long histories must be spread over time |
| Reports from the interface | Manual download of report views from the GA4 interface | Limited to what the interface shows for the chosen date range; suits small, one-off pulls |
| Universal Analytics history | No export path remains in the interface or API | Access ended the week of July 1, 2024; unexported data was permanently deleted and is not recoverable |
| Retention-limited explorations | Explorations and retention-limited views | Retention settings cap explorations, not standard reports; confirm which views your exports cover |
Why the BigQuery export is the only complete raw copy
The daily BigQuery export is the component to rely on if you need a complete raw copy of GA4 events before a switch. It delivers a complete, unsampled set of the previous day's raw event data, which is what makes it useful for rebuilding history in your own warehouse. The streaming export covers the current day and delivers data within minutes, but only on a best-effort basis, so it can contain gaps. Treat the two as complementary feeds, not as one unbroken history. Any day you rely on for an audit or a migration should be checked against the daily export once it has completed.
Standard GA4 properties are capped at 1 million events a day through the daily export. If your property exceeds that, events beyond the cap are not exported for that day, so a silent gap can appear in your copy. Google suggests filtering events to stay under the cap, for example by excluding high-volume events you do not need for the migration. Check your own daily event volumes in the property before you plan the export. If you run Analytics 360, confirm the higher daily limit in Google's BigQuery export documentation for your contract.
The export only starts once the GA4 property is linked to a BigQuery project, and it does not backfill earlier days. History collected before linking cannot be recovered this way, so the link date sets the start of your raw record. Link the property and confirm that daily tables are arriving well before you set a cutover date, and record the first complete day in your migration log. Anything before that date must come from another source, such as the aggregated reports you can still export. Confirm the exact handling of historical days with Google before you rely on it.
What cannot be exported and what to do about each gap
Some GA4 data can be taken out before a switch and some cannot. The gaps below differ in cause: Google's deletion of Universal Analytics history, the daily event cap on BigQuery exports, retention settings that limit explorations, and aggregated figures that raw events cannot reproduce.
Universal Analytics history is gone
Google stopped processing standard Universal Analytics data on July 1, 2023, and access to its data, interface and API ended the week of July 1, 2024. Data not exported by then was permanently deleted and cannot be recovered. Check first whether any old report exports exist in your team's files or shared drives. If they do, keep them as read-only archive files with the date range and view settings recorded beside them.
Daily event cap on standard properties
A standard GA4 property can export at most 1 million events a day through the daily BigQuery export. Properties that exceed this lose events beyond the cap for that day. Filter out low-value events such as scroll or internal traffic before the export runs, and check the daily event counts in your property so you know which days were affected. Analytics 360 raises the daily limit to 20 billion events.
Exploration data limited by retention
Retention settings in GA4 cap how long event-level data remains available to Explorations, while standard reports keep their own history. A team that expects to rebuild a multi-year funnel from the interface may find the older event rows missing. Confirm which retention period your property uses, then export the event-level history you need to BigQuery or the Data API while it is still available.
Sampled and aggregated figures
Reports built from the Data API return aggregated results, and bulk pulls of long histories must be spread across the per-property daily token quota of 200,000 core tokens for standard properties. Figures that were sampled or aggregated in the interface cannot be rebuilt from raw events later. Accept the aggregated history in the new tool, and label it as imported summary data so analysts do not compare it with raw hits.
Why retention settings cap explorations but not standard reports
The event data retention setting in a GA4 property controls how long event-level data remains available to Explorations, the analysis tool that works on raw events. Standard reports are not governed by that setting, so a short retention period is easy to misread as a loss of the whole history. Before you change the setting, list every exploration your analysts rely on, including saved funnels, path analyses and segment comparisons, and export the underlying data for each one while it still exists. Because a retention change can delete data, treat it as a change request with a named owner.
Confirm the current values in your own property before you plan anything. Open the data retention settings under the property's data settings and record the period shown for event data and the period shown for user data, since the two are configured separately. Do not work from a figure remembered from an old training deck or contract. The value in your property is the one that determines what is kept, and anyone with the right property access can change it, so write down who holds that access during the migration window.
Pair the retention check with an export route. Explorations built on raw events can be rebuilt from the daily BigQuery export, which delivers a complete set of the previous day's raw event data once the link is in place and the data is stored under your control. Ask your analytics owner whether the link will cover history from before it was enabled, because a link created now will not reconstruct earlier days. Standard report figures can be pulled through the Data API, but that returns aggregated results within token quotas, so long histories must be extracted in stages.
The export sequence and how to verify each stage
This sequence moves GA4 history into storage you control before any switch, and each stage ends with a check you can record as evidence. Work through it in order, because later steps depend on the BigQuery link and the event volume measured earlier.
Inventory properties, reports and data streams
Start by listing every GA4 property, data stream, custom dimension, custom metric, audience and report your team relies on. Include the Google Ads and Search Console links, because they shape what a replacement must reproduce. The analytics owner or a GA4 administrator should do this, ideally with a marketing lead who knows which reports are used in decisions. The step is done when the inventory is a shared document with a named owner for each property and a list of reports that need archiving. Keep the inventory as your first piece of evidence for the migration file.
Link the BigQuery export and confirm the first tables
In the GA4 admin settings, link the property to a Google Cloud project and enable the daily export, and enable the streaming export if you need current-day data. Google describes the daily export as a complete, unsampled set of the previous day's raw events, while the streaming export arrives within minutes on a best-effort basis and may contain gaps. Check that the events_ tables appear in the dataset after the first daily run, and confirm the streaming tables carry data for the current day. Record the link settings, the dataset location and the table names as evidence. Export starts only from the point of linking, so history before this step has to come from other sources.
Measure daily event volume against the export cap
Standard GA4 properties can export at most 1 million events a day through the daily BigQuery export, and Google suggests filtering events to stay under that cap. Query the exported tables to count events per day over a representative period, including peak campaign days. Compare the highest daily count with the cap and note which event names account for most of the volume. If a day approaches the limit, decide with the analytics owner which low-value events to exclude from the export. Analytics 360 properties have a much higher daily limit, so confirm the property type first. Save the daily counts and the filter decision as evidence.
Pull aggregated reports through the Data API in batches
Use the GA4 Data API to request the reports in your inventory, one report definition at a time, with date ranges split into smaller windows. The API returns aggregated reports, and its quotas for standard properties are set in core tokens per property per day, so large historical pulls should be spread over several days rather than run at once. Log each request with its date range, report name, row count and the remaining quota reported in the response where available. The step is complete when every report in the inventory has a stored output for every planned window. Keep the request logs and the raw response files together.
Download report snapshots for archive
Export the key reports from the GA4 interface as CSV or spreadsheet files, covering the same date ranges used in the API pulls. This gives you a human-readable copy that does not depend on any query code. Store the files in a location with access controls and retention rules set by your data protection lead, and record who exported them and when. Google states that Universal Analytics data not exported by the end of the week of July 1, 2024 was permanently deleted and cannot be recovered, so treat the GA4 archive as the only copy of anything you have not yet moved. Keep the file manifest, with checksums if your team uses them, as evidence.
Verify row counts and totals on sample days
Choose several sample days, including a low-traffic day, a high-traffic day and a day with a known campaign. For each day, compare the event count in the BigQuery export with the event count in the GA4 interface, and compare API report totals for sessions, users and key conversions with the same figures in the interface. Small differences can come from processing timing, streaming gaps or report-level thresholds, so document the size of each gap and the cause you identify. A sample day passes when the variance is explained and accepted by the analytics owner. Keep the comparison table, with dates, queries and screenshots, as the verification record.
Which exported data can be loaded into Matomo, Plausible or PostHog
Matomo's Google Analytics Importer, a free plugin for Matomo On-Premise under the GPL v3+ license, imports reports from a Google Analytics property into a new Matomo site. It brings over aggregated report data, not raw visit and action data. That distinction decides what your team can still do with the history after the import finishes.
- Visitor Log is unavailable: Individual visits cannot be reviewed for imported periods because the raw hits are not carried over.
- Segmentation does not apply: Segments built on visit-level data do not work on imported reports.
- Some reports are not imported: Funnels, for example, are not part of the imported set, so rebuild them on new data.
- Ecommerce and custom reports are limited: The Ecommerce Log and Custom Reports do not work for imported reports.
- Historical and live data sit side by side: Imported aggregates remain reports, while tracking from cutover onward keeps raw detail.
Confirm the current importer limits with Matomo's FAQ on Google Analytics import before you plan which dashboards need to be rebuilt.
Plausible Community Edition offers a Google Analytics 4 import that loads aggregated history into a new site. Like Matomo's importer, it works from report-level figures rather than individual events, so the imported period behaves as a set of daily summaries. Plan your dashboards around that shape.
- Daily aggregates only: Imported history appears as totals by day and dimension, not as individual sessions.
- Raw-event views do not reach back: Features that depend on event-level data will show nothing for the imported period.
- Goals and revenue must be recreated: Configure goals in Plausible yourself rather than expecting them to carry over.
- Some detail is lost: UTM detail and exit pages are among the items you should check against the import output.
- Tracking changes at cutover: Replace the Google tag with the Plausible script on the same date you start relying on the imported history.
Check the current Plausible import documentation for the exact dimensions and date range supported before you commit to a cutover plan.
PostHog documents a scripted migration from Google Analytics that runs through the BigQuery export. Your GA4 raw events are exported to BigQuery and then mapped and sent into PostHog. This keeps event-level data, which is the main difference from the aggregated importers above. The route depends on your BigQuery export being in place before the data it needs is gone.
- Source is the BigQuery export: The GA4 daily export provides complete raw events for the previous day, so the history you can move is bounded by what you exported.
- Mapping is manual work: GA event names such as page_view must be mapped to PostHog events and properties by your team.
- Standard property cap applies: Standard GA4 properties export at most 1 million events a day, so filter events to stay under the limit or plan longer exports.
- Managed imports cover other sources: PostHog's managed imports from Mixpanel, Amplitude, or JSONL files in S3 cover at most one year per job, and events are not deduplicated.
- Paid plan needed for import features: The historical import features require a paid product analytics plan, and imported events cannot be selectively deleted.
Ask PostHog to confirm the current Google Analytics migration steps and any plan requirements for the import before you start the export.
What to plan before the GA4 contract or tagging ends
Exporting GA4 data is mostly a set of ownership, timing and format decisions made before anything is switched off. The cards below cover the Google Cloud project, the export start date, the archive, the API access and the tagging changes, in the order they tend to block each other.
Owner of the BigQuery project
The daily and streaming exports write into a BigQuery dataset inside a Google Cloud project, and that project is billed separately from the GA4 property. Name a person or team who owns the project, its billing account and its IAM roles before the export is linked. Confirm who can read the dataset after the GA4 property is retired, because access to the export does not depend on the property staying active.
Start date for the daily export
The daily export delivers a complete set of the previous day's raw events, so it can only backfill from the day it was linked onward. Set the date by which the link must be running and confirm it in the project before the switch-off date. Any gap between the link date and the cutover is data you cannot recover from GA4 through this route.
Event volume against the daily cap
Standard GA4 properties can export at most 1 million events a day through the daily BigQuery export, and Google suggests filtering events to stay under the cap. Check the event count per day in the property before linking, because a day above the cap will not export in full. Analytics 360 raises this limit, so confirm which property type you hold before planning the export volume.
Archive format and storage location
Decide where the exported tables will live after the project changes, which format they will be copied into and how long they must be kept. Confirm the storage location, the retention period and the encryption and access controls that apply to the archive. Record the dataset schema alongside the files, so the data can be read later without the original GA4 interface.
Data API service accounts and quota use
Bulk extraction of reports through the GA4 Data API uses core tokens against a daily quota of 200,000 per property for standard properties. Create dedicated service accounts with read-only access to the property, record which pipelines use them and estimate their token use per day. Long histories have to be spread over several days, so start these jobs early rather than in the last week.
Tagging and consent changes at cutover
Data collection stops when the gtag snippet, the Tag Manager container or the consent configuration that fires GA4 is removed or changed. List every site and app that loads these tags, and schedule removal together with the new tracker so there is no period with neither tool running. If a consent banner gates GA4 today, decide whether the replacement needs one, because that depends on its configuration and the rules in your jurisdiction.
Questions teams ask before exporting GA4 data
Can we export our GA4 data without outside help?
Yes, a team with a Google Cloud project, a GA4 property with the right access and someone comfortable with BigQuery and the Data API can run the export in-house. The daily BigQuery export gives you a complete, unsampled set of the previous day's raw event data, and the streaming export adds current-day data on a best-effort basis that may contain gaps. The harder part is usually not the export itself but deciding what to keep, how to reshape events for the new tool and how to prove the copy is complete. Teams without that experience often bring in an implementation partner for a fixed-scope export, which DeployOpen offers, with scope and deliverables agreed in writing before work starts.
What drives how long a GA4 data export takes?
The main drivers are the volume of events in the property, how many reports and dashboards you need to rebuild, how far back the history must reach and whether data must stay in a specific region. Standard GA4 properties can export at most 1 million events a day through the daily BigQuery export, so a high-traffic property may need event filtering or several days of backfill. Bulk extraction through the Data API is limited by quotas of 200,000 core tokens per property per day for standard properties, so long histories have to be spread over time. Residency rules can add review steps before data is moved between regions. Ask any provider to break its estimate down by these drivers and to state the assumptions behind each one.
What internal access and skills does the export need?
Plan for a named owner on your side, someone who can approve access and make decisions about which events and reports matter. The technical work usually needs BigQuery access to the linked dataset, permission to read the GA4 property through the Data API and a Google Cloud project with billing enabled for the export. Engineers should understand GA4's event model, including how parameters and user properties are nested, because that shapes how events map to another tool. Your security team should review who holds the service accounts and where the exported files are stored. Keeping these roles written down before work begins reduces delays later.
Can we still recover Universal Analytics history?
No. Google states that standard Universal Analytics properties stopped processing data on July 1, 2023, and that access to Universal Analytics data, the interface and the API ended the week of July 1, 2024. Data not exported by then was permanently deleted and is not recoverable. If you still hold Universal Analytics exports, they are the only copy of that history and should be kept under your retention policy. Any migration plan should treat GA4 and its BigQuery export as the only sources that can still be taken out, and should state clearly which years of history are gone.
Do BigQuery export costs apply, and how do I confirm them?
Export to BigQuery is set up through Google Cloud, and storage and query charges are billed by Google under your own Google Cloud account, not by DeployOpen. Whether a specific charge applies depends on your Google Cloud billing setup, the volume of data exported and how often the dataset is queried, so confirm current terms with Google's billing documentation before you start. Ask your finance and cloud teams to model storage for the full history you plan to keep, and to include the cost of any extra queries used to validate the copy. Any quote you receive should show Google Cloud costs separately from implementation fees.
How do we confirm a GA4 export is complete?
Confirm completeness by comparing the exported data with GA4's own reports for the same dates and by checking for gaps. Compare event counts per day and per event name between the BigQuery tables and the standard reports, and note the differences that come from filtering, bot exclusion or streaming gaps. Check that the daily tables for every date in scope are present, and that the Data API returns the same totals for the aggregated reports you plan to rebuild. Record the validation results, the queries used and who signed off, so auditors and internal reviewers can trace the export. DeployOpen prepares these controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit reports.
How DeployOpen scopes and delivers a GA4 data export
DeployOpen treats the GA4 export as a written, fixed-scope engagement that starts with what your properties, BigQuery links and reporting needs require. We plan the export paths, build and test them inside your own Google Cloud and server environment, and hand over documented, verified copies of the data you need before any cutover.
How we scope
- Inventory every GA4 property, data stream and BigQuery link that holds data you need to keep.
- Measure daily event volumes against the 1 million event daily export cap on standard properties.
- Agree in writing which tables, date ranges and Data API reports are in and out of scope.
How we build
- Configure the daily BigQuery export and decide whether the streaming export is also needed.
- Build extraction jobs that spread Data API requests across time to stay within token quotas.
- Test row counts and date coverage against GA4 reports, and document known gaps such as best-effort streaming data.
How we hand over
- Deliver a runbook covering export schedules, storage locations, access controls and retention settings.
- Provide a data dictionary mapping exported GA4 fields to the target analytics platform.
- Confirm with you which exports are complete before any Universal Analytics or GA4 access is changed.
How we support
- Offer ongoing support, upgrades and continuous testing of export jobs as a retainer.
- Review export jobs when Google changes quotas, schemas or export behavior.
- Ask your own auditors or certification bodies to assess the controls, since DeployOpen prepares evidence but does not issue attestations.
