Google Ads API v26: что проверить при миграции и новом ритме релизов

Google выпустил Google Ads API v26 — крупное обновление интерфейса, через который рекламные платформы, отчётные системы и собственные инструменты управляют Google Ads. Версия затрагивает Performance Max, туристические кампании, Shopping, Demand Gen, измерение эффективности и отслеживание конверсий.

Для команд главный вывод практический: v26 стоит рассматривать как задачу по поддержке интеграции с понятным списком проверок. Google также меняет ритм релизов и планирует выпускать обновления API дважды в месяц. Такой график сокращает путь новых функций до продукта и повышает требования к процессу разработки.

Performance Max и Local Services Ads

В v26 появилась возможность создавать кампании Performance Max для Local Services Ads через API. Local Services Ads — формат для локальных услуг, где рекламодатель получает обращения пользователей, ищущих исполнителя в своём регионе.

Изменение полезно платформам и агентствам, которые создают кампании массово или собирают процесс запуска в собственном интерфейсе. Команда получает больше контроля над сценарием: от формирования кампании до передачи обязательных параметров в Google Ads.

При создании Local Services Performance Max теперь нужны страна и идентификатор объявления. Эти поля стоит включить в модель данных, форму настройки и автоматические проверки до отправки запроса. Иначе сценарий создания кампании остановится на этапе валидации.

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

Измерение: Search Lift и расширенные конверсии

Google добавил измерение Search Lift. Этот инструмент оценивает влияние рекламы на поисковое поведение аудитории и помогает увидеть изменения, которые стандартная атрибуция может показывать не полностью.

Для performance-команд это ещё один сигнал при оценке медийных и охватных активностей. Конверсия в отчёте фиксирует целевое действие, а Search Lift дополняет картину данными о том, как реклама связана с последующим интересом к поиску.

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

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

Shopping, Demand Gen и политическая реклама в ЕС

Обновление добавляет возможности для Shopping и Demand Gen. Эти изменения важны для продуктов, которые управляют товарными кампаниями, генерируют отчёты или предлагают автоматизацию работы с форматами Google Ads.

В таких системах API редко существует отдельно от интерфейса и аналитики. Новое поле или новый метод затрагивает цепочку целиком: схему данных, серверную логику, экран настройки, тесты и документацию для клиента. Поэтому полезно разбирать релиз по пользовательским сценариям, а не по списку методов в отрыве от продукта.

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

Как организовать миграцию на v26

Обновление клиентских библиотек и кода открывает доступ к возможностям v26. Я бы не сводил эту работу к плановой технической задаче: API связывает рекламные операции, данные и пользовательские действия в платформе. Ошибка в миграции способна затронуть создание кампаний, сбор статистики или передачу конверсий.

Рабочий план может выглядеть так:

• составить список интеграций, библиотек и сценариев, которые используют Google Ads API;
• выделить функции v26, нужные продукту сейчас: Local Services Performance Max, измерение, конверсии, Shopping или Demand Gen;
• добавить обязательные параметры страны и идентификатора объявления в сценарии Local Services Performance Max;
• обновить клиентские библиотеки и адаптировать код под изменения версии;
• прогнать тесты на создании кампаний, получении отчётов и передаче данных о конверсиях;
• назначить владельца мониторинга релизов и вести короткий журнал изменений для команды.

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

Что это меняет для маркетолога и продукта

Маркетологу не обязательно погружаться в структуру каждого API-запроса. Его зона ответственности — сформулировать, какие кампании, сигналы измерения и отчёты действительно нужны бизнесу. Тогда разработчик сможет оценить обновление через конкретные сценарии, а не через абстрактное требование «поддержать новую версию».

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

Моя позиция: частые релизы полезны тем командам, которые умеют работать с изменениями малыми итерациями. Достаточно выделить ответственного, вести реестр интеграций и иметь набор проверок для критичных операций. Тогда обновления Google Ads API становятся управляемой частью развития рекламного продукта, а не срочной задачей в день, когда перестал работать привычный сценарий.

Практический вывод: запланируйте аудит текущей интеграции с Google Ads API, обновите библиотеки до v26 и отдельно проверьте сценарии Performance Max, конверсий и отчётности. После этого закрепите регулярный обзор релизов в рабочем календаре команды.