TL;DR: From 1 June 2026 on, Google Ads keeps your hourly, daily and weekly data only for 37 months, and reach and frequency for 3 years. Monthly and yearly aggregates survive 11 years, but those are useless for modeling future measurement. So the data your model needs most is the google ads data that disappears first. If your regression-based attribution, econometric model, or media mix model reads its history from Google, you have days, not months. Export steps are below. But the export isn’t the real fix.
What’s actually changing
Third-party cookies. iOS 14. The Privacy Sandbox. And now a quiet 37-month delete clock on Google Ads. Every 18 months or so, a platform narrows what you’re allowed to measure and store, reasons are various but the impact is real. The result is always the same: the ground under your measurement moves, and your models wobble with it 😉
But this announcement is easy to underreact to, because delete sounds like a backup problem. But it isn’t, it’s a modelling problem even if you don’t model yet.
Straight from Googles updated data retention policy, as of 1 June 2026:
- Hourly, daily and weekly data: 37 months. After that, granular queries past the window throw a “DateRangeError” in the API and vanish from the UI.
- Reach and frequency: 3 years. Unique users, average frequency, 7-day and 30-day frequency, frequency distribution. Shortest window, hardest to rebuild later.
- Monthly, quarterly and annual data: 11 years. Nothing to worry, but it’s mostly data and therefore quite unusable for most measurement models.
So the challenge is aggregeated weekly/monthly data is not enough to model a proper measurement, you need high granularity to model. Also, you must consider how much google ads data you are able to retain. Important, this isn’t only Google. Meta already enforces a comparable 37-month cap. This is the platform standardising downward together. Also relevant, we assume GA4 won’t keep your data: No GA4 backfills past 37 month, the null-overwrite could erase years of stored history in a single run by June 1st.
The export to-do list
Run this top to bottom before 1 June 2026.
Already on Nexoya? The history of your data has been stored raw in your teant. So we can still read date ranges Google has dropped afterwards. Ask your CSM what data we’re already have for your account and if more needs to be fetched, before you build anything new. Therefore, keep track of all google ads data that you export for your records.
Own the layer, don’t rent it.
After you’ve done all that you’re safe, at least for the next 18 months, because the next restriction is already being drafted somewhere 😉
The onetime export isn’t the fix; if your measurement lives inside a platform you don’t control, you don’t own a system; you own a lease, and the landlord keeps rewriting the terms. In other words, google ads data is only as secure as the platform allows.
The teams that still trust their numbers in five years treat measurement as owned infrastructure: cross-platform, modelled independently of whatever any single publisher platform decides to keep. The platforms become inputs, not the source of truth.
Suggest you export your history this week. Then ask the bigger question: what’s the oldest data your model depends on, and who controls it? 😉
Sources
- Google Ads Data Retention Policy: the 11-year, 3-year and 37-month windows.
- Google Ads Developer Blog: the 1 June date and the API
DateRangeErrorfor granular queries past 37 months. - BigQuery Data Transfer Service change log : the 37-month backfill block and the GA4 null-overwrite warning.
