Триггерная рассылка

Происхождение и история термина

Событийная отправка имеет техническую предысторию в автоматических ответах электронной почты. В августе 2004 года RFC 3834 описывал уже применявшиеся автоответчики об отсутствии сотрудника, почтовые информационные службы и проблемы нежелательных ответов. Событием для них служило входящее письмо. Документ обсуждал и почтовые циклы: автоматические ответы могли провоцировать новые ответы друг другу. ^[6]

В январе 2009 года RFC 5436 развил стандартизацию автоматических уведомлений для языка почтовых правил Sieve и регистрацию признаков автоматически созданных сообщений. Это документированный этап развития событийной почты, а не дата появления маркетингового термина. ^[7] В современной маркетинговой автоматизации исходное событие шире входящего письма: например, Mailchimp позволяет начать сценарий после подписки или покупки. ^[1] Таким образом, сопоставление источников показывает расширение рассматриваемых событий и сценариев; оно не устанавливает единственного изобретателя триггерной рассылки.

Суть и механизм

Разберём учебный сценарий редакции. Читатель подтвердил подписку на образовательный дайджест. Система получила запись об этом событии и связала её с адресатом. По нашему условию первое ознакомительное письмо запланировано на следующий день. Перед отправкой проверяется, сохраняется ли подписка. Если читатель уже отказался от неё, сценарий прекращается. Задержка здесь нужна по замыслу примера, а не потому, что любое приветственное письмо должно ждать сутки.

В таком сценарии различаются три вопроса: что произошло, кому предназначено письмо и нужно ли оно сейчас. Запись о событии отвечает на первый вопрос, контакт — на второй, проверки перед отправкой — на третий. В Mailchimp для подобных решений предусмотрены фильтры входа, разделение пути по условиям, ожидание события и временная задержка. Набор возможностей и ограничения относятся именно к этой платформе. ^[1]

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

Виды и классификации

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

Назначение письма рассматривают отдельно. Руководство американской Федеральной торговой комиссии (FTC) различает коммерческое содержание, содержание о сделках или текущих отношениях с клиентом и прочее содержание. Подтверждение согласованной сделки и продвижение товара относятся к разным категориям; при смешении важна основная цель сообщения. Эта правовая классификация относится к США. ^[3] Она помогает увидеть разницу между поводом и содержанием, но не определяет статус письма по российскому праву.

Как применяется на практике

В международной документации Mailchimp подписка и покупка приведены как основания входа в автоматизацию. ^[1] Российское издание может использовать аналогичную логику как проектную модель, учитывая российские нормы. Учебный пример: после оформления доступа к архиву редакция готовит письмо с инструкцией входа. Если доступ отменён до отправки, прежний текст становится неверным. В нашем проекте система сначала запрашивает актуальный статус и только затем формирует сообщение.

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

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

Учебный журнал должен различать вход в сценарий, допуск к отправке, попытку отправки и её результат. Для простого расчёта возьмём 100 разных адресатов, у каждого по одному событию. Допуск прошли 80 человек, а до конца выбранных суток задания на отправку выполнены для 60. Оставшиеся 20 допущенных ещё ожидают своего времени. Все числа условные.

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

Здесь E — число исходных адресатов, A — число допущенных, M — число адресатов с выполненным заданием. Получаем 80% допуска и 75% выполнения среди допущенных. От исходной группы доля выполненных заданий составляет 60%. Если исходных адресатов нет, D не определена; если нет допущенных, не определена S. Нулевой знаменатель нельзя заменять нулевым результатом.

Ни одна из этих долей не измеряет доставку. Amazon SES описывает ситуацию, когда запрос к сервису выполнен успешно, но письмо на адрес из глобального списка подавления не отправляется. API — программный интерфейс обращения к сервису; его ответ сообщает об обработке запроса, а не о чтении письма человеком. ^[2] В нашем журнале поэтому результаты доставки записываются отдельно от заданий на отправку.

Ошибки, ограничения и спорные вопросы

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

Нельзя одинаково обрабатывать все неудачи доставки. В Amazon SES hard bounce означает устойчивый сбой, например несуществующий ящик, а soft bounce — временную проблему. Жалобы адресатов учитываются отдельно. AWS рекомендует не повторять отправки адресам с устойчивыми сбоями и жалобами. ^[2] Число выполненных заданий также ничего не говорит о полезности содержания: учебный журнал подтверждает исполнение сценария, но не доказывает, что письмо помогло читателю.

Правовой аспект

В России часть 1 статьи 18 закона № 38-ФЗ «О рекламе», в редакции от 04.08.2026, требует предварительного согласия на рекламу по сетям электросвязи; доказательство согласия возложено на рекламораспространителя. По требованию адресата распространение должно прекращаться немедленно. Часть 2 отдельно запрещает рекламу со средствами автоматического выбора или набора абонентского номера без участия человека. Согласие само по себе не отменяет это ограничение; применимость к конкретной системе оценивается отдельно. ^[4]

Статья 5 закона № 152-ФЗ «О персональных данных», в редакции от 26.07.2026, требует соответствия обработки её целям, неизбыточности и точности данных. ^[5] Поэтому описание технического сценария не является юридическим разрешением на его запуск. Правовая оценка должна учитывать содержание писем, основание обработки данных и устройство отправки..

Частые вопросы

Связанные термины

• email-marketing
• crm-sistema
• segmentatsiya-bazy-klientov
• konversiya
• podpisochnaya-model
• lid-skoring