Покупатель зашёл в карточку товара, покрутил фотографии, почитал характеристики — и ушёл, не положив ничего в корзину. Формально ничего не произошло: ни заказа, ни даже добавления. Но это сигнал интереса, который большинство магазинов просто теряет. А ведь именно из таких «тёплых» просмотров при аккуратной работе вырастают продажи.
В этой статье разберём, как выстроить догоняющие коммуникации по брошенному просмотру товара в магазине на 1С-Битрикс: чем этот сценарий отличается от брошенной корзины, как фиксировать просмотры, что умеет модуль «Рассылки» (Sender) и триггеры, какие цепочки и тайминги работают и как не превратить заботу в спам. Такие механики — часть системной работы с воронкой, и мы настраиваем их в рамках автоматизации на 1С.
Коротко
- Брошенный просмотр — слабый сигнал интереса; коммуникация должна быть мягкой, а не «вы забыли оформить».
- Просмотры фиксируются через события каталога и хранятся отдельно, а рассылки строятся на модуле «Рассылки» (Sender) и триггерах.
- Догонять письмом можно в основном известных пользователей: анонимный просмотр надо связать с контактом.
- Одно-два спокойных касания, ограничение частоты, обязательная отписка и контроль доставляемости.
Что такое брошенный просмотр и чем он ценен
Брошенный просмотр — это ситуация, когда пользователь открыл карточку товара (иногда несколько раз), но не совершил целевого действия: не добавил в корзину, не оформил заказ, не запросил цену. С точки зрения аналитики это ранний, слабый, но реальный сигнал интереса. Человек не случайно попал на страницу — он что-то искал.
Ценность этого сигнала в его массовости. Просмотров карточек на порядок больше, чем добавлений в корзину, и даже небольшая доля возвращённых просмотров даёт заметный прирост. Но именно из-за слабости сигнала работать с ним нужно тоньше, чем с корзиной: агрессивное «вернитесь и купите» здесь отпугивает. Это часть общей работы с поведением на сайте — рядом с ней стоят технические темы вроде D7 ORM в Битрикс, на которой держится хранение и обработка событий пользователя.
Просмотр против корзины: разная температура
Ключевая ошибка — обращаться с брошенным просмотром как с брошенной корзиной. Это разные стадии воронки с разной температурой намерения, и коммуникация под них строится по-разному.
| Параметр | Брошенный просмотр | Брошенная корзина |
|---|---|---|
| Действие | Открыл карточку | Добавил в корзину |
| Температура | Тёплый интерес | Горячее намерение |
| Тон письма | Мягкое напоминание, помощь | «Вы не завершили заказ» |
| Первый тайминг | Часы — сутки | 10–60 минут |
| Число касаний | 1–2 | 2–3 |
| Конверсия | Ниже, но охват выше | Выше на письмо |
Из таблицы видно главное: просмотр требует бережности и терпения, а корзина — скорости. Если перепутать тон, письмо по просмотру прозвучит как давление на пустом месте — «я просто посмотрел, чего вы от меня хотите». Правильная догоняющая коммуникация уважает стадию, на которой находится покупатель.
Как фиксировать просмотры в 1С-Битрикс
Чтобы догонять просмотр, его сначала нужно зафиксировать. В 1С-Битрикс для этого используют события при показе детальной страницы товара и собственное хранилище истории просмотров, привязанное к пользователю или сессии.
Что обычно фиксируют:
- Идентификатор товара. Какой именно элемент каталога открывали.
- Пользователь или сессия. Авторизованный ID или анонимный идентификатор до авторизации.
- Время и повторы. Когда смотрели и сколько раз — повторный визит усиливает сигнал.
- Контекст. Откуда пришёл, положил ли потом в корзину (чтобы не догонять уже купленное).
Историю просмотров разумно хранить в highload-блоке или отдельной таблице, а не раздувать основные сущности каталога. Правильная модель хранения и быстрые выборки по ней — это работа с ORM и данными, о которой мы писали в статье про D7 ORM. Чистые, надёжно собранные данные о просмотрах — фундамент всех дальнейших сценариев.
Модуль «Рассылки» (Sender) и триггеры
Основной штатный инструмент для догоняющих коммуникаций в 1С-Битрикс — модуль «Рассылки» (Sender). Он умеет то, что нужно: хранить контакты, делить их на сегменты, отправлять письма и запускать триггерные рассылки по событию.
Ключевые возможности под наш сценарий:
- Сегменты. Наборы получателей по условиям — например, «смотрели товар, но не добавляли в корзину».
- Триггерные рассылки. Письмо, которое уходит не всем сразу, а конкретному человеку по событию, с нужной задержкой.
- Персонализация. Подстановка в письмо просмотренного товара, его названия, цены, ссылки.
- Учёт отписок и статистики. Встроенный контроль доставки, открытий и отписок.
Для более сложной логики (мультиканальность, сложные условия входа в цепочку) к Sender добавляют бизнес-процессы, агентов или внешние сервисы через API. Как безопасно интегрировать внешние сервисы рассылок и обрабатывать их ответы, мы разбирали в материале про REST-вебхуки и безопасность в Битрикс.
Связка анонимного просмотра с контактом
Главное ограничение сценария — адресат. Пока человек анонимен, у вас есть только его сессия, но нет email. Отправить письмо по просмотру можно лишь тому, чей контакт известен.
Момент связки наступает, когда пользователь:
- Авторизуется. История просмотров сессии привязывается к его профилю.
- Подписывается. Оставляет email в форме подписки — с согласием на рассылку.
- Оформляет заказ. Контакт из заказа становится известным, а прошлые просмотры — атрибутируемыми.
Отсюда практический вывод: догоняющие письма по просмотру в первую очередь работают на базе известных пользователей — подписчиков и покупателей. Для анонимных остаются каналы, не требующие email: web-push (если подписан) и напоминания на самом сайте. Поэтому наращивание базы согласий — необходимое условие эффективности всей механики.
Сценарии догоняющих цепочек
Не существует одного «правильного» письма — под разные ситуации работают разные сценарии. Вот те, что дают эффект чаще всего:
- Простое напоминание. «Вы смотрели этот товар» с фото, ценой и ссылкой — самый базовый и рабочий сценарий.
- Снятие возражений. Ответы на частые сомнения по этому товару: гарантия, доставка, возврат.
- Похожие и альтернативы. Если конкретный товар не зашёл, показать близкие по параметрам позиции.
- Наличие и цена. Сообщить, что товар снова в наличии или изменилась цена — сильный триггер.
- Повторный интерес. Отдельный сценарий для тех, кто вернулся к карточке несколько раз, — сигнал сильнее.
Тайминги и частота касаний
Тайминг для просмотра мягче, чем для корзины. Слишком быстрое письмо выглядит как слежка: человек только что закрыл вкладку — а ему уже пишут. Дайте намерению отлежаться.
- Первое касание. Через несколько часов или на следующий день, когда ясно, что сам покупатель не вернулся.
- Второе касание. По желанию, через день-два, с дополнительной ценностью — похожие товары или ответ на возражение.
- Стоп. Больше писем по одному просмотру не отправляем — сигнал слишком слабый, чтобы давить дальше.
Отдельно важна глобальная частота: человек не должен получать письмо по каждой открытой карточке. Ограничьте, сколько догоняющих писем он получает в неделю, иначе активный пользователь утонет в напоминаниях и отпишется. Надёжная отправка таких цепочек по расписанию зависит и от инфраструктуры — очередей и почтового стека, о которых мы писали в статье про хостинг и инфраструктуру BitrixVM.
Сегментация: кому вообще писать
Отправлять письмо всем, кто открыл товар, — плохая идея. Сегментация отсеивает тех, кому писать не нужно, и повышает и конверсию, и доставляемость.
- Уже купил. Если товар после просмотра оказался в оплаченном заказе — не догоняем.
- Уже в корзине. Такой пользователь идёт по сценарию брошенной корзины, а не просмотра.
- Нет согласия. Без согласия на рассылку email-канал недоступен.
- Недавно писали. Если человек уже получил догоняющее письмо, выдерживаем паузу.
- Ценность товара. Для дорогих B2B-позиций логичнее задача менеджеру, чем письмо.
Хорошая сегментация — это ещё и уважение к пользователю: вы пишете тогда, когда это уместно, и о том, что ему действительно интересно.
Каналы: email, push, SMS, задача менеджеру
Email — основной, но не единственный канал догоняющих коммуникаций. Под разные аудитории и сигналы подходят разные каналы.
- Email. Универсальный канал для известных контактов, подходит для содержательных писем с товарами.
- Web-push. Работает для анонимных, но подписанных на уведомления пользователей — короткое напоминание.
- SMS. Дорогой канал для важных сигналов (снова в наличии, изменение цены), а не для рутинных напоминаний.
- Задача менеджеру. В B2B крупный клиент, несколько раз открывший дорогую позицию, стоит личного звонка.
Оркестрация нескольких каналов — уже более сложная система: события с сайта уходят в разные сервисы, ответы возвращаются обратно. Это интеграционная задача, где важна надёжность обмена и деплоя — темы, которые мы затрагивали в материале про CI/CD и деплой в Битрикс.
Согласие, отписка и доставляемость
Догоняющие письма — это реклама, поэтому играть надо по правилам. Иначе вместо продаж получите жалобы на спам и падение доставляемости всей рассылки.
- Только по согласию. Отправляем тем, кто дал согласие на рекламные сообщения.
- Заметная отписка. В каждом письме — простая ссылка отписаться, работающая с первого клика.
- SPF, DKIM, DMARC. Технические записи почты, без которых письма уходят в спам.
- Контроль жалоб. Следим за долей жалоб и отписок, отключаем сценарии, которые их разгоняют.
Репутация домена — актив, который легко потерять и трудно восстановить. Один агрессивный сценарий без отписки способен испортить доставляемость всех писем магазина, включая транзакционные.
Метрики и оценка эффекта
Чтобы понять, работают ли цепочки, нужны честные метрики и корректная атрибуция. Смотреть только на «сколько писем отправили» бессмысленно.
- Доставляемость и открытия. Доходят ли письма и открывают ли их — базовое здоровье канала.
- Переходы на карточку. Возвращается ли человек к товару по ссылке из письма.
- Конверсия в заказ. Доля получателей, которые в итоге оформили заказ по догоняющей цепочке.
- Отписки и жалобы. Обратная сторона — не разгоняет ли сценарий негатив.
Важно сравнивать с контрольной группой: часть покупателей вернулась бы и без письма. Только сравнение с теми, кому не писали, показывает реальный вклад цепочки. Настроить корректный сбор и хранение таких данных помогает аудит и оптимизация 1С.
Частые ошибки
- Тон корзины на просмотре. «Вы не завершили заказ» там, где человек просто посмотрел товар.
- Слишком быстро. Письмо через минуту после закрытия вкладки выглядит как слежка.
- Слишком часто. Письмо по каждому просмотренному товару без глобального лимита частоты.
- Отправка без согласия. Рассылка по тем, кто не давал согласия, — нарушение и удар по домену.
- Догоняют купленное. Нет проверки, не оформлен ли товар в заказе, — письмо раздражает.
- Нет отписки. Отсутствие простой отписки гонит жалобы на спам.
- Нет контрольной группы. Эффект приписывают цепочке, хотя часть вернулась бы и так.
Чек-лист внедрения
- Просмотры фиксируются. События каталога пишут историю просмотров в отдельное хранилище.
- Связка с контактом. Анонимные просмотры привязываются к профилю при авторизации, подписке, заказе.
- Сегменты настроены. Отсеяны купившие, уже в корзине, без согласия и недавно получившие письмо.
- Триггеры в Sender. Цепочки в модуле «Рассылки» запускаются по событию с нужной задержкой.
- Мягкий тон и ценность. Письма помогают выбрать, а не давят «купите скорее».
- Частота ограничена. Есть глобальный лимит догоняющих писем на пользователя.
- Согласие и отписка. Отправка только по согласию, отписка в каждом письме, настроены SPF/DKIM/DMARC.
- Метрики и контроль. Считаются конверсия, отписки и эффект против контрольной группы.
Вывод
Брошенный просмотр — это огромный, но недооценённый пласт тёплого интереса. В отличие от корзины сигнал здесь слабее, поэтому и работать с ним нужно бережнее: мягкий тон, разумные тайминги, одно-два касания и обязательное уважение к согласию и частоте. Тогда догоняющая коммуникация помогает покупателю вернуться, а не отпугивает его.
В 1С-Битрикс всё для этого есть: события каталога для фиксации просмотров, модуль «Рассылки» с сегментами и триггерами, а также highload-хранилище для истории. Собранные в аккуратную систему, эти инструменты превращают массовые просмотры в дополнительные заказы — без спама и без ущерба репутации домена.
