On May 1, 2026, Google announced a policy change that breaks every Google Ads year-over-year report built on more than three years of history. Starting June 1, 2026, hourly, daily, and weekly performance data older than 37 months will be permanently blocked from the Google Ads UI, the Google Ads API, Google Ads scripts, the Google Analytics Data API, and the BigQuery Data Transfer Service. If you do not archive your historical granular data before that date, it is gone.

This is the inverse of the policy Google announced in October 2024 when it extended retention to 11 years. The 11-year data retention is staying, but only for monthly, quarterly, and yearly aggregates. Anything more granular than month-level gets the 37-month cap. For most marketing teams, that's the data that actually matters: ad-level day-by-day spend, hourly bid performance, week-over-week creative tests across years. All of it disappears from Google's systems on June 1 unless you have it stored somewhere else by then.

This guide covers exactly what is being capped, where the silent failure modes are (the Google Analytics Data API is the most dangerous), who is affected (most advertisers running multi-year granular analyses), and three methods to preserve your granular Google Ads history before the deadline.

What is actually being capped

The change distinguishes between two tiers of data:

• Granular data (hourly, daily, weekly). Capped at 37 months rolling. Anything older is permanently blocked.
• Aggregate data (monthly, quarterly, yearly). Retained for up to 11 years. Unaffected by this change.

If you only ever look at monthly spend by campaign for board reports, you are not affected. If you ever look at day-level performance from 3+ years ago, ad-level creative tests from your 2022 campaigns, hour-of-day pacing analyses across years, or week-over-week trends with multi-year baselines, you are affected.

Where the cap is enforced

Five interfaces enforce the limit. The behavior differs in nasty ways:

• Google Ads UI. Date ranges older than 37 months for granular reports return empty results or a "data unavailable" message. Reports already scheduled for older date ranges break silently.
• Google Ads API. Queries with granularity at HOURLY / DAILY / WEEKLY for dates older than 37 months return an explicit error. The error is informative; downstream scripts that don't handle it will crash.
• Google Ads scripts. Same behavior as the API. Scripts running on cron that pull granular history without bounded date ranges will throw and stop refreshing dashboards.
• Google Analytics Data API (the most dangerous one). The API silently truncates ad metrics older than 36 months (one month tighter than the Google Ads cap) instead of erroring. Your queries succeed, return data, and just happen to be missing the older values. No exception, no warning, no obvious sign in the response. The failure mode that takes weeks to detect because the dashboard "still works."
• BigQuery Data Transfer Service. Scheduled transfers will stop pulling data older than 37 months from June 1 onward. Manual backfills targeting dates older than 37 months are expected to fail or return no data; existing rows already in your BigQuery tables should remain untouched. The risk is at the configuration layer: audit your DTS schedules and any custom orchestration that re-triggers historical date ranges to avoid load errors or schema mismatches post-deadline. The exact API behavior on out-of-window backfills isn't documented yet. Google has announced the cap but hasn't published post-enforcement behavior in detail, so the precise error vs no-op response will only be fully known after June 1.

The GA Data API silent truncation is the pattern that will cause the most damage post-deadline because it does not produce a visible error. Your queries succeed, the data is missing, and your dashboards keep refreshing as if nothing changed.

Who this hits hardest

Four audiences feel this immediately:

• Performance marketers running YoY analyses. If you compare this May to May 2023, you have ~36 months of headroom right now. By September 2026 you'll have lost January-August 2023 from granular reports.
• Agencies with multi-year client histories. Client onboarding decks that show "the trajectory we've delivered over four years" require data older than 37 months. Once it's gone from Google's systems, those decks can no longer be regenerated.
• Anyone using the BigQuery Data Transfer Service for Google Ads or Search Ads 360. The DTS is the most common Google-native pipeline for Google Ads data into a warehouse. Every existing DTS-fed BigQuery table is one accidental manual backfill away from being wiped.
• Teams that built dashboards on the assumption of 11-year retention. Google's prior 11-year retention announcement (late 2024) gave teams confidence to architect long-window dashboards. Those dashboards now have a deletion date.

Cross-platform note: 37 months is not the industry floor. Meta moved Reach with breakdowns down to 13 months in January 2026, and most other Meta Ads Insights metrics default to 2 years or less. Retention is tightening on several ad platforms. The defense is the same in every case: archive forward into a destination you own.

What you can still safely query after June 1

The cap is specifically on granularity, not on age. After June 1:

• Monthly spend, impressions, clicks, conversions per campaign back to 2015 or so. Fine.
• Quarterly performance trends over 11 years. Fine.
• Yearly aggregates for board decks. Fine.
• Day-level performance from January 2023 onward (37 months from June 2026). Fine.
• Day-level performance from December 2022 or earlier. Gone unless archived.
• Hourly bid data older than 37 months. Gone unless archived.

If your reporting only ever uses monthly or coarser granularity, this change is invisible to you. If your reporting uses anything at week-level or finer, you need to act before June 1.

The 12-day action plan

Three methods to preserve your granular Google Ads history. Pick one and execute it before June 1.

Method 1: BigQuery Data Transfer Service one-time backfill (before June 1)

If you don't already have BigQuery Data Transfer Service set up, you can configure it now and run a one-time backfill for all granular data going back as far as your account has history. Once it's in BigQuery, the data is yours; the June 1 cap only affects what DTS can pull after that date.

Setup: in Google Cloud Console, BigQuery → Data Transfers → Create Transfer → Google Ads. Authenticate, pick destination dataset, set start date as far back as your Google Ads account history goes. Run the initial backfill manually. Verify the data landed in your BigQuery tables before June 1.

Operational tip: after June 1, manual backfills for date ranges older than 37 months will fail or return no data. Your historical rows in BigQuery are safe; the risk is at the configuration layer. Restrict who can edit transfer settings or trigger orchestrated re-loads so you don't introduce schema mismatches between fresh and archived data.

When this fits: teams already in Google Cloud, comfortable with BigQuery and dataset management, fine with paying BigQuery storage and on-demand query costs (see our BigQuery hidden costs for marketing teams guide if you're new to those).

Method 2: Apps Script export to Google Sheets

The free path for teams without a warehouse. Pull granular Google Ads history into a Google Sheet via Apps Script + the Google Ads API, then keep the sheet (or export to Drive) forever.

Setup outline: generate a Google Ads API developer token, write an Apps Script that paginates through GoogleAdsService.searchStream with HOURLY or DAILY segments for date ranges going back as far as you need, append rows to a Sheet. The Google Ads API documentation covers reporting query syntax and pagination.

Where this gets hard:

• Volume. Day-level data across multiple campaigns and accounts hits Google Sheets' 10 million cell limit fast. You'll need to split exports across multiple sheets or chunk by quarter.
• Apps Script timeout. Free Workspace caps execution at 6 minutes. Paid caps at 30 minutes. Pulling 4+ years of granular data across 10 accounts will exceed both. Solution: chunk by month and run repeatedly.
• Auth setup. The developer token requires a Google Ads MCC and an approval review by Google. Google doesn't publish a guaranteed turnaround time; community reports typically describe a roughly one-week window, but the actual wait varies and isn't officially committed. Don't start this method on May 28 expecting to finish by June 1.

When this fits: small advertisers with one or two accounts, history under 2 years, no budget for a warehouse, and a marketer comfortable with code.

Method 3: Scheduled connector (Dataslayer)

The path for teams that want the data preserved without managing API quotas, MCC approval, or Apps Script chunking. Setup takes minutes for single-account teams; agencies with multi-year history across many client accounts should plan for a few hours of backfill runtime in the background.

Dataslayer connects to Google Ads via OAuth, queries the same Google Ads API the manual script would, and lands the data in your destination of choice: Google Sheets, Looker Studio, BigQuery, Snowflake, Redshift, or the upcoming Dataslayer Data Warehouse. For the June 1 deadline, the relevant workflow is a one-time historical backfill: connect Google Ads, pick the granular fields you want preserved (daily, weekly, monthly, ad-level if needed), set the date range as far back as your Google Ads account goes, run the query, write to your destination. After that, configure an ongoing daily refresh so anything pulled forward stays current (scheduled refresh requires the Starter plan or higher; the Free plan supports manual refresh only).

Why a scheduled connector is the right answer for most teams racing the June 1 deadline:

• No MCC / dev token bottleneck. Dataslayer's Google Ads connector handles the API authentication layer for you. OAuth on the user side, queries run on the back end.
• Volume isn't a limit. The connector batches API calls and respects rate limits across multi-account agency setups.
• Destination flexibility. Land the history in Sheets for small teams, BigQuery for warehouse-using teams, or both. The data is yours regardless of where it lives.
• Ongoing refresh is the same flow. The one-time backfill and the ongoing daily refresh use the same connector. You don't rebuild anything after June 1.

Costs: Free covers 1 connector and 1 user with manual refresh, enough to run the one-time historical backfill before June 1. Starter ($35/mo annual) adds daily scheduled refresh across 3 connectors; Advanced ($115/mo) covers hourly refresh and AI Insights; Pro ($345/mo) handles 100+ accounts per connector for agencies. Current pricing here.

Comparing the three methods

Ongoing strategy after June 1

Preserving your historical Google Ads data is the urgent task before the data retention cap hits. The ongoing task is making sure you never face this loss again, because Google has shown twice in 18 months that retention policies can change in either direction. The principle: any reporting layer you don't own can be deprecated. Your defense is a destination you control where data lands and stays.

For most marketing teams, that destination is a warehouse: BigQuery, Snowflake, Redshift, or a marketing-native managed option like the Dataslayer Data Warehouse. For teams not yet at warehouse-volume, a Google Sheet kept current via a scheduled connector serves the same role at a smaller scale. The shape that matters is: data lands in storage you own on a schedule, separated from the platform whose retention policy might change.

For the full decision framework on whether you need a warehouse and which kind, see our Marketing Data Warehouse 2026 Guide.

FAQ

Does this change affect the Google Ads UI date pickers immediately, or only the API?
Both. The UI will return empty results or "data unavailable" for granular reports older than 37 months from June 1. The API throws an error. The Google Analytics Data API silently truncates to 36 months without warning. The failure mode that's hardest to detect because your queries just return less data than they used to. There is no UI-only or API-only carve-out.

Is monthly aggregate data really safe?
Yes. Monthly, quarterly, and yearly aggregates remain available for up to 11 years per Google's announcement. The 37-month cap is specifically on hourly, daily, and weekly granularity.

What happens to my existing BigQuery tables fed by Data Transfer Service?
Existing data in your BigQuery tables stays where it is. Post-June 1, scheduled transfers will stop populating new data older than 37 months, and manual backfills for those date ranges will fail or no-op. The operational risk is at the configuration layer. Audit your transfer schedules and any custom orchestration that re-triggers historical date ranges to avoid load errors or schema mismatches between fresh data and the granular history you preserved before the deadline.

Can I appeal the change or get an exception?
No exception process has been announced. The policy is uniform across all Google Ads accounts and all advertisers.

Will Search Ads 360 data also be capped?
Yes. The same 37-month limit applies to the Search Ads 360 connector in BigQuery Data Transfer Service. The behavior on manual backfills is also the same: they fail or no-op for date ranges older than 37 months.

What if I only need year-over-year comparisons, not daily history?
If your YoY comparisons are at monthly or coarser granularity, you're unaffected. The cap only hits granular reports. If your YoY uses daily or weekly granularity to compare specific weeks or campaign launches across years, you need to archive before June 1.

Conclusion

The 37-month cap is a hard deadline with no exception process. The June 1 enforcement date separates teams that will keep their full granular history forever from teams that will be locked at 37-month rolling windows for the rest of their reporting life. The Google Analytics Data API silent truncation is the failure mode most likely to go undetected; teams that don't archive before June 1 will only discover the gap weeks later when a year-over-year query quietly returns less data than it used to.

The action is straightforward: pick a destination you own, run a one-time historical backfill of all granular Google Ads data, verify it landed before June 1, then set up ongoing daily refreshes so you never face this loss again. Method matters less than execution speed. The teams that don't act lose data; the teams that act keep it.

Start a free Dataslayer trial to preserve your Google Ads history before the deadline. Setup takes minutes; the historical backfill runs in the background.