✓ 22 октября 2026 года Google открыл публичную beta Display & Video 360 API v5. Релиз меняет не интерфейс рекламного кабинета для всех пользователей, а возможности и контракты интеграций, которые управляют программатик-кампаниями, YouTube-размещениями, аудиториями и инвентарём через API.
Главные изменения для рекламных команд — полноценное управление исключениями YouTube-каналов и видео на уровне рекламодателя, поддержка создания Digital Out of Home insertion orders, обновлённая работа с источниками инвентаря и перестройка audience targeting для Demand Gen и YouTube ad groups. Одновременно Google убирает из DV360 API управление Customer Match и направляет такие процессы в Data Manager API.
Версия пока находится в beta. Google предупреждает, что до стабильного релиза возможны breaking changes. Поэтому v5 стоит рассматривать не как сигнал немедленно переключить production, а как начало управляемой миграции: инвентаризация вызовов, отдельный тестовый контур, сравнение результатов и подготовка плана отката.
Что запустил Google
DV360 API v5 доступна в публичной beta с 22 октября. Чтобы использовать новые возможности, Google рекомендует обновить клиентскую библиотеку и проверить официальный migration guide.
В релиз вошли пять групп изменений:
- управление advertiser-level исключениями YouTube-видео и каналов;
- создание Digital Out of Home `InsertionOrder`;
- обновлённое получение и таргетинг inventory sources;
- переработанные audience-настройки для Demand Gen и YouTube `AdGroup`;
- удаление управления Customer Match из DV360 API в пользу Data Manager API.
Это важно разделять. Первая часть расширяет возможности автоматизации, а последняя требует переноса существующего процесса в другой API. Если интеграция только читает отчёты и не управляет аудиториями или таргетингом, объём изменений может быть небольшим. Если система создаёт кампании, синхронизирует исключения и обновляет Customer Match, понадобится полноценный migration project.
Публичная beta означает доступность для разработки, но не гарантирует неизменность схем. Google прямо оставляет возможность внести breaking changes и обещает фиксировать их в release notes. Значит, version pinning и регулярная проверка документации становятся частью эксплуатации.
Что меняется в YouTube-исключениях
В v4 исключения конкретных YouTube-каналов и видео на уровне рекламодателя были доступны только для чтения. V5 позволяет управлять ими через API с типами таргетинга `TARGETING_TYPE_YOUTUBE_CHANNEL` и `TARGETING_TYPE_YOUTUBE_VIDEO`.
Для агентства это убирает ручной разрыв между политикой brand safety и фактической настройкой аккаунтов. Централизованный список можно синхронизировать с несколькими рекламодателями, проверять расхождения и фиксировать историю изменений.
Но автоматизация исключений требует ограничителей. Ошибка в идентификаторе, слишком широкий список или некорректная операция удаления способны резко сократить доступный инвентарь. Поэтому процесс должен включать:
- источник истины для утверждённых исключений;
- разделение глобальных и клиентских списков;
- предварительный diff до записи;
- лимит на число изменений за один запуск;
- журнал автора, времени и причины обновления;
- сигнал тревоги при неожиданном падении доступного охвата.
Сам факт появления write-доступа не означает, что все существующие исключения нужно унифицировать. У брендов отличаются категории риска, рынки, договорные требования и допустимые площадки. API помогает исполнять политику, но не определяет её.
Почему нужно проверить audience targeting
Google отдельно указывает на рефакторинг audience targeting для Demand Gen и YouTube ad groups. Это зона повышенного риска для интеграций, которые создают или обновляют группы объявлений автоматически.
Нельзя ограничиться проверкой того, что запрос вернул HTTP 200. После миграции нужно сравнить смысл итоговой настройки:
- какие аудитории включены;
- какие исключены;
- на каком уровне находится таргетинг;
- сохранились ли логические отношения между наборами;
- не изменилась ли доступность отдельных полей;
- совпадает ли результат чтения после записи с ожидаемой конфигурацией.
Полезный тест — взять небольшой набор реальных конфигураций v4, описать ожидаемый результат в независимом формате и воспроизвести их через v5 в тестовом рекламодателе. Затем нужно прочитать созданные сущности обратно и сравнить не только ID, но и бизнес-смысл таргетинга.
Для Demand Gen особенно важно не переносить предположения из обычного Google Ads API в DV360. Названия форматов могут быть похожими, но модель ресурсов, уровни настроек и доступные операции отличаются.
Куда переносится Customer Match
В v5 Google удаляет функции управления Customer Match из Display & Video 360 API и рекомендует переходить на Data Manager API. Это не просто замена URL одного метода другим.
Data Manager API использует собственную модель аудиторий, назначения данных и ingestion-запросы. Для DV360 рабочий процесс выглядит так:
- создать аудиторию или получить ID существующей;
- передать ID как `productDestinationId`;
- отправить участников через `audienceMembers.ingest`;
- отдельно обрабатывать удаление участников или полную очистку списка.
Команде нужно проверить authentication scope, формат resource names, destination account, правила нормализации данных и обработку частичных ошибок. Официальное руководство по переходу содержит сопоставление операций и полей — его следует использовать как спецификацию миграции, а не переписывать mapping по памяти.
Переход также полезно использовать для ревизии privacy-процесса. В Customer Match передаются first-party данные, поэтому важны документированное основание их использования, контроль доступа, минимизация полей, сроки хранения и возможность удалить пользователя из аудитории.
Google не сообщает, что сам запуск v5 меняет требования к согласию или автоматически делает любой список допустимым. Техническая возможность загрузки данных не заменяет юридическую и договорную проверку.
DOOH и источники инвентаря
V5 добавляет возможность создавать `InsertionOrder` для Digital Out of Home. Для платформ, которые централизованно планируют programmatic-размещения, это сокращает объём ручной настройки и позволяет включать DOOH в общий workflow создания заказов.
Однако наружная digital-реклама имеет собственные операционные параметры: географию экранов, расписание, требования к креативам, доступность инвентаря и правила измерения. Поддержка ресурса в API не означает одинаковую доступность всех форматов или площадок на каждом рынке.
Google также обновил получение и таргетинг inventory sources. После перехода нужно повторно проверить:
- какие источники доступны рекламодателю;
- совпадают ли их идентификаторы и статусы;
- не изменились ли фильтры при чтении;
- корректно ли обрабатываются недоступные или архивные источники;
- не создаёт ли кэш интеграции устаревший выбор.
Для Казахстана Google не объявлял отдельный rollout v5 или гарантированный набор DOOH-инвентаря. Поэтому применимость нужно определять по конкретному аккаунту DV360, договору и фактически доступным источникам, а не по одной новости о beta API.
Основные риски beta-миграции
Первый риск — изменение схемы до general availability. Если production-код жёстко привязан к beta-полям без version pinning и тестов, последующее обновление может остановить создание или изменение кампаний.
Второй риск — незаметное расхождение настроек. Запрос может завершиться успешно, но итоговая аудитория, исключение или источник инвентаря будет отличаться от ожидания из-за новой модели полей.
Третий риск — двойная запись во время переноса Customer Match. Параллельные pipelines без idempotency могут повторно отправлять участников, конфликтовать при удалении или формировать разные версии одной аудитории.
Четвёртый риск — чрезмерные права. Появление write-операций для YouTube-исключений требует пересмотреть service accounts и принцип минимальных привилегий. Процесс, которому достаточно чтения отчётов, не должен автоматически получать право менять таргетинг.
Пятый риск — отсутствие rollback. Если v5 становится единственным путём записи до того, как команда научилась восстанавливать предыдущую конфигурацию, ошибка превращается в длительный ручной ремонт.
План перехода с v4 на v5
Безопасную миграцию удобно разделить на семь этапов.
1. Инвентаризация. Соберите все методы v4, используемые ресурсы, частоту вызовов, service accounts и зависимые процессы. Отдельно отметьте Customer Match, YouTube exclusions и audience targeting.
2. Классификация изменений. Для каждого вызова определите: остаётся без изменений, требует нового поля, переносится в Data Manager API или больше не поддерживается.
3. Новый контур авторизации. Настройте необходимые scopes и доступы для Data Manager API отдельно. Не расширяйте права существующих учётных записей без причины.
4. Контрактные тесты. Зафиксируйте примеры запросов и ожидаемые ответы. Проверяйте обязательные поля, enum-значения, пагинацию, ошибки и ограничения квоты.
5. Shadow read. Сравнивайте чтение v4 и v5 на одних сущностях без записи. Расхождения нужно объяснить до включения изменений.
6. Ограниченный write-тест. Выберите тестового рекламодателя и небольшую группу сущностей. После каждой записи перечитывайте результат и сверяйте его с утверждённой конфигурацией.
7. Постепенное переключение. Включайте v5 по аккаунтам или функциям через feature flag. Сохраняйте мониторинг ошибок, latency, квот и числа изменённых объектов.
Для Customer Match отдельный dual-write допустим только при контролируемой idempotency и понятной модели удаления. Во многих случаях безопаснее остановить старый writer, проверить последнюю синхронизацию и затем включить новый pipeline.
Чек-лист для рекламодателя
Если кампании ведутся вручную и у бизнеса нет собственной интеграции DV360, срочных действий может не быть. Нужно уточнить у агентства или технологического подрядчика, используется ли API и кто отвечает за миграцию.
Если интеграция есть, проверьте:
- зафиксирован ли перечень вызовов v4;
- используется ли Customer Match через DV360 API;
- подготовлен ли доступ к Data Manager API;
- протестированы ли YouTube video/channel exclusions;
- проверены ли Demand Gen и YouTube audience settings;
- есть ли тестовый рекламодатель;
- настроены ли diff, журналирование и лимиты записи;
- предусмотрен ли rollback;
- закреплена ли версия клиентской библиотеки;
- отслеживаются ли release notes beta-версии.
Оценивать переход нужно не по факту «API отвечает», а по сохранению результата рекламы: таргетинг соответствует утверждённой стратегии, исключения не режут охват без причины, Customer Match обновляется корректно, а автоматизация не получает лишних прав.
DV360 API v5 даёт больше контроля, но одновременно разделяет ответственность между DV360 API и Data Manager API. Лучший момент для миграции — до того, как beta-изменения станут критичной зависимостью production-процессов.
Если нужно проверить рекламные интеграции, аудитории, brand safety и структуру кампаний, закажите ведение Google Рекламы.
Источники
- Announcing beta launch of Display & Video 360 API v5 — Google Ads Developer Blog, 22 октября 2026 года.
- Migrate from Display & Video 360 API v4 to v5 — новые возможности и изменения ресурсов.
- Upgrade from the Display & Video 360 API — официальный переход Customer Match.
- Customer Match overview for Display & Video 360 — workflow аудиторий и загрузки участников.
- Audiences overview — поддержка аудиторий Google Ads и Display & Video 360.
Оставьте отзыв