Google Ads · Status at source date: Newsletter archive
Google Ads 37-month data retention policy officially confirmed
Google has officially confirmed the new data retention policy via the Google Ads Developer Blog, providing the canonical source URL that was missing when the change was first flagged in Week 18 via advertiser email. Effective 1 June 2026, Google Ads API, Google Ads scripts, Google Analytics Data API, and the BigQuery Data Transfer Service all transition to a 37-month retention window for granular performance statistics (daily, hourly, weekly).

What changed
Higher-level granularities (monthly, quarterly, yearly) remain available for 11 years. The DV360 and CM360 APIs retain their current 24-month window: no change.
The Google Ads API technical detail: queries for granular segments older than 37 months will return DateRangeError.INVALID_DATE, transitioning to DateRangeError.REQUESTED_DATE_GRANULARITY_NOT_SUPPORTED in future API versions. Unsegmented historical queries must align with calendar-month boundaries (1st to last day of the month) to succeed. For BigQuery, advertisers who want to retain granular history beyond 37 months should start backfill runs before 1 June to complete in time. Already-transferred data in BigQuery remains in tables, but manually-triggered transfers for 37-month-old report dates will overwrite the existing data with empty values.
Why it matters for advertisers
For you, this means the export window before 1 June is now a hard cutoff with no flexibility built in. Engineering and measurement teams running any of the affected APIs need to confirm migration plans before the deadline. Particularly urgent for teams running multi-year seasonality modelling or attribution analysis that depends on granular pre-2023 history.
Perspective from the original PMC newsletter.Sources & contributor credit
- Newsletter coverage · Paid Media Collective newsletter
Original newsletter text, contributor labels and media for this update.
- Source referenced in newsletterGoogle Ads Developer Blog
Linked from the original newsletter. The source publication date has not been independently confirmed.
Original creator unverified
The original creator has not yet been verified. Newsletter curation and publication do not establish original authorship.
Attribution evidence and limitations
Full attribution review pending.
A source link alone does not establish original authorship.
Original image and video creators have not yet been verified.
- Published on this site
This update reflects the dated source reporting. Availability may have changed. Further coverage of this same development will be added to this page.
Original newsletter text and archive evidence
Google Ads 37-month data retention policy officially confirmed
Google has officially confirmed the new data retention policy via the Google Ads Developer Blog, providing the canonical source URL that was missing when the change was first flagged in Week 18 via advertiser email. Effective 1 June 2026, Google Ads API, Google Ads scripts, Google Analytics Data API, and the BigQuery Data Transfer Service all transition to a 37-month retention window for granular performance statistics (daily, hourly, weekly). Higher-level granularities (monthly, quarterly, yearly) remain available for 11 years. The DV360 and CM360 APIs retain their current 24-month window: no change.
The Google Ads API technical detail: queries for granular segments older than 37 months will return DateRangeError.INVALID_DATE, transitioning to DateRangeError.REQUESTED_DATE_GRANULARITY_NOT_SUPPORTED in future API versions. Unsegmented historical queries must align with calendar-month boundaries (1st to last day of the month) to succeed. For BigQuery, advertisers who want to retain granular history beyond 37 months should start backfill runs before 1 June to complete in time. Already-transferred data in BigQuery remains in tables, but manually-triggered transfers for 37-month-old report dates will overwrite the existing data with empty values.
For you, this means the export window before 1 June is now a hard cutoff with no flexibility built in. Engineering and measurement teams running any of the affected APIs need to confirm migration plans before the deadline. Particularly urgent for teams running multi-year seasonality modelling or attribution analysis that depends on granular pre-2023 history.
Source captured . No explicit first-contributor label was provided for this update.




