Google yesterday published two documents confirming that granular Google Ads reporting data will be accessible for a maximum of 37 months starting June 1, 2026 - a significant contraction from the 11-year retention window the company established less than 18 months ago. The announcement affects the Google Ads API, Google Ads scripts, the Google Analytics Data API, and the BigQuery Data Transfer Service, with different technical consequences for each.

The developer-facing notice was published on May 1, 2026, on the Google Ads Developer Blog by Nadine Wang of the Advertising and Measurement APIs Team. A parallel update to the Google Ads Help Center, dated with a May 1, 2026 effective date, confirmed that the 37-month window applies to the Google Ads interface as well as APIs.

What changes on June 1

According to the Google Ads Developer Blog post, the 37-month limit applies specifically to granular performance statistics broken down at the daily, hourly, and weekly level. High-level aggregations at the monthly, quarterly, and yearly granularity will continue to be retained for 11 years. This distinction is technically precise and operationally important: developers and analysts who rely on day-level or week-level data for trend modeling, anomaly detection, or year-over-year comparisons going back more than three years will lose access to that data through the interface and APIs.

The Help Center document puts the transition date plainly. According to Google, "Beginning on May 1, 2026, reporting data collected by Google Ads will be available for 37 months." Data beyond that window "will not be accessible via the Google Ads interface or APIs."

One category has an even shorter limit. Reach and frequency metrics - including unique users, average impression frequency per user, the 7-day and 30-day frequency variants, and frequency distribution thresholds at 1+, 2+, 3+, 4+, 5+, and 10+ - will be accessible for only three years, shorter than the general 37-month window.

For developers querying the Google Ads API or running Google Ads scripts, the technical implication is concrete. According to the developer blog post, queries that request granular segments - such as segments.date or segments.week - for date ranges older than 37 months from the current date will return a DateRangeError.INVALID_DATE error starting June 1, 2026. Future API versions will return a more descriptive DateRangeError.REQUESTED_DATE_GRANULARITY_NOT_SUPPORTEDerror instead.

To retrieve data older than 37 months, developers must update their queries to use segments.month, segments.quarter, or segments.year. There is a further constraint for unsegmented historical queries: they must align precisely with calendar month boundaries - that is, from the first day to the last day of a month - to succeed.

This means any automated script or scheduled reporting pipeline that requests, for example, day-level campaign data from 2022 will begin returning errors on June 1 rather than data. The requirement to audit and update these integrations before the deadline falls entirely on developers and agencies running third-party tooling.

Google Analytics Data API: truncation, not an error

The behavior for the Google Analytics Data API differs from the hard error approach used for the Google Ads API. According to the announcement, the Google Analytics Data API will truncate affected metrics to the latest 36-month window when the dimension "date" is also present in the report. The affected metrics are Advertiser Ad Cost, Clicks, and Impressions. Only reports that include all of the affected metrics, cover a date range of 37 months or older, and include the "date" dimension are impacted. Date-equivalent dimensions such as "Day of week" and "day" are also affected by this truncation behavior.

The practical difference matters: a developer querying the Google Ads API will receive an error and no data; a developer querying the Google Analytics Data API may receive partial data silently truncated to the 36-month window. Teams that stitch data from both APIs need to reconcile these two different behaviors to avoid silent data gaps in downstream reporting systems.

BigQuery Data Transfer Service: backfill runs stop

The BigQuery Data Transfer Service sees a different type of impact. According to the blog post, starting June 1, 2026, the BigQuery Data Transfer Service connectors for Google Ads and Search Ads 360 will stop populating data for backfill runs with dates older than 37 months from the current date. Data already transferred and stored in BigQuery will remain in the tables with no impact - the change affects only new backfill attempts.

The situation for the Google Analytics 4 connector is more consequential. Also starting June 1, 2026, the BigQuery Data Transfer Service for GA4 will stop populating data for backfill runs with dates older than 37 months. More significantly, if a transfer is manually triggered for a report date that is 37 months or older, the data of that date in the BigQuery table will be overwritten by an empty value. This means that a manual backfill triggered after June 1 for an old date could actively destroy existing historical data in a BigQuery table rather than simply failing to add new data. Teams managing GA4 data in BigQuery should be aware of this specific risk before triggering any historical backfills after the deadline.

DV360 and CM360 remain unchanged

The DV360 API and CM360 API are not affected by this transition. According to the announcement, these APIs currently maintain a 24-month retention period, which remains unchanged.

A sharp reversal from the 11-year policy

The timing of this change is notable. In October 2024, Google announced an 11-year data retention policy for Google Ads reporting data, which took effect on November 13, 2024. That policy was framed as enabling advertisers to conduct long-term historical analyses - more than a decade of campaign performance data for trend identification and strategic planning. Less than seven months after that policy took effect, Google is now establishing a 37-month ceiling on granular access, while preserving the 11-year window only for high-level monthly, quarterly, and yearly aggregates.

The contrast with other recent retention policy changes at Google is also worth noting. In June 2025, Google AdMob announced cuts to historical data retention for mobile publishers, limiting Ads Activity report data to seven years and User Activity report data to just 90 days. In February 2025, Google set a 540-day limit for Customer Match data retentionacross Google Ads and Display & Video 360, effective April 7, 2025. A pattern of narrowing data access windows across Google's advertising products has emerged throughout 2024 and 2025, driven in part by regulatory pressure around data storage and privacy compliance.

The 37-month window for granular Google Ads reporting data places the platform broadly in line with what was previously reported as a standard for Facebook Ads, which PPC Land noted retains data for approximately 37 months. The window also aligns closely with the 36-month truncation point now applied in the Google Analytics Data API for the same categories of ad metrics.

What developers need to do before June 1

The developer blog post outlines a set of actions for each affected system. For teams using the Google Ads API or Google Ads scripts, the requirement is to review applications and make updates. Any query requesting granular segments - segments.date, segments.week, segments.hour - for date ranges beyond 37 months must be rewritten to use monthly, quarterly, or yearly segments. According to the post, "If you require granular historical data beyond 37 months, we recommend exporting it prior to the June 1, 2026 deadline."

For teams using the Google Analytics Data API, the action is to review data stitching logic to account for the 36-month truncation. This is particularly relevant for organizations that combine GA4 metrics with Google Ads cost data in unified reporting layers.

For teams using BigQuery Data Transfer Service, the recommendation is more time-sensitive. According to the announcement, "If you want to keep historical data beyond 37 months in BigQuery, we recommend starting backfilling runs early so that they can complete before June 1, 2026." Given that BigQuery backfill runs can take considerable time for large datasets, organizations that have not already started this process have less than a month to act.

Support is available through the Google Ads API support channel and the Google Ads scripts support channel, as well as through the "Google Advertising and Measurement Community" Discord server referenced at the end of the blog post.

Context for measurement teams

The change arrives at a moment when the Google Ads API has been undergoing significant structural updates. In January 2026, Google launched version 23 of the Google Ads API, introducing channel-level reporting for Performance Max campaigns. In April 2026, Google released version 24, adding cart data reporting and lead generation conversion types. Just this week, Google announced that the API will expand product reporting for Video, Demand Gen, and App campaigns from June 15, 2026.

This context matters for measurement teams trying to maintain continuity in reporting systems. The June 1 retention cutoff and the June 15 product reporting expansion arrive within two weeks of each other, each requiring distinct changes to query logic and data pipeline architecture. Teams building or maintaining custom dashboards, automated reporting, or data warehouse integrations that pull from the Google Ads API face a concentrated period of technical updates in the first half of June.

The shift to a 37-month window also has implications for how organizations approach long-term campaign benchmarking. Any comparative analysis that relied on four or more years of day-level performance data - for example, tracking how a seasonal category performed in 2021 versus 2022 versus 2023 - will no longer be possible through standard API queries once the cutoff takes effect. The workaround - exporting data now, before June 1 - requires identifying which historical data is worth preserving and building storage infrastructure to hold it outside the Google Ads ecosystem.

Timeline

Summary

Who: Google, through its Advertising and Measurement APIs Team (post authored by Nadine Wang), announced the change via the Google Ads Developer Blog and the Google Ads Help Center.

What: Granular Google Ads reporting data - at the daily, hourly, and weekly level - will be limited to a 37-month retention window. Reach and frequency metrics will be available for only three years. High-level monthly, quarterly, and yearly aggregates remain accessible for 11 years. The Google Ads API and Google Ads scripts will return errors for granular queries beyond 37 months. The Google Analytics Data API will silently truncate affected ad metrics to a 36-month window. The BigQuery Data Transfer Service will stop backfilling data older than 37 months, with the risk of overwriting existing GA4 historical data if backfills are manually triggered after the cutoff.

When: The developer blog post was published on May 1, 2026. The policy takes effect on June 1, 2026. The Help Center document states a May 1, 2026 effective date for the interface. Developers working with BigQuery should begin backfilling historical data immediately to complete runs before the June 1 deadline.

Where: The change applies globally to all Google Ads accounts and affects access through the Google Ads interface, the Google Ads API, Google Ads scripts, the Google Analytics Data API, and the BigQuery Data Transfer Service. DV360 and CM360 APIs are not affected.

Why: Google has not provided a detailed public rationale. The change aligns with a broader pattern of data lifecycle restrictions across Google's advertising products over the past 18 months, a period that has also seen Customer Match retention limited to 540 days and AdMob User Activity data capped at 90 days. Regulatory pressure around data storage and privacy compliance has been cited in related announcements as a driving factor behind these types of policy changes.

Share this article
The link has been copied!