Отметим: когда после внедрения рекомендаций CTR не растёт, причина часто в плохом трекинге событий. Многие разработчики неправильно определяют просмотр товара: используют viewDidAppear — и модель получает зашумленные данные. Мы строим инфраструктуру, которая реально повышает конверсию. Опыт — 5+ лет в мобильной разработке, 30+ проектов с рекомендательными модулями. Гарантируем соблюдение App Store Review Guidelines и политик Google Play. Персонализация в мобильном e-commerce — не просто тренд, а необходимость: без качественных рекомендаций до 70% пользователей уходят с пустой лентой. Правильная рекомендательная система увеличивает средний чек на 15–30% и удержание на 20%. Особенно сложна ситуация с холодным стартом — когда у приложения мало данных о поведении. В этом случае помогают heuristics: популярные товары, редакционные подборки, гео-рекомендации. Стоимость готового рекомендательного API (например, Firebase Predictions) начинается от 50 000 руб./мес. Разработка собственной модели с нуля обойдётся в 2–5 раз дороже, чем интеграция готового решения, и может потребовать бюджета от 1,5 млн руб.
Архитектура: из чего состоит система
Рекомендательная система состоит из трёх слоёв, и мобильное приложение участвует в каждом.
Сбор событий. Приложение генерирует поведенческие сигналы: просмотр товара, добавление в корзину, покупка, время на экране, свайп-скролл по ленте. Эти события отправляются в аналитическую систему (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 для кеша вычисленных рекомендаций. На клиенте — предзагрузка следующего блока при скролле. Если сервис недоступен, показываем редакционную подборку из локального конфига. Стоимость лицензии на готовый сервис составляет от 50 000 руб./мес., что значительно дешевле собственной разработки.
Холодный старт и 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 месяцев. Стоимость рассчитывается индивидуально после анализа текущего стека и объёма каталога. Закажите аудит — мы оценим вашу систему и предложим решение. Получите консультацию по внедрению.