AI-персоналізація рекомендацій автомобілів для автодилерів

Клієнт не знаходить відповідної комплектації в каталозі та йде без запису — заявки губляться на етапі підбору. Ми розробляємо AI-персоналізацію рекомендацій автомобілів під ключ: від аналізу даних дилера до запуску моделі й супроводу. У результаті шлях клієнта до пробної поїздки стає коротшим, а частка записів зростає.
Часті запитання

Чому AI для автодилерів не підвищує конверсію підбору

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

Клієнт приходить з іншим питанням — «просторий сімейний на кожен день», «компактний для коротких поїздок містом», — але інтерфейс запитує про характеристики, а не про сценарій використання.

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

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

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

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

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

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

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

Що змінюється після впровадження персоналізації підбору

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

Конверсія з підбору в запис на пробну поїздку

Тут рахують не візити, а частку влучань в інтерес: скільки сесій доходять до картки з підбірки та до запису на пробну поїздку.

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

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

Швидкість підбору й навантаження на менеджерів

Другий ефект — час до осмисленого списку кандидатів. Раніше клієнт приходив із запитом «покажіть щось у цьому класі», і зустріч ішла на з'ясування потреби. Тепер на вході є дві-три моделі з зрозумілими критеріями, і менеджер обговорює умови.

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

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

Формати персоналізації: порівняння підходів та обмежень

Ручні правила та фільтри каталогу

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

Модель на історії угод проти гібридної схеми

Модель на історії угод знаходить неочевидні зв'язки між комплектаціями, але сліпа до новинок складу та різких зсувів попиту — поки за позицією немає угод, вона у видачі не з'явиться.

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

Варіант Коли підходить Обмеження
Ручні правила та фільтри каталогу Невеликий склад, стійкий попит, потрібна пояснюваність кожної рекомендації Правила конфліктують зі зростанням каталогу, новинки й сезонність правляться вручну
Модель лише на історії угод Угоди накопичені за тривалий період, попит змінюється повільно Холодний старт за новими позиціями, немає реакції на відмову в моменті
Гібридна схема зі зворотним зв'язком Великий каталог, висока частота звернень, важлива реакція всередині сесії Потрібна розмітка подій і контроль якості даних, складніше налагодження

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

Як ми впроваджуємо рекомендаційну систему: етапи робіт

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

Аудит даних і постановка метрики

  1. Аудит даних. Звіряємо каталог (марка, кузов, комплектація, привід, пробіг), історію угод, звернення в CRM, записи на тест-драйв і причини відмов. Шукаємо дублі та розбіжності в кодах комплектацій. На виході — карта придатності даних і список того, що потрібно дозаповнити.
  2. Схема даних. Збираємо єдиний профіль клієнта й автомобіля, фіксуємо ключі зв'язку між стоком, CRM і каналом показу. Пропуски закриваємо явними правилами, а не здогадками.
  3. Налаштування видачі. Визначаємо сигнали, що рухають картку вгору: бюджет, тип кузова, термін володіння попередньою машиною, історія сервісних візитів. Комерційні пріоритети дилера задаємо окремими вагами — їх змінюють без перенавчання.
  4. Метрики якості підбору. Фіксуємо до запуску: частка сесій з відкриттям трьох і більше карток, частка записів на тест-драйв із підбірки, частка відмов через нерелевантну ціну. Базовий рівень рахуємо на історичних даних, інакше порівнювати буде нема з чим.

Перевірка на живому трафіку та передача

  • Тіньовий запуск рекомендацій. Система будує видачу паралельно з поточною, відвідувач бачить попередній варіант. Порівнюємо на одних і тих самих сесіях і знімаємо розбіжності до того, як вони торкнуться клієнтів.
  • Розгортання на живому трафіку. Вмикаємо підбір частками: спочатку на частині відвідувачів, стежимо за метриками, при відхиленні відкочуємо на попередню видачу.
  • Передача системи замовнику. Віддаємо доступи й ролі, регламент розбору спірних видач, навчаємо співробітників відділу продажів. Далі дилер сам змінює ваги й додає сигнали.

Що передаємо автодилеру: моделі, схеми даних, регламенти

Передача системи — це не бінарний факт «у нас працює». Дилер отримує модель, схему даних каталогу, регламенти та правила доступу — те, за чим підбір можна розвивати самостійно.

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

Схема даних і правила перенавчання

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

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

Кейс: як зросла частка записів на пробну поїздку

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

Персоналізацію зібрали на подіях сесії: перегляди карток, порівняння, застосовані фільтри, збережені підбірки. За ними рахуємо профіль уподобань — тип кузова, коробка, привід, діапазон пробігу, бюджетна смуга — і переранжовуємо каталог, блок «схожі» та підбірки в листі.

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

Що змінилося в поведінці клієнтів

  • Частка підборів, що завершилися записом на тестову поїздку — з 2,4% до 7,1% сесій з активним підбором. Зростання дали не банери, а порядок видачі: потрібна комплектація потрапляла в перші картки.
  • Глибина перегляду каталогу — з 7 до 15 карток за сесію. Прискорення завдяки тому, що відсів за нерелевантними кузовами й коробками знімався до гортання.
  • Частка повернень до незавершеного підбору протягом тижня — з 11% до 27%. Збережений профіль підтягується в новій сесії, тому клієнт продовжує з того місця, де зупинився, а не починає заново.

Результат впровадження міряли на контрольній групі, а не порівнянням «до і після»: половина трафіку бачила базове ранжування, тому сезонні сплески попиту не приписали персоналізації.

Для сесій без історії працює холодний старт на агрегованих уподобаннях майданчика, а вимкнення профілю повертає звичайне сортування — відкат не потребує перезбирання каталогу.

Чим відрізняється рекомендаційна модель від фільтрів каталогу

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

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

На виході — не бінарний відбір «підходить/не підходить», а порядок, у якому каталог показує найімовірніший наступний крок клієнта.

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

Так закривається холодний старт, а онлайн-поведінка пов'язується з фактами угод з облікових систем дилера (1С, CRM), а не лише з кліками.

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

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

Критерій приймання — частка сесій, де відкрито рекомендований автомобіль, глибина перегляду, конверсія в тест-драйв саме за цими сесіями. Якщо зсуву немає, блок вимикається одним перемикачем, і сайт працює як раніше.

Часті технічні питання про рекомендаційні системи

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

Скільки історії угод потрібно, щоб рекомендації запрацювали?

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

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

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

Як вирішується холодний старт нового клієнта?

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

Чи можна впровадити без зупинки продажів?

Так. Рекомендаційний сервіс підключається до каталогу та облікової системи збоку й не втручається в поточні процеси.

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

Як зрозуміти, що модель деградує?

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

Обговоримо задачу: дані, інтеграції, критерії приймання

Оцінка та план робіт із персоналізації сп

Напрямки AI-розробки

Останні роботи

  • Розробка сайту компанії B2B ADVANCE
    Розробка сайту компанії B2B ADVANCE
    1543
  • Розробка веб-додатків для компанії FEEDME
    Розробка веб-додатків для компанії FEEDME
    1394
  • Розробка веб-сайту для компанії БЕЛФІНГРУП
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    1081
  • Розробка інтернет магазину для компанії FURNORO
    Розробка інтернет магазину для компанії FURNORO
    1374
  • Розробка логотипу компанії B2B Advance
    Розробка логотипу компанії B2B Advance
    816
  • Розробка веб-додатків для компанії Enviok
    Розробка веб-додатків для компанії Enviok
    1142