Настройка email-уведомлений о брошенной корзине 1С-Битрикс

Брошенная корзина: где теряются заказы и почему письма не уходят

Брошенная корзина в 1С-Битрикс — это не «клиент передумал», а разрыв в цепочке событий. Пользователь добавляет товар, переходит к оформлению, заполняет поля — и уходит на шаге оплаты. Заказ при этом не создаётся: в базе нет ни записи, ни привязки к покупателю, ни триггера для письма. Со стороны бизнеса это выглядит как тишина в статистике, хотя трафик и добавления в корзину были.

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

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

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

Что даёт настроенная цепочка писем о брошенной корзине

Настроенная цепочка писем о брошенной корзине — это не «одно письмо через сутки», а последовательность касаний, привязанная к поведению пользователя на сайте. Первое письмо уходит через 30-60 минут после того, как корзина осталась без движения: за это время человек ещё помнит, что выбирал, и вероятность возврата максимальна. Дальше — второе касание через сутки и третье через 3-5 дней, если заказ так и не оформлен. Такая схема возвращает заметную долю брошенных корзин, тогда как одиночное письмо «вы что-то забыли» почти не работает.

Ключевой параметр здесь — скорость реакции. Пока письмо идёт часами, клиент либо покупает у конкурента, либо остывает к покупке. Мы настраиваем отправку так, чтобы уведомление уходило в пределах часа после события, а не в конце дня пакетной рассылкой. Это напрямую влияет на конверсию корзины: чем короче разрыв между действием и письмом, тем выше доля возвратов.

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

Мы собираем цепочку на данных из самой корзины: подставляем состав заказа, актуальную цену и остатки, добавляем ссылку возврата в корзину с сохранённым товаром. Если товар закончился или цена изменилась, письмо это учитывает — клиент не приходит на пустую страницу и не теряет доверие. Отдельно настраиваем сегментацию: авторизованные и гости, повторные и разовые покупатели получают разные сценарии.

Всё это работает на штатных средствах 1С-Битрикс и Битрикс24 без внешних сервисов рассылок, поэтому данные о заказах не покидают ваш контур. Мы настраиваем журналирование отправок и отписок, чтобы видеть, какие шаги цепочки дают возврат заказов, а какие можно убрать.

Способы отправки: транзакционные письма, рассылки и внешние сервисы

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

Что определяет доставляемость

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

Как выбирают на практике

Для интернет-магазина с потоком в сотни заказов достаточно транзакционных писем средствами платформы с вынесенным поддоменом. Когда добавляются сегменты, A/B-тесты шаблонов и аналитика открытий, подключают рассылочный сервис. Почтовый шлюз оправдан, когда объём растёт и нужен детальный контроль отказов и жалоб. Часто схему комбинируют: транзакции идут напрямую, а реактивационные серии — через сервис.

Этапы настройки уведомлений о брошенной корзине

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

1. Аудит событий и данных. Смотрим, какие действия покупателя фиксируются в системе: добавление товара, изменение количества, вход в оформление, уход со страницы. Проверяем, привязана ли корзина к пользователю или к сессии, как хранится контакт — из профиля, из формы или из cookie. На этом этапе становится ясно, по каким событиям вообще можно строить триггеры, а где данных не хватает.

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

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

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

5. Запуск и наблюдение. Включаем рассылку на части трафика, сверяем фактическую отправку с планом, отслеживаем возвраты к оформлению. Если доля открытий или переходов ниже ожидаемой, корректируем интервалы и текст.

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

Опишите вашу задачу — вернёмся с оценкой и планом работ по вашему проекту.

Что заказчик получает после настройки: конфигурации и регламенты

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

• Шаблоны писем — три-четыре сценария под разное поведение: бросил корзину на этапе выбора, дошёл до оформления и ушёл, не открыл первое письмо. Тексты, темы, переменные подстановки (имя, состав корзины, ссылка на возврат) — в отдельных файлах, правятся без вызова разработчика.
• Схема триггеров — карта: какое событие запускает письмо, через сколько минут или часов, при каких условиях останавливается. Отдельно описаны исключения: оформленный заказ, отписка, повторная корзина — чтобы клиент не получал два письма подряд.
• Правила сегментации — по каким признакам аудитория делится на группы: новые и повторные покупатели, категория товара, активность в письмах. Для каждого сегмента указано, какой шаблон и какая задержка применяются.
• Инструкция для сотрудников — что менеджер видит в панели, как вручную снять клиента с рассылки, куда смотреть при жалобе на лишнее письмо. Без этого настройка живёт до первого вопроса отдела продаж.
• Документация по сопровождению — где лежат шаблоны, как поменять текст и интервал, как проверить, что письмо ушло, как откатить изменение. С описанием точек, где чаще всего ломается логика.
• Регламент проверки — периодичность сверки: доходят ли письма, нет ли роста отписок, корректно ли подставляются данные. С указанием ответственного и порога, после которого нужно вмешаться.
• Схема отката — как вернуть прежнее поведение, если новая логика даёт сбой: какие настройки сохраняются перед запуском и в каком порядке восстанавливаются.

Всё передаём в вашем репозитории и на вашей инфраструктуре — без привязки к нам. Опишите задачу, вернёмся с оценкой и планом по вашему каталогу и воронке.

Кейс: как восстановили отправку писем и вернули заказы

Проект — интернет-магазин на 1С-Битрикс с несколькими тысячами позиций и потоком заказов в день. Клиент жаловался на «тишину»: покупатели добавляли товары, уходили, но писем с напоминанием не получали. По факту брошенная корзина копилась, а догнать покупателя было нечем.

Что нашли

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

Что сделали

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

Метрики до и после

Через месяц после запуска доля возвращённых заказов вышла на 11% от всех брошенных корзин — это заказы, которые раньше просто терялись. Отдельно вынесли метрику в панель: если доля отправленных писем падает ниже 95%, приходит уведомление ответственному. Такой контроль ловит ошибку в событиях в тот же день, а не через месяц по упавшей выручке.

Чем отличается уведомление о брошенной корзине от транзакционного письма

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

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

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

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

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

Частые технические вопросы по настройке уведомлений

Письмо о брошенной корзине — это транзакционное сообщение, но почтовые провайдеры судят его по тем же правилам, что и рассылку: репутация домена и IP, наличие SPF, DKIM и DMARC, доля жалоб и переходов. Если домен молодой или с него параллельно уходит массовая рассылка, письма начинают уходить в «Промоакции» и «Спам» — корзина формально брошена, а клиент уведомления не видит. Лечится это не текстом письма, а настройкой аутентификации отправителя и выносом транзакционного потока на отдельный поддомен, чтобы репутация не смешивалась с маркетинговой.

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

Как гарантированно избежать дублей писем?

Идемпотентность на уровне данных: пишем факт отправки в отдельную таблицу с уникальным индексом по паре «пользователь + корзина». Повторный запуск агента видит запись и не отправляет письмо второй раз. Дополнительно исключаем пересечение агентов и обработчиков событий, чтобы одно действие не триггерило отправку дважды.

Что делать, если отправка падает или почтовый сервер недоступен?

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

Как понять, что уведомления реально доходят?

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

Обсудим вашу задачу по уведомлениям о брошенной корзине

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

• Платформа и редакция. Битрикс или Битрикс24, редакция, модуль интернет-магазина, подключённые каналы уведомлений. От этого зависит, какие события уже отдают данные о корзине, а какие придётся собирать.
• Схема корзины. Где хранится: привязана к пользователю, к сессии или к обоим; как долго живёт брошенная; есть ли объединение корзин при входе. Это определяет, по какому признаку считать корзину брошенной.
• Сценарии возврата. Что уже отправляется — письма, сообщения в мессенджеры, звонок менеджера. Какие шаги и через сколько после броска. Так мы не дублируем то, что работает.
• Данные о клиенте. Согласия на рассылку, поля профиля, история заказов. Нужны, чтобы уведомление было уместным и не уходило тем, кто уже купил.
• Инфраструктура. Как устроена отправка писем, кто провайдер, есть ли ограничения по объёму и репутации домена. Очередь и повторные попытки — часть работы.
• Доступы. Тестовый контур, копия базы, доступ к настройкам и логам. Без стенда проверять сценарии вслепую нельзя.
• Ожидания по срокам. К какой дате нужен запуск и есть ли привязка к акции или сезону.

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