Как управлять спросом в прямом эфире: кейс live-commerce
Live-commerce ускоряет покупки, но не всегда. В кейсе Alto разбираем, как длинный чекаут влияет на механику продаж.
1. Формат live-продаж переживает второе рождение
Но теперь вместо телевизора — стримы на сайте или в приложении интернет-магазина, а вместо звонка оператору — кнопка «Купить» прямо во время трансляции.
Такой формат называют live-commerce: ведущий показывает товары в прямом эфире, а зрители могут сразу перейти к карточке товара и оформить заказ.
2. Как работает live-продажа
Механика действительно похожа с той, что раньше показывали по телевизору: ведущий показывает товар, рассказывает о его особенностях и предлагает купить его прямо во время трансляции.
Но если в телевизионной версии покупка происходила через звонок оператору, то в eCommerce весь путь пользователя проходит на одной площадке. Зритель смотрит эфир на сайте, рядом с видео видит подборку товаров из трансляции и может сразу перейти к карточке товара и оформить заказ.
Во время эфира для товаров действуют скидки или ограниченные предложения, это и есть основной «рычаг» таких механик. Эфир фактически становится коротким промо-окном, чтобы покупатель решился на покупку.
Как механика работает в воронке
Live-эфиры используют как отдельный формат внутри интернет-магазина. Пользователь может прийти на сайт заранее, увидеть анонс эфира на главной странице и подключиться к трансляции. Либо попасть на трансляцию случайно и сделать спонтанную покупку, это тоже работает.
Такой формат сокращает путь от демонстрации товара до покупки: пользователь одновременно получает презентацию продукта и возможность сразу оформить заказ.
3. Но «просто добавить эфир» на сайт магазина не получится
Дело в том, что во время эфира на одной странице одновременно работают сразу несколько элементов eCommerce-системы. Поэтому при запуске таких механик важно заранее учитывать не только интерфейс трансляции, но и архитектуру корзины, промо-условий, остатков и оформления заказа — то есть подходить к задаче как к полноценной разработке интернет-магазина, а не как к добавлению отдельного блока на сайт.
Во время эфира одновременно задействованы несколько ключевых элементов:
- Трансляция + витрина товаров: пользователь смотрит эфир и одновременно видит подборку товаров из него, может сразу перейти к покупке.
- Промо-условия по времени: скидки и офферы включаются и отключаются в заданный момент, они должны корректно применяться в точности во время эфира.
- Динамические данные: во время эфира товары могут закончиться, и эти изменения должны сразу отображаться на сайте.
- Оформление заказа: пользователь может начать покупку прямо во время эфира, и система должна корректно обработать заказ с учётом условий акции.
В классическом eCommerce эти процессы разнесены во времени: пользователь сначала изучает каталог, потом оформляет заказ, и небольшая задержка обновления данных обычно не критична.
А тут всё происходит одновременно. Система должна быстро обновляться и реагировать, иначе пользователь увидит неактуальную цену, товар или условия покупки.
Этим и отличается live-commerce от «магазина на диване» по ТВ: там заказ оформляется отдельно от эфира, а здесь витрина, промо-условия и покупка работают внутри одного контура.
4. Где возникает проблема
В одном из проектов команда Alto разрабатывала витрину eCommerce-сервиса Moymir.ru с механикой live-продаж.
Аудитория сервиса долго принимает решения о покупке, по внутренним данным средний чекаут занимает 60–80 минут. А еще, покупатель может посмотреть эфир, добавить товары в корзину, уйти, вернуться позже и завершить покупку.
Но условия акции у нас действуют ограниченное время. И как «подстроиться» под поведение аудитории и не потерять продажи, и в то же время стимулировать к покупкам короткими промо-окнами.
Если не учесть все эти нюансы в архитектуре сервиса, могут произойти вот такие случаи, которые система должна корректно обрабатывать:
- Скидка закончилась: пользователь добавляет товар в корзину по акционной цене во время эфира, но завершает оформление позже — когда скидки уже нет и цена в заказе может измениться.
- Товар закончился: пользователь видит товар в подборке эфира и добавляет его в корзину, но к моменту оформления заказа этот товар уже разбирают.
- Корзина «обнулилась»: пользователь покидает сайт и возвращается позже, корзина может потерять добавленные товары или данные заказа.
Такие ситуации создают риск ошибок в заказах и потери покупок, поэтому сервис должен учитывать эти сценарии ещё на уровне архитектуры.
И это был главный драматический конфликт проекта и этого кейса.
5. Особенность аудитории 55+
Особенным «ограничением» проекта была его аудитория — люди старше 55 лет, и это сильно влияло на их путь к покупке внутри интернет-магазина.
Эти люди осторожничают, они могут долго изучать товар, возвращаться к карточке несколько раз и откладывать оформление покупки. В среднем они оформляли заказы по 60–80 минут.
Также их пользовательский путь часто был «разорванным». Они смотрели часть эфира, добавляли товар в корзину, закрывали страницу и позже возвращались. Естественно, они ожидали что все условия акции сохранятся.
Механику прямых эфиров добавили на сайт под эту аудиторию. Для пользователей 55+ это привычный формат — тот самый «магазин на диване», только внутри интернет-магазина. Им это понятно, они этому доверяют, им так комфортно.
По сути, сервис встроил «телик» в сайт: эфиры, ведущий, подборки товаров — всё как они привыкли.
И не учитывать особенностей поведения аудитории было нельзя. Система должна корректно работать с длинными и разорванными сессиями и учитывать, что за время чекаута могут измениться условия акции, цены и остатки товаров.
6. Почему обычный eCommerce не справляется
Никита, технический директор Alto: «Когда мы начали анализировать сценарии покупок во время эфира, стало понятно, что стандартные подходы eCommerce здесь не работают. В live-продажах система должна реагировать на изменения практически сразу — иначе пользователь может видеть товар или цену, которые уже не актуальны».
Обычно в eCommerce-проектах данные о товарах обновляются не в реальном времени.
Фиды мы уже генерировали для сторонних систем типа Яндекса, но для нашей задачи они не подходили. Способ простой и популярный, но тут есть нюанс: данные обновляются с задержкой. Фид формируется периодически, поэтому изменения в каталоге могут попадать в другие системы не сразу.
В обычном интернет-магазине это редко становится проблемой. Если цена или остаток обновятся через несколько минут, пользователь, скорее всего, этого даже не заметит.
Но не во время прямого эфира, когда всё происходит в рамках короткого окна: товар должен появиться в нужный момент, с правильной ценой и действующей скидкой.
Даже небольшая задержка передачи данных может приводить к проблемам:
- товар уже показывают в эфире, но он ещё не появился на витрине;
- акция началась, а система продолжает показывать старую цену;
- товар закончился, но всё ещё отображается в предложениях.
Фактически возникает рассинхронизация данных: то, что происходит в эфире и в бизнес-логике акции, не совпадает с тем, что пользователь видит на сайте. Задержка даже в несколько минут может означать потерянные продажи или ошибки в заказах.
7. Как перестроили архитектуру
Чтобы запустить live-продажи, мало просто добавить на сайт стрим и подборку товаров. Архитектуру архитектуру витрины пришлось «пересобрать» под новую логику.
Никита, технический директор Alto: «Мы «разделили» механизм обмена. Для актуализации остатков сделали отдельный легковесный функционал и применили внутренние оптимизации».
7.1. Динамическая модель характеристик: убираем лишнее, добавляем нужное.
Информация о товарах, их свойствах и наличии «лежит» в мастер-системе. Сайт — это витрина, он только отображает эти данные. До начала проекта мастер-система передавала данные на сайт через API «как есть»: в одной таблице были сразу все возможные параметры. Например, размеры обуви и джинс одновременно.
Контент-менеджеры в карточке товара в админ-панели видели лишние поля. Им приходилось лишний раз напрягаться, останавливаться и определять, какие характеристики заполнять, а какие игнорировать. Они работали медленнее и могли ошибаться.
Мы «привязали» характеристики к категориям. Это было компромиссное решение, чтобы не вводить отдельную сущность «тип товара» и не тянуть лишние поля. В итоге каждый товар получал только атрибуты своей категории, и у админа отображались только нужные поля.
Качественное наполнение контента это очень важно в ecom-проектах. Плюс это дало удобство построения фильтров товаров в категории за счет того что опции уже привязаны к категории, неявно как будто к типу товара.
7.2. Добавили виртуальные категории
Для прямых эфиров и акций нужно быстро формировать товарные подборки. Если делать это через основную структуру каталога, она быстро станет перегруженной и плохо управляемой.
Поэтому в проекте реализовали механику виртуальных категорий. Они работают как обычные категории каталога, но не меняют основную структуру. Так стало возможно быстро собирать любые подборки товаров под промо-акции разного масштаба.
7.3. Ввели правила синхронизации остатков
Во время эфира остатки товаров могут меняться очень быстро. Чтобы поддерживать актуальность данных и не перегружать мастер-систему, реализовали гибкую схему синхронизации.
Часто меняющиеся товары, например позиции из эфира, обновляются чаще. Менее приоритетные товары синхронизируются реже. Так мы поддерживаем точные остатки на витрине и не создаём избыточную нагрузку на систему.
7.4. Отказались от XML-фидов и внедрили событийную модель
В проекте отказались от фидов и сделали событийную модель интеграции через очереди. Любое изменение: публикация товара, изменение цены, обновление остатков или привязка товара к эфиру отправляется в очередь, затем передается в Retail Rocket (платформа для персонализации интернет-магазина) через API.
Так мы передавали изменения практически сразу и при этом не перегружали витрину, обработка событий происходила в отдельном масштабируемом сервисе.
7.5. Поставили все процессы в «умную» очередь
Отдельным архитектурным слоем стали очереди. Их внедрение было одним из приоритетов проекта, потому что для работы части процессов нужна интеграция с внешними сервисами.
Вынесли такие операции в воркер — фоновый процесс, который работает отдельно от основного потока и не нагружать основную витрину. В результате изменения данных могут обрабатываться быстро, а сайт работает стабильно даже во время пиковых нагрузок.
7.6. Сделали все изображения «легче»
Отдельно сделали сервис для обработки изображений товаров. Он автоматически сжимает картинки и переводит их в формат WebP, так страницы загружаются быстрее.
Во время эфиров на сайт приходит больше людей, и все они одновременно смотрят карточки товаров. Если картинки тяжёлые, страницы начинают грузиться медленно, растёт нагрузка на сервер и всё может начать «тормозить» — а это прямой путь к потере заказов.
Поэтому сделали так, чтобы изображения заранее обрабатывались и кэшировались: один раз подготовили — дальше отдаются быстро, без лишней нагрузки.
В итоге получился отдельный сервис работы с приложениями внутри интернет-магазина, функции работают без задержек и не «ломают» механику промо-канала. А за счёт нового стека эту механику масштабировали, сейчас эфиры проходят почти нон-стопом.
Проект перевели с монолитной архитектуры на распределённую. Развели по слоям то, что в live-commerce конфликтует: витрину, данные, интеграции и промо-логику — и заставили всё это работать вместе. Раньше это был один «кусок», теперь — набор сервисов, каждый со своей зоной ответственности. Это сложнее в разработке, особенно внутри уже работающего бизнеса.
Систему пересобрали не «в чистом поле», а внутри живого бизнеса, который уже продает, покупает, принимает заказы, добавляет новые товары. Это всегда требует более аккуратных решений и строгой архитектурной дисциплины.
Главный вывод: если в продукте есть короткие промо-окна и длинный путь пользователя, это нельзя решать «на фронте». Это задача архитектуры.
8. Когда сильный маркетинг требует сильной системы
Формат live-commerce сейчас переживает второе рождение. Он вовлекает, сокращает путь к покупке и даёт быстрый результат.
Но на практике всё может сломаться там, где пользователь ведёт себя не так, как задумал маркетинг. Если система к этому не готова, начинаются ошибки и потери.
Перед запуском новых форматов надо продумать не только саму механику, но и понять, где будут «сюрпризы» и выдержит ли это система.
Сейчас маркетологам сложнее. Важно уже не только придумать идею, заложить нужные смыслы и механику, но и понять, как всё это будет работать на уровне системы.
И если такие паттерны не предусмотреть заранее и не протестировать, проблемы всплывут уже в момент продаж. В Alto такие сценарии рассматривают как архитектурную задачу, а не только как маркетинговую механику.