Зауважимо: коли після впровадження рекомендацій CTR не зростає, причина часто в поганому трекінгу подій. Багато розробників неправильно визначають перегляд товару: використовують viewDidAppear — і модель отримує зашумлені дані. Ми будуємо інфраструктуру, яка реально підвищує конверсію. Досвід — 5+ років у мобільній розробці, 30+ проєктів з рекомендаційними модулями. Гарантуємо дотримання App Store Review Guidelines та політик Google Play. Персоналізація в мобільному e-commerce — не просто тренд, а необхідність: без якісних рекомендацій до 70% користувачів ідуть з порожньою стрічкою. Правильна рекомендаційна система збільшує середній чек на 15–30% і утримання на 20%. Особливо складна ситуація з холодним стартом — коли в додатку мало даних про поведінку. У цьому випадку допомагають heuristics: популярні товари, редакційні добірки, гео-рекомендації.
Архітектура: з чого складається система
Рекомендаційна система складається з трьох шарів, і мобільний додаток бере участь у кожному.
Збір подій. Додаток генерує поведінкові сигнали: перегляд товару, додавання в кошик, покупка, час на екрані, свайп-скрол по стрічці. Ці події надсилаються до аналітичної системи (Amplitude, Mixpanel, Segment, власний Kafka-топік). Якість даних критична: якщо view_product спрацьовує при кожному скролі повз картку — модель отримує зашумлений сигнал. Для коректного impression-трекінгу використовуйте таймер видимості (див. код нижче).
Модель і офлайн-навчання. Персоналізація будується на основі collaborative filtering (за Wikipedia), content-based filtering за атрибутами товару або гібридних підходах. Для e-commerce з холодним стартом (нові користувачі, нові товари) чистий CF не працює — потрібні fallback-стратегії на основі атрибутів. Гібридний підхід дає на 20% більше точності порівняно з чистим CF.
Доставка рекомендацій. Мобільний додаток запитує рекомендації через API, отримує впорядкований список товарів. Тут важливі: час відповіді (< 200ms для inline-блоків), TTL кешу, деградація при недоступності сервісу. 95% uptime сервісу підтримується за рахунок CDN та Redis.
Чому трекінг подій — найвужче місце?
Найчастіше упущення — неправильне визначення «перегляду» товару. 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
На Android аналог — RecyclerView + кастомний OnScrollListener або ViewTreeObserver.OnGlobalLayoutListener з логікою Intersection Observer. Використовуйте бібліотеку `Transitions Everywhere` для плавної появи.Інтеграція 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 хвилин, вони мають враховувати поточну сесію.
Як забезпечити швидкість відповіді рекомендацій?
Час відповіді API — < 200ms для inline-блоків. Використовуємо CDN для статичних fallback-списків, Redis для кешу обчислених рекомендацій. На клієнті — попереднє завантаження наступного блоку при скролі. Якщо сервіс недоступний, показуємо редакційну добірку з локального конфігу. Вартість ліцензії на готовий сервіс розраховується індивідуально.
Холодний старт і fallback
Новий користувач — немає історії, немає вектора. Варіанти:
- Онбординг з вибором категорій інтересів → передаємо як початкові сигнали
- Популярні товари в категорії (editorial picks, не просто топ продажів)
- Geo-based recommendations (що купують у цьому регіоні)
Fallback при недоступності рекомендаційного сервісу: готовий статичний список «редакційна добірка» в конфігу або CDN.
A/B тестування
Система рекомендацій без A/B тесту — це віра в модель. Кожен новий алгоритм перевіряємо через Feature Flags (Firebase Remote Config, Unleash): 10% трафіку на нову модель, метрика — CTR рекомендаційного блоку та конверсія в покупку з attribution_window 7 днів. Для in-app purchases використовуємо StoreKit 2 на iOS та Google Play Billing 6 на Android. Порівняння підходів:
| Алгоритм | CTR | Конверсія | Холодний старт |
|---|---|---|---|
| Collaborative Filtering | 5% | 3% | Ні |
| Content-based | 4% | 2.5% | Так |
| Гібридний | 7% | 4.2% | Так |
Що входить у роботу
- Аудит поточного трекінгу подій та схеми даних
- Проєктування event schema: імена, параметри, контекст
- Інтеграція рекомендаційного API або розробка кастомної моделі
- Реалізація UI-компонентів: горизонтальний скрол, карусель, inline-блок з impression-трекінгом
- Налаштування кешування, fallback та офлайн-режиму
- A/B тестування та визначення метрик успіху
- Документація та навчання команди
Процес роботи
- Аудит поточного трекінгу подій: що вже збирається, що потрібно додати.
- Проєктування event schema: назви подій, обов'язкові параметри, контекст.
- Інтеграція рекомендаційного API або розробка моделі (якщо немає готового сервісу).
- Реалізація UI-компонентів: горизонтальний скрол, карусель, inline-блок, з коректним impression-трекінгом.
- Кешування, fallback при помилках, offline-режим.
- Налаштування A/B тестування, визначення метрик успіху.
- Передача документації та code review.
Орієнтири за термінами
Інтеграція готового рекомендаційного API в існуючий додаток — від 1 до 2 тижнів. Розробка системи з нуля, включаючи збір даних, модель, API та мобільну частину — від 2 до 3 місяців. Вартість розраховується індивідуально після аналізу поточного стеку та обсягу каталогу. Замовте аудит — ми оцінимо вашу систему та запропонуємо рішення. Отримайте консультацію щодо впровадження.