Google Ads’ 37-Month Data Cap Hits June 2026: The BigQuery Archive Lead Gen Advertisers Need Live Before April

Google Ads is reported to begin enforcing a 37-month historical reporting cap starting June 1, 2026, affecting the UI and Ads API (Google Ads Developer Blog). The standard BigQuery Data Transfer mirrors that source retention by default. After the cutover, a query for January 2022 keyword performance returns nothing, not a partial result.

If you run pay-per-call or lead gen at any scale, this is the single most important data engineering deadline on your 2026 calendar. The Google Ads 37 month data limit lead generation operators have been hearing about quietly destroys the longitudinal baselines you use to validate which keywords actually produce bound policies, funded loans, or qualified B2B opportunities.

Most advertisers will assume the BigQuery Data Transfer they turned on two years ago has them covered. It does not. Below is what’s actually changing, why it matters more for lead buyers than for ecommerce or brand advertisers, and the exact three-pipeline archive you need live in BigQuery before April.

When the 37-Month Cap Lands, Your 2022 Baselines Disappear, They Don’t Truncate

The change is simple to state and ugly to live with. Reporting indicates that as of the June 2026 cutover, any date range older than 37 months returns empty in the Google Ads UI and the Google Ads API (Google Ads Developer Blog). The cap is rolling, so each new month an older month ages out.

Which surfaces are affected: UI, Ads API, Search Terms report, and the Data Transfer mirror

Four surfaces matter for lead gen operators:

• The Google Ads UI, including custom date ranges and the change history.
• The Google Ads API, which most agencies and in-house teams use for nightly reporting pulls.
• The Search Terms report, already the most retention-sensitive object in the platform.
• The Google Ads BigQuery Data Transfer, which mirrors source retention by default per Google’s transfer documentation.

If your reporting stack touches any of these, your historical lookback shortens to 37 months at the cutover.

Why ‘truncated’ and ‘deleted’ are different problems for advertisers

A truncated dataset still tells you something. A deleted one tells you nothing. After the cutover, a query against 2022 returns zero rows, which means dashboards that join Ads cost data to CRM revenue silently lose their 2022 cost side. Revenue stays. Cost vanishes. Your revenue per lead ratio for that cohort becomes mathematically undefined.

This is the part most operators miss. The numbers don’t get worse. They go blank.

If Your Sales or Renewal Cycle Runs Longer Than 3 Years, the Google Ads 37 Month Data Limit Breaks Lead-Quality Validation

For ecommerce and brand advertisers, 37 months of history is fine. For lead gen and pay-per-call, it isn’t, because the unit of analysis is not a single click-to-purchase event. It’s a click that becomes a lead, a lead that becomes a call, a call that becomes a policy or a loan, and a policy or loan that pays out across years.

Insurance, mortgage, and financial services: the verticals with the most to lose

A few concrete examples from how our clients use multi-year lookbacks:

• A final expense advertiser validating a keyword’s true cost-per-bound-policy across a four-year cohort, including chargebacks. In our experience, final-expense chargeback exposure routinely lands in the 6 to 18 month window past bind.
• A mortgage advertiser correlating 2022 refi-window keywords against the current pipeline. The 2022 cohort is the only honest comparison to current rate-environment behavior, and it ages out first.
• A P&C advertiser benchmarking seasonality across three full renewal cycles to separate true keyword performance from quote-shopping noise.
• A B2B lead gen operator measuring multi-year LTV by source, where the deal cycle from MQL to closed-won often runs well past 12 months and the expansion revenue tail runs years longer.

In every case, the formulas operators rely on lose their longitudinal anchor:

• Cost per qualified call = Total campaign cost ÷ qualified calls
• Revenue per lead = Total revenue ÷ total qualified leads
• Call qualification rate = Qualified calls ÷ total calls

These formulas still compute after the cutover. They just can’t be compared to anything older than 37 months. You lose the ability to say “this keyword’s qualified call rate is consistent with its 2022 baseline” because there is no 2022 baseline anymore.

What YoY benchmarking and seasonality lookbacks actually require

Proper YoY benchmarking needs at least two full prior cycles to separate signal from noise. Seasonality models for Medicare AEP, ACA open enrollment, tax-season financial services, or HVAC summer demand need three. The 37-month cap gives you, at most, three years and one month, which is barely enough for the third cycle and zero margin for backtesting.

Reader takeaway: the loss is silent. Your dashboards keep working. They just lie by omission.

The Default BigQuery Data Transfer Is a Mirror, Not an Archive

This is where most advertisers will discover the problem too late. The Google Ads BigQuery Data Transfer is excellent at what it does, but it is bounded by Google Ads’ own retention policy at the source. Once a month falls outside the 37-month window at the source, you cannot rely on the transfer to keep refreshing it, and any reprocessing Google performs will only operate on data still inside that window.

If you want history beyond 37 months, you need to copy each day’s transfer output into a separate, write-once dataset that you control. That’s an architectural choice, not a setting.

What the default Data Transfer captures, and what it silently leaves out

The default schema captures campaign, ad group, keyword, and click-level performance data on a daily refresh. What it does not capture, in any form useful to a pay-per-call operator:

• Full historical search terms at the granularity needed to validate match-type drift over time.
• Call tracking dispositions (call duration, qualified flag, buyer, payout, recording link).
• CRM revenue events (policy bound, premium, chargeback flag, LTV milestones).
• The joins that connect a search term to a click to a call to a bound policy.

Why an immutable, date-partitioned snapshot dataset is non-negotiable

The fix is structural. You need a second BigQuery dataset, separate from the live transfer, with write-once date-partitioned tables. A scheduled query copies each day’s data from the live transfer into the archive dataset and never updates it again. Once written, those rows are frozen. Google’s source retention can’t reach them because they no longer live in the transfer object that mirrors the source.

If you turned on Data Transfer two years ago and walked away, you have a mirror, not an archive. As of today, you still have time to fix that. By the cutover, you don’t.

Build These Three Pipelines Into BigQuery Before April 2026, Not One

The trap most advertisers will fall into is assuming the BigQuery Data Transfer is the archive. It isn’t. Operators who actually run pay-per-call know the real archive is three pipelines, joined on a composite key of campaign_id + click_id + call_id. Building this in May 2026 is too late. The 2023 baseline you’d use to validate a final-expense keyword’s true lead quality is already aging out month by month right now.

Pipeline 1: Ads API to date-partitioned BigQuery tables you control

A daily pull from the Google Ads API writing to operator-controlled, write-once date-partitioned tables. At minimum, pull:

• Keyword-level performance with gclid-resolvable click IDs.
• Search terms at keyword and match-type granularity.
• Geo performance at the metro or zip-prefix level your buyers care about.
• Device performance.

Backfill to the earliest accessible date the day you stand the pipeline up. If today is mid-2026 and you can still reach late 2022, grab it. Tomorrow’s accessible window is one day shorter than today’s.

If you’re concerned about your tooling breaking before you can finish the backfill, our Google Ads API v20 sunset analysis covers the version-cutover risk on top of the retention cutover.

Pipeline 2: Call-tracking webhook stream joined on gclid

From your call-tracking platform, stream every call event to BigQuery as it happens:

• call_id, gclid (or click ID), caller_number_hash, call_duration, qualified_flag, disposition, buyer, payout, recording_url.

In our experience, qualified-call thresholds vary by vertical: final expense calls under 90 seconds qualify at under 15%, while Medicare AEP calls under 120 seconds qualify at under 20%. Capture the raw duration, set the threshold downstream. Most serious call-tracking platforms support webhook delivery natively. Our Ringba vs Retreaver vs Invoca operator’s guide walks through which platforms make this clean and which make it painful.

Pipeline 3: CRM revenue and disposition events joined on lead_id

From your CRM or policy administration system, stream every revenue-affecting event:

• lead_id, policy_id or loan_id, bind_date, premium, commission, chargeback_flag, chargeback_date, ltv_event_type, ltv_value.

This is the offline conversion layer that closes the loop from click to revenue. Without it, the other two pipelines tell you which keywords drove calls, not which keywords drove money.

The composite key and the daily materialized view

The glue is a daily materialized view that joins all three pipelines on campaign_id + click_id + call_id and locks keyword-level cost per qualified call before the underlying search-term data ages out. The view writes its results to a date-partitioned, immutable table. Once written, those numbers are frozen, even when the source search-term row eventually disappears.

Do These Five Things This Week to Preserve the 2022–2023 Baseline

This is triage. Every week of delay is a week of 2022–2023 data you cannot get back.

Backfill priorities by vertical: what to grab first if you only have a week

If you only have a week of engineering capacity:

• Insurance (final expense, Medicare, ACA, life): search terms, call dispositions, bind and chargeback events back to the earliest accessible date.
• Mortgage: search terms, click-level cost, funded loan events, with extra attention to 2022 refi-window keywords.
• Financial services and B2B: keyword-level cost, lead-to-opportunity-to-closed-won timestamps.
• Home services (HVAC, plumbing, roofing, solar, pest): search terms, call dispositions, booked-job revenue, with seasonality cuts by metro.

Storage cost vs. data-loss cost: the ROI math is trivial

BigQuery long-term storage runs $0.01 per GB per month per Google Cloud pricing. A multi-year keyword and call archive for a mid-sized lead gen account is typically 20 to 200 GB. Annual storage cost: roughly $2.40 to $24. The cost of losing your 2022–2023 baseline is the cost of every future media decision made without it.

Talk to Our Pay-Per-Call Team Before the April Deadline

If you buy leads or calls in insurance, mortgage, financial services, home services, or B2B, the Google Ads 37 month data limit is going to change how you validate source quality. The operators who build the three-pipeline archive before April keep their longitudinal baselines and keep buying with confidence. The ones who don’t will be flying blind on every keyword decision tied to a multi-year cycle.

We help lead buyers structure the BigQuery archive, wire the call-tracking and CRM webhooks, and stand up exclusive routing that preserves the source-quality signal across the retention cutover. If you want to talk about your specific vertical, your volume needs, or how we structure pay-per-call buying with preserved historical baselines, book a free strategy call with Elevarus and ask about exclusive lead routing for your vertical. Bring your current data setup. We’ll tell you exactly what to archive this week.