Google Ads API v25: что изменилось для рекламы интернет-магазинов

22 июля 2026 года Google выпустил Google Ads API v25 — новую крупную версию программного интерфейса для управления рекламой. Релиз добавляет новые цели для привлечения и удержания клиентов, метрики взаимодействия с рекламой в YouTube Shorts, декларации синтетического и созданного с помощью AI контента, а также автоматическое создание анимированных материалов для Demand Gen. Одновременно v25 содержит несовместимые изменения, из-за которых существующие интеграции могут перестать работать после обычного обновления клиентской библиотеки.

Главное за одну минуту

• Google Ads API v25 нужен не каждому интернет-магазину. В первую очередь обновление касается бизнеса с собственной автоматизацией рекламы, CRM-интеграциями, передачей офлайн-конверсий или собственными аналитическими панелями.

• Google удалил старые ресурсы для целей жизненного цикла клиентов и перевел интеграции на новую объединенную структуру.

• Появилась отдельная Loyalty Retention Goal для работы с участниками программ лояльности.

• В отчетах по рекламе в YouTube Shorts теперь можно получать комментарии, отметки «Нравится» и репосты.

• Новые Demand Gen multi-asset объявления, созданные через v25, могут по умолчанию использовать автоматическую генерацию анимированных изображений.

• Поля деклараций синтетического и AI-контента стали доступными для записи в v25, v24 и v23.

• Официальная PHP-библиотека для v25 требует актуальной версии пакета и PHP 8.1 или новее.

• Старые магазины OpenCart на PHP 5.6 или 7.4 лучше подключать к Google Ads через отдельный интеграционный сервис.

Что выпустил Google

Google Ads API — это программный интерфейс для систем, которые управляют рекламными аккаунтами непосредственно через код. С его помощью можно создавать кампании, изменять бюджеты, загружать аудитории, передавать конверсии, получать отчеты и управлять несколькими рекламными аккаунтами из единой панели.

Версия v25 является крупным релизом. Это означает, что она содержит не только дополнительные поля и новые функции, но и несовместимые изменения: удаленные ресурсы, новые структуры данных, измененные типы полей и дополнительные требования к валидации.

Важное уточнение

Выход v25 не означает, что каждому владельцу интернет-магазина нужно срочно обновлять сайт. Сначала необходимо определить, использует ли сайт или связанная с ним система Google Ads API вообще.

Кого касается Google Ads API v25

Обновление касается интернет-магазина, если его модуль, CRM, серверный скрипт или собственная административная панель отправляет программные запросы в Google Ads.

Типичные сценарии использования API:

• автоматическое создание рекламных кампаний для новых товаров и категорий;

• остановка рекламы товаров, которых нет в наличии;

• изменение бюджетов в зависимости от выручки, маржи, ROAS или складских остатков;

• передача заказов из CRM как офлайн-конверсий;

• корректировка ценности конверсии после возврата или отмены заказа;

• загрузка аудиторий Customer Match;

• разделение новых, постоянных, B2B- и розничных клиентов;

• создание собственной аналитической панели по рекламе;

• управление несколькими рекламными аккаунтами из одной административной панели;

• автоматическое обнаружение кампаний с перерасходом бюджета или ухудшением показателей.

Что не является Google Ads API

Обновление API не следует путать с другими продуктами и интеграциями Google.

Если магазин использует только интерфейс Google Ads, GA4, Merchant Center и стандартный тег покупки, срочная миграция из-за выхода v25 не требуется.

Новые и постоянные клиенты переходят на новую структуру целей

Одно из самых значительных изменений v25 связано с жизненным циклом клиента. Google удалил устаревшие ресурсы CustomerLifecycleGoal и CampaignLifecycleGoal и предложил новую объединенную структуру на основе ресурсов Goal и CampaignGoalConfig.

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

New Customer Acquisition Goal

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

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

Однако функция будет работать правильно только тогда, когда магазин умеет точно определять нового клиента. Типичные проблемы:

• один и тот же покупатель оформляет заказы с разными email-адресами;

• гостевые заказы не связываются с зарегистрированной учетной записью;

• телефонные номера сохраняются в разных форматах;

• возвращенные или тестовые заказы считаются успешными покупками;

• B2B-клиенты смешиваются с розничными покупателями;

• CRM и интернет-магазин используют разные идентификаторы клиента.

Loyalty Retention Goal

В версии v25 появилась отдельная Loyalty Retention Goal. Она предназначена для кампаний, ориентированных на участников программ лояльности и постоянных покупателей.

Новые настройки можно использовать для того, чтобы:

• применять корректировки ставок для участников программы лояльности;

• рассматривать удержание клиентов как отдельную цель кампании;

• показывать преимущества программы лояльности в товарных объявлениях;

• разделять привлечение новых клиентов и повторные продажи;

• строить отчетность по типам покупателей.

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

YouTube Shorts получил отдельные метрики взаимодействия

Google Ads API v25 добавляет три специализированных показателя для рекламы в YouTube Shorts:

• Metrics.youtube_comments — комментарии;

• Metrics.youtube_likes — отметки «Нравится»;

• Metrics.youtube_shares — репосты.

Метрики доступны на уровне кампании, группы объявлений, объявления, рекламного ресурса, клиента и видео. Благодаря этому можно создавать отчеты, которые показывают не только показы и клики, но и непосредственную реакцию аудитории на конкретный ролик.

Как правильно оценивать эффективность Shorts

Комментарий или отметка «Нравится» не равны покупке. Для корректной аналитики показатели нужно разделить на три уровня:

1. Внимание: показы, просмотры, частота и время просмотра.

2. Взаимодействие: отметки «Нравится», комментарии и репосты.

3. Бизнес-результаты: переходы на сайт, добавления в корзину, покупки, выручка и маржа.

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

Декларации AI-контента и автоматическая анимация

Информацию о синтетическом контенте можно передавать программно

Поля Asset.synthetic_content_info и Ad.synthetic_content_info содержат информацию о синтетическом или созданном с помощью AI контенте.

В примечаниях к выпуску v25 Google уточнил, что эти поля стали полностью доступными для записи в версиях v25, v24 и v23. Это важное уточнение: обновление логики деклараций синтетического контента не обязательно требует полной миграции на v25, если интеграция уже использует поддерживаемую версию v23 или v24.

Собственная рекламная система должна сохранять информацию о происхождении креатива еще до его загрузки в Google Ads.

Рекомендуемые поля в базе данных:

• тип происхождения: фотография, графический дизайн, AI-генерация или смешанный контент;

• сервис или модель, использованная для генерации;

• дата создания;

• автор или ответственный менеджер;

• статус ручного согласования;

• версия исходного файла;

• статус декларации, переданной рекламной платформе.

Не следует определять AI-контент только по названию файла, например generated-banner-final-2.jpg. Файл можно переименовать, и информация о его происхождении будет потеряна.

Demand Gen может создавать анимированные изображения

В версии v25 появился новый тип автоматизации GENERATE_ANIMATED_IMAGES_FROM_OTHER_ASSETS. Он позволяет Google создавать анимированные материалы из обычных статических изображений для Demand Gen multi-asset ads.

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

Это может ускорить производство рекламных материалов, но одновременно создает несколько рисков:

• логотип может двигаться или масштабироваться неестественно;

• часть товара может быть обрезана;

• мелкий текст может стать нечитаемым;

• композиция может не соответствовать брендбуку;

• анимация может выглядеть менее профессионально, чем исходный статический дизайн;

• система может создавать варианты, которые никто не согласовывал вручную.

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

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

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

Худшая возможная стратегия — заменить v24 на v25 в конфигурации и сразу развернуть изменения на production.

Отдельная проблема: официальная библиотека требует PHP 8.1+

Согласно официальной таблице совместимости Google, для Google Ads API v25 требуется PHP client library версии 34.0.0 или новее. Актуальная библиотека требует PHP 8.1 или более новой версии.

Это создает проблему для старых интернет-магазинов, включая OpenCart 2.3, которые продолжают работать на PHP 5.6 или 7.4.

Установка актуальной клиентской библиотеки непосредственно в такой магазин может привести к следующим проблемам:

• ошибкам Composer из-за неподдерживаемой версии PHP;

• конфликтам версий google/protobuf, grpc или google/auth;

• значительному увеличению размера каталога vendor;

• конфликтам с другими устаревшими пакетами;

• фатальным ошибкам во время загрузки классов;

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

Рекомендуемая архитектура

OpenCart / PrestaShop │ │ заказы, товары, статусы, маржа ▼ Integration Gateway на PHP 8.2+ │ ├── очередь операций ├── журнал запросов ├── механизм повторных попыток ├── защита от дублирования └── OAuth2 и Google Ads client library │ ▼ Google Ads API

Интернет-магазин не должен разбираться во внутренней структуре актуальной версии Google Ads API. Он должен передавать стабильный набор бизнес-данных отдельному сервису, а сервис будет преобразовывать эти данные в запросы для нужной версии API.

Такая архитектура позволяет:

• не обновлять ядро старого магазина ради одной интеграции;

• использовать современную версию PHP, Composer и поддерживаемые библиотеки;

• обновлять Google Ads API независимо от OpenCart;

• повторять неудачные запросы без влияния на покупателя;

• не замедлять оформление заказа;

• обслуживать несколько интернет-магазинов через один интеграционный сервис;

• вести подробный журнал передачи конверсий.

Когда старые версии перестанут работать

Выход v25 не отключает предыдущие версии в тот же день. Google публикует отдельный график sunset, который определяет, когда запросы к конкретной версии API перестанут работать.

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

Как определить текущую версию

Версия API может отсутствовать в настройках модуля. Она также может быть указана:

• в зависимостях Composer;

• в названии namespace;

• в REST endpoint;

• в конфигурационном файле;

• в Docker-образе интеграционного сервиса;

• в старом cron-скрипте;

• во внешней CRM или агентской платформе.

Google также позволяет просматривать недавние API-запросы в Google Cloud Console. Название метода содержит версию, сервис и операцию, например google.ads.googleads.v25.services.GoogleAdsService.Mutate.

Подробный план безопасного обновления до v25

Этап 1. Инвентаризация

1. Найти все модули, CRM-системы, cron-скрипты и сервисы, взаимодействующие с Google Ads.

2. Определить версию API для каждого компонента.

3. Зафиксировать текущую версию клиентской библиотеки.

4. Проверить версии PHP, Composer, gRPC и Protobuf.

5. Составить список аккаунтов и кампаний, которыми управляет интеграция.

Этап 2. Карта функциональности

Для каждого API-запроса нужно зафиксировать его назначение:

• получение статистики;

• создание или редактирование кампаний;

• изменение бюджетов;

• загрузка конверсий;

• корректировка конверсий;

• операции Customer Match;

• управление рекламными материалами;

• получение рекомендаций;

• управление целями жизненного цикла клиентов;

• формирование прогнозов.

Этап 3. Контрольные данные

До обновления следует сохранить контрольный набор результатов:

• расходы на рекламу за последние 7 и 30 дней;

• количество кликов и показов;

• конверсии и их ценность;

• количество активных кампаний;

• количество загруженных аудиторий;

• последние успешные и неудачные API-операции;

• примеры ответов для критически важных GAQL-запросов.

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

Этап 4. Обновление кода

1. Обновить клиентскую библиотеку в отдельной ветке или контейнере.

2. Заменить удаленные ресурсы жизненного цикла клиентов.

3. Проверить все GAQL-запросы.

4. Обновить DTO, типы данных и сериализацию.

5. Проверить новые обязательные поля.

6. Обновить обработку новых кодов ошибок.

7. Проверить настройки AI-контента и автоматизации Demand Gen.

Этап 5. Тестирование

Отдельно необходимо проверить:

• авторизацию OAuth2;

• обновление access token;

• получение отчетов;

• создание и редактирование кампаний;

• передачу тестовой конверсии;

• повторную отправку одной и той же операции;

• частичные ошибки в пакетных запросах;

• ограничения частоты запросов и повторные попытки;

• временную недоступность Google API;

• ошибочный customer ID;

• недостаточные права пользователя;

• восстановление очереди после перезапуска сервиса.

Этап 6. Постепенный запуск

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

Для критически важных отчетов полезно временно запускать старые и новые запросы параллельно и сравнивать:

• количество возвращенных строк;

• расходы на рекламу;

• конверсии;

• выручку;

• сегментацию;

• типы значений;

• время выполнения запросов.

Что следует добавить в интеграцию во время миграции

Обновление API — хороший момент не только переписать устаревшие классы, но и устранить архитектурные проблемы.

Очередь операций

Конверсия не должна передаваться непосредственно во время оформления заказа. Магазин должен добавить задачу в очередь и сразу завершить checkout. Отдельный worker затем передаст данные в Google.

Защита от дублирования

У каждой операции должен быть стабильный внешний идентификатор. Повторный запуск cron или worker не должен создавать дополнительную конверсию для того же заказа.

Журнал запросов и изменений

Для каждой передачи рекомендуется сохранять:

• номер заказа;

• тип события;

• дату и время;

• сумму и валюту;

• версию API;

• customer ID;

• статус операции;

• код ошибки;

• количество повторных попыток;

• идентификатор ответа Google.

Корректировки после возвратов

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

Маржа вместо одной только выручки

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

• закупочную стоимость;

• размер скидки;

• расходы на доставку;

• комиссию платежной системы;

• комиссию маркетплейса;

• валовую прибыль;

• фактическую маржу после возвратов.

Тогда рекламная панель сможет показывать не только ROAS, но и реальную прибыль, полученную от кампании.

Что владельцу интернет-магазина следует сделать сейчас

Сценарий 1. Вы используете только интерфейс Google Ads

Срочные действия не требуются. Выход v25 не требует изменений на сайте, в Google Analytics или в стандартном Google tag.

Сценарий 2. У вас установлен модуль отслеживания конверсий

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

Сценарий 3. CRM передает офлайн-конверсии

Определите текущую версию API, ее дату sunset и клиентскую библиотеку, используемую CRM. Особого внимания требуют интеграции на v21 и v22.

Сценарий 4. Магазин работает на PHP 5.6 или 7.4

Не устанавливайте актуальную PHP-библиотеку непосредственно в старый проект. Перенесите интеграцию Google Ads в небольшой отдельный сервис на PHP 8.2 или другой поддерживаемой версии.

Сценарий 5. Вы оптимизируете ставки для новых и постоянных клиентов

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

Сценарий 6. Вы используете кампании Demand Gen

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

Пятиминутная проверка

1. Найдите в коде GoogleAdsClient, google.ads.googleads и googleads/google-ads-php.

2. Проверьте composer.json и composer.lock.

3. Найдите номер версии API: v21, v22, v23, v24 или v25.

4. Просмотрите последние запросы в Google Cloud Console.

5. Проверьте ошибки передачи конверсий и выполнения cron.

6. Сравните текущую версию с графиком sunset.

7. Не обновляйте production без контрольного отчета и резервной копии.

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

Нужно ли обновлять стандартный модуль Google Analytics?

Не обязательно. Google Analytics, Google tag и Google Ads API выполняют разные функции. Сначала необходимо проверить, отправляет ли модуль серверные запросы в Google Ads API.

Перестали ли v23 и v24 работать после выхода v25?

Нет. Они остаются доступными до соответствующих дат sunset. По текущему графику v23 должна работать до февраля 2027 года, а v24 — до мая 2027 года.

Кому необходимо обновляться срочно?

Наиболее срочного внимания требуют интеграции, использующие v21, поскольку ее sunset запланирован на август 2026 года. Пользователям v22 также следует начинать миграцию, поскольку отключение этой версии предварительно ожидается в октябре 2026 года.

Можно ли установить новую PHP-библиотеку в OpenCart 2.3?

Только если серверное окружение и все зависимости соответствуют требованиям библиотеки. Магазин на PHP 5.6 или 7.4 не сможет штатно использовать актуальную библиотеку, поскольку она требует PHP 8.1 или новее. Более безопасное решение — отдельный интеграционный сервис.

Можно ли использовать API без официальной PHP-библиотеки?

Технически можно разработать собственный REST-клиент. Однако в таком случае разработчик самостоятельно отвечает за OAuth2, структуру запросов, типы данных, повторные попытки, обработку ошибок и обновление версий API. Для большинства проектов отдельный сервис с официальной библиотекой будет надежнее.

Будет ли Google создавать анимацию для всех объявлений?

Нет. Описанное изменение касается новых Demand Gen multi-asset ads, созданных через v25, для которых соответствующий тип автоматизации включен по умолчанию.

Нужно ли немедленно переходить с v24 на v25?

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

Улучшит ли Loyalty Retention Goal повторные продажи автоматически?

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

Нужно ли хранить информацию об AI-креативах в собственной базе?

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

Как убедиться, что миграция прошла успешно?

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

Технический аудит

Не знаете, какую версию Google Ads API использует ваш интернет-магазин?

SiteZilla может провести аудит модулей, CRM, cron-скриптов и внешних сервисов, найти устаревшие API-запросы, оценить риски sunset и подготовить план миграции.

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

Заказать аудит рекламной интеграции

Официальные источники

• Google Ads Developer Blog — Announcing v25 of the Google Ads API

• Google Ads API — Release notes

• Google Ads API — Upgrade your API version

• Google Ads API — Deprecation and sunset

• Google Ads API — Client libraries and supported versions

• Google Ads PHP Client — composer.json