Google reversed an 11-year Google Ads data retention policy that was only 18 months old. From June 1, 2026, hourly, daily, and weekly Google Ads reporting data caps at 37 months. Queries beyond that window return a DateRangeError.INVALID_DATE error. WooCommerce stores running GA4 BigQuery exports face an additional risk most stores do not realize: a manual backfill that crosses the 37-month line will overwrite existing historical records with NULLs.

You have 26 days to export the granular history you actually need before June 1.

Why Your WooCommerce BigQuery Backfill Now Risks NULL Overwrites#

Google announced the change on its Ads Developer Blog on May 1, 2026. The new policy reverses the November 13, 2024 retention policy that gave advertisers an 11-year window for granular data. The official rationale is alignment with the 37-month caps already enforced by other platforms.

The Google Ads Help Center update reads: “Starting on June 1, 2026, Google Ads will adjust the availability of performance reporting data at specific granularities. Hourly, daily and weekly reporting data collected by Google Ads for periods of time shorter than one month will be available for 37 months.”

What Actually Caps at 37 Months#

The cap is on granularity, not on reporting altogether. Aggregated monthly, quarterly, and annual data keep the original 11-year window. The change targets the data store owners use most for forensic analysis.

Specifically, the 37-month cap applies to:

• Hourly, daily, and weekly performance data — the segments most useful for finding the day a campaign broke or the week a competitor outbid you
• Reach and frequency metrics including Avg impr. freq./user (7d/30d) and Frequency distribution, capped at 3 years from June 1, 2026 (Google Ads Help Center, 2026)
• The Google Ads API and Google Ads scripts
• The Google Analytics Data API
• The BigQuery Data Transfer Service for Search Ads 360 and Google Ads connectors (PPC Land, 2026)

Translation: every reporting layer that feeds an SMB WooCommerce dashboard is in scope. If your weekly campaign performance reports run through any of those pipes, they hit the wall at the 37-month line.

The BigQuery NULL Overwrite Trap#

This is the part most coverage glosses over. Surfside PPC’s analysis of the Google Help Center update flagged a specific risk for stores using GA4 BigQuery exports as their long-term reporting layer: a manual backfill that requests data older than 37 months actively writes NULL into existing rows that already had values.

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 — overwriting whatever historical record was previously stored.

A botched backfill is worse than no backfill. You do not lose access to data Google still holds. You lose data you already had.

For granular queries past 37 months after June 1, the Google Ads API returns DateRangeError.INVALID_DATE (PPCNewsfeed, 2026). That error is the safety rail for direct queries — but a backfill orchestrator that does not catch the error and skip the row instead of writing the response can still corrupt your warehouse.

You may be interested in: Data Sovereignty for WooCommerce: Own Your Pipeline

Why an 11-Year Window Lasted Only 18 Months#

The November 13, 2024 policy that introduced the 11-year retention window was an outlier from day one. Facebook Ads, LinkedIn Ads, and most other paid platforms had been enforcing tighter granular windows for years. Per Surfside PPC’s May 2026 analysis, the reversal aligns Google with the 37-month caps already standard across competitor platforms.

The strategic read is more uncomfortable than the alignment story. An 11-year promise can become 37 months with 30 days’ notice. Whatever Google offers as a retention window, the platform reserves the right to shorten it whenever it serves the platform.

For a WooCommerce store that runs three or four years of holiday season comparison off Google’s reporting layer, that is not a hypothetical. It is a 26-day deadline.

Your 26-Day Export Checklist#

Before June 1, 2026:

• Export Google Ads granular history — pull hourly, daily, and weekly reports through the Google Ads API or Ads Editor for every campaign you want a full record of. Store them as raw CSVs and as BigQuery tables in your own project.
• Audit your BigQuery Data Transfer Service — confirm every Google Ads connector dataset has data older than 37 months mirrored into a table the transfer service no longer touches. Snapshot it.
• Verify your GA4 BigQuery export — check that no scheduled backfill spans more than 37 months past June 1. If it does, split the backfill at the 37-month boundary or disable it.
• Save reach and frequency exports — those cap at 3 years (Google Ads Help Center, 2026), tighter than the granular cap. Run them this week.
• Document your warehouse schema — the rows you are saving need to remain queryable in 2030 when the columns Google publishes have changed.

The Architectural Answer: Stop Renting Your History#

The export checklist solves the immediate problem. It does not solve the structural one. Every piece of data on the export checklist is data Google is letting you keep because Google still has it. The next policy change can shorten the window again.

The real fix is owning the event capture itself. If your raw WooCommerce events flow through your own infrastructure into your own BigQuery, the platform’s retention window is no longer your data limit. Google’s 37 months is what Google reports back to you. Your warehouse keeps the original events for as long as you want them.

This is the same architectural argument that justifies first-party server-side tracking against ad blockers. Per Statista (2024), 31.5% of global users run ad blockers, and standard WooCommerce client-side tracking already misses 30-50% of conversions. The historical data Google is now capping is already a partial record of what actually happened. Owning your event capture closes both gaps in one move.

You may be interested in: Data Trees and AI: Why GTM Users Fall Behind

How a Transmute Engine-Backed Store Handles This#

Transmute Engine™ is a first-party Node.js server that runs on your own subdomain (e.g., data.yourstore.com). The inPIPE WordPress plugin captures WooCommerce events and sends them via API to your Transmute Engine server, which writes raw events into your own BigQuery in parallel with delivering them to Google Ads, Facebook CAPI, and the rest of your stack.

The 37-month cap on Google’s side does not affect data the store warehoused itself. A Transmute-Engine-backed store on June 2, 2026 still has every order, every click, every cart abandonment from 2023 in its own warehouse — because it never depended on Google to keep them in the first place.

Key Takeaways#

• June 1, 2026: Granular Google Ads data caps at 37 months. Reach and frequency metrics cap at 3 years.
• Affected APIs: Google Ads API, Google Ads scripts, Google Analytics Data API, BigQuery Data Transfer Service.
• Backfill risk: A GA4 manual backfill exceeding 37 months overwrites existing BigQuery records with NULLs (Surfside PPC, 2026).
• Error code: Granular queries beyond 37 months return DateRangeError.INVALID_DATE.
• 26 days to act: Run your Google Ads granular export, audit BigQuery Data Transfer mirrors, and verify GA4 backfills do not cross the cap.
• Long-term fix: Own your event capture so the next retention change is not your data limit.

Frequently Asked Questions#

Run the export this week. Then plant the warehouse that does not depend on the next policy change. Start at seresa.io.