Автоматизация брошенных корзин: напоминание, согласие и остановка после покупки

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

Ниже — правила для одной текущей покупки. Это не сценарий реактивации давно ушедшего клиента и не допродажа к уже оформленному заказу.

Какую задачу решает этот процесс

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

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

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

Какие данные и правила подготовить

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

Короткий синтетический образец без клиентских данных: cart_id = C12, customer_id = U7, last_activity_at = 10:00, согласие на email активно, order_created отсутствует, order_paid отсутствует. Идентификаторы и время здесь условные: это форма записи правила, а не данные клиента Switch On AI.

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

Как определить брошенную корзину

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

• started_waiting_at = last_activity_at;
• planned_send_at = last_activity_at + 30 минут;
• добавление, удаление или изменение количества товара задаёт новое last_activity_at и запускает паузу заново.

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

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

Неудачная оплата — отдельное состояние. Событие payment_failed не равно order_paid, но и само по себе не доказывает, что корзина брошена. Для него нужен отдельный сценарий: например, показать ошибку оплаты или передать обращение человеку.

Как остановить напоминание после покупки

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

Условие отправки можно записать так:

send_allowed = consent_active AND NOT unsubscribed AND NOT order_paid AND cart_is_current AND secure_link_available

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

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

Повтор одного события оплаты с тем же event_id не должен менять конечное состояние, создавать новую задачу или запускать ещё одну серию. Это правило идемпотентности проверяют отдельно.

Официальная документация Sendsay, обновлённая 30 июля 2026 года, описывает для сценария «Брошенная корзина» передачу событий обновления и очистки корзины и заказа, настройку задержки и автоматическое прерывание сценария после заказа или очистки корзины. Это подтверждает возможности указанной платформы, но не доказывает совместимость с конкретным магазином и не заменяет проверку его тарифа, прав, API и фактической передачи событий.

Что отправлять и как оценивать результат

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

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

CR = число корзин с order_paid в окне / число корзин, включённых в группу

Синтетический расчёт: в тестовой группе оплачены 18 из 200 корзин, поэтому CR_test = 18 / 200 = 9%. В контрольной группе оплачены 14 из 200, поэтому CR_control = 14 / 200 = 7%. Абсолютная разница равна 9% − 7% = 2 процентным пунктам, относительная — (9% − 7%) / 7% ≈ 28,6%.

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

Учебный пример: путь от входных данных до результата

Все идентификаторы, времена, данные и решения ниже синтетические. Таблица показывает ожидаемую работу правил, а не результат внедрения у клиента Switch On AI.

Для C12 промежуточная проверка даёт true AND true AND NOT true AND true AND true = false: оплата блокирует письмо, хотя остальные условия выполнены. Запись переходит в состояние paid, задача снимается.

Для C13 проверка останавливается на consent_active = false. Отсутствие оплаты не даёт права отправить письмо без согласия.

Для C14 изменение в 12:20 задаёт новое время: 12:20 + 30 минут = 12:50. В 12:50 система ещё раз проверяет оплату, согласие, отписку и актуальность корзины. Защищённая ссылка после проверки получателя получает текущий состав, а не показывает перечень, сохранённый до изменения.

Как проверить результат перед запуском

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

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

Что согласовать для внедрения

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

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

Switch On AI может разработать ИИ-помощника, бота или интеграцию для этой операции после проверки данных и API. Для описанной задачи чаще достаточно обычной интеграции с явными правилами: ИИ не нужен для проверки булевых состояний оплаты и согласия. Формат решения определяют после разбора процесса; прототип ключевого сценария не равен полноценному внедрению.

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