How Do You Keep Your Google Ads Historical Data After the 37-Month Cutoff?

The Take: Google is capping granular Google Ads reporting data at 37 months from 1 June 2026. Monthly, quarterly and yearly aggregates survive for 11 years, but hourly, daily and weekly detail older than 37 months disappears from the interface and the API for good. This is a reference guide for what to export, how to preserve it and what to check on a routine basis from here on.

From 1 June 2026, Google Ads limits access to granular reporting data (hourly, daily and weekly) to a rolling 37-month window. Monthly, quarterly and annual aggregates stay available for 11 years. Once granular data passes the 37-month mark it is not archived or moved to cold storage. It is simply no longer retrievable through the Google Ads interface or the API.

Google's own developer blog and Help Centre documentation spell out the mechanics precisely. Queries against the Google Ads API or Google Ads scripts that request granular segments, such as `segments.date` or `segments.week`, for ranges older than 37 months will return a `DateRangeError.INVALID_DATE` error. Future API versions return a `DateRangeError.REQUESTED_DATE_GRANULARITY_NOT_SUPPORTED` error instead. To pull data older than 37 months at all, queries need to shift to `segments.month`, `segments.quarter` or `segments.year`, and unsegmented historical queries must align exactly with calendar month boundaries to succeed.

There's one narrower carve-out worth knowing. Reach and frequency metrics, including unique users and impression frequency distributions, are capped at 3 years rather than 37 months.

Because a lot of Australian campaign planning runs on cycles this policy cuts straight through. Financial year comparisons, End of Financial Year sales pushes, Boxing Day and post-Christmas trading windows, back-to-school periods. Comparing this year's EOFY campaign against the one from three years back needs daily-level detail, and after the cutoff that comparison is gone unless it was exported first.

BigQuery Data Transfer Service pulls are affected too. The source data feeding those transfers follows the same retention rules, so a warehouse keeps whatever it already pulled, but new transfers cannot reach further back than 37 months. If a data warehouse has been running for less than three years, there's a real gap forming right now between what's in the warehouse and what existed in the account before the pipeline was switched on.

Three steps in order of urgency. Export what's at risk now. Set up an ongoing pipeline so this never becomes urgent again. Keep a lightweight benchmark record even after the raw data is gone.

First, export everything at risk today. Pull hourly and daily reports as far back as the account allows, prioritising any campaign data older than roughly three years, since that's the data closest to falling out of the window. Store exports in BigQuery, another data warehouse or, at minimum, a structured spreadsheet. The format matters less than the act of getting it out of Google Ads before the window closes on it.

Second, set up an ongoing BigQuery Data Transfer Service pipeline if one isn't already running. Google Cloud's own documentation describes the BigQuery Data Transfer Service as the native path for scheduled, recurring Google Ads data pulls straight into BigQuery tables partitioned by date. No API credentials are needed since it authenticates through Google OAuth directly, and pulling Google Ads data into BigQuery this way is free beyond standard BigQuery storage costs. One limitation worth planning around: a single backfill request tops out at 180 days, so pulling several years of historical data means running sequential 180-day chunks rather than one large pull, and the process typically takes a week or more per chunk.

Third, document baseline benchmarks even where raw data can't be preserved in full. Even a simple record of cost per click, conversion rate and ROAS by quarter, going back as far as possible, gives a future comparison point even if the underlying granular rows are gone.

Treat this less as a one-off scramble and more as a recurring account discipline, since the same 37-month clock keeps rolling forward every month after June 2026.

Methodology note: the retention window, error codes and BigQuery backfill limits referenced above are drawn directly from Google's own developer blog and Help Centre documentation, not from third-party reporting. This is genuinely reference material Google itself may continue to update, so it's worth checking the linked source pages directly for any revisions after publication.

When does Google's 37-month data retention policy take effect?

The policy took effect on 1 June 2026. From that date, hourly, daily and weekly Google Ads reporting data older than 37 months is no longer retrievable through the interface or the API.

Does this policy delete monthly or quarterly Google Ads data too?

No. Monthly, quarterly and annual aggregate data remains available for 11 years. Only granular hourly, daily and weekly data is capped at 37 months.

Can I still get Google Ads data older than 37 months if I export it first?

Yes. If granular data is exported to BigQuery, another warehouse or a structured file before it ages past 37 months, that exported copy is unaffected by Google's retention policy. The cutoff only applies to what's still sitting inside Google Ads itself.

What's the easiest way to keep Google Ads historical data going forward?

Set up a recurring BigQuery Data Transfer Service pipeline for Google Ads. It's free beyond standard BigQuery storage costs, requires no separate API credentials and pulls new data automatically so the 37-month cutoff never catches unexported data again.

If your Google Ads account has been running for years and nobody's checked whether this export is already happening, that's exactly the kind of gap NR Studio surfaces alongside the rest of your marketing data, benchmarked against real Australian businesses.