Google Ads API Will Inflate PMax Numbers on June 15 and Refuse to Backfill

On June 15, 2026, Google's Ads API will start returning cost and conversion data for Video, Demand Gen, and App campaigns through the shopping_product resource, expand the shopping_performance_view to every campaign type that uses Merchant Center, and return all networks for Performance Max instead of a partial set. Google's own announcement warns of a one-time spike in product reporting metrics, with no historical backfill. Anyone whose dashboards alert on YoY drift has roughly six weeks to neutralize the alarm before it fires.

The change was posted on the Google Ads Developer Blog by Dora Sun on April 30, with PPC Land being the first to surface it outside the dev forum. It's a small post. The implications are not.

What actually flips on June 15

Three things, and they're easy to read past if you don't run reporting infra:

First, the shopping_product resource will start returning Cost and Conversion metrics for Video, Demand Gen, and App campaigns. Until now, those campaign types only exposed impressions and clicks at the SKU level. If you've been pulling product-level cost data for any non-Shopping, non-PMax campaign, you've been pulling zeros, or you've been imputing it with allocations off the campaign-level totals. Both of those go away.

Second, the shopping_performance_view will start returning results for every campaign type that uses Google Merchant Center, not just the subset it returns today. According to the existing shopping ads reporting docs, this view aggregates by product dimension at the time of the event, which is why retailers lean on it for SKU-level analytics. Standardizing the behavior is overdue. It also means rows you weren't expecting are about to show up in queries that filter loosely.

Third, and this is the one that will set off pagers: shopping_performance_view will start returning all networks for Performance Max campaigns, not the partial coverage it returned before. Google describes this as producing "a one-time increase in all product reporting metrics." That's the spike.

The backfill problem nobody is talking about yet

Buried in the same announcement is the line that should make every analytics lead read it twice: "Historical API requests for dates prior to the launch will not contain this expanded data."

That sentence breaks year-over-year comparisons for any team that pulls product-level metrics through the API. The June 15, 2026 numbers will include networks the June 14 numbers don't. The June 15, 2025 numbers won't be retroactively updated to match. You can't paper over it with a join, because Google isn't going to release the historical detail at all.

This isn't the first time Google has changed PMax reporting and refused to backfill. Channel-level reporting in v23 followed the same pattern: data only available from June 1, 2025 onward, with nothing before. Search Engine Land covered that v23 change when it shipped. So if you've already been living with one PMax discontinuity in your charts, June 15 is a second one in the same year.

For most teams the practical impact is a vertical line on every product-level chart and a footnote that nobody reads.

Why this hits dashboards harder than it looks

The reason this matters more than a typical API tweak is the layering. Most BI stacks I've seen do three things at once: pull metrics through a connector, run anomaly detection on top, and feed YoY benchmarks into pacing models. All three break in slightly different ways.

Anomaly detection fires on June 15 because the spike is mechanical, not behavioral. PMax product impressions go up. PMax product clicks go up. PMax product cost stays roughly the same as before, since the underlying spend hasn't changed. CTR craters in the report even though it didn't crater in the auction. If your alerting watches CTR or cost-per-impression and you haven't suppressed alerts for that day, oncall is going to spend the morning chasing a phantom.

YoY pacing models drift quietly. PMax pacing tools that compare current product-level reach to last year's product-level reach will start telling you you're crushing last year. You're not. You're just measuring more networks. From what I've seen, this is the kind of change that doesn't trigger an investigation until quarter-end, when budgets get redistributed off the inflated numbers.

Connector-fed dashboards lose definition without warning. If you've named your charts "PMax product impressions" and trusted that the underlying definition was stable, the rug pull is that the same metric name now means something larger. Anyone reading the chart who doesn't know June 15 happened will read the post-cutover number as a real lift.

The six-week prep list

This isn't theoretical work. There's a finite list of things to ship before June 15:

1. Add a discontinuity marker to every PMax and Shopping product-level chart. A vertical line, an annotation, a banner above the chart. Whatever your BI tool supports. Make the cutover visible by default so nobody reads the spike as performance.

2. Suppress anomaly alerts on June 15 for PMax product reports. Not silence them entirely, but raise the threshold or carve out the specific ad_group/campaign type combinations Google is changing. The Performance Max segments to watch, per the retail reporting docs, are ad_using_product_data combined with ad_network_type.

3. Decide what to do with YoY pacing models. The cleanest fix is to recompute your June 15, 2025 baseline as if it included the new networks, but Google isn't giving you that data, so you can't. The next-best fix is to switch product-level pacing to a 4-week trailing window for the rest of the calendar year, which avoids the YoY break.

4. Audit which Video, Demand Gen, and App campaign reports you're imputing cost for. Those imputations need to be turned off the moment real data starts arriving. If you keep them, you'll double-count cost on June 15 and your CPA will look much higher than it is. The Performance Max reporting docs are the cleanest reference for what's currently exposed versus what changes.

5. Snapshot June 14, 2026 numbers before the cutover. Pull the last full day of pre-change product-level reporting for every campaign type and store it somewhere your BI tool can join against. You'll want it as the only clean reference point for "what these metrics looked like under the old definition."

The pattern this fits into

Google's been migrating reporting toward Merchant Center as the spine for product-level data across more campaign types. Channel-level PMax reporting in January, the AI Max upgrades coming in September that we covered when Google announced auto-upgrades for DSA campaigns, the Q1 earnings reading where Search ads grew 19% while the same products got harder to attribute. Each step makes Performance Max the universal container, and each step pushes more of the actual measurement work onto the buyer.

Six weeks isn't a lot of time, but it's enough if the work starts this week instead of June 12. The teams that get caught are the ones who treat it as a developer-blog footnote. It's the kind of change where a half-hour of dashboard prep saves a month of "wait, why are our PMax product numbers so high" conversations on Slack.

Notice Me Senpai Editorial