Switching analytics tools should not reset your reporting history.
That is the quiet problem behind most analytics migrations. Your new setup starts collecting clean data today, but your team still needs last month, last quarter, and last year. Without that history, every dashboard has a hard break in the timeline.
d8a.tech is already designed to work alongside GA4, which gives teams time to build fresh d8a history before fully switching. Because d8a.tech is highly compatible with GA4’s collected data points, that parallel run gives you a clean path instead of a hard migration cliff.
Now the switch is even more comfortable: if you have GA4 BigQuery export enabled, d8a.tech can import that existing history into the same reporting environment as your new d8a data.
Why Historical Import Matters
For marketing leaders, digital analysts, BI teams, and data engineers, analytics migration is not just a technical task. It affects planning, reporting, and trust.
If your new analytics dashboard starts empty, you lose context. You cannot compare this campaign to the previous one. You cannot see whether traffic is seasonal. You cannot tell whether a conversion dip is caused by the website, the market, or the migration itself.
Historical import fixes that gap. It gives your new d8a setup a useful starting point instead of forcing the team to wait months before the dashboard has enough history to matter.
This is especially important when GA4 BigQuery export has already been enabled. In that case, the historical data is sitting there. The problem is that GA4’s BigQuery schema is not designed for clean reporting. It is nested, awkward to query, and missing some of the structure teams expect from an analytics model.
The importer turns that source into something more usable.
What The Importer Does
The importer reads historical event data from GA4 BigQuery export tables and migrates it into d8a.tech.
% ./d8a-importer --config examples/ga4-bigquery.yaml run
Starting preflight: checking BigQuery source scope
Preflight OK: 52/52 tables found, estimated scan 160 MiB, source size 230 MiB, source rows 246,400
Starting import: 246,400 source rows across 52 matching tables
[--------------------] 2.3% | rows 5,667/246,400 | sent 4,378 | skipped 1,289 | failed 0 | 161.9 rows/s | elapsed 35s | ETA warming up | shard 20260405
[####----------------] 22.8% | rows 56,179/246,400 | sent 30,837 | skipped 25,342 | failed 0 | 510.7 rows/s | elapsed 1m50s | ETA warming up | shard 20260414
[###########---------] 59.5% | rows 146,608/246,400 | sent 82,050 | skipped 64,558 | failed 0 | 763.6 rows/s | elapsed 3m12s | ETA 1m30s | shard 20260506
Import complete: read 246,400 rows, sent 126,700 events, skipped 119,700, failed 0 in 4m42s (873.8 rows/s)The importer runs from the CLI, so the migration is explicit and auditable.
Known fields are mapped into the d8a schema where possible, so the data becomes easier to report on than raw GA4 BigQuery exports. Original GA4 values are preserved as custom parameters, and imported events are marked with source metadata so teams can identify historical BigQuery data later.
That gives teams historical continuity without pretending the original GA4 export was cleaner than it really was.
Built To Control BigQuery Cost
GA4 BigQuery export tables can be large, especially for properties with months or years of data. The importer is built to avoid careless full-scan backfills where possible, keeping the migration safer to run on real production datasets.
Technical Notes
Under the hood, the importer makes a few deliberate choices to keep the migrated data useful.
- Source and access: The importer reads GA4 BigQuery export tables using standard Google Cloud service account credentials.
- Data quality safeguards: The importer focuses on data that can be modeled reliably. It imports consented data only, because non-consented GA4 BigQuery rows do not have meaningful identifiers for forming sessions or assigning a useful user ID. Since GA4 BigQuery exports also do not include the original user agent, the importer creates a synthetic one from available source data to keep technology detection accurate and preserve the highest possible data quality.
What To Do Next
If you are already using d8a.tech and need historical GA4 continuity, contact us about running a GA4 BigQuery import for your account.
If you are still planning a migration from GA4, enable GA4 BigQuery export now if you have not already. The earlier you start exporting, the more history you will have available when you move.
For Cloud or on-premises import options, contact d8a.tech.