Как спроектировать приветственную цепочку писем с понятными условиями переходов

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

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

Сначала задайте цель цепочки и состояние подписчика

Узкий вопрос у такой цепочки один: что должен понять и сделать новый подписчик в первые несколько дней после подтвержденной подписки. Для учебного сценария достаточно простой цели: познакомить с отправителем, дать один полезный материал и затем отправить разное третье письмо в зависимости от поведения. Важно не пытаться решить welcome-цепочкой сразу все задачи: продажи, опрос, прогрев, реактивацию и повторные касания. Чем больше задач вы смешиваете, тем труднее управлять переходами.

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

Минимальный набор полей для логики небольшой:

• confirmed_subscription_at — когда подписка подтверждена;
• welcome_flow_active — идет ли сценарий сейчас;
• welcome_state — текущее состояние в цепочке;
• material_clicked_at — было ли явное действие по полезному материалу;
• is_customer и unsubscribed — признаки немедленного выхода;
• permanent_bounce — признак постоянной недоставки адреса;
• welcome_completed_at — когда сценарий закончился.

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

Соберите таблицу переходов, а не просто список писем

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

У такой таблицы есть сильная практическая сторона: она сразу выявляет пропуски. Например, если в ней нет строки «что делать при повторном входном событии», система будет решать это сама — а значит, не всегда так, как вы ожидаете. Еще одна частая ошибка — не прописать приоритет условий. Для welcome-цепочки полезно принять простое правило: условия выхода сильнее, чем условия перехода. Если человек стал клиентом в тот же день, когда должен уйти в третье письмо, он выходит, а не получает еще одно письмо по инерции.

Отдельно проверьте выход из цепочки и повторный вход

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

Повторный вход — второй источник дублей. По умолчанию лучше запретить его, пока welcome-цепочка активна. Это значит, что повторное событие confirmed_subscription через пять минут не должно запускать вторую копию сценария. После завершения цепочки можно задать отдельное правило повторного входа, например: разрешать новый запуск только если появилась новая подтвержденная подписка позже welcome_completed_at и прошло не меньше условного периода охлаждения. Для учебного примера ниже я беру 30 дней. Это не универсальная норма, а понятный способ защититься от случайных перезапусков.

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

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

Учебный пример. Допустим, у нас есть цепочка после подписки на подборку материалов. Логика такая: письмо 1 отправляется сразу после подтверждения подписки; письмо 2 с полезным материалом — через 1 день; письмо 3 зависит от явного действия по материалу и уходит через 2 дня после письма 2. Если клик по ссылке был, отправляем углубляющее письмо 3A. Если клика не было, отправляем короткое напоминание 3B. Выход из сценария — при отписке, переходе в статус клиента или постоянной недоставке. Повторный вход в течение 30 дней запрещен.

Исходные тестовые контакты и ожидаемые маршруты можно описать так:

Проверяемый результат здесь не маркетинговый, а логический: каждый тестовый контакт должен пройти ровно один ожидаемый маршрут. Если Борис получил письмо 3B вместо 3A, значит условие клика проверяется не в том окне. Если Глеб получил два приветствия, значит на входе нет защиты от повторного события. Если Вера все равно дошла до письма 2, значит выходные условия проверяются слишком поздно. Такой результат можно перепроверить по журналу событий и времени отправок без каких-либо предположений о конверсии.

Как проверить цепочку до реальной рассылки

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

Потом перенесите схему в тестовый сегмент и сократите задержки. Например, вместо одного дня поставьте 10 минут, а вместо двух дней — 20 минут. Так вы проверите тот же порядок переходов, но не будете ждать почти неделю. Тестовый сегмент лучше держать отдельно от реальной базы, чтобы не смешать служебные адреса с настоящими подписчиками. После каждого шага смотрите не только на факт отправки письма, но и на то, как меняются поля welcome_state, welcome_flow_active и welcome_completed_at.

Отдельно проверьте граничные случаи:

• клик по материалу пришел ровно в момент окончания задержки;
• человек кликнул после того, как уже ушло письмо 3B;
• из интеграции дважды пришло входное событие подряд;
• контакт вышел из цепочки за минуту до следующей отправки;
• у письма 2 не сработала ссылка, и поле клика осталось пустым;
• доставка временно сбоила, но адрес не получил признак постоянной недоставки.

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

Если хотите потренировать такие сценарии системно, посмотрите карточку курса «Маркетолог коммуникаций (CRM-маркетолог)». По официальной программе там подтверждены темы построения цепочек писем, создания приветственного письма для сегмента, сбора статистики, A/B-тестирования и расширенных сценариев автоматизации. Это полезно, если вам нужно не только нарисовать welcome-цепочку, но и увязать ее с CRM и аналитикой.