Кастомный AI-биддинг для рекламных кампаний: ROAS/CPA

Оптимизация ставок в рекламе: где ломается управление

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

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

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

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

Измеримый эффект: время реакции, охват, класс отказов

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

Скорость реакции на изменение спроса

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

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

Устранённые классы отказов

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

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

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

Автоматические ставки против ручных правил: границы применимости

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

Гибридный режим: правила задают коридор, модель — ставку

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

Где ручные правила всё ещё уместны

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

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

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

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

Проверка на истории и контрольный запуск

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

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

Что остаётся у команды: конфигурации, правила, журнал решений

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

Логика пересчёта и пороги

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

Панель контроля решений

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

Кейс: доля целевых действий выросла при прежнем расходе

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

Как было до

На замерной неделе доля целевых действий от всех переходов держалась на 2,4%, возврат на рекламные расходы гулял от 1,9 до 3,1 при неизменном расходе, а CPA в худшей трети кампаний был в 2,3 раза выше, чем в лучшей. Перераспределение между кампаниями происходило вручную и не чаще раза в сутки — дневной бюджет успевал выработаться раньше, чем становилась заметна просадка.

Что изменили

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

Подход совпадает с выводами исследований по управлению ставками на неполных данных Journal of Marketing Research.

После перехода доля целевых действий составила 3,6%, разброс возврата сузился до 2,6–3,3, а динамика CPA дала снижение на 31% при том же расходе.

Что делать, если аукцион уже разогнан ручными правилами?

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

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

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

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

Технические сомнения: данные, задержки, безопасный откат

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

Конверсия приходит через несколько дней — какая тут оптимизация?

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

Как откатить изменения, если ставки ушли не туда?

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

Это конфликтует со встроенными средствами рекламных систем?

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

Обсудим задачу: что нужно для оценки и плана

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

• Доступы к данным. Выгрузка статистики по кампаниям за несколько периодов с разбивкой по каналам, площадкам, аудиториям и объявлениям. Обезличенных данных достаточно — персональные сведения не нужны.
• Целевые метрики. Что считаем результатом: окупаемость расходов на рекламу, стоимость привлечения, доля повторных покупок. Отдельно — границы, за которые алгоритм не должен выходить.
• Ограничения. Регионы, закрытые площадки, требования к модерации, сезонные всплески спроса. Всё, что нельзя нарушать при автоматической корректировке ставок.
• История попыток. Какие правила и стратегии уже применялись, что дало рост, что уводило бюджет в минус. Это экономит целый этап проверок.
• Технический контур. Откуда забираем данные, кто владелец систем, как часто обновляется статистика и насколько быстро нужно реагировать на изменение спроса.
• Ответственные. Кто согласовывает изменения ставок и готов ли бизнес передать рутину алгоритму под контролем человека.

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

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