Как собрать «почтовые» триггеры в 1 воронку: from broadcast → lifecycle (без потери доставляемости)

Как собрать «почтовые» триггеры в 1 воронку: from broadcast → lifecycle (без потери доставляемости)

Если у вас триггеры живут отдельно от рассылок, система начинает «конкурировать сама с собой»: разные сегменты, разные частоты, разные темпы роста, а в итоге — просадка по доставляемости и рост жалоб. Эту неделю можно потратить на сборку единой модели: один набор событий → один контроль частот → один мониторинг inbox-рисков.

Шаг 1. Зафиксируйте триггеры как события, а не как письма
Составьте таблицу (10–20 строк достаточно):
— событие (что произошло): просмотр страницы / скачивание / первая сделка / неактивность N дней / открытие без клика / отказ от демо
— объект: клиент/контакт/компания
— окно ожидания: сколько дней вы «ждёте» следующего действия
— целевое действие: клик / регистрация / ответ / повторная активность
Важно: одно событие = один смысл. Письма — это следствие.

Шаг 2. Разведите потоки: «новые» и «реанимация»
Триггеры нужно разнести по скорости принятия решения:
— поток 1 (новые): реакции на свежие действия (в идеале 0–48 часов)
— поток 2 (реанимация): реактивация после паузы (7–30 дней)
Это снижает конфликты с broadcast (массовыми рассылками) и уменьшает риск «перегрева» аудитории.

Шаг 3. Введите frequency caps на уровне контакта (не на уровне кампании)
Сделайте простое правило на неделю:
— максимум 2 письма за 7 дней на контакт, если контакт уже получил broadcast
— максимум 1 письмо за 24 часа, если контакт находится внутри триггерной цепочки
— приоритет: *триггер события* важнее broadcast (массовую можно поставить в очередь/перенос)
Если у вас нет очередей в платформе, реализуйте перенос через «исключения» по статусу: «получил broadcast сегодня/в течение 3 дней» → исключить из списка рассылки.

Шаг 4. Привяжите триггеры к состоянию (state machine в CRM-терминах)
Добавьте 3–5 статусов, чтобы письма не дублировались по смыслу:
— новый лид (не был в lifecycle)
— в процессе (есть активность в последние 14 дней)
— прогрет/ожидает (был клик/заявка, но нет сделки)
— клиент (есть сделка)
— неактивен (нет активности 30 дней)
Дальше: любое событие обновляет статус и выбирает следующий шаг. Так вы уберёте «повторы логики» из разных кампаний.

Шаг 5. Срежьте deliverability-риски через «температуру» домена
Для каждого типа письма используйте свой темп отправок:
— прогревающие/реактивационные цепочки отправляйте меньшими долями (например, 20–30% аудитории за волну)
— если есть рост отказов (hard bounces) или жалоб — остановка цепочки и переключение на более тёплые сегменты
— для новых триггеров первые 3–5 дней держите небольшой пилот и смотрите динамику (отказы, жалобы, доля доставленных)
Так вы заранее снижаете вероятность «общей просадки домена» из-за одной сломанной логики.

Шаг 6. Добавьте «контактный шлюз» между триггером и broadcast
Сделайте правило:
— если контакт получил письмо по триггеру за последние X дней — он исключается из broadcast на ближайшую отправку
X выбирайте по вашему циклу: чаще всего 3–7 дней достаточно
— если контакт не получил триггер за последние X дней — он доступен для broadcast
Это простая механика, которая уже на этой неделе убирает конкуренцию за внимание и улучшает метрики.

Шаг 7. Настройте наблюдение не только по open/click
Для триггеров критичны:
— delivered rate (доставляемость)
— bounce rate (отказы)
— spam complaint rate (жалобы)
— время до следующей реакции (сколько дней до клика/ответа/следующего события)
И обязательно: сравнение «до/после» по группам. С учётом privacy-first атрибуции смотрите на поведение, а не только на last-click.

Шаг 8. Проверьте тестом на «краевые случаи»
Перед включением прогоните сценарии:
— контакт попал в триггер и в broadcast в один день
— контакт получил два разных события подряд (например, просмотр + скачивание)
— контакт отписался/стал недоступен по согласию
В идеале: цепочка должна либо корректно остановиться, либо перейти в состояние «не отправлять».
…