Из эфира в заказ: кейс механики live-commerce для интернет-магазина

1. Вводная задача от заказчика, проблематика, цели

Формат live-продаж переживает второе рождение

Но теперь вместо телевизора — стримы на сайте или в приложении интернет-магазина, а вместо звонка оператору — кнопка «Купить» прямо во время трансляции. Такой формат называют live-commerce: ведущий показывает товары в прямом эфире, а зрители могут сразу перейти к карточке товара и оформить заказ.

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

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

Проблематика: «разрыв» между скоростью эфира и поведением аудитории

Главным вызовом кейса стала аудитория 55+. Эти люди осторожничают, долго изучают товар и оформляют заказ в среднем 60–80 минут. Часто их путь был «разорванным»: посмотрели эфир, добавили товар в корзину, закрыли страницу и вернулись через час.

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

2. Описание реализации кейса и творческого пути по поиску оптимального решения

Просто «добавить эфир» на сайт магазина не получится

Дело в том, что во время эфира на одной странице одновременно работают сразу несколько элементов eCommerce-системы. Поэтому при запуске таких механик важно заранее учитывать не только интерфейс трансляции, но и архитектуру корзины, промо-условий, остатков и оформления заказа — то есть подходить к задаче как к полноценной разработке интернет-магазина, а не как к добавлению отдельного блока на сайт.

Во время эфира одновременно задействованы несколько ключевых элементов:

Трансляция + витрина товаров: пользователь смотрит эфир и одновременно видит подборку товаров из него, может сразу перейти к покупке.

Промо-условия по времени: скидки и офферы включаются и отключаются в заданный момент, они должны корректно применяться в точности во время эфира.

Динамические данные: во время эфира товары могут закончиться, и эти изменения должны сразу отображаться на сайте.

Оформление заказа: пользователь может начать покупку прямо во время эфира, и система должна корректно обработать заказ с учётом условий акции.

В классическом eCommerce эти процессы разнесены во времени: пользователь сначала изучает каталог, потом оформляет заказ, и небольшая задержка обновления данных обычно не критична. А тут всё происходит одновременно. Система должна быстро обновляться и реагировать, иначе пользователь увидит неактуальную цену, товар или условия покупки. Этим и отличается live-commerce от «магазина на диване» по ТВ: там заказ оформляется отдельно от эфира, а здесь витрина, промо-условия и покупка работают внутри одного контура.

Где возникает проблема и особенность аудитории 55+

Аудитория сервиса долго принимает решения о покупке, по внутренним данным средний чекаут занимает 60–80 минут.

Эти люди осторожничают, они могут долго изучать товар, возвращаться к карточке несколько раз и откладывать оформление покупки. Также их пользовательский путь часто был «разорванным». Они смотрели часть эфира, добавляли товар в корзину, закрывали страницу и позже возвращались. Естественно, они ожидали что все условия акции сохранятся.

Механику прямых эфиров добавили на сайт под эту аудиторию. Для пользователей 55+ это привычный формат — тот самый «магазин на диване», только внутри интернет-магазина. Им это понятно, они этому доверяют, им так комфортно. По сути, сервис встроил «телик» в сайт: эфиры, ведущий, подборки товаров — всё как они привыкли.

Почему обычный eCommerce не справляется

Обычно в eCommerce-проектах данные о товарах обновляются не в реальном времени. Фиды мы уже генерировали для сторонних систем типа Яндекса, но для нашей задачи они не подходили. Способ простой и популярный, но тут есть нюанс: данные обновляются с задержкой. Фид формируется периодически, поэтому изменения в каталоге могут попадать в другие системы не сразу.

Даже небольшая задержка передачи данных может приводить к проблемам: товар уже показывают в эфире, но он ещё не появился на витрине; акция началась, а система продолжает показывать старую цену; товар закончился, но всё ещё отображается в предложениях. Фактически возникает рассинхронизация данных. Задержка даже в несколько минут может означать потерянные продажи или ошибки в заказах.

Как перестроили архитектуру

Чтобы запустить live-продажи, мало просто добавить на сайт стрим и подборку товаров. Архитектуру витрины пришлось «пересобрать» под новую логику.

7.1. Динамическая модель характеристик: убираем лишнее, добавляем нужное. Информация о товарах, их свойствах и наличии «лежит» в мастер-системе. Сайт — это витрина, он только отображает эти данные. До начала проекта мастер-система передавала данные на сайт через API «как есть»: в одной таблице были сразу все возможные параметры. Контент-менеджеры в админ-панели видели лишние поля. Мы «привязали» характеристики к категориям. Это было компромиссное решение, чтобы не вводить отдельную сущность «тип товара» и не тянуть лишние поля. В итоге каждый товар получал только атрибуты своей категории. Качественное наполнение контента это очень важно в ecom-проектах. Плюс это дало удобство построения фильтров товаров в категории.

7.2. Добавили виртуальные категории

Для прямых эфиров и акций нужно быстро формировать товарные подборки. Если делать это через основную структуру каталога, она быстро станет перегруженной и плохо управляемой. Поэтому в проекте реализовали механику виртуальных категорий. Они работают как обычные категории каталога, но не меняют основную структуру.

7.3. Ввели правила синхронизации остатков

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

7.4. Отказались от XML-фидов и внедрили событийную модель

В проекте отказались от фидов и сделали событийную модель интеграции через очереди. Любое изменение: публикация товара, изменение цены, обновление остатков или привязка товара к эфиру отправляется в очередь, затем передается в Retail Rocket через API. Так мы передавали изменения практически сразу и при этом не перегружали витрину.

7.5. Поставили все процессы в «умную» очередь

Вынесли такие операции в воркер — фоновый процесс, который работает отдельно от основного потока и не нагружает основную витрину. В результате изменения данных могут обрабатываться быстро, а сайт работает стабильно даже во время пиковых нагрузок.

7.6. Сделали все изображения «легче»

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

Никита Быков

технический директор, Alto

«Когда мы начали анализировать сценарии покупок во время эфира, стало понятно, что стандартные подходы eCommerce здесь не работают. В live-продажах система должна реагировать на изменения практически сразу — иначе пользователь может видеть товар или цену, которые уже не актуальны.

Мы "разделили" механизм обмена. Для актуализации остатков сделали отдельный легковесный функционал и применили внутренние оптимизации»

3. Результаты сотрудничества

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

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

Систему пересобрали не «в чистом поле», а внутри живого бизнеса, который уже продает, покупает, принимает заказы, добавляет новые товары. Это всегда требует более аккуратных решений и строгой архитектурной дисциплины.

Главный вывод: если в продукте есть короткие промо-окна и длинный путь пользователя, это нельзя решать «на фронте». Это задача архитектуры.