Розроблення системи рекомендацій товарів у мобільному додатку
Рекомендаційна система — це не просто «з цим товаром часто купують». Це інфраструктура, яка збирає поведінкові сигнали, навчає модель й доставляє персоналізований результат у потрібний момент. Без правильно виробленого трекінгу подій модель буде рекомендувати популярні товари замість релевантних — й різниці з «топ продаж» користувач не почує.
Архітектура: з чого складається система
Рекомендаційна система складається з трьох шарів, й мобільний додаток бере участь у кожному.
Збір подій. Додаток генерує поведінкові сигнали: перегляд товара, додавання в кошик, покупка, час на екрані, свайп-скролл по ленті. Ці події надсилаються в аналітичну систему (Amplitude, Mixpanel, Segment, власний Kafka-топік). Якість даних критична: якщо view_product стріляє при кожному скролі мимо карточки — модель отримує зашумлений сигнал.
Модель та оффлайн-навчання. Collaborative filtering (Matrix Factorization, ALS), content-based filtering за атрибутами товара, або гібридні підходи. Для e-commerce з холодним стартом (нові користувачи, нові товари) чистий CF не працює — потрібні fallback-стратегії на основі атрибутів.
Доставка рекомендацій. Мобільний додаток запрошує рекомендації через API, отримує впорядкований список товарів. Тут важливі: час відповіді (< 200ms для inline-блоків), TTL кеша, деградація при недоступності сервісу.
Трекінг подій у мобільному додатку
Найчастіше упущення — неправильне визначення «перегляду» товара. viewDidAppear на екрані товара стріляє раніше, ніж користувач реально побачив контент. Для impression-трекінгу в списку використовуємо UICollectionView.indexPathsForVisibleItems з таймером:
// iOS: считаємо impression тільки якщо товар видно > 1 секунди
private var impressionTimers: [IndexPath: Timer] = [:]
func collectionView(_ collectionView: UICollectionView,
willDisplay cell: UICollectionViewCell,
forItemAt indexPath: IndexPath) {
let timer = Timer.scheduledTimer(withTimeInterval: 1.0, repeats: false) { [weak self] _ in
guard let product = self?.products[indexPath.item] else { return }
Analytics.track(.productImpression(productId: product.id, source: .recommendations))
}
impressionTimers[indexPath] = timer
}
func collectionView(_ collectionView: UICollectionView,
didEndDisplaying cell: UICollectionViewCell,
forItemAt indexPath: IndexPath) {
impressionTimers[indexPath]?.invalidate()
impressionTimers.removeValue(forKey: indexPath)
}
На Android аналог — RecyclerView + кастомний OnScrollListener або ViewTreeObserver.OnGlobalLayoutListener з Intersection Observer логікою.
Інтеграція API рекомендацій
Рекомендації бувають кількох типів з різними точками інтеграції:
| Тип | Місце в UI | Контекст запиту |
|---|---|---|
| Homepage feed | Головний екран | user_id |
| Similar items | Екран товара | product_id, user_id |
| Cross-sell | Кошик | cart_items[], user_id |
| Post-purchase | Екран «Дякуємо» | order_id, user_id |
Для кожного типу — окремий endpoint або параметр placement. Не один універсальний запит «дай мені рекомендації».
Кеширование: рекомендації головної сторінки кешуються на 30–60 хвилин (NSCache на iOS, Room + WorkManager на Android для фонової підгрузки). Рекомендації на екрані товара — не кешуємо або з TTL 5 хвилин, вони повинні враховувати поточну сесію.
Холодний старт та fallback
Новий користувач — нема історії, нема вектора. Варіанти:
- Онбординг з вибором категорій інтересів → передаємо як початкові сигнали
- Популярні товари в категорії (editorial picks, не просто топ продаж)
- Geo-based recommendations (що купують у цьому регіоні)
Fallback при недоступності рекомендаційного сервісу: готовий статичний список «редакційна підборка» в конфігу або CDN.
A/B тестування
Система рекомендацій без A/B тесту — це віра в модель. Кожен новий алгоритм перевіряємо через Feature Flags (Firebase Remote Config, Unleash): 10% трафіку на нову модель, метрика — CTR рекомендаційного блоку та конверсія в покупку з attribution_window 7 днів.
Процес роботи
Аудит поточного трекінгу подій: що вже збирається, що потрібно додати.
Проектування event schema: імена подій, обов'язкові параметри, контекст.
Інтеграція рекомендаційного API або розроблення моделі (якщо нема готового сервісу).
Реалізація UI-компонентів: горизонтальний скролл, карусель, inline-блок, з коректним impression-трекінгом.
Кеширование, fallback при помилках, offline-режим.
Налаштування A/B тестування, визначення метрик успіху.
Орієнтири по термінам
Інтеграція готового рекомендаційного API в існуючий додаток — 1–2 тижні. Розроблення системи з нуля включаючи збір даних, модель, API й мобільну частину — 2–3 місяці. Вартість розраховується індивідуально після аналізу поточного стека й обсягу каталогу.