Skip to content
RiverCore
Google Ads API расширяет отчёты по продуктам с 15 июня: что сломается
Google Ads APIproduct reportingPPC automationGoogle Ads API product reporting changes June 2026video demand gen app campaign cost data

Google Ads API расширяет отчёты по продуктам с 15 июня: что сломается

9 июн 20266 мин. чтенияAlex Drover

Любой технический лид, который хоть раз настраивал детектор аномалий на основе данных Google Ads, знает этот сценарий: пороги тщательно подбираются неделями, а потом одно изменение схемы на стороне платформы ломает всё в 3 часа ночи. Именно это произойдёт 15 июня 2026 года. Google расширяет отчётность на уровне продуктов через Ads API, и изменение данных будет выглядеть не как запуск новой функции. Оно будет выглядеть как инцидент.

Что произошло

30 апреля 2026 года Дора Сан из команды Google Ads API опубликовала уведомление в Google Ads Developer Blog о трёх скоординированных изменениях в отчётности по продуктам, которые вступят в силу 15 июня 2026 года. Как сообщил PPC Land, изменения одновременно затрагивают ресурс shopping_product, ресурс shopping_performance_view и охват сетей Performance Max.

Первое изменение: метрики расходов и конверсий начнут возвращаться для кампаний Video, Demand Gen и App внутри ресурса shopping_product. До 15 июня эти типы кампаний возвращали только показы и клики на уровне продукта. Без расходов. Без конверсий. Все, кто запускал кампании Video или App, связанные с продуктами, не имели данных о ROI на уровне продукта через этот эндпоинт.

Второе изменение: shopping_performance_view будет возвращать результаты для каждого типа кампаний, использующих Google Merchant Center. Ранее поведение было непоследовательным в зависимости от типа кампании, что делало создание единых продуктовых дашбордов без дополнительного кода крайне затруднительным.

Третье изменение — то самое, которое разбудит дежурных, — касается Performance Max. При запросе shopping_performance_view для PMax начнут возвращаться все сети. Ранее включались только некоторые из них. Google прямо предупреждает, что это приведёт к единовременному росту всех метрик отчётности по продуктам для кампаний PMax. Рост — это не новые результаты. Это данные, которые уже генерировались, но не отдавались через API.

Одна деталь, которая важнее, чем кажется: бэкфилла не будет. Исторические запросы к API для дат до 15 июня 2026 года не будут содержать расширенные данные. Никакой беты. Никакого периода подключения. Граница жёсткая.

Техническая анатомия изменений

Чтобы понять, почему это обновление имеет такой эффект, стоит посмотреть на историю изменений Google за 2025–2026 годы. Отчётность на уровне каналов для Performance Max впервые появилась в интерфейсе рекламодателей в мае 2025 года, разделив доставку по Search, YouTube, Display, Discover, Gmail и Maps. Эта видимость добралась до API восемь месяцев спустя — в Google Ads API v23 в январе 2026 года, заменив обобщённый enum MIXED конкретными разбивками по каналам. Важно: данные по каналам в v23 существуют только для дат начиная с 1 июня 2025 года. Тот же паттерн с жёсткой границей повторяется теперь на уровне продуктов.

Если двигаться в обратном порядке: v20 вышел 4 июня 2025 года и представил минус-слова на уровне кампаний для PMax (ранее доступные только на уровне аккаунта), а также расширенную отчётность по группам объявлений. v22 вышел 15 октября 2025 года и добавил сегменты отчётности, такие как ad_using_product_data и ad_using_video, которые показывают, использовало ли объявление фиды Merchant Center или видеоактивы. v24 вышел 22 апреля 2026 года с CartDataSalesView для отчётности о проданных товарах на уровне позиций, девятью новыми enum типов конверсий для лидогенерации, охватывающих GA4 и Firebase, а также поддержкой VTC-оптимизации для Demand Gen и App.

Изменение от 15 июня закрывает структурный пробел, который оставался во всех этих обновлениях. Demand Gen охватывает YouTube, Discover и Gmail. App-кампании обеспечивают установки и действия внутри приложений в Search, Play, YouTube и Display. Обе категории генерировали расходы и конверсии, привязанные к продуктам, но ни одна из них не возвращала эти данные на уровне продукта. PMax возвращал их, но только для части сетей.

Моя оценка: это не запуск фичи, а наверстывание прозрачности. Google унифицирует поверхность отчётности по продуктам, чтобы кампании, связанные с GMC, одинаково отображались через API вне зависимости от типа кампании. В долгосрочной перспективе это хорошо для инженерных команд. В краткосрочной — это операционный удар, потому что один и тот же SQL- или BigQuery-экспорт, запущенный 16 июня, вернёт другую структуру и бо́льшие числа, чем 14 июня, без какого-либо флага версии для управления поведением.

Кто пострадает

Больше всего рискуют команды с наиболее зрелой инфраструктурой. Если вы построили систему обнаружения аномалий поверх отчётности по продуктам Google Ads, ваши детекторы теперь стали потенциальными источниками проблем. Производственные инциденты, которые я наблюдал в iGaming и e-commerce, почти всегда начинаются одинаково: система доверяет метрике, источник метрики меняется без предупреждения, и кто-то получает алерт на скачок, которого на самом деле нет. 15 июня — это запланированная версия такого сценария.

Аккаунты Performance Max ощутят наибольший шум. Рост показов, кликов, расходов и конверсий в отчётности по продуктам будет пропорционален количеству сетей, которые ранее были исключены для данного аккаунта, — а Google не опубликовал эту разбивку заранее. Так что заранее рассчитать масштаб невозможно. Можно только зафиксировать дату и поставить алерты на карантин вокруг неё.

Агентства, ведущие клиентские дашборды, — следующая зона поражения. Рост расходов PMax по продуктам на 30% в понедельничном клиентском отчёте «неделя к неделе» без каких-либо изменений в кампаниях — это тот тип артефакта, который порождает экстренные звонки. Команды, с которыми я работал в performance-маркетинге, знают: объяснить артефакт в пайплайне данных нетехническому стейкхолдеру занимает больше времени, чем само исправление.

Аналитические команды, проводящие год-к-году анализ эффективности продуктов, тоже пострадают — просто тихо. Любое сравнение, охватывающее 15 июня 2026 года, структурно некорректно без аннотации границы. Запрос расходов Demand Gen по продуктам за май 2026 года не вернёт ничего. Тот же запрос за июль 2026 года вернёт реальные цифры. Это не тренд год-к-году — это изменение схемы, замаскированное под рост.

Неудобный вывод: все, кто рассматривает Google Ads API как стабильный контракт, будут продолжать сталкиваться с подобным. Платформа находится в стадии расширенной прозрачности, и каждый квартал будет приносить очередной эндпоинт, который начнёт возвращать данные, которых раньше не возвращал.

Руководство по действиям для performance-маркетинга

До 15 июня сделайте четыре вещи. Первое: проведите инвентаризацию всех правил алертинга и дашбордов, которые затрагивают shopping_product или shopping_performance_view. Если правило срабатывает на процентное изменение расходов или конверсий для кампаний PMax, Video, Demand Gen или App — заглушите его на одну неделю вокруг даты изменения.

Второе: аннотируйте ваше хранилище данных. Добавьте столбец или флаг в таблицу измерений, помечающий 15 июня 2026 года как границу смены схемы для отчётности по продуктам. Любой BI-инструмент, сравнивающий данные до и после, должен отображать этот флаг в интерфейсе, а не хоронить его в вики, которую никто не читает.

Третье: проинформируйте стейкхолдеров сейчас, а не 16 июня. Отправьте клиентам и внутренним финансовым партнёрам краткое пояснение о том, что расходы PMax по продуктам, конверсии и ROAS покажут скачок в эту дату, и что это — полнота отчётности, а не рост медиабюджетов. Отметьте время отправки письма до того, как произойдёт скачок.

Четвёртое: если вы принимали решения о распределении кампаний на основе ROAS по продуктам для Video, Demand Gen или App, отложите эти решения на две-три недели после 15 июня, чтобы накопились реальные данные. Решения, принятые на первой неделе расширенной отчётности, будут зашумлены.

Формулировка на вынос: API не стал лучше за одну ночь — просто стало меньше слепых зон.

Ключевые выводы

  • Google Ads API расширяет отчётность по продуктам с 15 июня 2026 года, добавляя метрики расходов и конверсий для кампаний Video, Demand Gen и App в shopping_product.
  • shopping_performance_view для Performance Max начнёт возвращать все сети, что вызовет единовременный скачок показов, кликов, расходов и конверсий на уровне продуктов.
  • Бэкфилла не будет. Запросы для дат до 15 июня 2026 года не будут содержать расширенные данные, что делает год-к-году сравнения по продуктам некорректными через эту границу.
  • Системы обнаружения аномалий и правила клиентских алертов, построенные на отчётности по продуктам Google Ads, необходимо заглушить вокруг даты изменения, иначе они будут генерировать ложные срабатывания.
  • Это обновление является частью более длительного цикла работы по прозрачности API от v20 до v24, и следует ожидать дальнейших расширений, меняющих схему данных.

Часто задаваемые вопросы

В: Затронут ли изменения от 15 июня 2026 года мои исторические данные Google Ads API?

Нет. Google подтвердил, что бэкфилла, беты и возможности подключения к историческим данным не будет. Любой запрос к API для дат до 15 июня 2026 года вернёт старую структуру данных, что означает структурное несоответствие год-к-году для метрик на уровне продуктов по Performance Max, Video, Demand Gen и App-кампаниям через эту границу.

В: Почему метрики продуктов Performance Max резко вырастут 15 июня?

Ранее отчётность по продуктам Performance Max через shopping_performance_view включала только часть сетей. С 15 июня будут возвращаться все сети. Рост отражает данные, которые Google уже генерировал, но не отдавал через API, — а не новые медиарезультаты. Масштаб зависит от того, сколько сетей было исключено ранее для каждого аккаунта.

В: Какие версии Google Ads API имеют отношение к этому изменению?

Изменение от 15 июня опирается на последние релизы: v20 (4 июня 2025) — добавил минус-слова на уровне кампаний для PMax; v22 (15 октября 2025) — добавил сегменты отчётности PMax; v23 (январь 2026) — заменил обобщённый enum MIXED конкретными разбивками по каналам; v24 (22 апреля 2026) — представил CartDataSalesView и VTC-оптимизацию для Demand Gen и App.

AD
Alex Drover
RiverCore Analyst · Dublin, Ireland
ПОДЕЛИТЬСЯ
// RELATED ARTICLES
ГлавнаяРешенияПроектыО насКонтакт
Новости06
Дублин, Ирландия · ЕСGMT+1
LinkedIn
🇷🇺RU