Карта событий для cart recovery: как собрать триггеры так, чтобы письма попадали в нужный момент

Карта событий для cart recovery: как собрать триггеры так, чтобы письма попадали в нужный момент

Если у вас cart recovery сейчас строится “по факту брошенной корзины”, вы неизбежно теряете часть выручки: пользователь возвращается не в момент “оставил корзину”, а позже — при просмотре карточки, изменении параметров, повторном входе или при появлении доставки/наличия. Выход — перейти от одного статуса к событийному “кадру” и связать его с конкретными письмами.

Как сделать за 5–7 дней (только практические шаги):

1) Составьте минимальный набор событий (не больше 8)
Для интернет-магазина/маркетплейса достаточно:
— cart_created (создали корзину)
— cart_updated (изменили состав: количество/вариант/добавили/удалили)
— checkout_started (начали оформление)
— checkout_failed (попытка оформления не завершилась: ошибка/отвал)
— order_placed (покупка)
— product_page_viewed_after_abandon (вернулись и снова смотрят товар после ухода)
— account_logged_in (возврат авторизованного пользователя)
— inventory_or_shipping_changed (изменилось доступность/доставка для позиции из корзины)

2) Определите, какие события “управляют” сериями
Нужны 3 ветки, чтобы не плодить десятки писем:
— Ветка А (быстрое напоминание): cart_created + 30–120 мин без checkout_started
— Ветка B (помощь при проблеме): checkout_failed → письмо с причиной/подсказкой + ссылка на шаг оплаты/адрес
— Ветка C (возврат через интерес): product_page_viewed_after_abandon или cart_updated → письмо “вы уже рядом” (поддержка выбора/конфигурации)

3) Настройте дедупликацию: один контакт = один “сценарный токен”
На уровне CRM/email делайте правило:
— пока не закрыт сценарий (например, в течение 7 дней после события), не запускайте повторно одно и то же письмо для того же контакта по той же “причине”
Технически это решается полем вроде scenario_trigger_id в событии или временным блокером в триггере.

4) Привяжите письма не к времени “X часов”, а к состоянию
В триггере используйте условия:
— Ветка А: “последнее событие для корзины = cart_created или cart_updated” и “нет checkout_started” и “с момента последнего изменения корзины прошло N”
— Ветка B: “последнее событие = checkout_failed” и “код/категория ошибки соответствует типу” (например, недоступно/ошибка оплаты/адрес)
— Ветка C: “последнее событие = product_page_viewed_after_abandon” и “покупка не совершалась”

5) Добавьте “стоп-условия” под retention-логику
Чтобы письма не превращались в спам и не снижали доверие (особенно в 2026, когда конкуренция за внимание жестче):
— немедленно останавливайте сценарий при order_placed
— для авторизованных: останавливайте при account_logged_in, если после логина человек прошёл checkout_started
— не шлите “Ветку А” после успешного checkout_started (даже если покупка не завершилась — тогда вступает Ветка B)

6) Упакуйте причины отказа в 3–5 категорий
В cart recovery ценнее не “мы напоминаем”, а “мы объясняем, что мешает”:
— доставка/наличие
— ошибка оформления/адреса
— проблема оплаты
— технический сбой на шаге
— выбор/совместимость (если релевантно)

7) Сделайте контрольную схему измерений “incrementality”
Внутри вашей аналитики минимум:
— группа контрольного неотправления для одного письма серии (например, первого касания Ветки А)
— оценка разницы по conversion в течение 72 часов и 7 дней
— проверка по сегментам: новые/повторные, корзина с доставкой vs без, ошибка оплаты vs адрес
Это защитит вас от “мы просто попали на тех, кто и так бы купил”.

8) Запустите пилот на одном типе потока и одном канале
На этой неделе достаточно:
— один сегмент (например, пользователи, которые дошли до checkout_failed)
— один тип письма (помощь при проблеме)
— один период (например, 14 дней наблюдения)
После пилота расширяйте на Ветку А и Ветку C.

Если хотите, пришлите вашу текущую схему триггеров (какие статусы есть в CRM и как запускаются письма) — подскажу, какие события добавить первыми и как не раздувать дерево сценариев.