Чому прогнозування конверсії ламається на реальних даних
Модель конверсії, яка на відкладеній вибірці показала точність вище 0.9, у продакшені часто просідає до випадкового вгадування протягом кількох тижнів.
Причина не в алгоритмі: прогнозування конверсії ламається на властивостях самих даних — рідкісній цільовій події, зміщеній історії та нестаціонарній поведінці користувачів. Розбираємо, як це закривається інженерно.
Зміщення вибірки проявляється найтихіше. Логи навчаються на подіях, які вже пройшли через поточну воронку: покази, кліки, минулі покупки.
Користувачі, яких система раніше не пускала в показ, в історію не потрапляють — модель навчається на усіченому просторі й упевнено помиляється саме на тих сегментах, де рішення найцінніше.
Лікується не «додаванням даних», а відновленням механізму відбору: логуємо причини непоказу, фіксуємо політику минулих рішень і перераховуємо ваги так, щоб розподіл ознак у навчанні збігався з тим, що модель побачить у бою.
Рідкісні події додають другий шар проблеми. Конверсія — це частки відсотка від трафіку, і стандартна функція втрат на такому дисбалансі просто вивчає «завжди ні». Метрика accuracy при цьому виглядає пристойно, а модель марна.
Тому цільову змінну перевизначають: навчають на проміжних сигналах (мікроконверсіях), застосовують зважування класів і калібрування ймовірностей, а якість оцінюють за precision-recall і підйомом у верхніх децилях, а не за загальною точністю.
Дрейф даних добиває те, що залишилося. Поведінка аудиторії змінюється: приходить новий канал, змінюється ціна, оновлюється інтерфейс — і розподіл ознак від'їжджає від навчального. Без моніторингу розходження й регулярного перенавчання модель тихо деградує між релізами. Далі — про те, як ці три причини закриваються на рівні архітектури та процесу.
Що дає модель передбачення конверсії та як її будують
Модель передбачення конверсії — це не «розумна кнопка», а контур із трьох частин: ознаки, навчання, регулярна переоцінка. На вхід ідуть поведінкові події, історія торкань, властивості сегмента та контекст візиту; на виході — ймовірність цільової дії для кожного користувача.
Далі поріг відсікання налаштовується під задачу: утримання у воронці, пріоритет у черзі обробки або тригер комунікації.
Що реально вимірюємо
Якість моделі вважаємо не за однією цифрою. Дивимося ROC-AUC і PR-AUC на відкладеній вибірці, калібрування ймовірностей (наскільки передбачені 20% збігаються з фактичною часткою), і lift у верхніх децилях — саме він визначає, скільки звернень іде не марно.
Повнота вибірки важлива не менше: якщо події збираються з втратами, модель навчається на зміщених даних і впевнено помиляється на «тихих» сегментах.
Чим будуємо
Градієнтний бустинг бере табличні ознаки та категорії, стійкий до пропусків, дає готові оцінки важливості ознак — це робоча конячка для більшості задач.
Логістична регресія виграє там, де потрібна прозорість: коефіцієнти читаються як вплив фактора, модель легко пояснити бізнесу та перевірити на стабільність. На практиці часто ставлять бустинг як основну модель, а регресію — як базову лінію та контроль дрейфу.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Логістична регресія | Мало даних, потрібна інтерпретація, швидкий старт | Погано ловить нелінійні зв'язки та взаємодії ознак |
| Градієнтний бустинг | Табличні дані, різнорідні ознаки, потрібна точність | Потребує налаштування та контролю перенавчання, слабше пояснюється |
| Нейромережа на послідовностях | Довга історія торкань, тексти, складні сценарії | Потрібні обсяги даних та інфраструктура для регулярного перенавчання |
scikit-learn закриває базову лінію та метрики, бустинг — основну модель.
Впровадження окупається не «магією», а тим, що пріоритезація звернень стає вимірюваною: частка попадань у цільовий сегмент у верхніх децилях зростає в рази відносно випадкового відбору, а рішення спираються на відтворюваний розрахунок, а не на інтуїцію.
Як ми впроваджуємо модель: від аудиту даних до передачі
Впровадження моделі передбачення конверсії починається не з навчання, а з аудиту даних: дивимося, що взагалі є в CRM, веб-аналітиці та білінгу, як розмічені цільові події та чи немає витоку майбутнього у ознаки.
На цьому етапі найчастіше з'ясовується, що частина конверсій губиться в логах, а частка розмічених прикладів занадто мала для чесного навчання — це змінює план робіт до того, як написано перший рядок коду.
- Аудит даних. Зводимо джерела, перевіряємо повноту та узгодженість розмітки цільової події, рахуємо базову частку конверсій і період спостереження. Фіксуємо, яких даних не вистачає і як їх збирати.
- Проєктування ознак. Збираємо поведінкові, транзакційні та контекстні ознаки, стежимо за часовими зсувами, щоб модель не «підглядала» в майбутнє. Окремо готуємо категоріальні ознаки та обробку пропусків.
- Навчання та підбір моделі. Порівнюємо кілька підходів на відкладеній вибірці, налаштовуємо баланс класів і поріг спрацювання під бізнес-завдання, а не під абстрактну точність.
- Валідація моделі. Перевіряємо на часовому розбитті, а не випадковому: дивимося частку вірних спрацювань у топ-сегменті, стійкість до зсуву даних і поведінку на рідкісних сегментах аудиторії.
- Інтеграція моделі. Підключаємо скоринг до CRM, рекламних кабінетів або сайту через API, налаштовуємо регулярний перерахунок ознак і моніторинг якості передбачень.
- Передача та супровід. Віддаємо документацію, схеми ознак, регламент перенавчання та дашборд з метриками, щоб команда замовника могла працювати з моделлю самостійно.
Кожен етап закінчується артефактом, який можна перевірити: звіт по даних, набір ознак, метрики на відкладеній вибірці, робочий інтеграційний контур.
Такий порядок дозволяє зупинитися на будь-якому кроці та побачити, де саме втрачається якість передбачення конверсії, а не з'ясовувати це після запуску в продакшн.
Чим відрізняється передбачення конверсії від прогнозу виручки?
Передбачення конверсії та прогноз виручки — це два різних типи задач, і плутати їх дорого: модель навчать не на тому таргеті, і на виході отримають красиві числа, які не відповідають на бізнес-питання.
Перша відповідає «чи станеться подія» — користувач оформить замовлення, лід дійде до угоди, клієнт активується. Друга відповідає «скільки» — яку суму принесе цей користувач, сегмент або період. Звідси й різна математика.
Передбачення конверсії — задача класифікації. Модель видає ймовірність події в діапазоні від нуля до одиниці, а рішення приймається за порогом: вище порога вважаємо «сконвертує», нижче — ні.
Метрики моделі тут про якість ранжування та розділення класів — ROC-AUC, precision, recall, частка вірних спрацювань на топі. Поріг підбирається не за красою кривої, а під економіку: скільки хибних спрацювань готовий прийняти процес, якою є ціна пропуску цільового користувача.
Прогноз виручки — задача регресії. Модель передбачає неперервну величину, і метрики інші: середня абсолютна похибка, частка поясненої дисперсії, симетрична похибка у відсотках.
Тут важливо не «вгадати клас», а не схибити в масштабі — заниження прогнозу на великих клієнтах спотворює планування сильніше, ніж розкид на дрібних.
Практична різниця проявляється в даних і цільовій змінній. Для конверсії таргет бінарний, важливий баланс класів і те, як розмічений горизонт події: конверсія «протягом тижня» і «протягом місяця» — це дві різні моделі з різною передбачувальною силою.
Для виручки таргет неперервний, з довгим хвостом і викидами, тому часто працюють з логарифмом суми або будують двоступеневу схему: спочатку класифікатор відокремлює тих, хто взагалі сконвертує, потім регресія оцінює суму за тими, хто сконвертував.
На практиці ці задачі часто йдуть у зв'язці. Класифікатор відсікає завідомо нецільових, регресія рахує очікувану цінність за тими, хто залишився, а бізнес отримує і ймовірність, і суму.
Якщо змішати їх в одну модель на одному таргеті, втрачається інтерпретованість: незрозуміло, похибка в ймовірності чи в масштабі суми. Тому ми спочатку фіксуємо, яке саме питання має закривати результат, і тільки потім обираємо тип задачі та метрики моделі.
Кейс: як модель передбачення конверсії змінила воронку
Клієнт — відділ продажів B2B-напрямку — звернувся до нас із класичною проблемою: менеджери обробляли всі вхідні заявки підряд, а конверсія в угоду трималася на рівні 4-6%.
Половина часу йшла на явно «холодні» звернення, гарячі ліди чекали відповіді по кілька годин і охолоджувалися. Ручна пріоритизація не працювала: у кожного менеджера своя інтуїція, єдиного критерію не було.
Що змінили
Зібрали історичні дані щодо заявок за кілька років: джерело, поведінка на сайті, галузь, розмір компанії, історія дотиків. Навчили модель бінарної класифікації — вона оцінює ймовірність угоди за кожною заявкою в момент надходження. Скор вбудували прямо в CRM: менеджер бачить пріоритет і працює спочатку з лідами вище порогу.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Точність пріоритизації | інтуїція менеджера | 78% на відкладеній вибірці |
| Конверсія в угоду | 4-6% | 11% |
| Час до першого дотику гарячого ліда | 4-6 годин | 20-30 хвилин |
| Частка заявок, оброблених у пріоритеті | — | 100% |
Окремо налаштували моніторинг дрейфу: якщо розподіл вхідних даних зміщується, модель сигналить і йде на перенавчання. Без цього точність тихо деградує за пару місяців — класична пастка під час впровадження.
Що це дало воронці
Конверсія зросла майже вдвічі без збільшення штату та рекламного бюджету — просто за рахунок того, що зусилля сфокусувалися на перспективних лідах. Витрати на залучення в перерахунку на угоду знизилися: той самий потік заявок став давати більше закритих угод. Рішення щодо пріоритету тепер ухвалюються за секунди й однаково в усіх менеджерів.
Модель побудована на CatBoost — стійко працює з категоріальними ознаками та табличними даними, які якраз і становлять профіль заявки.
Сумніви перед впровадженням: сумісність, міграція, відкат
Перед впровадженням моделі передбачення конверсії замовник зазвичай ставить три питання: як це впишеться в поточний стек, що буде з уже працюючими правилами і як відкотитися, якщо якість просяде.
Відповідаємо по суті: модель віддає прогноз через API або пакетний розрахунок, тому не вимагає змінювати CRM, сховище або фронтенд — достатньо точки інтеграції, куди йде числовий скор.
Старі бізнес-правила залишаються увімкненими і працюють паралельно, поки ми не підтвердимо, що модель дає приріст на живому трафіку.
Що якщо якість на проді виявиться гіршою, ніж на тесті?
Ми не перемикаємо весь трафік одразу: спочатку модель обробляє частку запитів, метрики порівнюються з поточним правилом на одній і тій самій аудиторії. Перемикання йде через конфігурацію — повернути попередню логіку можна без викату коду, за хвилини. Модель версіонується, попередня версія залишається доступною для миттєвого відкату.
Що якщо у нас своя інфраструктура і закритий контур? Розгортаємо модель усередині вашого середовища, без виходу даних назовні. Навчання та інференс ідуть на ваших потужностях, ми передаємо конфігурацію і скрипти перенавчання.
Що якщо дані лежать у різних системах? Збираємо ознаки з доступних джерел через шар підготовки даних — він ізольований, тому додавання нового джерела не ламає модель.
Після здачі ви отримуєте на руки:
- код навчання та інференсу з описом залежностей;
- конфігурацію розгортання і точки інтеграції з поточними системами;
- схему ознак: звідки береться кожна, як часто оновлюється;
- політику версіонування моделей і процедуру відкату;
- регламент перенавчання і контролю якості на нових даних;
- звіт з метриками на відкладеній вибірці та розбором помилок;
- інструкцію для команди: як читати прогноз і що робити при відхиленнях.
Опишіть вашу задачу і поточний стек — повернемося з оцінкою, планом впровадження і межами відповідальності.
Терміни впровадження моделі передбачення конверсії за етапами
Терміни впровадження моделі передбачення конверсії залежать не від обсягу історичних даних, а від того, наскільки швидко вдається зібрати чесну навчальну вибірку та домовитися про метрику успіху.
Тому план робіт будується навколо етапів, а не календарних дат: кожен наступний крок стартує, коли попередній дав перевірюваний результат, а не коли настало число в графіку.
Найдовше триває не навчання, а підготовка даних: якщо події конверсії пишуться в різні системи з різними ідентифікаторами користувача, на склеювання йде більше часу, ніж на саму модель.
Зворотна ситуація теж буває — коли історія коротка або цільових подій мало, доводиться спочатку накопичити дані, і це єдиний етап, який не можна прискорити інженерно.
Орієнтовні терміни вище — для проєкту, де дані вже збираються і доступ до них є. Якщо потрібно спочатку вибудувати збір подій або розмітку, план робіт зсувається, і ми говоримо про це одразу, а не на середині. Опишіть задачу — повернемося з оцінкою та планом під ваш контекст.
