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

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Привіт! Я Андрій — Head of Products напрямку вживаних авто на AUTO.RIA, одному із продуктів української IT-компанії RIA.com для придбання та продажу авто. За весь час його існування ми максимально спрощували й покращували досвід користувача, а потреби перетворювати на функції.

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

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

Щоб шлях покупця був коротшим і легшим, ми йдемо довгою дорогою.

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

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

Глибинні інтервʼю — база, основа і далі за текстом, якщо треба виявити реальну потребу та зрозуміти, в яку сторону покращувати.

На другому етапі відбувається розробка макетів і прототипів із конкретними рішеннями. Ми знову повертаємося до наших користувачів/покупців і збираємо від них фідбек. Цей зворотний зв’язок допомагає нам поліпшувати прототипи та виявляти слабкі місця. Додатково ми проводимо кількісні дослідження. Це можуть бути розсилки зі стандартними для багатьох запитаннями: «Чим ви найчастіше користуєтесь?», «Чим не користуєтесь узагалі?» тощо. На основі фідбеку ми також розуміємо, де потрібно покращити сервіс, а де не чіпати, бо воно справді працює.

Також ми побудували цілу систему збору зворотного звʼязку на різних етапах користувацької взаємодії. Про неї далі.

Модерація

Це гібрид правил і ML. У місяць проходить ~780—970 тис. модерацій (25k+ щодня); ~93% — автоматично. Ядро складається з: текстового аналізу (контакти/лінки/спам-патерни), каскаду класифікаторів для фото (зокрема, підготовка до розпізнавання VIN та номерів), пошуку дублів, оцінки ринкової ціни (статистика + нейромережа), антифрод-графа зв’язків і 3-класового класифікатора на 100+ сигналів («пропустити / шахрай / передати на руки»). Люди закривають «важкий» хвіст і нові схеми обходу.

1. Масштаб і мета

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

2. Конвеєр модерації (від кліку «Опублікувати» до вердикту)

1. Збір сигналів. Підтягуємо все: текст оголошення, фото/відео, дані про користувача і його історію, технічні та мережеві атрибути (сеанси, пристрої, IP), контекстні довідники (моделі авто, роки випуску тощо).
2. Текстова перевірка. Модулі знаходять контакти (телефони, месенджери), зовнішні посилання і спам-побудови з урахуванням обфускацій; окремий класифікатор аналізує якість і «ризиковість» формулювань.
3. Фото-пайплайн. Для кожної фотографії працює каскад з десятка+ класифікаторів: тип сцени, документ/не документ, орієнтація, наявність номерного знака, водяні знаки, «скриншотність», ознаки поганої якості тощо. Це не лише про «заборонене» — ці класифікатори готують картинку до складніших кроків.
4. VIN та номерні знаки. Використовуємо ту саму ідею, що й у розпізнаванні номерів (наш open-source підхід у Nomeroff-Net): спочатку локалізація потрібної області, нормалізація, далі — OCR. Для VIN перед цим потрібно переконатися, що на фото саме документ чи його фрагмент і він вірно зорієнтований.
5. Оцінка ціни (AGV). Є базова статистична модель ринку за маркою/моделлю/роком та ін. + нейромережева модель, що враховує комплектації, пробіг, стан та інші «м’які» фактори. Сильно занижена/завищена ціна — вагомий тригер.
6. Антифрод-зв’язки. Будується граф відносин між оголошеннями, акаунтами, сеансами та адресами. Якщо нове оголошення технічно «споріднене» з відомими фейками — це окремий ризик-сигнал. Є чорні списки телефонів та ідентифікаторів клієнтів.
7. Інтеграція сигналів у рішення. Спочатку спрацьовують жорсткі правила (наприклад, контакти в описі). Далі вступає 3-класовий класифікатор на 100+ ознак з усіх попередніх кроків. На виході — одне з трьох: пропустити, шахрай, передати на руки.
8. Людська модерація. Для кейсів «на руки» інтерфейс показує зведення: які тригери спрацювали, які підозри по фото/тексту/ціні/зв’язках. Модератор приймає кінцеве рішення і, важливо — формує зворотний зв’язок для навчання моделей.

3. Виявлення «фейкових» оголошень: що реально працює

• Сітка технічних зв’язків. Фейкові «ферми» рідко ізольовані: повторюються пристрої, мережі, поведінкові патерни.
• Контентні патерни. Демасковані контакти в тексті, «надто добра» ціна, повторне використання одних фото, підроблені/нечитабельні номери.
• Ескалація наслідків. Після підтвердження шахрайства подія розноситься в граф: пов’язаним вузлам знижується довіра, нові оголошення з таких «кластерів» перевіряються жорсткіше.

4. Чому багато класифікаторів на кожне фото і навіщо це все

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

5. Як система приймає фінальний вердикт

• Правила: миттєво закривають очевидні порушення; забезпечують пояснюваність («не можна додавати посилання/контакти в описі»).
• Класифікатор на 100+ сигналів: підхоплює «сірі зони», де одиничного правила замало. Враховує одночасно текст, фотоознаки, ціну, історію користувача, зв’язки.
• Прозорість: у рішенні завжди фіксуються причини — що саме дало зелений/жовтий/червоний сигнал.

6. Що дає найбільший ефект проти фейків

• AGV із нейромережею — хапає «медові пастки» з нереалістичною ціною, навіть коли статистики мало.
• Граф зв’язків — дозволяє не «гасити пожежу» точково, а накривати цілі «клани».
• Текст + обфускації — ловимо контакти незалежно від розривів, альтернативних написань і «маскувань».

7. Де в цьому всьому люди і навіщо вони потрібні

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

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

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

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

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

Що ми збираємо

• Події взаємодії — пошукові запити, перегляди сторінок оголошень, кліки, додавання в обране, відкриття контактів; а також технічний контекст (платформа/застосунок/браузер). Самі по собі події — це «сировина» для моделей і профілю користувача.
• Атрибути оголошень — марка/модель/рік/пробіг/ціна/місто/стан/тип палива /кузов тощо. Це «фічі товару», за якими ми знаходимо схожі варіанти та узгоджуємо їх із профілем користувача.
• Технічні сигнали якості — інспектованість, наявність оригінальних фото, повнота заповнення, «свіжість» (час від публікації/оновлення). Вони впливають на видимість у стрічці навіть за однакової релевантності.

Як це працює

• База — колаборативна фільтрація (Collaborative Filtering, CF). Для кожного авто ми підтримуємо великий список «схожих» (top-N кандидатів на оголошення). Ідея проста: «користувачі, які цікавилися цим авто, часто дивилися ще ось ці» — отже, їх варто підсвітити. Це швидко дає «кістяк» рекомендацій.
• Candidate Generation (кандидати). Етап, де ми масово й швидко дістаємо потенційно релевантні оголошення (до ~1000 на «якір»). Це ще не фінальний порядок, а грубий відбір для подальшої роботи.
• Фільтри й профіль.

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

— Price Window («вікно ціни») — починаємо з невеликого відсоткового коридору відносно цільової ціни і за потреби поступово розширюємо, поки не наберемо мінімально потрібний набір. Так ми зберігаємо релевантність і не зносимо в топ «крайні» варіанти.

— User Profile (профіль користувача) — агрегований «портрет» інтересів за історією: міста/цінові діапазони/типи кузова/паливо тощо. Профілем ми коригуємо ранги: те, що краще пасує звичкам цього користувача, підіймаємо вище.

• Re-ranking (переранжування). Фінішне впорядкування кандидатів під конкретну людину. Тут, окрім профілю, працює:

— Freshness/Decay (свіжість/старіння) — експоненційне зменшення ваги з часом, щоб упереджувати новіші пропозиції й прибирати застаріле зі старту.

• Міксер. Ми зшиваємо кілька потоків у єдину стрічку з заданими пропорціями: вживані авто, нові авто. Міксер балансує релевантність vs новизну.
• Фотоперсоналізація. Ми класифікуємо всі фото (екстер’єр/салон/оптика/деталі) і як обкладинку підбираємо той тип кадру, на який сегмент користувачів, схожий на поточного, частіше клікає. Це дає стабільний плюс до CTR.

• Старт для нового користувача (Cold Start). Це ситуація, коли про користувача ще мало сигналів. Щоб не показувати «порожню» або надто вузьку стрічку, ми:

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

— Додаємо популярні за базовими фільтрами. Підтягуємо популярні пропозиції у типовому для регіону / категорії / цінового діапазону коридорі (без надспецифічних умов). Це «безпечний старт», який подобається більшості.

Навіщо це користувачу

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

Як ми підтримуємо якість

• A/B-тестування — паралельно порівнюємо конфіги/формули й прямо на трафіку дивимося, що працює краще (CTR, конверсії в контакти тощо).
• Швидкі реакції на події — якщо оголошення зняли/змінили, воно оперативно зникає зі «схожих» і зі стрічки, щоб не водити користувача колами.

UX-метрики як фундамент вдосконалення та оптимізації

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

У компанії застосовується Data Driven підхід, тому критично важливо, щоб обрані метрики були максимально якісними для оцінки ефективності. Для дослідження різноманітних гіпотез широко застосовується АВ-тестування, що дозволяє паралельно перевіряти кілька ініціатив та обирати найкращу.

Екосистема АВ-тестування містить сервіс розподілу, який дозволяє максимально точно та рівномірно розподіляти вибірки, адмін панель — для можливості керування АВ-тестами та мінімізації залучення технічних членів команди, а також систему аналітики, яка збирає метрики по всьому продукту та кожну з них мітить приналежністю до певного варіанту певного АВ-тесту (якщо корисувач в такий потрапив). Такий підхід дає можливість за потреби проаналізувати непрямий вплив нових ініціатив на продукт більш глибоко.

Як ми забезпечуємо швидку та зручну роботу сервісу на будь-якому пристрої — навіть офлайн

AUTO.RIA працює на мікросервісній архітектурі. Це дозволяє швидко масштабуватись з точки зору функціоналу та апскейлу в разі неочікуваних навантажень. Ми маємо кілька власних Kubernetes, які працюють в кількох датацентрах України. Вони вирішують питання доставки наших сервісів до користувачів (production deploy) в кілька кліків миш. А також автоматичного реагування на проблеми, які можуть виникати, — збільшення кількості подів потрібних сервісів, автоматичний рестарт тощо.

Сервіс постійно моніторить основні метрики сервісів та, в разі виникнення проблем, запускає процес швидкого реагування та вирішення. Це досягається каналами автоматичної комунікації про проблеми та присутності цілодобово онлайн чергових технічних спеціалістів. За допомогою Grafana ми збираємо інформацію про кожен наш мікросервіс щодо Memory Usage, Requests per pod, Response status rate, Request rate, Request weight, Response time та інше.

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

Високоновантажені сервіси реалізовані за принципом множинних деплоїв. Наприклад: сервер приймає аналітичні дані та виступає в ролі producer, які далі обробляються воркерами в ролі consumer. Відповідний зв’язок між ними забезпечується за допомогою message brokers (RabbitMQ / Apache Kafka). Таким чином ми не втрачаємо дані, навіть при технічних роботах на базах даних.

Для забезпечення потрібних функціональних можливостей використовуються найоптимальніші рішення з точки зору поставлених завдань. Наприклад, для забезпечення максимальної швидкодії та зменшення навантаження на сервіси застосовується кілька рівнів кешування: кеш браузера/застосунку, вебсервера/CDN, бекенд кешування (Memcached, Redis, KeyDB). Загалом парк баз даних доволі обширний і містить такі як MongoDB, Elasticsearch, ClickHouse, MariaDB, PostgreSQL та інші.

З точки зору адаптивності та кросплатформеності ми застосовуємо інноваційний підхід Server Driven UI. Це дозволяє керувати відображенням та функціональністю продукту на клієнтах цілісно та швидко. Наприклад, для зміни інтерфейсу в застосунку на екрані лістингу немає потреби випускати новий білд — всі потрібні інструкції прилітають з бекенду. Це також дає можливість тестувати різноманітні гіпотези шляхом АВ-тестів та керувати їх проходженням через спеціалізовану адмін-панель.

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

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