Рекомендательные системы в приложении: персонализация каталога и рост конверсии

Рекомендательная система — это модуль приложения, который анализирует поведение пользователя и вместо общего каталога показывает ему персональную подборку товаров, услуг или контента. В Казахстане внедрение стоит от 1,8 до 12 млн ₸ в зависимости от алгоритма и объёма данных, а окупается за счёт роста конверсии, среднего чека и удержания.

Зачем приложению рекомендации: экономика вопроса

Каталог на 5 000 позиций бесполезен, если пользователь видит первые двадцать. Мобильный экран — это 3–4 карточки товара без скролла, и борьба идёт именно за них. Когда на этих позициях оказывается то, что человек с высокой вероятностью купит, метрики меняются по всей воронке: растёт глубина просмотра, добавления в корзину, повторные сессии.

Для бизнеса в Казахстане это особенно актуально в трёх сценариях:

• E-commerce и маркетплейсы — блоки «Похожие товары», «С этим покупают», персональная главная. Самый прямой путь поднять средний чек без увеличения рекламного бюджета.
• Доставка еды и продуктов — повторный заказ в два тапа: система помнит привычки и собирает корзину заранее. Здесь рекомендации работают на частоту заказов.
• Контент и сервисы — лента, подборки, push-уведомления с релевантным содержимым. Цель — удержание: пользователь, которому «попадают в интерес», реже удаляет приложение.

Важно понимать: рекомендации — не виджет, который «прикручивается» за неделю. Это связка из сбора данных, алгоритма и интерфейса, и слабое звено в любой из трёх частей обнуляет результат. Поэтому мы проектируем такие модули как часть архитектуры при разработке мобильных приложений, а не как надстройку постфактум.

Три подхода к рекомендациям — и когда какой выбирать

Контентная фильтрация (content-based)

Система сравнивает атрибуты товаров: категорию, бренд, цену, теги, описание. Пользователь смотрел беговые кроссовки — получает похожие модели и сопутствующую экипировку. Подход работает с первого дня, не требует истории покупок и большой аудитории. Минус — «пузырь»: система предлагает только похожее на уже просмотренное и не открывает пользователю новые категории.

Коллаборативная фильтрация (collaborative filtering)

Алгоритм ищет пользователей с похожим поведением и рекомендует то, что выбирали «соседи по вкусу». Именно так работают блоки «С этим товаром покупают». Подход даёт неожиданные и точные попадания, но требует данных: при базе меньше нескольких тысяч активных пользователей матрица взаимодействий слишком разрежена, и качество падает.

Гибридные модели

На практике мы почти всегда строим гибрид: контентная фильтрация закрывает «холодный старт» для новых пользователей и товаров, коллаборативная включается по мере накопления истории, а поверх работают бизнес-правила — приоритет маржинальных позиций, исключение товаров не в наличии, сезонные подборки. С 2024–2025 годов к этому добавились эмбеддинги на базе языковых моделей: описание товара превращается в числовой вектор, и «похожесть» считается по смыслу, а не по совпадению тегов. Для каталогов с плохо структурированными карточками это снимает половину проблем.

Персонализация каталога: что меняется в интерфейсе

Алгоритм — половина дела. Вторая половина — где и как рекомендации встроены в приложение. Рабочие точки размещения:

• Персональная главная — первый экран собирается под пользователя: его категории, его ценовой сегмент, незавершённые сценарии («вы смотрели», «в корзине осталось»).
• Карточка товара — «похожие» и «дополняющие» блоки. Дополняющие (чехол к телефону, соус к пицце) дают больший прирост чека, чем похожие.
• Корзина и чекаут — аккуратный блок «добавить к заказу» с недорогими позициями. Здесь важна сдержанность: агрессивный апселл на чекауте роняет конверсию оплаты.
• Поиск — персональное ранжирование выдачи: два пользователя по одному запросу «куртка» видят разный порядок результатов.
• Push и e-mail — рекомендательный движок переиспользуется для триггерных сценариев: брошенная корзина, снижение цены на просмотренное, пополнение привычного заказа.

Отдельный пласт — голосовой и визуальный ввод. Если пользователь ищет товар по фото, система компьютерного зрения распознаёт объект, а рекомендательный модуль достраивает выдачу — как это устроено, мы разбирали в статье про компьютерное зрение в мобильном приложении. Аналогично с голосом: связка распознавания речи в приложении и персонального ранжирования превращает запрос «закажи как обычно» в готовую корзину.

Какие данные нужны и как их собирать

Качество рекомендаций определяется данными, а не выбором модели. Минимальный набор событий, который мы закладываем в трекинг:

• просмотры карточек и время на них;
• добавления в корзину и избранное, удаления из корзины;
• покупки с составом заказа, суммой и временем;
• поисковые запросы, включая закончившиеся пустой выдачей;
• реакции на сами рекомендации — показы, клики, скрытия.

Последний пункт критичен: без логирования показов невозможно посчитать CTR блоков и честно оценить, работает ли система. Вторая обязательная часть — чистый каталог: заполненные атрибуты, корректные категории, актуальные остатки. По нашему опыту, на проектах со «старым» каталогом заметная часть бюджета внедрения уходит именно на приведение данных в порядок — и это окупаемая работа.

С точки зрения закона поведенческие данные в Казахстане подпадают под требования о персональных данных: нужны согласие в политике конфиденциальности, обезличивание идентификаторов в аналитике и понятная процедура удаления профиля по запросу. Мы закладываем это на этапе проектирования, а не после претензий.

Сколько стоит рекомендательная система в Казахстане

Вилки актуальны для рынка КЗ на 2026 год и зависят от трёх факторов: размер каталога, объём аудитории и требование к скорости реакции — пересчёт раз в сутки или в реальном времени.

К этому добавляется инфраструктура: сервер под модель и хранилище событий обходятся в 40 000–150 000 ₸ в месяц в зависимости от нагрузки. Если брать готовые облачные движки по подписке, разработка дешевле, но ежемесячный платёж привязан к числу запросов и на растущем трафике быстро обгоняет стоимость собственного решения — этот расчёт мы делаем до старта, а не после первого счёта.

Этапы внедрения: как мы это делаем

1. Аудит данных и каталога (1–2 недели). Проверяем, что уже логируется, в каком состоянии атрибуты товаров, хватает ли истории для коллаборативных методов. На выходе — выбор подхода и метрики успеха.
2. Трекинг событий. Достраиваем сбор недостающих событий. Если истории нет, базовый уровень на контентной фильтрации запускаем сразу — он не ждёт накопления данных.
3. Модель и API. Обучение, офлайн-проверка качества на исторических данных, вынос рекомендаций в отдельный сервис с быстрым API — приложение получает подборку за десятки миллисекунд.
4. Интеграция в интерфейс. Блоки на главной, в карточке, в корзине; обязательное логирование показов и кликов.
5. A/B-тест. Часть аудитории видит рекомендации, часть — прежний каталог. Решение о раскатке принимается по конверсии и среднему чеку, а не по ощущениям.
6. Дообучение и сопровождение. Модель регулярно переобучается, бизнес-правила корректируются под сезон и ассортимент.

Типичные ошибки, которые мы видим на входящих аудитах: запуск без логирования показов (нечем мерить эффект), рекомендации товаров не в наличии, одинаковые подборки для всех новичков вместо опоры на первую же сессию и перегрузка интерфейса — когда блоков с подборками больше, чем самого каталога.

Почему Applications.kz

Мы разрабатываем мобильные продукты с 2007 года — за это время команда выпустила более 300 проектов для рынков Казахстана, ОАЭ и Таиланда. Рекомендательные модули строим внутри собственной разработки: один подрядчик отвечает и за приложение, и за данные, и за модель, поэтому не возникает классического разрыва «ML-команда сделала, мобильная не интегрировала». Офис — в Алматы, работаем по всему Казахстану; директор студии Иван Калита лично участвует в постановке архитектуры сложных проектов. Если нужна команда полного цикла — посмотрите страницу о разработке мобильных приложений в Алматы.

Пришлите описание задачи на +7 (707) 928-13-15 — посчитаем смету за 24 часа с разбивкой по этапам и честной оценкой, какой уровень персонализации оправдан именно для ваших данных.

Частые вопросы

Сколько данных нужно, чтобы рекомендации заработали?

Контентная фильтрация работает с первого дня — ей достаточно атрибутов каталога. Коллаборативным методам нужна история: ориентир — от 3–5 тысяч активных пользователей и десятков тысяч событий. Поэтому мы запускаем систему поэтапно: сначала правила и «похожие товары», затем, по мере накопления данных, подключаем ML-уровень без переделки интерфейса.

Можно ли взять готовый сервис вместо своей разработки?

Можно, и для проверки гипотезы это разумно. Но облачные движки тарифицируются за запросы: на растущем трафике подписка за год сравнивается со стоимостью собственного модуля, а поведенческие данные ваших клиентов уходят на сторону. Мы считаем обе модели в смете и рекомендуем по цифрам, а не по умолчанию «своё».

Как измерить, что рекомендации действительно подняли конверсию?

Только A/B-тестом: часть пользователей видит персональные блоки, контрольная группа — обычный каталог. Сравниваем конверсию в покупку, средний чек, CTR блоков и долю выручки через рекомендации. Замер «до и после» без контрольной группы не годится — на метрики влияют сезон, реклама и ассортимент.

Что делать с новыми пользователями, о которых ничего не известно?

Это «холодный старт», и он решается каскадом: до первого действия показываем популярное в регионе и сезонные подборки, после двух-трёх просмотров включается контентная фильтрация по текущей сессии, а с накоплением истории — персональная модель. Уже первая сессия даёт достаточно сигнала, чтобы выдача отличалась от общей.

Сколько стоит поддержка рекомендательной системы после запуска?

Закладывайте 150 000–400 000 ₸ в месяц: инфраструктура, мониторинг качества, регулярное переобучение модели и корректировка бизнес-правил под ассортимент. Без сопровождения качество деградирует за несколько месяцев — каталог и поведение аудитории меняются, а модель остаётся в прошлом.