Google Ads API v22 отключён: как проверить интеграции и не потерять данные

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

Новость не означает отключение рекламных кампаний или кабинета Google Ads. Если специалист работает только в веб-интерфейсе, сам по себе sunset v22 не выключает рекламу. Риск относится к программам, которые явно отправляют запросы к адресу или сервисам версии v22: собственным скриптам вне интерфейса, CRM-коннекторам, ETL-процессам, агентским панелям и сторонним платформам.

Для бизнеса Казахстана задача практическая: определить, где используется Google Ads API, проверить версию каждого подключения, обновить клиентскую библиотеку и прогнать критические операции до переключения production. Простая замена строки v22 на v25 без проверки несовместимых изменений может привести к ошибкам в отчётах или мутациях кампаний.

Содержание

Что меняется 7 октября
Кого затрагивает отключение
Какие процессы бизнеса могут остановиться
Как найти обращения к v22
На какую версию переходить
Порядок безопасной миграции
Что проверить в отчётах
Что проверить в изменениях кампаний
Особенности для бизнеса Казахстана
Типичные ошибки
Чек-лист на сегодня

Что меняется 7 октября

Google опубликовал напоминание 2 сентября 2026 года и назвал точную дату завершения поддержки v22 — 7 октября 2026 года. Начиная с этой даты запросы к v22 перестают выполняться. Это стадия sunset, а не обычная deprecation.

В документации Google эти состояния разделены:

deprecated — версия уже не самая новая, но её конечные точки продолжают работать до даты отключения;
sunset — конечные точки версии больше недоступны, запросы к ним возвращают ошибку и требуется немедленное обновление.

Версия v22 вышла 15 октября 2025 года. Google обычно поддерживает major-версию около года и стремится оставлять доступными не более пяти major-версий. Поэтому интеграция, которая работала без изменений много месяцев, всё равно нуждается в плановом обновлении.

Нельзя считать успешный вчерашний запрос доказательством, что система продолжит работать после даты sunset. Для такого отключения нормален резкий переход: до дедлайна конечная точка отвечает, после него — нет.

Кого затрагивает отключение

Проверка нужна компаниям и специалистам, у которых есть хотя бы один программный обмен с Google Ads.

Собственные интеграции

Сюда относятся сервисы, которые получают статистику кампаний, меняют бюджеты и ставки, создают объявления, загружают аудитории или синхронизируют данные с внутренней системой.

CRM и загрузка офлайн-результатов

Если CRM передаёт в рекламный контур статусы квалифицированных лидов, сделки или выручку, нужно выяснить, какой API и версия используются. Название модуля в интерфейсе CRM не всегда показывает технический маршрут.

Агентские отчёты

Автоматические дашборды могут ежедневно запрашивать расходы, клики, конверсии и разрезы по кампаниям. После отключения устаревшей версии отчёт может показывать вчерашние данные, пустые таблицы или ошибку обновления.

Системы управления ставками и бюджетами

Такие платформы не только читают данные, но и отправляют изменения. Ошибка здесь опаснее: реклама может продолжить работать со старыми настройками, пока команда ошибочно считает, что лимиты или правила уже применены.

Сторонние SaaS-платформы

Ответственность за обновление лежит на поставщике, но бизнесу нужно получить подтверждение. Фраза «интеграция поддерживается» недостаточна — важно уточнить, не используется ли v22 в конкретном подключении и завершена ли миграция.

Обычная работа в веб-интерфейсе Google Ads не требует от рекламодателя выбирать API-версию. Также нельзя автоматически относить к риску каждый Google Ads Script: сначала нужно определить фактическую архитектуру и наличие внешних вызовов к Google Ads API.

Какие процессы бизнеса могут остановиться

Отключение API не обязательно останавливает показ рекламы. Чаще ломается окружающая инфраструктура, и поэтому проблема может оставаться незаметной.

Возможные последствия:

дашборд перестал обновлять расход;
ежедневный отчёт приходит с нулевыми значениями;
автоматизация не приостановила кампанию при достижении лимита;
CRM не получила свежие идентификаторы или статистику;
собственный сервис не создал новую кампанию;
обновление бюджета завершилось ошибкой;
выгрузка поисковых запросов или ресурсов перестала работать;
аудитории не синхронизировались;
пакетная задача выполнилась частично;
система повторяет запросы и накапливает очередь ошибок.

Наиболее опасен «тихий» отказ. Например, сервис пишет данные в кэш и продолжает показывать старые цифры без явного предупреждения. Поэтому после миграции нужно проверять не только HTTP или gRPC-ответ, но и свежесть данных, количество строк и время последнего успешного обновления.

Как найти обращения к v22

Google рекомендует открыть Google Cloud Console, перейти в APIs & Services, выбрать Google Ads API и посмотреть вкладку Metrics. В таблице методов отображается версия в полном имени вызова, например:

google.ads.googleads.v22.services.GoogleAdsService.Mutate

Проверка через Cloud Console полезна тем, что показывает фактические вызовы проекта, а не только заявленную конфигурацию. Выберите период, который охватывает ежедневные, еженедельные и месячные задачи.

Дополнительно выполните инвентаризацию кода и инфраструктуры:

Найдите строки v22 в репозиториях.
Проверьте версии официальных клиентских библиотек.
Просмотрите Docker-образы и lock-файлы зависимостей.
Проверьте переменные окружения и конфигурацию endpoint.
Найдите Cloud Functions, cron-задачи и серверные обработчики.
Просмотрите логи API gateway и фоновых очередей.
Составьте список внешних подрядчиков и SaaS-коннекторов.
Зафиксируйте владельца каждого подключения.

Поиск только в основном приложении недостаточен. Устаревшая версия может остаться в редко запускаемом месячном отчёте, архивном сервисе или отдельной функции загрузки конверсий.

На какую версию переходить

На дату проверки Google документирует v23, v24 и v25 как доступные major-версии; последняя опубликованная minor-версия — v25.2 от 23 сентября 2026 года. Документация рекомендует переходить на самую новую версию, которую команда может безопасно внедрить.

Необязательно обновляться последовательно через каждую промежуточную версию. Google прямо указывает, что можно перейти, например, с версии N сразу на N+2. Но нужно прочитать все upgrade guides между исходной и целевой версиями, потому что major-релизы могут содержать несовместимые изменения.

При выборе учитывайте:

срок оставшейся поддержки;
совместимость клиентской библиотеки;
используемые сервисы и поля;
готовность тестовой среды;
наличие внутренних обёрток;
требования стороннего продукта;
время на контроль после релиза.

Для v25 Google приводит минимальные версии официальных библиотек: Java 44.0.0, .NET 26.1.0, PHP 33.6.0, Python 31.2.0, Ruby 43.0.0 и Perl 33.0.0. Для minor-релизов нужно дополнительно открыть changelog конкретной библиотеки.

Не следует автоматически ждать v26, ожидаемую в октябре 2026 года, если production уже использует отключённую v22. Сначала восстановите работу на поддерживаемой версии и только затем планируйте следующий цикл обновления.

Порядок безопасной миграции

1. Зафиксируйте текущее поведение

Сохраните примеры запросов и ответов v22 по ключевым процессам. Запишите число полученных строк, итоговые суммы и идентификаторы ресурсов. Это станет контрольной точкой.

2. Обновите клиентскую библиотеку

Используйте официальную библиотеку, совместимую с выбранной версией API. Не обновляйте dependency вслепую во всём проекте: сначала прочитайте changelog и проверьте требования среды выполнения.

3. Изучите upgrade guides

Major-версии могут менять поля, enum, доступные сервисы и поведение запросов. Составьте перечень изменений, которые затрагивают именно ваш код.

4. Переведите тестовую среду

Сначала обновите sandbox-процесс или тестовый рекламный аккаунт. Для операций изменения используйте validate-only там, где это поддерживается, либо тестовый customer без реального бюджета.

5. Сравните чтение данных

Одни и те же GAQL-запросы должны давать сопоставимую структуру и смысл. Разница из-за задержек допустима, но исчезновение поля или сегмента требует объяснения.

6. Проверьте мутации

Создание, обновление и удаление ресурсов проверяются отдельно. Успешный запрос статистики не доказывает, что сервис изменения бюджета или кампании совместим.

7. Настройте наблюдаемость

Добавьте алерт на ошибки API, нулевой объём данных, старый timestamp и рост очереди повторов. Логируйте request ID и версию без записи токенов или пользовательских данных.

8. Выполните контролируемый production-релиз

Переведите небольшую долю задач на новую версию, сравните результаты, затем переключите остальные. Для критических мутаций используйте ограниченное окно и ответственного специалиста.

9. Удалите fallback на v22

После подтверждённой миграции отключите автоматический откат на устаревшую конечную точку. Такой fallback уже не восстанавливает работу, а только создаёт дополнительные ошибки.

Что проверить в отчётах

После перехода откройте не только логи, но и итоговые бизнес-отчёты.

Сверьте:

дату и время последнего обновления;
валюту аккаунта;
часовой пояс;
расход;
показы и клики;
конверсии и ценность;
количество кампаний;
разбивку по дням;
разрезы по устройствам и сетям;
корректность пагинации;
отсутствие дублированных строк;
обработку удалённых или приостановленных ресурсов.

Для аккаунтов Казахстана особенно внимательно проверьте тенге и часовой пояс рекламного аккаунта. Миграция API не меняет их сама по себе, но ошибка в преобразовании времени или денежных micros может исказить отчёт.

Если данные поступают в Looker Studio, Power BI или собственный кабинет через промежуточное хранилище, отметка «обновлено» на визуализации может относиться к кэшу. Сверьте первичный лог коннектора и максимальную дату в таблице.

Что проверить в изменениях кампаний

Операции записи требуют более строгого контроля.

Перед production:

Проверьте customer ID и manager account.
Убедитесь, что OAuth-пользователь имеет нужные права.
Выполните запрос без реального изменения, если доступен режим проверки.
Ограничьте число операций в первом batch.
Зафиксируйте resource names до и после.
Проверьте partial failure.
Не повторяйте весь пакет без идемпотентности.
Сверьте бюджет в micros и валюту.
Проверьте, что статус кампании не изменился случайно.
Убедитесь, что отрицательные критерии и география сохранились.
Выполните ручную проверку результата в интерфейсе Google Ads.
Добавьте возможность остановить автоматизацию без остановки самих кампаний.

Особое внимание нужно уделить повторам. Если клиент получил timeout после отправки запроса, это не всегда означает, что операция не была применена. Повтор без проверки может создать дублирующий ресурс или дважды изменить значение.

Особенности для бизнеса Казахстана

Сам sunset v22 является глобальным и не зависит от страны рекламодателя. Локальная специфика появляется в данных и бизнес-процессах.

Русский и казахский языки

После миграции проверьте, что отчёты, названия кампаний и текстовые ресурсы сохраняются в UTF-8 без искажений. Особенно это важно для казахских букв и автоматической генерации CSV.

Тенге

Стоимость и бюджет в API передаются в micros. Внутренняя система должна корректно преобразовывать значение и не применять чужой валютный курс к аккаунту в KZT.

Города и география

При автоматическом создании или обновлении кампаний сверяйте geo target constants, а не только человекочитаемые названия. Алматы, Астана, Шымкент и области должны соответствовать утверждённому плану, а не результату неточного текстового поиска.

Звонки и CRM

Для локальных услуг ключевым результатом часто является звонок или заявка в мессенджер. После обновления интеграции нужно провести тестовый лид и убедиться, что источник, gclid, кампания и статус сделки проходят весь путь.

Работа агентства

Если агентство использует общую платформу для нескольких клиентов, ошибка одной интеграции не должна блокировать все аккаунты. Разделяйте очереди, логируйте customer ID и повторяйте только упавшие операции.

Типичные ошибки

Решили, что реклама отключится. Sunset касается API v22, а не самого кабинета и не всех кампаний.

Проверили только интерфейс. Кампания показывает объявления, но отчёты и автоматические правила уже могут не обновляться.

Просто заменили номер версии. В major-релизах возможны несовместимые изменения; нужен аудит полей, enum и методов.

Обновили библиотеку без фиксации зависимостей. Вместе с API-клиентом могут измениться другие пакеты и среда выполнения.

Не проверили редкие задачи. Месячная выгрузка или архивная функция проявит ошибку позже.

Не сравнили бизнес-итоги. HTTP 200 не доказывает, что расход, конверсии и валюты интерпретируются правильно.

Не спросили поставщика SaaS. Название интеграции не сообщает версию, поэтому требуется подтверждение и дата обновления.

Оставили silent failure. Сервис продолжает показывать кэш, а команда считает данные актуальными.

Ждут v26 при уже сломанной v22. Ожидание будущего релиза не восстанавливает текущую интеграцию.

Чек-лист на сегодня

Составлен список всех систем, связанных с Google Ads.
В Google Cloud Console проверены фактические методы v22.
Репозитории и конфигурации проверены по строке v22.
У поставщиков CRM и коннекторов запрошена версия API.
Выбрана поддерживаемая целевая версия.
Прочитаны все промежуточные upgrade guides.
Клиентская библиотека совместима с целевой версией.
Подготовлена тестовая среда.
Проверены GAQL-запросы и пагинация.
Сверены расход, клики, конверсии и ценность.
Проверены customer ID, валюта и часовой пояс.
Проверены мутации бюджетов, статусов и ресурсов.
Проведена тестовая заявка из рекламы до CRM.
Настроены алерты на ошибки и устаревшие данные.
Production переключён поэтапно.
Fallback на v22 удалён.
Результат вручную сверен в Google Ads.
Ответственный подтвердил стабильность фоновых задач.

Google Ads API v22 завершил жизненный цикл 7 октября 2026 года. Для рекламодателя без прямой интеграции это не повод останавливать кампании. Для разработчика, агентства или бизнеса с CRM и автоматическими отчётами — это обязательная техническая проверка.

Правильная миграция состоит не только в обновлении номера версии. Нужно найти все фактические вызовы, выбрать поддерживаемый релиз, проверить чтение и запись данных, провести тестовый лид и настроить контроль свежести отчётов.

PIUN Marketing настраивает Google Рекламу в Казахстане с проверкой аналитики, CRM, конверсий, рекламной структуры и качества обращений.