Google BigQuery Data Storage and Refresh

This guide explains where your exported data is stored, what happens when you run an export again, and how to keep earlier data when needed.

To connect your project, start with Set up the connection.

Dataset and table names

Adzviser uses your Dataset Prefix, workspace name, and data source to name each dataset. Within that dataset, tables use the source name, with a report segment appended when the source returns separate reports.

Dataset: <prefix>_<workspace>_<source>
Table:   <source> or <source>_<segment>

Names keep letters, numbers, and underscores. Other characters become underscores; repeated underscores are collapsed, and underscores at the beginning or end are removed. For example, Google Ads becomes Google_Ads. The same cleanup applies to column names returned by the source.

For this example:

The dataset is Adzviser_Acme_Google_Ads. A report segment named campaign is written to:

my-project.Adzviser_Acme_Google_Ads.Google_Ads_campaign

A source result without separate report segments uses the table name Google_Ads instead. Another source in the same workspace gets its own dataset, such as Adzviser_Acme_HubSpot.

Adzviser creates the dataset and tables when needed and reuses them on later exports. Pipeline names and run IDs are not part of these names. Renaming a pipeline does not create a separate table. Changing the dataset prefix or workspace name can change the destination name; existing data is not automatically moved to the new dataset.

Repeat exports and backfills

For a table with returned data, Adzviser refreshes the requested dates in two steps:

1. Delete existing rows whose first column matches the requested date intervals or their date-range labels.
2. Load the newly retrieved rows into the same table.

The first column is normally the reporting date. This matching also handles an exact range label such as 2026-09-01 - 2026-09-30. It is date-based replacement, not a merge by account, campaign, or another record ID.

For example, after exporting September 1–25, running September 20–25 again replaces matching rows for those six days. September 1–19 remains. If you request separate intervals, such as September 1–3 and September 20–25, the refresh targets those intervals and leaves the intervening dates alone.

Tables or report segments with no returned data rows are skipped, leaving their existing data unchanged. An empty response therefore does not automatically clear previously exported rows. Keep time granularity consistent within a table: changing between daily rows and weekly or monthly aggregates does not guarantee that older aggregates will be removed.

Deletion and loading are separate operations. If loading fails after deletion succeeds, matching rows can be missing until a successful rerun. Check Export History, resolve the reported error, and rerun the affected dates.

Pipelines that share a table

Pipelines using the same project, prefix, workspace, source, and report segment write to the same table. Different pipeline names, account selections, or metric selections do not automatically separate their output.

Because replacement uses dates rather than account IDs, one pipeline can remove rows written by another for the same dates before loading its own results. Avoid overlapping runs into a shared table. If exports need independent tables, configure separate destination prefixes or projects.

The _exported_at column

Each loaded row receives an _exported_at value containing the export time in UTC. It tells you when Adzviser prepared that batch for loading, not the date the marketing activity occurred or the exact time the load finished.

Rows from earlier, untouched dates keep their earlier values. Refreshed rows receive a new value. Exports processed in batches can have different values across batches, so _exported_at is not a unique pipeline run ID and does not retain previous row versions.

Keeping earlier data

The Export History tab records runs, their status, and destination tables. It does not store a separate table snapshot for each run. For recovery or longer retention, configure BigQuery's own features separately:

• Time travel lets you query or recover earlier table data within the dataset's configured recovery window. This is limited recovery, not an indefinite archive. See BigQuery time travel.
• Table snapshots preserve a table at a particular point in time and can retain it beyond the time-travel window. Your Google Cloud administrator can create or schedule snapshots and set their expiration and access controls. See BigQuery table snapshots.

Adzviser does not create or schedule these snapshots. A snapshot has read-only data, but can still expire or be deleted by an authorized user; it is not automatically an immutable archive. Choose a retention schedule and storage budget appropriate to the history you need.