If your Google Ads reporting is part of how you defend budget, explain CAC swings, or diagnose “what changed” across multiple years, there’s a new constraint coming: that detail won’t be there forever. Starting June 1, 2026, Google Ads will only retain granular reporting (hourly/daily/weekly) for 37 months. After that, it’s gone from the UI and no longer queryable via API, scripts, and some BigQuery/Data Transfer workflows. Monthly/quarterly/yearly rollups will stick around for 11 years. (Source: Search results, Query 1 and Query 3.)
That split sounds reasonable until a demand gen leader tries to answer a simple board question: “How did this quarter compare to the same quarter four years ago—week by week—after the pricing change and the category shift?” With 37 months of day/week data, the “why” starts to blur right when the story usually gets interesting.
If you only change one thing, change this: treat June 1, 2026 as a data-archiving deadline, not a product update. The work isn’t glamorous. It’s operational. But it’s the difference between being able to audit performance and being stuck with coarse rollups when something breaks.
What’s actually changing (and what isn’t)
Google is enforcing a split retention model for Google Ads reporting. Granular performance data segmented by hour/day/week will only be available for 37 months. Aggregated data at monthly/quarterly/yearly levels will remain available for 11 years. (Source: Search results, Query 1 and Query 3.)
So macro trend reporting doesn’t disappear. You’ll still be able to see longer-term spend and performance at a high level. The cliff is on diagnostic detail: the stuff operators use to spot creative fatigue, isolate a match-type problem, or explain why last year’s Q2 looked “fine” but actually had three ugly weeks that got masked in a monthly average.
And the enforcement isn’t limited to the UI. Google notes it will affect the Google Ads API, scripts, and some BigQuery/Data Transfer workflows. (Source: Search results, Query 1 and Query 3.) That’s the part that tends to hurt quietly—dashboards keep running until they don’t, and then everyone scrambles.
The failure mode nobody wants: broken queries and missing context
Here’s the mechanical break: API and script queries that request granular segments (for example, segments.date or segments.week) for periods older than 37 months will fail with a date-range error after enforcement. (Source: Search results, Query 3.)
That’s not “your chart looks a little different.” That’s “your pipeline pacing dashboard errors out,” or worse, “someone removes the segment to make it work” and now leadership is looking at a smoothed line that hides the thing you were trying to prove.
The BigQuery nuance matters too. Google indicates that data already transferred and stored in BigQuery is not removed. But backfill runs for dates older than 37 months will stop populating new data after the change. (Source: Search results, Query 3.)
Translation: if your warehouse is your source of truth, you’re safer—if you’ve been pulling the right grain all along. If you’ve been relying on backfills or re-pulls to “complete the history later,” that door closes for older periods. The gap shows up when someone rebuilds a model, refreshes a table, or changes attribution logic and expects to re-run history.
Why this matters more in B2B than people admit
For B2B SaaS teams, the pain isn’t just nostalgia for old dashboards. The main impact is losing long-range, high-detail trend and diagnostic data: long sales-cycle analysis, keyword/campaign/audience-level diagnostics over long periods, and YoY comparisons that rely on day/week granularity beyond roughly three years. (Source: Search results, Query 1.)
In practice, B2B measurement lives on two timelines at once. One is fast: weekly pacing, lead flow, CPL, and short feedback loops. The other is slow: cohort quality, pipeline conversion, and the downstream “was that quarter’s spend actually worth it?” readout. When granular history disappears, the slow timeline gets harder to defend because you can’t reconstruct what happened in the messy middle.
There’s another layer: signal quality. Commentary around this change often lands on a broader risk—missing or insufficient conversion data weakens the feedback loop that makes Google Ads optimization profitable, which increases wasted spend risk. (Source: Research Brief, Expert Perspectives.) The retention policy isn’t the same thing as conversion tracking, but it compounds the same operational reality: less trustworthy data makes automation easier to misread and harder to audit.
One move: build a retention-ready archive, then redesign reporting
Google’s own recommendation is straightforward: export the granular historical data you’ll need before June 1, 2026, and review queries now to avoid broken reporting after enforcement. (Source: Search results, Query 3.)
That’s the primary tactic. Everything else is implementation detail.
The hypothesis (make it falsifiable): If we warehouse Google Ads day/week-level performance data before June 1, 2026, then executive reporting continuity and diagnostic speed will improve because dashboards and analyses won’t depend on Google’s post-37-month availability.
Run it this week: the Retention Readiness Audit
- Owner: Marketing Ops (primary), with RevOps/data engineering support if BigQuery is involved.
- Tools: Google Ads UI + API/scripts inventory; BI tool query logs; BigQuery/Data Transfer configs if used.
- Timeline: 3–5 business days for the first pass.
- Scope: Identify every dashboard, scheduled report, script, and API pull that uses day/week/hour segments.
Setup: Make a list of all reporting surfaces that matter: exec scorecards, weekly pacing, creative/keyword diagnostics, cohort analyses, and any model training datasets that use granular Google Ads inputs.
Launch: For each surface, trace the query. If it requests segments.date, segments.week, or any hourly/day-level segmentation beyond 37 months, flag it as “will break.” (Source: Search results, Query 3.)
Readout: Classify each use case into one of two buckets:
- Durable at aggregate grain: can live with monthly/quarterly/yearly for long-range views (11 years). (Source: Search results, Query 1 and Query 3.)
- Requires granular history: must be archived externally to preserve diagnostic depth past 37 months.
Next test: Pick one “requires granular history” dashboard and run it end-to-end off the warehouse copy (not the live Google Ads query). Time the rebuild. Document the deltas.
Success metrics and guardrails
- Success = 100% of business-critical reporting surfaces remain functional after June 1, 2026 without removing granularity “just to make it run.”
- Secondary = time-to-diagnosis on a performance anomaly stays flat (or improves) when looking back beyond 37 months.
- Stop-loss = if rebuilding warehouse-driven reporting requires changing metric definitions or attribution logic midstream, pause and document before shipping (otherwise you’ll “fix” retention by breaking comparability).
Trade-off (say it out loud): This adds storage and governance overhead. It also forces decisions about what grain to keep and for how long. But the alternative is worse: losing the ability to audit your own spend history at the level where most B2B mistakes actually show up.
June 1, 2026 is when the 37-month window becomes real. After that, the story of your account still exists—but only as a blur of monthly totals unless you’ve kept the frame-by-frame tape.