BigQuery Backfills Now Cap at 37 Months — and Can Overwrite Your Data

What Changed on June 1, 2026#

Google reversed an 18-month-old retention policy, capping granular BigQuery backfills at 37 months and catching most WooCommerce store owners off guard.

On May 1, 2026, Google announced that its BigQuery Data Transfer Service connectors for Google Ads, Search Ads 360, and GA4 would stop populating backfill runs for dates older than 37 months from the current date. The change took effect June 1, 2026. The announcement reversed a November 2024 policy that had promised advertisers an 11-year window for granular data access — a promise that lasted barely 18 months.

The connectors themselves still work. Scheduled transfers still run. But any attempt to pull historical data beyond the 37-month boundary now returns empty or partial results. For Google Ads API queries, that means a DateRangeError.INVALID_DATE error. For GA4 backfills, it means something worse.

Google’s rationale was alignment with the 37-month caps already enforced by other advertising platforms. The practical consequence for WooCommerce store owners is that the BigQuery Data Transfer Service — the tool most stores use as their analytics safety net — now has an expiration date baked into its architecture.

Data already transferred and sitting in your BigQuery tables is safe. Google will not delete existing rows. But the next time you need to re-import, repair, or extend a historical dataset, the 37-month wall is there.

Google’s BigQuery Data Transfer Service caps GA4 and Google Ads backfills at 37 months from June 1, 2026, reversing an 18-month-old policy that promised 11 years of granular access.

The Overwrite Risk Nobody Warned You About#

A single careless backfill can destroy historical data you already own — and the mechanism is built into how BigQuery Data Transfer Service handles GA4 imports.

This is the part most coverage glosses over. The 37-month cap is inconvenient. The overwrite risk is destructive.

When you trigger a manual GA4 backfill for a date older than 37 months, the Data Transfer Service does not simply fail gracefully. It calls the GA4 Data API, receives partial or empty data for the out-of-range dates, and then writes that empty response into the target BigQuery partition — overwriting whatever complete historical records were previously stored there.

The mechanism is straightforward. GA4 backfills replace target rows with the API response. If the API returns NULL for a segment beyond the cap, the backfill commits that NULL. Your existing data gets overwritten with nothing. A botched backfill is worse than no backfill — you don’t just fail to retrieve old data, you actively destroy data you already had.

This risk is not theoretical. It’s documented directly in Google’s BigQuery Data Transfer Service changelog, which warns that attempting to backfill GA4 data older than 37 months “can lead to data loss” and that “the transfer run will overwrite the existing data in your BigQuery partition with the incomplete results from the API.”

For WooCommerce stores that set up GA4 BigQuery exports during the Universal Analytics migration in 2023, three years of accumulated event data now sits one accidental backfill away from being replaced with empty values.

You may be interested in: Google Just Capped Your Google Ads Data at 37 Months

A manual GA4 backfill that crosses the 37-month boundary overwrites existing BigQuery rows with NULL values, actively destroying historical data a store already owned.

GA4’s 14-Month Ceiling Makes This Worse#

GA4’s built-in data retention caps event-level access at 14 months, which means BigQuery is not a nice-to-have — it’s the only path to granular year-over-year analysis.

GA4 stores two types of data internally, and they follow different retention rules. Standard reports use aggregated data that has no retention limit — you can view high-level traffic and revenue totals going back to the day you created your property. But Exploration reports, where you build custom funnels, segment by custom dimensions, and trace individual user paths, rely on event-level and user-level data. GA4 deletes this granular data after 14 months, maximum.

Translation: if you want to compare this December’s conversion funnel against last December’s, you can’t do it inside GA4. The detailed data is gone. You can see that revenue was higher. You cannot see why.

This makes BigQuery the only realistic path to year-over-year WooCommerce analysis at the event level. And that’s where the 37-month backfill cap creates a compounding problem. GA4 deletes your granular data after 14 months. BigQuery was supposed to be the permanent copy. Now the pipeline feeding that permanent copy has a 37-month ceiling of its own.

The catch with GA4’s BigQuery export is that it only captures data from the moment you enable it. There is no historical backfill. If you turned on the export in January 2024, your BigQuery tables start in January 2024. Everything before that date — every session, every purchase, every funnel step — exists nowhere at the event level.

For WooCommerce stores that delayed enabling the export, the window is already narrower than they think. And for stores that relied on the DTS connector to periodically re-import or repair gaps, that repair mechanism now has a hard expiration.

Data Source	Granular Retention	Backfill Window	Overwrite Risk
GA4 UI (Explorations)	14 months max	None — data deleted	N/A
GA4 BigQuery Export (DTS)	Indefinite (once stored)	37 months (from June 2026)	Yes — NULLs overwrite existing rows
Server-side pipeline to BigQuery	Indefinite	N/A — captures live events	None — you own the write path
Google Ads API (granular)	37 months	37 months	No (returns error, doesn’t overwrite)

DTS Connector vs Direct Pipeline#

The BigQuery Data Transfer Service is a convenience layer that Google controls. A direct server-side pipeline is infrastructure you own — and the distinction determines whether Google’s next policy change affects your data.

The BigQuery Data Transfer Service works by pulling data from Google’s APIs on a schedule you configure. You set the connector, point it at a BigQuery dataset, and Google handles the extraction and loading. It’s convenient, free, and — as June 1 demonstrated — entirely subject to Google’s retention decisions.

When Google changed the rules, every store using the DTS connector as its primary data pipeline inherited the new limitations automatically. No opt-out. No grandfathering. No warning longer than 30 days.

A direct server-side pipeline operates on a fundamentally different model. Instead of pulling data from Google’s APIs, it captures events at the source — in this case, WordPress action hooks that fire when a WooCommerce customer views a page, adds an item to their cart, begins checkout, or completes a purchase. Those events route from the server directly to BigQuery’s Streaming Insert API.

The distinction matters because the data never passes through GA4’s processing layer. No 14-month retention applies. No 37-month backfill cap applies. No future retention policy change applies. The events go from your WordPress server to your BigQuery dataset, and once they’re there, they’re yours.

Server-side event capture also closes the collection gap that GA4’s browser-based tag creates. Ad blockers, Safari ITP cookie caps, and iOS click-ID stripping all affect JavaScript-based tracking. None of them affect events captured at the server level, because the data path never depends on a third-party script running in a browser you don’t control.

You may be interested in: WooCommerce Events to BigQuery Without GA4: The Direct Pipeline Guide

The Protection Playbook for WooCommerce Stores#

Five concrete steps to protect your existing BigQuery data and ensure future events reach your warehouse regardless of Google’s retention policies.

The damage from the 37-month cap is preventable if you act on the right sequence. Here’s what to do, in order of urgency.

First, snapshot your existing BigQuery tables. If you have GA4 data older than 37 months in BigQuery, copy those tables to a separate dataset that no DTS connector touches. Use BigQuery’s CREATE TABLE AS SELECT statement or the bq cp command-line tool. This takes minutes, costs fractions of a cent, and creates a write-protected copy that no accidental backfill can overwrite.

Second, audit every scheduled backfill. Review your BigQuery Data Transfer Service configurations. If any GA4 transfer has an automated backfill window that could span past the 37-month boundary, shrink it. Google’s documentation is explicit: ensure that all manual or automated backfill processes don’t target dates older than 37 months from the schedule date.

Third, extend GA4 data retention to 14 months immediately. The default is 2 months. Go to Admin, then Data Settings, then Data Retention, and select 14 months. Toggle “Reset user data on new activity” to on. This won’t recover data already expired, but it preserves the maximum window going forward.

Fourth, verify your GA4 BigQuery export is active. If it’s not enabled, turn it on now. The export only captures data from the moment of activation — there is no historical backfill. Every day you wait is a day of event data that will never exist in your warehouse.

Fifth, add a server-side event pipeline. This is the only step that makes you permanently immune to retention policy changes. A server-side pipeline captures events at the WordPress hook level and routes them to BigQuery directly, bypassing GA4’s collection and retention layers entirely. The data arrives in your warehouse the moment the event fires, and stays there indefinitely at long-term storage rates of $0.01 per GB per month.

Server-side event pipelines that write directly to BigQuery bypass the DTS connector entirely, making stores immune to future Google retention policy changes.

Why Data Ownership Is the Only Durable Fix#

Every retention policy change proves the same point: data that passes through infrastructure you don’t control is data you don’t own.

The 37-month cap is not an isolated incident. It’s the latest in a pattern of platform decisions that shrink the data window available to store owners. GA4 replaced Universal Analytics and capped event retention at 14 months. The Google Ads API enforced 37-month limits for granular queries. Now the BigQuery Data Transfer Service — the tool that was supposed to preserve what the others deleted — has the same ceiling.

Each change followed the same script: announcement with minimal lead time, no grandfathering for existing data, and a rationale framed around “alignment” with industry norms. Each change moved the data ownership line further away from the store owner and closer to the platform.

The structural response is to stop building analytics infrastructure on data access Google can revoke. BigQuery itself remains an excellent warehouse — the storage is durable, the query engine is powerful, and the free tier covers most small businesses. What needs to change is the data pathway. Instead of pulling from Google’s APIs, you push from your own server.

Transmute Engine™ handles this for WooCommerce stores. The inPIPE WordPress plugin listens to WooCommerce action hooks — page views, add-to-cart events, checkout steps, purchases — and batches them via authenticated API to a first-party server running on your subdomain. From there, events route simultaneously to GA4, Meta CAPI, Google Ads, BigQuery, and any other destination. Because BigQuery is one destination among many, the same pipeline that protects your analytics data also feeds your ad platforms and email automations — from one capture point.

BigQuery active storage costs $0.02 per GB per month. Data untouched for 90 days drops to $0.01 per GB per month automatically. A WooCommerce store with millions of events typically pays pennies per month for indefinite retention. There is no economic reason to delete historical event data. The only question is whether it arrives in your warehouse through a path you control.

You may be interested in: Why Your Two-Year-Old BigQuery Data Is More Valuable Than Last Week’s Dashboard

Key Takeaways#

• 37-month cap is live: Google’s BigQuery Data Transfer Service stopped backfilling GA4 and Google Ads data older than 37 months on June 1, 2026, reversing an 11-year access promise made just 18 months earlier.
• Overwrites are real: A manual GA4 backfill past the boundary doesn’t just fail — it replaces your existing historical rows with empty values, destroying data you already owned.
• GA4 can’t save you: GA4’s 14-month event-level retention means BigQuery is the only path to granular year-over-year analysis, but the pipeline feeding it now has a ceiling too.
• Snapshot immediately: Copy any BigQuery tables with data older than 37 months to a separate dataset no DTS connector touches — this takes minutes and costs almost nothing.
• Own the pipeline: Server-side event capture that writes directly to BigQuery bypasses every retention limitation because Google’s policies can’t reach data that never passed through Google’s collection layer.

References#

• Google Cloud. (2026). BigQuery Data Transfer Service data source change log. docs.cloud.google.com
• Google Ads Developer Blog. (2026). Google Ads Data Retention Update. ads-developers.googleblog.com
• Google Analytics Help Center. (2026). Data retention in Google Analytics 4. support.google.com
• Google Cloud. (2026). BigQuery Pricing. cloud.google.com
• PPC.Land. (2026). Google Ads cuts granular data access to 37 months starting June 2026. ppc.land
• ALM Corp. (2026). Google Ads Data Retention Update 2026: 37-Month Limit Explained. almcorp.com

Ready to stop renting access to your own WooCommerce data? See how Transmute Engine keeps your event history safe in BigQuery — permanently.