OpenProposal предлагает машиночитаемый способ описывать рекламные предложения. Для российской команды полезнее всего разобраться, какие вопросы должен закрывать такой документ, прежде чем доверять агенту выбор площадок. Ниже приведён редакционный проект пилота: его можно использовать при работе с обычными таблицами и API, даже если ваши партнёры ещё не поддерживают спецификацию.
Что действительно появилось и чего пока нельзя утверждать
IAB Tech Lab представила AAMP 3.0 с OpenProposal 22 сентября 2026 года. Предмет обновления: обмен предложениями между брифом покупателя и обязательством по закупке. Это расширение агентного процесса на планирование, а не только на исполнение кампании.
В репозитории OpenProposal на момент проверки 23 октября документ обозначен как draft; указанный срок общественного обсуждения закончился 22 октября. Окончание обсуждения само по себе не подтверждает утверждение стабильного стандарта. Перед разработкой нужно проверить тег версии и изменения. В этом разборе мы рассматриваем направление спецификации и собственный сценарий пилота, не заявляем готовность российского рынка к её эксплуатации.
Отдельно важно происхождение свидетельств. Релиз и репозиторий принадлежат одной организации. Они подтверждают существование и содержание инициативы, но не независимый результат внедрения. IAB Australia описывает seller-side sandbox как маршрут тестирования. Само объявление пилота не доказывает ни экономию времени, ни рост выручки.
В материале Digiday от 11 мая 2026 года покупатели и площадки обсуждают обе стороны агентной закупки: потенциальное упрощение операций и риск новой непрозрачности. Это более ранний рыночный контекст, а не оценка OpenProposal, появившегося позже. Он объясняет, почему проверка условий и наблюдаемость решений должны предшествовать автономному расходованию бюджета.
Сначала определите объект сравнения
Предложение площадки должно быть достаточно определённым, чтобы два аналитика независимо пришли к одному выводу о его допустимости. Если один понимает «видеопоказ» как старт плеера, а другой как подтверждённый просмотр на нужном экране, автоматизация лишь спрячёт расхождение в коде.
Начните с единицы закупки. За что платит рекламодатель: за тысячу доставленных показов, за тысячу видимых, за завершённый просмотр или за пакет с гарантированным объёмом? Затем зафиксируйте устройство, формат, период, территорию и ограничения качества. Это контур сопоставимости. Цена появляется после него.
Для одного пакета заведите карточку: идентификатор предложения, версия, срок действия, юридическая сторона продавца, предмет, единица цены, включённые услуги, доступное измерение и порядок изменения условий. Пустое поле должно сохраняться пустым. Агенту нельзя дописывать отсутствующие гарантии из общего описания площадки.
Практический тест прост: отдайте карточку сотруднику, который не участвовал в переговорах. Пусть он объяснит, что именно команда может заказать и как узнает, что обязательство выполнено. Если для этого требуется пересказать цепочку писем, карточка ещё не готова к автоматическому сравнению.
Переведите бриф в проверяемые ограничения
«Нам нужен качественный контакт с премиальной аудиторией» оставляет слишком много пространства для догадок. Машине нужны поля, по которым можно принять или отклонить предложение. Человеку они нужны не меньше.
Ниже учебный бриф для запуска видеокампании. Его значения условны и не являются рыночными бенчмарками.
| Поле | Учебное значение | Что проверяет агент |
|---|---|---|
| Период | Две согласованные недели | Весь ли объём доступен в периоде |
| Территория | Три выбранных региона | Совпадает ли географическое определение |
| Экран | Только заданный тип устройства | Не смешан ли он с другими экранами |
| База цены | Доставленные показы | Можно ли сопоставить стоимость |
| Контроль качества | Согласованный список проверок | Есть ли подтверждающие поля |
| Изменение бюджета | Только после согласования | Может ли рекомендация стать заказом |
В реальном документе к каждому полю добавляют владельца определения. Маркетинг отвечает за цель, медиакоманда за допустимые продукты, аналитик за измерение, закупка за коммерческие условия. Так расхождение превращается в конкретный вопрос ответственному человеку.
Не пытайтесь сразу формализовать весь стратегический замысел бренда. Для первого пилота достаточно задачи, где допустимость предложения можно проверить. Оценка культурного контекста, редакционной репутации или сложной интеграции может остаться экспертным этапом.
Допустимость проверяется раньше рейтинга
Плохой рейтинг пытается компенсировать отсутствующую гарантию дешёвой ценой. Например, модель снижает оценку за неизвестное устройство, но всё равно выводит пакет на первое место благодаря низкому CPM. В итоге команда получает убедительную рекомендацию на продукт, который не соответствует брифу.
Разделите процесс на два шага. Сначала проверяются обязательные ограничения. Ответы: выполнено, не выполнено или неизвестно. Предложение с неизвестным критическим параметром уходит на уточнение. Только оставшиеся варианты участвуют в сравнении цены и дополнительных преимуществ.
| Проверка | Решение при провале | Владелец уточнения |
|---|---|---|
| Единица цены совпадает с брифом | Исключить из ценового рейтинга | Закупка |
| Есть нужный экран | Отклонить или запросить отдельный пакет | Медиапланер |
| Измерение поддерживает согласованный KPI | Приостановить оценку результата | Аналитик |
| Условия действуют на весь период | Запросить новую версию предложения | Площадка |
Это редакционная рекомендация по устройству пилота. Мы не приписываем такую реализацию каждой платформе, использующей термин agentic. В запросе поставщику следует прямо спросить, где именно выполняются ограничения и может ли языковая модель их обойти.
Учебный разбор трёх предложений
Предположим, бренд получил три пакета. Первый стоит 180 условных денежных единиц за тысячу показов, второй 220, третий 200. Суммы придуманы для объяснения метода и не описывают российский рынок.
У первого продавца цена относится к смешанным экранам, хотя бриф требует один тип устройства. Второй продаёт нужный экран, но берёт дополнительную плату за проверку качества. Третий включает измерение, однако срок действия предложения заканчивается до согласования медиаплана.
Сортировка по числу 180, 200, 220 даёт ложное ощущение выбора. Корректный первый результат выглядит иначе: первому продавцу нужен запрос отдельного пакета, второму расчёт полной стоимости, третьему подтверждение актуальности условий. До ответов у команды нет трёх сопоставимых цен.
После уточнения второй пакет может стать самым дешёвым по полезному контакту или, напротив, выйти из бюджета. Это определяется условиями и данными, а не формулировкой промпта. Агент полезен, если сохраняет причины промежуточных решений и возвращает их человеку вместе с рейтингом.
Сравните такую работу с существующим гайдом по programmatic, RTB, DSP и SSP. Базовый гайд объясняет роли платформ; здесь задача уже конкретнее: принять предложение к сравнению до покупки. Эти два интента связаны, но требуют разной глубины.
Объяснение рекомендации должно быть воспроизводимым
Красивый абзац «пакет лучше соответствует целям бренда» почти бесполезен для аудита. Нужна связь между выводом и полем исходного предложения. Сохраняйте идентификатор брифа, версию пакета, значения обязательных проверок, использованные допущения и источник каждого коммерческого условия.
Отдельно записывайте действия агента. Получение предложения, запрос уточнения, изменение рейтинга и отправка заказа имеют разный уровень последствий. Если всё хранится как один разговор с ассистентом, восстановить состояние сделки становится трудно.
В рабочем журнале достаточно короткой записи: «пакет B, версия 4; прошёл проверки экрана и периода; полная цена включает верификацию; доступность объёма требует подтверждения». Такая запись полезнее длинного объяснения уверенности модели.
Проверяйте воспроизводимость на фиксированном наборе предложений. При повторном запуске допустим другой текст объяснения, но обязательные ограничения и причины отказа должны сохраняться. Если результат меняется без новых данных, команда должна понимать, какая часть процесса недетерминирована и чем это ограничено.
Кто имеет право превратить рекомендацию в обязательство
Рейтинг и заказ лучше рассматривать как отдельные полномочия. Даже если агент правильно сравнил пакеты, это ещё не означает права согласиться с новыми условиями, поменять лимит или подтвердить покупку. У каждой операции должен быть свой предел.
Для первого пилота агенту можно дать доступ на чтение каталога и подготовку черновика сравнения. Отправку уточняющего вопроса разрешить в заранее заданной форме. Создание заказа оставить за человеком, пока не проверены повторные запросы, отзыв доступа, изменение версии предложения и обработка ответа с задержкой.
Особенно опасна ситуация, когда интерфейс сообщил об ошибке, а продавец уже принял заказ. Повторное нажатие не должно создавать второй бюджет. Поэтому в испытания включают повтор команды с тем же идентификатором и проверку фактического состояния у принимающей стороны. Это отдельная инженерная задача, а не свойство хорошего русского промпта.
Бренд должен знать, кто отвечает за ошибочное обязательство: владелец кабинета, агентство или поставщик автоматизации. В статье нельзя заменить договорную и техническую проработку универсальным обещанием безопасности. Для пилота достаточно перечислить операции, ответственных и способ остановки.
Как провести пилот на российском рынке
Соберите один реальный бриф и обезличенные предложения нескольких партнёров, для которых разрешено такое использование. Уберите коммерческие тайны, которые нельзя передавать внешнему провайдеру модели. Договоритесь, какие поля можно хранить и кто имеет доступ к журналу.
Медиапланер вручную готовит эталон допустимости: какие варианты соответствуют обязательным требованиям, какие требуют уточнения и какие отклоняются. Это не эталон «лучшего вкуса», а контроль фактических ограничений. Спорные случаи разбираются до оценки агента.
Первый прогон выполняют без доступа к расходованию бюджета. Сравнивают пропущенные нарушения, ложные отказы, число нужных уточнений и время до пригодной таблицы. Отдельно измеряют время человеческой проверки: его нельзя исключать из заявленной экономии.
Затем добавляют неприятные случаи: устаревшую версию пакета, цену без указания базы, неполный ответ продавца, конфликт двух полей, повторный запрос. Система должна либо корректно обработать ситуацию, либо остановиться с понятной причиной. Уверенное угадывание считается ошибкой.
Лишь после этого можно обсуждать интеграцию со средствами исполнения. Поддержка OpenProposal у конкретного российского партнёра требует его подтверждения; наличие API или слова AI на сайте недостаточно. Даже без стандарта команда может получить пользу от нормализации предложений в собственной системе.
Как посчитать пользу без выдуманной экономии
Выберите единицу результата: согласованное предложение, пригодное для решения о закупке. Посчитайте полную работу до него: получение, извлечение полей, уточнения, проверку и согласование. Сравнение только времени генерации таблицы завысит эффект.
В затраты пилота входят настройка, обращения к модели, поддержка интеграций и разбор ошибок. В результат входят сокращение ручного времени и изменение качества выбора. Второе нельзя автоматически перевести в деньги: для этого потребуется отдельное наблюдение кампании или эксперимент.
Полезный итог пилота может оказаться скромным: агент хорошо извлекает условия, но плохо ранжирует сложные пакеты. Тогда его оставляют помощником по подготовке данных. Это полноценный результат испытания, который помогает не строить дорогую автономию раньше времени.
Перед проектированием пилота договоритесь о значении ролей: кто покупает, кто продаёт и кто подтверждает исполнение. Базовые понятия доступны в глоссарии DSP и RTB.
Что сделать до следующего запроса площадкам
Возьмите последний медиаплан и найдите строки, которые сравнивались по цене при разных условиях. Выберите одну такую категорию. Составьте минимальную карточку предложения и три обязательных ограничения. Проверьте её сначала на людях, затем на агенте.
Переход к автоматизации стоит продолжать, когда команда способна объяснить каждый отказ, воспроизвести сравнение и остановить превращение спорной рекомендации в заказ. Публичные материалы OpenProposal дают направление для такого разговора. Подтверждённой универсальной прибавки к эффективности они пока не заменяют.
