On June 15, 2026, the Google Ads API will finally return cost and conversion metrics at the product level for Video, Demand Gen, App and Performance Max campaigns — and historical API requests for dates before June 15 will return nothing for the new fields. That’s the good news and the catch in one sentence. The expansion is what advertisers have been asking for. The no-backfill rule is the year-over-year reporting break nobody is talking about.

This isn’t an isolated change. It lands inside a 15-day window with two other Google Ads policy shifts that together force a dashboard rebuild for every WooCommerce store running ads beyond Search and Shopping.

What June 15 Actually Unlocks

The announcement came from Dora Sun on the Google Ads API Team on April 30. The mechanics are narrow, specific, and have been quietly expected for months. Four things change.

One. The shopping_product resource — the Google Ads API endpoint that returns product-level performance — starts returning cost and conversion metrics for Video campaigns. Before June 15, Video campaigns only exposed impressions and clicks at the product level. After, they expose what the product cost you to advertise and what it sold.

Two. The same expansion applies to Demand Gen campaigns. If you’re running Demand Gen for a WooCommerce store, you’ve been flying with two of four wheels. After June 15, you have all four.

Three. App campaigns get the same treatment. Niche for most WooCommerce stores, important for the ones running them.

Four. Performance Max gets a deeper expansion. PMax channel-level reporting first appeared at user-interface level in May 2025 and became programmatic in January 2026 via API v23. The June 15 change adds cost + conversion granularity across the full network breakdown — Search, YouTube, Display, Discover, Gmail and Maps — at the product level.

The shopping_product resource on June 15 becomes the first single endpoint where a WooCommerce store can pull product cost and conversion data across all campaign types at once.

The Three-Change Window: June 1, June 10, June 15

One change is manageable. Three in 15 days is a project. Here’s the full picture.

June 1: The 37-month retention cap. Google’s 11-year granular reporting era ends. From June 1 onward, granular Google Ads data older than 37 months ages out. Stores that have been pulling 4+ year history into BigQuery for trend analysis lose the back catalog if they didn’t warehouse it themselves. Seresa covered this in Google Just Reversed Its 11-Year Data Retention Policy on May 1 — From June Your Granular Google Ads Data Caps at 37 Months.

June 10: Google Ads API v20 sunsets. All v20 API requests will fail. Any reporting tool, dashboard or middleware still on v20 needs to migrate to a current release before this date. Five days before the June 15 expansion, your pipeline either updated or broke.

June 15: Product reporting expansion + consent mode single-control. The new fields ship for Video, Demand Gen, App and PMax. Separately, ad_storage becomes the single consent control for ads personalisation — another reporting downstream change for stores honouring consent mode.

For a WooCommerce store with a single in-house dashboard, these are three different repairs to the same machine inside two weeks. The honest framing is that this is a Q2 project, not a Tuesday afternoon.

The Year-Over-Year Comparison Break

The line from the Google Ads Developer Blog is short and unambiguous: historical API requests for dates prior to launch will not contain the expanded data.

Translate that into a WooCommerce dashboard. If you have a Looker Studio chart showing product-level cost for Video campaigns over the last twelve months, on June 16 that chart looks like this: eleven months of zero, one month of real data. May 2026 numbers do not exist for those fields. June 2026 numbers exist. You can’t put them on the same line and call it a trend.

For Video, Demand Gen, App and Performance Max product-level data, there is no May-to-June comparison and no May-2026-to-May-2027 comparison until May 2027.

Search and standard Shopping campaigns are unaffected — they already had product-level cost and conversion data. If your dashboard only uses those campaign types, nothing here changes. If it includes Video, Demand Gen, App or PMax (and almost every modern WooCommerce ad mix includes at least PMax), you have a presentation problem on top of a data problem.

The clean answer is to annotate June 15 in every affected chart and treat the two periods separately for those campaign types. It’s not pretty. It’s honest.

What is the shopping_product Resource?

Definition: The Google Ads API resource that surfaces product-level performance data — historically returning only impressions and clicks for Video, Demand Gen and App campaigns, and gaining cost + conversion metrics for those campaign types starting June 15, 2026.

Key benefit: One endpoint, all campaign types, product-level granularity for the first time.

How it differs from earlier: Previously, you needed separate logic for Search/Shopping versus Video/Demand Gen/App/PMax when pulling product cost. From June 15, the resource is uniform — which makes the migration of any custom pipeline easier and the no-backfill problem less obvious to people maintaining those pipelines.

CartDataSalesView: The Other Quiet Addition

Two months before the June 15 expansion, Google shipped Google Ads API v24 on April 22 — and CartDataSalesView arrived with it. CartDataSalesView is item-level product-sold reporting using cart data, surfaced through the API for the first time. For a WooCommerce store sending cart data to Google Ads via enhanced conversions or server-side conversion uploads, this is the resource that ties ad spend to specific SKUs in a cart, not just to product clicks.

It’s independent of June 15 and gets less attention because it was a quiet release. It matters because the combination of the two — CartDataSalesView item-level cart data plus shopping_product expanded cost + conversions across all campaign types — is the most product-granular ad reporting Google has ever exposed through the API.

The capability ceiling just went up. The historical floor just came in.

If you want the longer arc on what PMax has been missing and what it still doesn’t tell you, see Google’s New Performance Max Channel Reporting Tells You Where Your Budget Went — but Not Which WooCommerce Products It Sold — June 15 is the chapter that finally partially answers that piece.

The Durable Answer: Own the History Yourself

Every Google reporting policy change in the last three years has moved in the same direction: more data exposed at the API, less data retained server-side, more breaks in historical comparison. The 37-month retention cap is the same shape of problem as the no-backfill rule on June 15 — the data is available now or never, and what you don’t capture today, Google won’t hold for you later.

The pattern is consistent enough to plan around. The advertisers who survive each policy change with their dashboards intact are the ones who warehouse Google Ads data into their own BigQuery instance, daily, against their own schema. When Google’s retention shortens or a reporting endpoint changes, the historical record is still in the warehouse and the dashboard rebuilds quickly.

Transmute Engine™ is a dedicated Node.js server that runs first-party on your subdomain (e.g., data.yourstore.com). The inPIPE WordPress plugin captures WooCommerce conversion events and sends them via API to your Transmute Engine server, which then enhances and routes events into BigQuery alongside your Google Ads API extracts. The result is that the history Google is no longer providing is the history you already own, and rebuilds after policy changes take days, not quarters.

Key Takeaways

• June 15, 2026 — Google Ads API returns cost + conversions at the product level for Video, Demand Gen, App and Performance Max for the first time.
• No backfill. Historical API requests for dates before June 15 will not contain the new fields. May/June 2026 are not comparable for the affected campaign types.
• Three changes in 15 days. June 1 retention cap, June 10 v20 API sunset, June 15 product expansion + consent single-control. Treat as one connected project.
• CartDataSalesView (v24, April 22) adds item-level cart data — the most product-granular ad reporting Google has ever shipped through the API.
• Annotate June 15 in every affected chart. For Video, Demand Gen, App and PMax product-level reporting, treat pre-June-15 and post-June-15 as separate periods.
• Warehouse Google Ads data into your own BigQuery daily. Every Google retention or reporting policy change becomes a routine repair instead of a quarter-long project.

Frequently Asked Questions

Annotate June 15 in your dashboards today and start warehousing your Google Ads extracts into your own BigQuery this month — every future Google reporting change is a routine repair from there. seresa.io