Колаборативна фільтрація для рекомендацій у мобільному додатку

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

Розробка та підтримка будь-яких видів мобільних додатків:

Інформаційні та розважальні мобільні програми
Новинки, ігри, довідники, онлайн-каталоги, погодні, фітнес та здоров'я, туристичні, освітні, соціальні мережі та месенджери, квіз, блоги та подкасти, форуми, агрегатори
Мобільні програми електронної комерції
Інтернет-магазини, B2B-додатки, маркетплейси, онлайн-обмінники, кешбек-сервіси, біржі, дропшиппінг-платформи, програми лояльності, доставка їжі та товарів, платіжні системи
Мобільні програми для управління бізнес-процесами
CRM-системи, ERP-системи, управління проектами, інструменти для команди продажів, облік фінансів, управління виробництвом, логістика та доставка, управління персоналом, системи моніторингу даних
Мобільні програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, платформи надання електронних послуг, платформи кешбеку, відеохостинги, тематичні портали, платформи онлайн-бронювання та запису, платформи онлайн-торгівлі

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

Послуги, які ми пропонуємо
Показано 1 з 1Усі 1734 послуг
Колаборативна фільтрація для рекомендацій у мобільному додатку
Складний
~2-4 тижні
Часті запитання

Колаборативна фільтрація для рекомендацій у мобільному додатку

Вступ

Уявіть: у вас 500 000 користувачів, каталог 100 000 товарів, а конверсія в рекомендаціях — лише 2%. Причина? Стандартні популярні товари не персоналізовані. Ми вирішуємо це завдання за допомогою колаборативної фільтрації (Collaborative Filtering, CF), яка аналізує матрицю взаємодій «користувач × товар» і видає персоналізовані результати. Жодної інформації про сам товар не потрібно — лише поведінкові сигнали. Саме тому CF працює там, де Content-Based пасує: у рекомендаціях одягу, книг, контенту з неструктурованими метаданими. Згідно з дослідженням Amazon, впровадження CF збільшує продажі на 20–30% у перші місяці. Наш досвід впровадження показує, що правильне налаштування ваг і A/B тестування дозволяють досягти стабільного приросту CTR на 30–50%.

Колаборативна фільтрація: технічна суть та основні складнощі

Matrix Factorization як основа

Класичний CF через dot-product пошуку найближчих сусідів не масштабується при >100K користувачів. Робочий підхід — розкладання матриці взаємодій на два embedding-простори: користувачі та товари представляються векторами фіксованої розмірності (зазвичай 64–256). Рекомендація — це пошук товарів, чиї ембеддинги найближчі до ембеддингу користувача.

Бібліотеки для тренування: Implicit (Python, спеціалізована на implicit feedback), LightFM (гібридний CF+content), RecBole (дослідницький фреймворк з 70+ алгоритмами). Для продакшн-деплою частіше обирають Implicit + FAISS для ANN-пошуку. За швидкістю Implicit у 3 рази швидший за LightFM на розріджених матрицях.

Бібліотека Тип даних Швидкість навчання Гнучкість Продакшен-готовність
Implicit Implicit/Explicit ★★★★★ ★★★ ★★★★★
LightFM Гібридний ★★★★ ★★★★★ ★★★★
RecBole Дослідницький ★★★ ★★★★ ★★★

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

Новий користувач без історії взаємодій — типовий cold start. Стандартне рішення: перші 5–10 взаємодій використовуємо правило «популярні товари з категорії інтересу» (onboarding flow з вибором уподобань). Після накопичення мінімальної історії перемикаємося на персоналізовану модель.

У коді це виглядає як стратегічний паттерн:

// Android: стратегія рекомендацій залежно від історії
interface RecommendationStrategy {
    suspend fun getRecommendations(userId: String, count: Int): List<Product>
}

class ColdStartStrategy(private val api: RecommendationApi) : RecommendationStrategy {
    override suspend fun getRecommendations(userId: String, count: Int) = api.getPopularByPreferences(userId, count)
}

class CFStrategy(private val api: RecommendationApi) : RecommendationStrategy {
    override suspend fun getRecommendations(userId: String, count: Int) = api.getPersonalized(userId, count)
}

class RecommendationRepository(private val api: RecommendationApi) {
    suspend fun getRecommendations(user: User): List<Product> {
        val strategy = if (user.interactionCount < 10) {
            ColdStartStrategy(api)
        } else {
            CFStrategy(api)
        }
        return strategy.getRecommendations(user.id, count = 20)
    }
}

Чому Implicit Feedback вигідніший за Explicit?

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

Схема ваг, яку використовуємо на практиці:

Дія Вага
Перегляд картки > 3 сек 1
Клік «детальніше» 3
Додавання в обране 5
Додавання в кошик 7
Купівля 10
Повернення -5

CF з правильними вагами дає приріст CTR на 30–50% порівняно з Content-Based за достатнього обсягу даних. В одному з проєктів для рітейлера одягу ми впровадили Implicit ALS з вагами, наведеними вище. Через 2 тижні A/B тесту CTR виріс на 40%, а конверсія в покупку — на 15%. Гарантуємо, що при ваших даних результат буде не нижче.

Логіювання подій на клієнті

Якість CF безпосередньо залежить від повноти та точності логіювання:

// iOS: логіювання взаємодій з точністю до часу перегляду
class ProductInteractionTracker {
    private var viewStartTime: Date?
    private let analytics: AnalyticsService

    func trackViewStart(productId: String) {
        viewStartTime = Date()
    }

    func trackViewEnd(productId: String) {
        guard let start = viewStartTime else { return }
        let duration = Date().timeIntervalSince(start)
        if duration > 3.0 {
            analytics.log(InteractionEvent(
                productId: productId,
                type: .view,
                weight: min(Int(duration / 3), 3),
                timestamp: start
            ))
        }
        viewStartTime = nil
    }

    func trackAddToCart(productId: String) {
        analytics.log(InteractionEvent(productId: productId, type: .addToCart, weight: 7))
    }
}

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

Serving: FAISS для ANN-пошуку ембеддингів

Навчена модель експортує ембеддинги товарів у FAISS-індекс. При запиті рекомендацій для користувача: отримуємо його ембеддинг → шукаємо K найближчих товарів у FAISS → фільтруємо вже куплені → повертаємо список. Latency при 1M товарів — 5–15 мс на сервері. FAISS пошук у 10 разів швидший за лінійний пошук для 1M товарів.

Архітектура serving на FAISS Індекс будується offline після навчання моделі. Для інференсу використовується REST API (Ktor/Kotlin або Vapor/Swift). При кожному запиті користувача його ембеддинг обчислюється на льоту або кешується. Пошук top-K виконується через `IndexIVFFlat` з nprobe=10 для швидкості. Результати пост-обробляються: видаляються вже куплені товари, застосовується бізнес-логіка (наприклад, різноманітність категорій).

Що входить в роботу

  1. Аудит даних: обсяг матриці взаємодій, спарсність, наявність cold start проблеми.
  2. Налаштування event-логіювання на клієнтах iOS/Android з урахуванням App Store Review Guidelines та Google Play Console.
  3. Навчання моделі (Implicit ALS або LightFM) на історичних даних.
  4. Розробка recommendation API + FAISS serving з використанням Ktor (Kotlin) або Vapor (Swift).
  5. A/B тест: CF-рекомендації vs популярні товари → вимірювання CTR та конверсії.
  6. Документація та навчання команди.
  7. Підтримка після запуску, моніторинг дрейфу даних.

Орієнтири за термінами

MVP з Implicit ALS + базовим serving — 2–3 тижні. Повна система з event-логіюванням, cold start fallback, A/B тестуванням та моніторингом — 6–8 тижнів. Вартість MVP: від $3 000, повна система: від $10 000. У нас понад 10 років досвіду в мобільній розробці, і ми гарантуємо прозорий процес з регулярними демо.

Підніміть конверсію рекомендацій — отримайте консультацію нашого інженера з налаштування CF під ваші дані. Замовте аудит матриці взаємодій — ми оцінимо потенціал. Зв'яжіться з нами для старту проєкту.

Наші компетенції:

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

  • Розробка мобільного додатка для компанії FEEDME
    Розробка мобільного додатка для компанії FEEDME
    1010
  • Розробка мобільного додатку для компанії XOOMER
    Розробка мобільного додатку для компанії XOOMER
    903
  • Розробка мобільного додатку для компанії RHL
    Розробка мобільного додатку для компанії RHL
    1332
  • Розробка мобільного додатку для компанії ZIPPY
    Розробка мобільного додатку для компанії ZIPPY
    1180
  • Розробка мобільного додатку для компанії Affhome
    Розробка мобільного додатку для компанії Affhome
    1107
  • Розробка мобільного додатку для компанії FLAVORS
    Розробка мобільного додатку для компанії FLAVORS
    714