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 обидва підходи сусідять: обмеження ставки зверху — поріг, стратегія за цільовою вартістю дії — модель.

Критерій вибору — покриття: скільки конверсій на тиждень припадає на сегмент. Мало — правило дає керований результат без ризику перенавчання; багато — модель витягує ставку там, де поріг промахується.

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

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

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

Що робити з пропусками та неповними даними?

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

Як зрозуміти, чому вибрано саме цю ставку?

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

Чи не розжене система витрати?

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

Що залишиться в нас після передачі?

Віддаємо систему, а не чорну скриньку: конфігурації, правила обмежень, журнали рішень, регламент перенавчання й розбору збоїв. Інженери замовника проходять навчання на своїх даних, далі розвиток іде без нас.

Обговоримо задачу: що підготувати до першого розбору

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

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

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