Programmatic Advertising AI: RTB, прогнозы и оптимизация бюджета

Programmatic Advertising AI: где ломается закупка

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

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

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

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

Что даёт внедрение AI в управление ставками

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

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

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

Класс отказов, который уходит, — показы без отклика: инвентарь выкуплен, целевого действия не последовало. Доля пустых показов в таком контуре падает с 50–60 % до 15–25 %, а слабая площадка отключается по статистике, накопленной за часы, а не по итогам недели.

Режимы оптимизации ставок: правила, прогнозы, гибрид

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

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

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

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

Внедрение: от аудита данных до передачи регламентов

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

1. Аудит данных. Сверяем источники — журналы показов и ставок, отчёты площадок, события из CRM и биллинга. Сводим идентификаторы, часовые пояса и валюты, считаем долю пропусков и дублей по каждому разрезу.
2. Схема потоков данных. Фиксируем, где рождается событие, сколько идёт до хранилища и в каком окне агрегируется. Проверяем, какие признаки доступны в момент ставки, — иначе обучение подтянет будущее и прогноз развалится на живом трафике.
3. Настройка прогноза. Берём простой базовый уровень по сегментам как точку отсчёта: с ним сравниваем каждую следующую версию. Главная метрика — калибровка вероятности, чтобы предсказанные 3% совпадали с фактическими.
4. Проверка на прошлых данных. Прогоняем модель на закрытом периоде с сохранённой историей ставок и сверяем с фактическим исходом. Расхождения разбираем по сегментам: где теряем на редких площадках, где переоцениваем дешёвый инвентарь.
5. Теневой запуск. Модель считает ставки параллельно с текущей закупкой, бюджет не тратит. Сравниваем состав закупки, расхождения по площадкам и поведение при резком росте конкуренции.
6. Передача регламентов. Отдаём правила переобучения, пороги деградации, мониторинговые метрики и порядок отката на прежнюю логику. Дальше команда заказчика ведёт контур сама.

Политики ставок, схемы потоков и рабочая документация

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

• Политики ставок: потолки по каналам, инвентарю и сегментам, приоритеты между кампаниями и условия, при которых автоматика обязана снизить темп расходования.
• Схемы потоков данных: путь события от площадки до витрины прогнозов, состав полей, точки обогащения, допустимые задержки и порядок сверки расхождений в отчётах.
• Регламент переобучения: триггеры (просадка точности прогноза, смена сезонности, дрейф данных), периодичность, объём валидации и условие отката на предыдущую версию.
• Документация по интеграциям: состав запросов, лимиты частоты, обработка отказов и повторных отправок, поведение при недоступности внешнего сервиса.
• Контроль качества решений: набор метрик и их сверка с фактом, порядок разбора инцидентов, матрица ответственных за изменения в политике ставок.
• Инструкции для команды: как поднять окружение, отключить автоматику, выгрузить логи и перевести управление торгами в ручной режим.

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

Кейс: как снизили долю неэффективных показов вдвое

Старт: ставка по среднему за прошлую неделю

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

Что изменили и что показали метрики

Прогноз разделили на два горизонта: суточный по объёму спроса и короткий — чтобы ловить смену активности внутри дня. Ставку считает модель под цель конкретной кампании, а не одно общее правило; ограничения по частоте и дневному расходу оставили в настройках кампании, поэтому расход выравнивается и модель его не перебивает. Данные аукциона подтягивали из DV360 и сверяли с фактическими показами: раз в неделю разбирали, где прогноз расходится с фактом, и правили признаки.

За два месяца доля показов без отклика снизилась с 41% до 19%, а реакция на всплеск спроса сократилась с шести часов до пятнадцати минут. Ошибка прогноза по дневному объёму показов — с 22% до 8%. Устойчивость проверяли на отложенном периоде и при смене креатива: там, где раньше модель разъезжалась в первую неделю, теперь держит точность. Неэффективные показы отсекаются по ходу дня, а не на разборе итогов, — ручных правок ставок больше не требуется.

Прогнозная модель или правила на пороге: что выбрать?

Короткий ответ: это не выбор «или-или». Правило на пороге — детерминированная функция: ставка считается по формуле и обрезается сверху, пока выполняются условия по сегменту и частоте. Модель прогнозирует вероятность целевого действия на каждом показе и из неё выводит ставку. Разница не в точности, а в объёме данных и стабильности аукциона.

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

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

Сомнения: качество данных и прозрачность решений

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

Что делать с пропусками и неполными данными?

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

Как понять, почему выбрана именно эта ставка?

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

Не разгонит ли система расходы?

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

Что останется у нас после передачи?

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

Обсудим задачу: что подготовить к первому разбору

Разбор задачи идёт быстрее, когда на руках есть данные, а не пересказ общих пожеланий. Ниже — что полезно подготовить к первому разговору: с этим сразу видно, где модель даст прирост, а где ограничение внешнее.

• Доступы к данным: выгрузки логов показов и кликов за несколько месяцев — идентификаторы кампаний, площадок и креативов, ставки, исходы аукционов. Кабинеты и хранилище аналитики достаточно открыть в режиме только чтения.
• Цели по метрикам: что оптимизируем — стоимость целевого действия, долю выкупленного инвентаря, охват в нужном сегменте. Нужны текущее и целевое значения, иначе не с чем сравнивать результат.
• Ограничения по площадкам: списки разрешённых и запрещённых источников, требования бренд-безопасности, гео, часы показа, закрытые категории контента.
• Правила ставок и бюджетов: дневные лимиты, максимальная ставка, приоритеты между кампаниями, поведение системы при исчерпании лимита.
• Сигналы о пользователе: какие признаки допустимо использовать — контекст, устройство, гео, источник трафика, и что закрыто политиками и согласиями.
• Контур эксплуатации: в чьём облаке разворачиваем, кто держит секреты, как выглядит откат модели на предыдущую версию.

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