Версии Google Ads API в 2026: релизы дважды в месяц и как не сломать отчётность
14 октября 2026 года вышла версия 26 Google Ads API, и вместе с ней Google поменял сам ритм выпусков: вместо четырёх релизов в год — примерно два в месяц. Для тех, кто тянет отчёты в BI, сводит расходы с CRM или гоняет свои скрипты через API, это означает одно: окно, в котором «ничего не трогаем, оно работает», стало короче. Версии Google Ads API теперь устаревают по расписанию, которое нужно держать в календаре, а не вспоминать в день, когда дашборд отдал пустую таблицу.
Эта статья — практическая: что именно изменилось в графике релизов, какие даты отключения уже объявлены, что приехало в v26, какие типы изменений чаще всего ломают интеграции и как выстроить миграцию так, чтобы она занимала полдня раз в квартал, а не три дня паники.
Короткая версия: зафиксируйте в коде конкретную версию API, подпишитесь на даты сансетов, раз в квартал прогоняйте свои GAQL-запросы на новой версии в тестовом аккаунте и сверяйте суммы метрик за фиксированный период. Всё остальное — детали этого цикла.
Что изменилось в графике релизов Google Ads API
По публикациям отраслевых изданий, ссылающихся на блог Google Ads Developer, картина на осень 2026 выглядит так:
- v26 вышла 14 октября 2026 года. Следом в том же месяце выпускается минорная v26.1.
- Релизы стали примерно двухнедельными. Между крупными версиями теперь выходят минорные — они добавляют поля и ресурсы, но не отменяют старые контракты целиком.
- Крупных версий по-прежнему четыре в год: v27 — январь 2027, v28 — апрель 2027, v29 — июль 2027, v30 — октябрь 2027. Google оговаривает, что даты могут сместиться, а релизы в сезон праздников могут пропускаться.
- Минорные версии отключаются вместе со своей крупной. То есть v26.1 живёт ровно столько, сколько v26 — отдельного срока у неё нет.
- Публикации о релизах и прямые эфиры для разработчиков тоже перешли на ритм «дважды в квартал».
Объявленные даты отключения версий
| Версия | Релиз | Плановое отключение | Что это значит для вас |
|---|---|---|---|
| v23 | 2026 | февраль 2027 | Мигрировать нужно уже сейчас — запас меньше квартала |
| v24 | 2026 | май 2027 | Планируйте переход в I квартале 2027 |
| v25 | 2026 | август 2027 | Комфортный запас, но без иллюзий |
| v26 | 14 октября 2026 | ноябрь 2027 | Текущая целевая версия для новых интеграций |
Даты — ориентир, объявленный Google, а не гарантия: исторически сансеты сдвигались, но только в сторону отсрочки и редко. Опираться на «наверняка продлят» — плохая стратегия: в день отключения запросы к снятой версии просто перестают обслуживаться, и это выглядит как внезапно опустевший отчёт, а не как понятная ошибка в интерфейсе.
Что приехало в v26 и кого это касается
v26 — не косметический релиз. Ниже то, что реально меняет схему данных и поведение интеграций.
Search Lift: новые метрики для измерения спроса
В API добавили ресурс SearchLiftKeywordBundle, сегменты segments.search_lift_keyword_bundle и segments.search_property, а также около пятнадцати новых метрик — в их числе relative_search_lift, normalized_incremental_searches и search_lift_impressions. Читать их предполагается вместе с настройкой Campaign.lift_measurement_config. Важная оговорка: сами исследования через API создавать нельзя — только читать результаты. Если вы уже считаете прирост брендового спроса от видео и Demand Gen, это как раз та механика, про которую мы писали в материале про Brand Lift и Search Lift на YouTube: теперь цифры можно забирать в своё хранилище, а не выписывать руками из интерфейса.
Performance Max для Local Services
Появилась настройка PmaxCampaignSettings.local_services_enabled. Ключевая деталь: она задаётся только при создании кампании и дальше неизменяема. Объект LocalServicesPmaxCampaignSettings требует код страны и listing_id профиля компании в Google. Сюда же — привязки лидов к кампании, тип лида «купон» и категория конверсии для сообщений. Тем, кто разбирался с переездом Local Services Ads в Google Ads, это даёт программный способ собирать такие кампании пачками — но ошибиться на этапе создания нельзя, переключить флаг потом не выйдет.
Расширенные конверсии: булево поле заменили на enum
Поля Customer.enablement_setting и Customer.effective_enablement_setting пришли на смену Customer.enhanced_conversions_for_leads_enabled. Это классический пример изменения, которое тихо ломает код: там, где раньше читался true/false, теперь приходит перечисление с несколькими состояниями, и наивный парсер либо падает, либо — хуже — молча считает значение ложным. Если вы настраивали расширенные конверсии в Google Ads и проверяете их статус программно, этот участок нужно переписать.
Переименования в модификаторах ставок для отелей
| Было (до v26) | Стало в v26 |
|---|---|
hotel_date_selection_type |
user_set_dates |
hotel_advance_booking_window |
advance_booking_window |
hotel_length_of_stay |
length_of_booking (min_days, max_days) |
hotel_check_in_day |
start_day_of_week |
hotel_check_in_date_range |
start_date_range |
Переименование поля — самый недооценённый вид поломки. Запрос не падает с понятной ошибкой «такого поля нет» только в том случае, если вы запрашиваете его явно; а вот маппинг в вашем хранилище, завязанный на имя колонки, просто перестанет находить данные и отдаст нули.
Остальное по мелочи, но с последствиями
- Политическая реклама в ЕС: поле
Campaign.contains_eu_political_advertisingстало необязательным для кампаний и групп Demand Gen с расширенным таргетингом, которые нацелены только на страны вне ЕС и не используют радиус и группы локаций. Добавлено полеrequire_eu_political_advertising_declarationуGeoTargetConstant,CampaignCriterionиAdGroupCriterion. - Shopping:
Campaign.listing_typeтеперь поддерживает торговые кампании. - Минимальный дневной бюджет:
CurrencyConstantотдаёт минимум по валюте. Порог в 5 долларов (или эквивалент) для Demand Gen действует с 1 апреля 2026 года, а попытка создать кампанию ниже порога возвращает ошибкуBUDGET_BELOW_DAILY_MINIMUMна v21 и старше.
Токены разработчика и доступ через Google Cloud
Отдельная история 2026 года — смена схемы доступа: работа с API переехала на проекты Google Cloud, и отраслевые источники расходятся в формулировках. Одни пишут, что токены разработчика в прежнем виде уже не используются с сентября, другие — что отказ от них закреплён в одной из будущих крупных версий. Практический вывод одинаковый в обоих случаях: доступ нужно оформлять через проект в Cloud Console, а не через унаследованный токен, и делать это заранее, а не в день, когда интеграция отвалится. Пошаговая часть разобрана в отдельном материале про получение доступа к Google Ads API через Cloud Console.
Там же стоит держать в голове правило из политик для разработчиков: инструмент, который только проксирует вызовы API наружу, под них не подходит. Это важно для тех, кто собирает внутренние обёртки и даёт к ним доступ подрядчикам.
Кого это касается, даже если вы не пишете код
Самое частое заблуждение: «я не разработчик, API меня не касается». На практике почти в каждом аккаунте есть хотя бы один канал, который ходит в API:
- Коннекторы для Looker Studio и другие готовые источники данных — у них своя версия API под капотом.
- Сервисы отчётности и сквозной аналитики, которые тянут расходы и конверсии.
- Интеграции с CRM для загрузки офлайн-конверсий.
- Самописные скрипты на Python или Node, которые кто-то в команде написал год назад и забыл.
- Выгрузка в BigQuery — у Data Transfer своя схема и свой цикл обновлений; про рабочую схему мы писали в статье про выгрузку Google Ads в BigQuery.
Когда версия отключается, падает не весь аккаунт, а конкретный поток данных. Выглядит это обманчиво безобидно: в дашборде за вчера пусто, кто-то решает, что «просто не докрутилось», и проблему замечают через неделю — когда уже некорректны недельные сводки и отчёты клиенту.
Карта версий: как понять, где вы сейчас
Прежде чем планировать миграцию, соберите инвентарь. На практике он занимает один лист таблицы:
| Потребитель API | Кто владелец | Текущая версия | Где зафиксирована | Дата сансета |
|---|---|---|---|---|
| Ночная выгрузка в хранилище | внутренняя аналитика | v24 | конфиг клиента в репозитории | май 2027 |
| Сервис отчётности | внешний вендор | уточнить у поддержки | на их стороне | по их ответу |
| Загрузка офлайн-конверсий из CRM | разработка CRM | v25 | библиотека в коде интеграции | август 2027 |
| Скрипт правил и алертов | медиабайер | не версионируется так же | Google Ads Scripts | — |
Последняя строка — важная оговорка. Скрипты Google Ads живут по своим правилам и не привязаны к версиям API так жёстко, поэтому часть автоматизации удобнее держать именно там. Где проходит граница между скриптом и полноценной интеграцией, мы разбирали в материале Google Ads API против скриптов.
Какие изменения ломают интеграции чаще всего
| Тип изменения | Как проявляется | Как поймать заранее |
|---|---|---|
| Поле переименовано | Колонка в отчёте пустая, ошибок нет | Сверка схемы запроса с релиз-нотами; тест на фиксированном периоде |
| Булево заменили на enum | Исключение парсера либо неверное «выключено» | Логировать сырой ответ по полю перед миграцией |
| Добавлено значение в перечисление | Падение строгого парсера на незнакомом значении | Обрабатывать неизвестные значения как «прочее», а не как ошибку |
| Поле стало обязательным | Отказ при создании сущности | Прогон операций создания в тестовом аккаунте |
| Ресурс только для чтения | Операции записи возвращают отказ | Читать раздел ограничений в релиз-нотах |
| Версия отключена | Запросы перестают обслуживаться целиком | Календарь сансетов и алерт за 60 дней |
Рабочий цикл миграции: раз в квартал, полдня
Новый ритм релизов не требует реагировать на каждый выпуск. Разумная стратегия — догонять раз в квартал, ориентируясь на крупные версии, и держать запас минимум в один квартал до сансета.
- Зафиксируйте версию в коде явно. Никаких «последняя доступная» по умолчанию: обновление должно быть вашим решением, а не побочным эффектом обновления библиотеки.
- Заведите календарные напоминания на каждую дату отключения минус 90 и минус 30 дней. Это единственное действие из списка, которое обязательно сделать сегодня.
- Поднимите тестовый аккаунт и прогоните на нём все операции записи: создание кампаний, загрузку конверсий, изменения бюджетов.
- Сверьте отчётные запросы на фиксированном окне. Берёте закрытый месяц, выполняете одни и те же GAQL-запросы на старой и новой версии и сравниваете количество строк и суммы по ключевым метрикам. Расхождение больше доли процента — повод разбираться, а не списывать на округление.
- Проверьте изменившиеся имена полей по релиз-нотам и обновите маппинг в хранилище, а не только код запроса.
- Логируйте версию в каждом запросе и заведите алерт на ошибки доступа к версии. Это превращает будущий сансет из аварии в уведомление.
- Переключайтесь не в пятницу и не в сезон пиков. Последняя неделя перед распродажами — худшее время для любых изменений в сборе данных.
Что сверять после переключения
- Количество строк по кампаниям и группам объявлений за один и тот же день.
- Суммы по расходу, кликам, показам и конверсиям за закрытую неделю.
- Поля, по которым вы джойните данные с CRM — идентификаторы кликов и кампаний.
- Поведение пустых значений: раньше поле приходило как ноль, а теперь может не приходить вовсе.
- Тайминг: не сдвинулось ли окно доступности свежих данных.
Отдельно стоит помнить, что расхождения в отчётах не всегда идут от версии API. Иногда меняется само определение метрики — и тогда «поломка» на самом деле является корректным новым значением. Мы разбирали такой случай в материале про изменение метрик Google Ads и порог вовлечения: цифры поехали, но код при этом был исправен.
Как читать релиз-ноты за десять минут
Полный список изменений крупной версии выглядит пугающе, но вам нужны ровно четыре раздела, и просматривать их можно по ключевым словам.
- Removed / Renamed. Это единственная часть, которую нужно прочитать целиком. Любое удалённое или переименованное поле — прямая работа для вас, даже если оно кажется экзотическим: достаточно, чтобы оно встречалось в одном SELECT.
- Changed type. Смена типа опаснее удаления, потому что запрос продолжает выполняться. Булево в перечисление, целое в строку, одиночное значение в список — всё это проходит мимо тестов, которые проверяют только код ответа.
- Added required. Касается только операций записи. Если вы ничего не создаёте через API, а только читаете, этот раздел можно пролистать.
- Behaviour changes. Самый коварный раздел: поля те же, но наполнение другое. Здесь живут изменения вроде нового правила атрибуции значения или другого состава сегмента.
Практический приём: держите в репозитории текстовый файл со списком всех полей, которые встречаются в ваших запросах. Перед каждым переходом прогоняйте по нему поиск из релиз-нот — это пять минут вместо вдумчивого чтения двадцати страниц. Такой список заодно показывает, насколько ваши запросы раздуты: в типичной выгрузке половина полей не используется ни в одном отчёте.
Минимальный тест, который ловит 80% проблем
Возьмите закрытый календарный месяц и выполните один и тот же запрос на текущей и целевой версии. Сравнивать нужно не визуально, а программно: количество строк, сумму расхода, сумму конверсий и количество уникальных идентификаторов кампаний. Если три метрики сошлись, а четвёртая нет — проблема локализована до одного поля за минуту. Разошлось количество строк — значит изменился состав сегментации, и это разбирается до того, как новая версия поедет в продакшен.
Если вы работаете с подрядчиком или готовым сервисом
Тогда ваша задача сводится к трём вопросам, которые стоит задать письменно:
- На какой версии Google Ads API работает интеграция сейчас?
- Какой у вас регламент перехода и за сколько дней до сансета вы обновляетесь?
- Как вы уведомляете клиентов, если данные за период пришли неполными?
Ответ «мы всегда на последней» — не лучший из возможных: автоматическое обновление на свежую версию несёт свои риски, потому что именно там появляются переименования и новые перечисления. Хороший ответ звучит как «мы держимся на N−1 и переходим за квартал до отключения».
Чек-лист на ближайший квартал
- Составить список всех потребителей API в аккаунте и MCC.
- Выяснить версию по каждому и записать дату её отключения.
- Поставить напоминания на минус 90 и минус 30 дней.
- Проверить, что доступ оформлен через проект Cloud Console.
- Прогнать отчётные запросы на v26 в тестовом аккаунте и сверить суммы.
- Обновить маппинг полей там, где они переименованы.
- Добавить в логи версию API и алерт на ошибки версии.
- Перенести рискованные переключения за пределы сезона пиков — про подготовку к ним у нас есть отдельный разбор подготовки к промо-пикам.
Где это пересекается с остальной отчётностью
Версионирование API — только один слой. Параллельно у вас живут интерфейсные отчёты, которые не зависят от версии: кастомные столбцы и редактор отчётов остаются рабочим инструментом, когда интеграция на паузе. А визуализацию в Looker Studio имеет смысл строить так, чтобы источник можно было подменить без переписывания всех графиков — на уровне промежуточной таблицы, а не прямого подключения к рекламному аккаунту.
Если инфраструктуру вы только выстраиваете и хочется не наступать на известные грабли, в гайде по Google Ads собрана практическая часть по структуре аккаунта и отчётности, а точечные вопросы по миграции удобнее закрывать на обучении Google Ads — там разбирается конкретный стек, а не абстрактная схема.
FAQ: версии Google Ads API
Что произойдёт, если я не обновлюсь до даты сансета?
Запросы к отключённой версии перестают обслуживаться. Интерфейс аккаунта при этом работает нормально — ломается только ваша интеграция: выгрузки, загрузка офлайн-конверсий, автоматические изменения.
Нужно ли переходить на каждую новую версию?
Нет. Крупных версий по-прежнему четыре в год, а минорные добавляют возможности, а не отменяют старые. Разумный режим — держаться на предыдущей крупной версии и переходить за квартал до её отключения.
Чем минорная версия отличается от крупной?
Минорная добавляет поля и ресурсы в рамках той же крупной версии и отключается вместе с ней. Отдельного срока жизни у неё нет, поэтому планировать стоит по крупным версиям.
Как узнать, какая версия используется в моём сервисе отчётности?
Спросить поддержку вендора письменно и зафиксировать ответ. В самописных решениях версия обычно задана в конфиге клиента или в имени пакета библиотеки.
Можно ли создавать исследования Search Lift через API?
Нет. В v26 добавлены ресурс и метрики для чтения результатов, но запуск самих исследований через API не предусмотрен — его делают в интерфейсе.
Почему после обновления версии цифры в отчёте разошлись?
Три типичные причины: переименованное поле, из-за которого колонка перестала заполняться; изменившееся определение метрики; разное окно доступности свежих данных. Сверка на закрытом периоде показывает, какая из трёх.
Настройку Local Services в Performance Max правда нельзя поменять потом?
По документации к v26 — да, она задаётся при создании кампании и дальше неизменяема. Поэтому такие кампании создают сразу с нужным флагом, а не «включают потом».
Что делать с токеном разработчика?
Ориентироваться на схему доступа через проект Google Cloud. Источники расходятся в том, когда именно старые токены перестают приниматься, но направление однозначное, и оформлять доступ лучше заранее.
Скрипты Google Ads тоже нужно мигрировать?
Скрипты не привязаны к версиям API тем же образом, поэтому часть простой автоматизации в них устойчивее. Но у них свои ограничения по объёмам и времени выполнения — выбирать инструмент стоит по задаче.
Как часто проверять календарь сансетов?
Достаточно раз в квартал, если у вас стоят напоминания за 90 и 30 дней до каждой даты. Дополнительно имеет смысл просматривать релиз-ноты крупных версий — там видно переименования полей.
Имеет ли смысл выгружать всё в BigQuery, чтобы не зависеть от версий?
Это снижает зависимость дашбордов от API, потому что отчёты строятся поверх вашей таблицы. Но сам канал загрузки всё равно живёт по правилам Google, поэтому версионирование никуда не девается — оно просто перемещается на один слой ниже.
Что сделать сегодня
Минимум из этой статьи — два действия. Первое: выписать все места, где ваш аккаунт отдаёт данные наружу, и узнать по каждому версию API. Второе: поставить напоминания на даты отключения v23, v24, v25 и v26. Этого достаточно, чтобы переход на новые версии Google Ads API перестал быть событием и стал рутиной: полдня работы раз в квартал против внезапно пустого отчёта в самый неподходящий момент.
Дальше по теме — свежие разборы в блоге PPC Rebels про платный трафик, в том числе соседние материалы этого выпуска: про правило названия бизнеса в объявлениях и про связку Google Ads и Shopify.