«Магазин на диване» сегодня: как работает live-commerce для аудитории 55+

Live-commerce предполагает быстрые покупки во время эфира. А что если аудитория проекта — люди 55+? Они думают дольше и оформляют заказы больше часа, хотя скидка действует только во время трансляции. На примере реального кейса от команды Alto покажем, где в такой механике возникают риски и какие технические решения помогают их избежать.

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

Но теперь вместо телевизора — стримы на сайте или в приложении интернет-магазина, а вместо звонка оператору — кнопка «Купить» прямо во время трансляции.

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

МегаФон Таргет: точный таргетинг и бонус 3000 рублей

• Помогает решать задачи бизнеса: реактивация базы, увеличение конверсии и лояльность клиентов.
• SMS-рассылки с высокой вовлеченностью.
• Получите 3000 бонусных рублей и запускайте первую кампанию с ИИ-помощником.

Узнать больше >>

Реклама. ПАО «МегаФон». ИНН 7812014560. ОГРН 1027809169585. ERID: 2W5zFJN2cgh.

Как работает live-продажа

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

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

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

Как механика работает в воронке

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

Такой формат сокращает путь от демонстрации товара до покупки: пользователь одновременно получает презентацию продукта и возможность сразу оформить заказ.

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

Дело в том, что во время эфира на одной странице одновременно работают сразу несколько элементов ecommerce-системы.

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

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

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

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

В классическом ecommerce эти процессы разнесены во времени: пользователь сначала изучает каталог, потом оформляет заказ, и небольшая задержка обновления данных обычно не критична.

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

Где возникает проблема

В одном из проектов команда Alto разрабатывала витрину ecommerce-сервиса Moymir.ru с механикой live-продаж.

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

Но условия акции у нас действуют ограниченное время. И как «подстроиться» под поведение аудитории и не потерять продажи, и в то же время стимулировать к покупкам короткими промоокнами.

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

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

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

• Корзина «обнулилась»: пользователь покидает сайт и возвращается позже, корзина может потерять добавленные товары или данные заказа.

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

И это был главный драматический конфликт проекта и этого кейса.

Особенность аудитории 55+

Особенным «ограничением» проекта была его аудитория — люди старше 55 лет, и это сильно влияло на их путь к покупке внутри интернет-магазина.
Эти люди осторожничают, они могут долго изучать товар, возвращаться к карточке несколько раз и откладывать оформление покупки. В среднем они оформляли заказы по 60–80 минут.

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

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

По сути, сервис встроил «телик» в сайт: эфиры, ведущий, подборки товаров — всё как они привыкли.

И не учитывать особенностей поведения аудитории было нельзя. Система должна корректно работать с длинными и разорванными сессиями и учитывать, что за время чекаута могут измениться условия акции, цены и остатки товаров.

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

Никита, технический директор Alto, рассказал, что когда начали анализировать сценарии покупок во время эфира, стало понятно, что стандартные подходы ecommerce здесь не работают.

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

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

В обычном интернет-магазине это редко становится проблемой. Если цена или остаток обновятся через несколько минут, пользователь, скорее всего, этого даже не заметит.

Но не во время прямого эфира, когда всё происходит в рамках короткого окна: товар должен появиться в нужный момент, с правильной ценой и действующей скидкой.

Даже небольшая задержка передачи данных может приводить к проблемам:

• товар уже показывают в эфире, но он ещё не появился на витрине;

• акция началась, а система продолжает показывать старую цену;

• товар закончился, но всё ещё отображается в предложениях.

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

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

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

Динамическая модель характеристик: убираем лишнее, добавляем нужное

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

Контент-менеджеры в карточке товара в админ-панели видели лишние поля. Им приходилось лишний раз напрягаться, останавливаться и определять, какие характеристики заполнять, а какие игнорировать. Они работали медленнее и могли ошибаться.

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

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

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

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

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

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

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

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

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

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

Так мы передавали изменения практически сразу и при этом не перегружали витрину, обработка событий происходила в отдельном масштабируемом сервисе.

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

Отдельным архитектурным слоем стали очереди. Их внедрение было одним из приоритетов проекта, потому что для работы части процессов нужна интеграция с внешними сервисами.

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

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

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

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

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

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

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

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

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

Когда сильный маркетинг требует сильной системы

Формат live-commerce сейчас переживает второе рождение. Он вовлекает, сокращает путь к покупке и даёт быстрый результат.

Но на практике всё может сломаться там, где пользователь ведёт себя не так, как задумал маркетинг. Если система к этому не готова, начинаются ошибки и потери.

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

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

И если такие паттерны не предусмотреть заранее и не протестировать, проблемы всплывут уже в момент продаж. В Alto такие сценарии рассматривают как архитектурную задачу, а не только как маркетинговую механику.

Мнение редакции может не совпадать с мнением автора. Ваши статьи присылайте нам на 42@cossa.ru. А наши требования к ним — вот тут.