Чому upsell-рекомендації ШІ не дають приросту середнього чека
Блок upsell-рекомендацій ШІ стоїть і на картці, і в кошику, але середній чек не рухається. Причина в тому, що підбір ранжує кандидатів за загальною популярністю і показує покупцеві те саме, що він уже знайшов сам.
Низький середній чек тут — не проблема попиту, а наслідок того, що підказка не несе нової інформації й не додає до замовлення жодної позиції.
Друга втрата — порожній блок підбору. Щойно товар закінчується на складі або картка потрапляє до вузької категорії, алгоритму не вистачає кандидатів, і модуль або зникає з вітрини, або віддає випадкову позицію.
Це прямі втрати на вітрині: покупець бачить, що йому нічого не запропонували, і йде до тих, хто збирає комплект повністю.
Найдорожче обходяться нерелевантні рекомендації. Якщо модель не бачить історію замовлень, ціновий сегмент і сумісність позицій, вона пропонує аксесуар до вже купленого або дублікат в іншій упаковці.
Покупець порівнює пару варіантів, не знаходить зв'язки і йде добудовувати замовлення в іншому місці — разом із кошиком.
Приріст з'являється, коли підбір будується на даних: залишки в реальному часі, поточний і минулий кошик, правила сумісності та зворотний зв'язок за фактом викупу. Тоді блок пропонує те, що клієнт ще не розглядав, але готовий узяти. Розбираємо, як це закривається на рівні моделі, даних і вітрини.
Ефект від впровадження: зростання середнього чека і повторних покупок
До впровадження допродаж тримався на пам'яті менеджера: частина замовлень ішла з однією позицією, бо відповідний товар просто не запропонували. Метрики при цьому не знімалися — оцінити, скільки втрачено, не було чим.
Ми починаємо із заміру базової лінії: за зіставний період фіксуємо частку замовлень із додатковою позицією, середній чек, частку повторних покупок і конверсію каталогу.
Далі кожну зміну рахуємо на зіставних групах покупців — контрольній і тестовій.
Рекомендації отримують ідентифікатори, за якими видно, який блок привів до додавання товару в кошик, а версії моделей та їхні метрики ведуться в MLflow: зрозуміло, яка версія дала зсув, яку потрібно перенавчити і на яку відкотитися.
Практичний результат зазвичай виглядає так. Частка замовлень із додатковою позицією зростає з 10-15% до 25-30%, середній чек — на 15-20% без зростання знижок.
Повторні покупки зростають завдяки персональним підбіркам і нагадуванням про витратні матеріали, конверсія каталогу — завдяки тому, що рідкісні позиції перестають бути невидимими для покупця.
Окремо знімаємо навантаження з людей: частка ручних підбірок падає в рази, менеджери повертаються до великих угод, де потрібна розмова. Метрики ефекту зводимо в одну панель, де поряд із виторгом видно, скільки підбірок зібрано автоматично і яку їхню частину прийняли в замовлення.
Варіанти upsell-сценаріїв: правила, модель, гібрид
Перші тижні після запуску ШІ-системи upsell-рекомендацій визначають, що показувати: жорсткі правила, модель, що навчається, чи їхню комбінацію. Вибір залежить від ширини каталогу, обсягу історії замовлень і того, як часто змінюється асортимент. Нижче — три режими, між якими обирають на старті.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Правила підбору | вузький каталог, є явна сумісність товарів | не масштабується: кожне виключення вноситься вручну |
| Модель, що навчається | накопичена історія замовлень і є чим ранжувати | холодний старт і рідкісні позиції — вчити нема на чому |
| Гібридний підхід | правила задають допустимі пари, модель — порядок | дорожче в супроводі: потрібні розмітка і контроль |
Правила підбору не залежать від накопичених даних і працюють із першого дня: явні зв'язки «купив — запропонуй» дають передбачувану видачу.
Слабке місце — ручна підтримка: новинка, сезонна заміна або виключення потребують правки списку, і на широкому каталозі схема розходиться з реальністю.
Модель, що навчається, поверх історії замовлень, наприклад на CatBoost, уловлює те, що правилами не описати: до дорогої позиції вигідніше запропонувати супутню, ніж другу дешеву.
Обмеження ті самі, що в будь-якої моделі рекомендацій: холодний старт і перші тижні роботи, коли вчити ще нема на чому.
Тому найчастіше ми збираємо гібрид: правила відсікають несумісні й недоступні пари, модель ранжує те, що залишилося, за ймовірністю покупки, а її частка в показах зростає в міру накопичення замовлень. Плата — регулярна звірка видачі та оновлення правил, інакше каталог і рекомендації розходяться.
Етапи впровадження: від аудиту даних до передачі рішення
Роботу ведемо ітераціями: кожен етап закривається перевірюваним артефактом — звітом за даними, схемою контуру, конфігурацією правил. Це дозволяє будь-якої миті побачити, на чому будується рекомендація і де проходить межа між контуром і вітриною.
- Аудит даних. Розбираємо події: перегляди, додавання в кошик, замовлення, відмови, пошукові запити. Перевіряємо глибину історії, частку пропусків і якість розмітки категорій — без цього персоналізація вироджується у випадкову видачу.
- Проєктування контуру. Вирішуємо, де рахується рекомендація: онлайн під час запиту чи попереднім розрахунком за сегментами, які сигнали до неї входять, куди віддається результат — картка, кошик, листи. Окремо фіксуємо поведінку за недоступності сервісу, щоб вітрина не втрачала видачу.
- Налаштування підбору. Збираємо базові правила: супутні товари, перехід на старшу лінійку, готові комплекти. Накладаємо обмеження за залишками, маржею та різноманіттям — система не повинна пропонувати те, чого немає.
- Перевірка якості. Спочатку офлайн: на історичних замовленнях дивимося, чи потрапила покупка в топ видачі. Потім живий трафік — частка кліків і додавань у кошик, зміна середнього чека, частка порожніх видач проти контрольної групи.
- Передача рішення. Віддаємо документацію контуру, конфігурацію правил, доступи та дашборд із метриками. Навчаємо команду замовника змінювати ваги, додавати зв'язки й читати звіти без нас.
- Супровід. Стежимо за зсувом асортименту, сезонністю та падінням частки непорожніх видач — за цими сигналами правила й модель перезбираються за регламентом.
Що залишається у вас після здачі проєкту
Проєкт закінчується не показом працюючої видачі, а набором артефактів, за якими ваша команда далі розвиває систему сама. Усе, що ми змінюємо в робочому контурі, лежить у сховищі коду з історією змін — відкат на попередню версію займає хвилини.
- Схема даних і потоків. Джерела подій (перегляди, кошик, замовлення), їхні поля, частота оновлення та правила дедуплікації — видно, звідки береться кожна ознака для ранжування.
- Конфігурації моделей і правил. Пороги впевненості, ваги категорій, списки виключень винесені окремими файлами поряд із кодом, із позначкою, що змінюється без перенавчання, а що потребує прогонки.
- Доступи та ролі. Розділення прав на читання, запис і запуск випуску, сервісні облікові записи, видача ключів через сховище секретів, журнал звернень до чутливих даних.
- Регламент оновлення. Вікно даних для перенавчання, періодичність запуску, метрики, за якими рахується деградація, та умови автоматичного повернення на попередню версію.
- Інструкції для команди. Покрокові сценарії: підняти середовище, перезібрати ознаки, випустити нову версію, відкотити її, розібрати інцидент за логами.
- Документація та журнал рішень. Архітектурні нотатки, обґрунтування вибраного підходу, перевірені й відхилені гіпотези, відкриті питання.
Систему можна передати своїй команді або іншому підряднику — без усних домовленостей і налаштувань, які живуть лише в голові розробника.
Кейс: зростання середнього чека в роздрібній мережі без зростання трафіку
Мережа продуктового ритейлу: 180 офлайн-точок та інтернет-магазин, трафік не зростав.
Рекомендації в кошику працювали за правилом «популярне в категорії» — додаткова позиція потрапляла лише до кожного дев'ятого замовлення, а правила ранжування тричі на рік правили вручну, за відчуттями категорійних менеджерів.
Метрики до і після
Порівнювали не з минулим місяцем, а з контрольною групою в 10% трафіку — так ефект відокремлювався від сезонності та промо. Чеки й поведінку збирали з касових логів і веб-вітрини в Google BigQuery.
| Метрика | До | Через 4 місяці |
|---|---|---|
| Замовлення з додатковою позицією | 11% | 34% |
| Середній чек | база | +21% |
| Частка повторних покупок за 90 днів | 24% | 31% |
| Ручні правки ранжування | 80% видачі | 9% |
Термін впровадження: що змінили
Перші три тижні — вивантаження історії покупок і залишків, ще три — навчання моделі на спільних покупках і сезонних зрізах. Пілот на 12 точках зайняв місяць: стежили за часткою замовлень із допродажем, повнотою видачі та часом відгуку в години пік.
На всю мережу розкотили за два місяці — метрики втрималися, а відкат на попередній ранжувальник це одне правило в налаштуваннях, без перезбирання вітрини.
Що робити, якщо каталог і ціни змінюються щотижня?
Рекомендаційна система не зберігає підбірки готовим списком — вона збирає їх на льоту з ознак товару й поведінки покупця. Тому зміна ціни, нове надходження чи вихід позиції в нуль не потребують перезбирання моделі цілком: оновлюється лише шар актуальності. Часте оновлення каталогу для такої схеми — штатний режим, а не аварійний.
Нові позиції входять у видачу через ознаки: категорія, атрибути, ціновий сегмент, сумісність із тим, що вже в кошику.
Поки в товару немає історії покупок, він отримує обмежену частку показів поряд із схожими позиціями — цього достатньо, щоб набрати статистику й далі конкурувати зі старим асортиментом на рівних.
Актуальність наявності тримає окремий фільтр: рекомендація не показується, якщо залишок нульовий або товар знято з продажу. Фільтр працює на етапі видачі, а не під час навчання, тому повернення позиції в наявність одразу повертає її в підбірки — без перенавчання й ручних правок.
Стійкість рішення — у версіонуванні ваг і правил: будь-яку правку можна відкотити, а зміни спочатку перевіряються на частині трафіку.
Дивимося частку рекомендацій без залишку, частку новинок у показах і конверсію в допродаж — за цими метриками видно, де каталог і модель розійшлися.
Перезбирання підбірок іде частинами, за зачепленими категоріями, а повний перерахунок запускається за розкладом. Тому навіть різке оновлення асортименту не перетворюється на паузу в роботі блоку.
Часті технічні питання перед стартом проєкту
Перед стартом майже кожна команда проходить один список сумнівів: чи вистачить даних, як це ляже на поточну вітрину, чи не спишемо ми на рекомендації звичайне сезонне зростання і хто відповідає за систему після запуску.
Чи вистачить наших даних для навчання?
На вході потрібні історія замовлень і подій за клієнтами, довідник товарів із категоріями та ознаки сегмента. Якщо історії мало, стартуємо на правилах і поступово замінюємо їх моделлю — вітрина отримує рекомендації з першого дня.
Як проходить інтеграція з каталогом?
Підключаємося до вашого каталогу через програмний інтерфейс або регулярне вивантаження, саму вітрину не переносимо. Рекомендації віддаються в той самий блок, де клієнт бачить товари, — логіка оформлення замовлення не змінюється.
Як відокремити ефект від сезонності?
Порівнюємо контрольну й тестову групи в межах одного й того самого тижня: сезонний сплеск піднімає обидві однаково і віднімається сам. У звіті видно приріст середнього чека саме на рекомендаціях.
Що з безпекою даних?
Працюємо у вашому контурі або в ізольованому середовищі, персональні дані знеособлюються до навчання. Доступи видаються за ролями, дії фіксуються в журналі.
Скільки чекати запуску і що відбувається після?
Перша версія виходить в обмеженому сегменті за кілька тижнів, повний запуск — після перевірки метрик. Далі система на супроводі: стежимо за часткою показів, перенавчаємо за розкладом, розбираємо просадки.
Обговоримо задачу: з чого почнемо і що потрібно від вас
Розмову про старт проєкту корисніше вести від даних, а не від загальних побажань. Нижче — мінімум вхідних даних, якого достатньо, щоб ми повернулися з оцінкою термінів і планом робіт, а не з уточнювальними питаннями через тиждень.
- Вивантаження історії замовлень і кошиків: склад, суми, час, знеособлений ідентифікатор клієнта.
- Каталог з ознаками супутності: категорія, ціна, сумісність, що купують разом.
- Поточний сценарій допродажів: де показуються рекомендації, які правила задані вручну і чому.
- Цільова метрика: середній чек, частка замовлень із допродажем або повторні покупки — що вважаємо результатом.
- Обмеження: які системи не можна змінювати, вимоги до навантаження, хто приймає результат на вашому боці.
- Доступи: тестовий контур і доступ до вітрини даних, щоб перевіряти гіпотези на реальній поведінці.
Перший крок із нашого боку — розбір вивантаження й перевірка, чи вистачає історії для навчання рекомендацій на вашому асортименті. Далі повертаємося з планом робіт за етапами, оцінкою термінів і складом команди під кожен етап.
Якщо частини даних немає — це не блокер: підкажемо, як зібрати потрібний мінімум із найменшим втручанням у поточні процеси. Опишіть задачу — повернемося з оцінкою та планом.
