Google Ads API розширює звітність по продуктах з 15 червня: що зламається

Будь-який тімлід платформи, який хоча б раз розгортав детектор аномалій на основі даних 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 на рівні продукту через цей endpoint.

Другий зсув: 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, майже завжди починаються однаково: downstream-система довіряє метриці, джерело метрики мовчки змінюється, і хтось отримує пейдж за стрибок, якого насправді не існує. 15 червня — це запланована версія такого сценарію.

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

Агентства, що ведуть клієнтські дашборди, — наступний радіус ураження. Зростання витрат PMax на рівні продуктів на 30% у порівнянні з попереднім тижнем у звіті для клієнта в понеділок вранці без жодних змін у кампанії — це артефакт, що породжує термінові дзвінки. Команди, з якими я працював у перфоманс-маркетингу, знають: пояснити артефакт у pipeline нетехнічному стейкхолдеру займає більше часу, ніж сам баг.

Аналітичні команди, що проводять річний аналіз ефективності продуктів, теж постраждають непомітно. Будь-яке порівняння, що охоплює 15 червня 2026 року, є структурно недійсним без анотації межі. Запит витрат Demand Gen по продуктах за травень 2026 року не повертає нічого. Той самий запит за липень 2026 року повертає реальні числа. Це не тренд рік-до-року — це зміна схеми, яка маскується під зростання.

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

Дії для перфоманс-маркетингу

До 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.
• Performance Max shopping_performance_view повертатиме всі мережі, що спричинить одноразовий стрибок показів, кліків, витрат і конверсій на рівні продуктів.
• Бекфілу не буде. Запити для дат до 15 червня 2026 року не міститимуть розширених даних, що порушує порівняння продуктів рік-до-року через межу.
• Правила виявлення аномалій і клієнтського алертингу, побудовані на звітності по продуктах Google Ads, потрібно вимкнути навколо межі, інакше вони генеруватимуть хибні спрацювання.
• Цей запуск є частиною тривалої роботи з підвищення прозорості API від v20 до v24, і слід очікувати подальших розширень зі зміною схем.