Рекомендательная система: как она устроена и когда окупается
Блок «с этим покупают» ставится за неделю. Через месяц у него хороший CTR, а выручка не изменилась, потому что блок продаёт то, что человек и так положил бы в корзину. Мы в Code Pilots делаем сервисы на своих моделях, и первое, что считаем в таких проектах, — порог, ниже которого затея не окупается.
Если совсем коротко. Рекомендательная система состоит из четырёх частей. Данные о поведении, модель, бизнес-правила поверх модели и эксперимент, который показывает прирост. Модель здесь самая маленькая часть работы.
Порог входа считается в четыре множителя. Выручка, маржа, ожидаемый прирост и срок, за который проект должен вернуться.
Что решает рекомендательная система и где она стоит
Одной рекомендательной системы не существует. Есть набор мест, и у каждого своя задача.
| Место | Задача | Чем мерить |
|---|---|---|
| Карточка товара, «похожие» | Не потерять человека, если товар не подошёл | Доля переходов, закончившихся покупкой другого товара |
| Карточка товара, «с этим покупают» | Добавить позицию в заказ | Число товаров в заказе |
| Корзина и оформление | Допродать мелочь и аксессуары | Средний чек |
| Главная и подборки | Дать вход в каталог тем, кто пришёл без запроса | Доля сессий с переходом в каталог |
| Поиск и категория | Поднять наверх то, что человек купит | Конверсия из выдачи в заказ |
| Письма и пуши | Вернуть человека, который ушёл | Выручка на отправленное письмо |
Разница между этими местами принципиальная. На карточке система работает с одним товаром и почти без истории человека, в письме — наоборот, с историей и без контекста текущей сессии. Одна модель на все шесть мест не подходит, и это первое, что выясняется на проекте.
Сама витрина при этом остаётся обычной задачей. Блоки, шаблоны и скорость отдачи делаются как всегда. Как устроен интернет-магазин с большим каталогом, мы разбирали отдельно; рекомендации — надстройка над этой витриной.
Данные: без событий ничего не работает
Модель учится на поведении, поэтому проект начинается с проверки, есть ли на чём учиться.
Явные сигналы. Оценки, отзывы, избранное, подписки. Их мало, зато они честные.
Неявные сигналы. Просмотры, время на карточке, добавления в корзину, покупки, возвраты. Их много, и они шумные: человек открыл карточку и ушёл, потому что цена не подошла.
Атрибуты товара. Категория, бренд, цена, характеристики, картинки, текст описания. Без них не работают рекомендации для новых товаров.
Отдельная работа — склейка человека. До входа в аккаунт он опознаётся по браузеру, после входа — по идентификатору, и на телефоне это третий след. Если истории не сшиваются, модель видит трёх разных людей вместо одного и рекомендует каждому с нуля.
Практическая проверка перед проектом одна. Собираете ли вы события с идентификатором пользователя, живут ли они дольше одной сессии и хватает ли их по объёму. Магазин с тремя тысячами заказов в месяц накопит статистику по большинству товаров за годы, и это само по себе ответ.
Отдельно про возвраты. Если модель учится на покупках и не знает о возвратах, она уверенно рекомендует то, что люди чаще всего возвращают.
Алгоритмы от простого к сложному
Четыре уровня, и каждый следующий дороже предыдущего. Двигаться имеет смысл по порядку.
| Уровень | Как работает | Когда достаточно |
|---|---|---|
| Популярное | Топ по категории, иногда с учётом сезона | Малый каталог, мало данных; это базовая линия, с которой сравнивают всё остальное |
| Похожие по атрибутам | Сравнение по категории, бренду, цене, характеристикам | Новые товары, узкий каталог, отсутствие истории |
| Совместные покупки | «С этим товаром чаще берут» по истории заказов | Есть поток заказов; даёт быстрый эффект в корзине |
| Коллаборативная фильтрация и векторные модели | Похожие пользователи и похожие товары в общем пространстве признаков | Большой каталог и большая история; здесь появляется настоящая персонализация |
Практика такая. Первые два уровня закрываются обычной разработкой и справочниками, третий — расчётом по истории заказов, и только четвёртый требует машинного обучения с обучением, версионированием и переобучением моделей.
Правильный порядок работ — сравнивать каждый следующий уровень с предыдущим на эксперименте. Если совместные покупки не переигрывают популярное, векторные модели тем более не окупятся.
Холодный старт
Проблема, которую в учебниках называют, а в проекте решают конкретными правилами.
Новый пользователь. Истории нет, значит показываем популярное по категории входа, а по ходу сессии подмешиваем то, что человек уже посмотрел. Первые релевантные рекомендации появляются после двух-трёх карточек.
Новый товар. Покупок нет, поэтому работают только атрибуты и текст описания. Товар подставляется в блоки «похожие» по признакам, а в «с этим покупают» попадает после первых заказов.
Новая категория или новый сезон. Прошлогодняя статистика тут скорее мешает. Здесь нужен либо ручной вес категории, либо явное окно давности событий.
Каждый из трёх случаев обязан иметь заранее решённый ответ. Иначе на новых товарах блок остаётся пустым, а пустой блок ломает вёрстку и доверие к разделу.
Бизнес-правила поверх модели
Здесь и живёт разница между работающим блоком и демонстрацией алгоритма. Модель предлагает список, правила решают, что из него можно показать.
- Наличие и срок доставки. Товар без остатка не рекомендуется, даже если он идеально подходит.
- Уже купленное. Человек, купивший холодильник, не должен видеть холодильники месяц.
- Маржа и приоритеты. При равной релевантности выше поднимается то, что выгоднее продать.
- Ограничения по категориям. Возрастные товары, рецептурные позиции, крупногабаритные наборы — у каждого свои правила показа.
- Разнообразие. Шесть почти одинаковых позиций в блоке выглядят как ошибка, поэтому в выдачу вводят ограничение на бренд и на ценовой диапазон.
- Персональные условия. Если у покупателя своя цена или свой уровень в программе, подборка обязана это учитывать; механика самих программ разобрана в материале про системы лояльности.
Правила меняются чаще моделей, поэтому их выносят в настройки с интерфейсом. Правило, зашитое в код, превращает каждое изменение приоритета в релиз.
Отклик и запасной вариант
Блок рекомендаций стоит на карточке товара, то есть на самой посещаемой странице магазина. Из этого следуют два жёстких требования.
Первое — бюджет времени. У блока есть десятки миллисекунд, и модель в этот бюджет не укладывается, если считать всё в момент запроса. Рабочая схема — считать кандидатов заранее и складывать их в быстрое хранилище, а в момент запроса только фильтровать по правилам и подмешивать поведение текущей сессии.
Второе — поведение при отказе. Сервис рекомендаций недоступен, и страница обязана отдаться без него: блок либо показывает популярное из кэша, либо не показывается вовсе. Требования к такому поведению — общая история для любого нагруженного продукта, она разобрана в материале про высоконагруженные системы.
Кандидатов обычно держат отдельным набором на каждое место размещения — по одному списку на карточку, на корзину, на письмо. Пересчитывают их по расписанию, а на горячих товарах чаще. Такой набор занимает немного места и снимает с онлайна всю тяжёлую работу.
Третье требование мягче, но про него забывают: рекомендации должны обновляться. Модель, обученная в марте, к августу рекомендует прошлую коллекцию. Переобучение — это регламент с расписанием, приёмкой и откатом на прошлую версию.
Что мерить и как не обмануться
Главная ловушка темы. CTR блока растёт, выручка стоит, и обе цифры честные.
| Метрика | Что показывает | Почему обманывает |
|---|---|---|
| CTR блока | Заметность и привлекательность | Клик по товару, который человек нашёл бы и сам |
| Конверсия после клика | Качество попадания | Не отличает добавленную покупку от перенесённой |
| Товаров в заказе | Работу допродажи | Легко испортить скидками, идущими параллельно |
| Средний чек | Эффект в деньгах | Меняется от ассортимента и сезона |
| Прирост выручки на пользователя | Настоящий эффект | Считается только на эксперименте |
| Доля выручки через рекомендации | Масштаб влияния | Приписывает системе покупки, которые случились бы всё равно |
Из шести строк по-настоящему решает одна — прирост выручки на пользователя относительно контрольной группы. Остальные полезны как диагностика: они объясняют, почему прирост есть или почему его нет.
Отдельно про горизонт. Влияние рекомендаций на средний чек видно за две-три недели, а влияние на удержание и повторные покупки — только за квартал и дольше. Поэтому короткий тест показывает нижнюю границу эффекта, и решение о развитии системы принимают по длинному наблюдению.
Каннибализация — не теоретический риск. Блок «похожие товары» на карточке часто перекладывает покупку с одного товара на другой, и выручка не меняется. Отличить перенос от прироста можно только сравнением с людьми, которым блок не показывали. Как устроены события и метрики в целом, разобрано в материале про продуктовую аналитику.
Эксперимент: A/B и контрольная группа
Без эксперимента разговор об эффекте не имеет смысла. Устройство простое, но в деталях ошибаются почти все.
Делим пользователей, а не сессии. Человек, попавший в тест, остаётся в тесте: иначе он видит блок в одном визите и не видит в другом, и сравнение рассыпается.
Считаем на пользователя за период. Рекомендации влияют и на возвраты человека в магазин, поэтому эффект в пределах одной сессии его недооценивает.
Держим срок. Тест длится не меньше полного цикла покупки в вашей категории. В электронике это недели, в продуктах — дни.
Оставляем постоянную контрольную группу. Небольшая доля пользователей навсегда остаётся без рекомендаций. Это единственный способ через год понять, что система всё ещё приносит деньги.
Не останавливаем тест на первом успехе. Через три дня разница почти всегда выглядит внушительной, и почти всегда потом сжимается. Срок и объём выборки фиксируют до запуска, иначе тест превращается в поиск удобного момента.
Сравниваем с базовой линией. Новая модель соревнуется с популярным по категории. Сравнение с пустым местом делает успешным любой блок.
Когда это окупается
Самый важный расчёт, и делать его нужно до проекта. Порог складывается из четырёх множителей. Выручку, маржу, ожидаемый прирост и срок возврата перемножаем и сравниваем со стоимостью проекта.
Возьмём консервативные допущения. Прирост выручки от рекомендаций — 3%, маржа — 25%, проект должен вернуться за 12 месяцев, стоимость проекта — 1,8 млн ₽. Тогда порог выручки получается 20 млн ₽ в месяц: 20 000 000 × 3% × 25% × 12 = 1 800 000 ₽.
| Прирост выручки | При марже 20% | При марже 25% |
|---|---|---|
| 2% | 37,5 млн ₽ в месяц | 30 млн ₽ в месяц |
| 3% | 25 млн ₽ в месяц | 20 млн ₽ в месяц |
| 5% | 15 млн ₽ в месяц | 12 млн ₽ в месяц |
Читается таблица так. Магазин с оборотом 3 млн ₽ в месяц своей моделью рекомендаций не окупится ни при каких допущениях, и ему нужен готовый сервис или простые правила. Магазин с оборотом 100 млн ₽ окупает проект за два-три месяца даже при скромном приросте.
Два уточнения к расчёту. Прирост в 3% — оптимистичная величина для первого запуска на карточке товара и реалистичная для персонализации писем и главной. И считать надо прирост маржи. Рекомендации, которые подсовывают дешёвый аксессуар вместо дорогой альтернативы, ухудшают экономику при растущем чеке.
Если порог не проходит, проект не отменяется, а меняет форму. Самый дешёвый вход — персонализация писем и подборок. Данных для неё нужно меньше, эффект считается на той же контрольной группе, а стоимость измеряется интеграцией с системой рассылок. Следом идут правила и готовый сервис на витрине, и только третьим шагом своя модель — когда первые два уже дали измеренный прирост.
Динамическое ценообразование рядом
Тема часто идёт в одном запросе с рекомендациями, и это разные системы с разными рисками.
Рекомендации отвечают на вопрос «что показать». Динамическое ценообразование отвечает на вопрос «по какой цене», и оно меняет цену в зависимости от спроса, остатка, конкурентов или сегмента покупателя.
Технически это близкие задачи: те же данные, те же эксперименты. Практически риски разного порядка. Разные цены для разных людей на один товар — быстрый способ получить скриншот в социальных сетях и разбор с антимонопольной службой. Изменение цены по спросу и по остатку таких вопросов не вызывает, потому что цена одна для всех.
Практичный порядок такой. Сначала рекомендации, потом переоценка по спросу и остатку, и только потом, если вообще, персональные условия — и лучше в виде скидок в программе лояльности, чем в виде разных цен на витрине.
Требования закона
Про это не пишут в статьях про алгоритмы, а требование действует с 1 октября 2023 года. Федеральный закон № 408-ФЗ дополнил закон об информации статьёй 10.2-2, и она касается любого ресурса, который применяет рекомендательные технологии.
Владелец ресурса обязан сделать три вещи.
- Уведомить пользователей, что на ресурсе применяются рекомендательные технологии.
- Опубликовать правила их применения — какие сведения собираются, как систематизируются и на что влияют.
- Указать адрес электронной почты для юридически значимых сообщений и свои идентификационные данные.
Контроль за Роскомнадзором, порядок взаимодействия с владельцами ресурсов утверждён в конце 2023 года, а при нарушении ведомство может потребовать отключить рекомендательные технологии и ограничить доступ к ресурсу.
В 2026 году появилась и административная ответственность. Закон № 199-ФЗ от 26 июня 2026 года ввёл в КоАП статью 13.56: за нарушение порядка применения рекомендательных технологий юридическое лицо платит от 500 до 700 тыс. ₽, за неисполнение предписания об отключении — до 1,4 млн ₽, за повторное — до 2,8 млн ₽.
Для проекта отсюда следует конкретная задача. Правила применения рекомендательных технологий пишут вместе с системой. После запуска состав собираемых данных приходится описывать задним числом, и текст расходится с тем, что система делает на самом деле.
Готовый сервис или своя модель
| Вариант | Когда подходит | Что учесть |
|---|---|---|
| Простые правила без модели | Малый каталог, мало данных, ограниченный бюджет | Дёшево и предсказуемо; персонализации не будет |
| Готовый сервис рекомендаций | Типовая розница, стандартные блоки, данные можно отдавать наружу | Быстрый старт, оплата по объёму; ваши бизнес-правила подгоняются под чужую модель |
| Движок в своём контуре | Требование не выпускать поведенческие данные наружу | Дороже в обслуживании, нужен свой инженер по данным |
| Своя модель и свой сервис | Большой каталог, нетиповые правила, рекомендации как часть продукта | Окупается на объёме; нужны данные, эксперименты и регламент переобучения |
Комбинация работает чаще одного варианта. Кандидатов считает готовый движок или своя модель, а фильтрация по наличию, марже и уже купленному живёт в вашем слое — именно она и определяет качество блока для покупателя.
Ещё один аргумент за комбинацию — скорость проверки гипотезы. Готовый сервис позволяет за месяц узнать, есть ли на ваших данных прирост вообще, и уже с этим числом идти в разговор про свою модель. Порядок «сначала измерили, потом вложились» экономит больше, чем выбор технологии.
Про то, где ещё в электронной торговле уместны модели и агенты, есть отдельный обзор — материал про ИИ в e-commerce. Для рекомендаций правило простое: покупается алгоритм, а конкурентным преимуществом остаются ваши данные и ваши правила.
Сколько стоит
Объём работ задают три параметра. Размер каталога, число мест размещения и наличие своей модели.
По нашим работам: сервисы на своих моделях — от 1,8 млн ₽, витрина и блоки в магазине — от 1,5 млн ₽, отдельная интеграция с готовым движком рекомендаций или с системой рассылок — от 150 тыс. до 1,5 млн ₽, аудит существующего решения и данных — от 200 до 600 тыс. ₽. Точную цифру считаем по каталогу и по составу мест: оценка проекта бесплатная.
Порядок бюджета можно прикинуть заранее — бесплатный калькулятор оценки собирает вилку по составу работ за несколько минут.
Пять дорогих ошибок
Начинают с модели. Заказывают машинное обучение, не проверив, переигрывает ли обычное «популярное по категории». Половина проектов на этом и заканчивается.
Считают CTR блока. Метрика растёт, выручка нет, и никто не может объяснить разрыв, потому что контрольной группы не было.
Не заводят бизнес-правила. Система рекомендует товар без остатка и холодильник тому, кто купил холодильник вчера.
Забывают про переобучение. Модель обучили один раз, через сезон она рекомендует прошлую коллекцию, и блок начинают считать бесполезным.
Не читают требования закона. Рекомендательные технологии работают, уведомления и правил их применения на сайте нет, а с 2026 года за это есть отдельная статья КоАП.
С чего начать
Первое — посмотреть на данные. Есть ли события с идентификатором пользователя, живут ли они дольше сессии, попадают ли в них возвраты. Если событий нет, проект начинается со сбора данных, и это отдельный этап.
Второе — посчитать порог. Подставьте свою выручку, маржу и желаемый срок возврата в четыре множителя. Ответ обычно сразу показывает, нужна вам своя модель или хватит правил и готового сервиса.
Третье — выбрать одно место и одну метрику. Не шесть блоков сразу, а один: например, «с этим покупают» в корзине и число товаров в заказе. На нём отрабатывается вся механика, включая эксперимент, и только потом добавляются остальные места.
Часто задаваемые вопросы
Жёсткого порога нет, но ориентир такой. Модели нужна история по большинству товаров каталога, и суммарный объём событий сам по себе ничего не гарантирует. Магазин с тремя тысячами заказов в месяц и каталогом на сто тысяч позиций накопит такую историю за годы, поэтому ему подходят рекомендации по атрибутам товара и по совместным покупкам. Персонализация по поведению начинает работать там, где на каждый товар приходятся десятки событий.
Рекомендации подбирают товары. Персонализация — более широкое понятие. Она меняет порядок блоков, баннеры, подборки и содержание писем под сегмент или под конкретного человека. Рекомендательная система обычно становится ядром персонализации, потому что именно она умеет отвечать на вопрос «что этому человеку показать».
Если каталог типовой, блоки стандартные, а поведенческие данные можно передавать наружу, готовый сервис закроет задачу быстрее и дешевле. Своя модель начинается там, где рекомендации становятся частью продукта, где правила показа нестандартные или где данные нельзя выпускать за пределы своего контура. Промежуточный вариант рабочий: кандидатов считает сервис, а фильтрация и приоритеты остаются у вас.
Только сравнением с контрольной группой. Часть пользователей постоянно остаётся без рекомендаций, и разница в выручке на пользователя между группами и есть эффект. Без такой группы любая цифра про «долю выручки через рекомендации» завышена, потому что включает покупки, которые случились бы всё равно.
Простые блоки на правилах и совместных покупках — обычно несколько недель. Своя модель с данными, экспериментом и регламентом переобучения считается от квартала, причём первый месяц уходит на данные и базовую линию. Цену и срок мы фиксируем до старта, а состав первого этапа собираем на бесплатной оценке.
Разработка с Code Pilots
Code Pilots — студия заказной разработки полного цикла: веб- и мобильные продукты со сложной бизнес-логикой, интеграциями и высокими нагрузками. В задачах про рекомендации мы делаем всё, что окружает модель. Собираем события и приводим их в порядок, считаем базовую линию, обучаем модели на ваших данных, выносим бизнес-правила в настройки, ставим блоки на витрину с быстрым откликом и запасным вариантом.
Отдельно строим эксперимент. Делим пользователей, держим постоянную контрольную группу и даём отчёт, по которому видно прирост выручки. Внедрением коробочных ИИ-платформ и закупкой чужих сервисов как услугой мы не занимаемся — движок берём готовый там, где он дешевле своей модели.
Внутри — аналитики с отраслевой экспертизой, дизайнеры, backend- и мобильные разработчики, QA и DevOps, middle+ и senior. Пришлите размер каталога, месячную выручку и выгрузку событий за квартал: по ним уже видно и достижимый прирост, и порог окупаемости. Обсудить проект →
