Unisendr: интеграции и планирование рассылок пользователям

Обзор Unisendr и архитектура рассылок

Зачем нужен Unisendr в продукте

Unisendr — это сервис, который помогает централизованно управлять коммуникациями с пользователями: хранить и обновлять контакты, собирать события из продукта, сегментировать аудиторию и отправлять сообщения по разным каналам (чаще всего email, SMS, push, мессенджеры — набор зависит от подключённых провайдеров и настроек).

В рамках курса Unisendr рассматривается как коммуникационный слой между вашим продуктом и пользователями:

продукт генерирует данные (профили, события)

интеграция передаёт данные в Unisendr

Unisendr применяет правила (сегменты, триггеры, расписания)

Unisendr отправляет сообщения через подключённые каналы и собирает статусы доставки

Базовая терминология (без которой сложно обсуждать интеграции)

Контакт и профиль

Контакт — запись о человеке (или получателе), которому можно отправлять сообщения.

Обычно в профиле контакта хранятся:

идентификаторы (например, внутренний user_id вашего продукта)

адреса для каналов (email, телефон, токен push)

атрибуты (язык, город, тариф, дата регистрации)

маркетинговые согласия (подписки, отписки)

Ключевая идея: контакт должен быть однозначно узнаваемым при обновлениях из интеграций.

Список и сегмент

Список — статическая группа контактов (например, “все пользователи, согласившиеся на рассылку”).

Сегмент — динамическая выборка по правилам (например, “пользователи с тарифом Pro, которые не заходили 14 дней”).

Практическое различие:

В список вы обычно добавляете/удаляете контакты действиями (импорт, API-вызов).

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

Событие

Событие — факт действия пользователя (например, регистрация, оплата, добавление товара в корзину).

События нужны для:

триггерных рассылок (отправить “Welcome” после регистрации)

персонализации (подставить товар из последней корзины)

аналитики (какой сценарий даёт больше конверсий)

Шаблон и кампания

Шаблон — подготовленный контент сообщения (текст, переменные, ссылки, параметры).

Кампания — конкретная отправка по аудитории: разовая, по расписанию или триггерная.

Каналы доставки и кто реально “доставляет” сообщение

Unisendr управляет логикой и данными, но физическая доставка зависит от канала:

email доставляется через SMTP-инфраструктуру/провайдеров (правила определяются, в частности, протоколом SMTP и политиками почтовых сервисов)

SMS доставляется через SMS-агрегаторов

push доставляется через платформы (например, мобильные пуш-сервисы)

Поэтому в архитектуре важно разделять:

систему принятия решения (кого и когда отправлять)

систему доставки (как именно сообщение попадёт в ящик/телефон)

систему трекинга (что произошло после отправки)

Если вам нужно понимать основу email-доставки на уровне протокола, ориентиром служит спецификация SMTP: RFC 5321 (Simple Mail Transfer Protocol).

Архитектура рассылок: данные, решения, доставка, обратная связь

Ниже — типовая архитектура рассылок при использовании Unisendr.

!Общая схема: как данные попадают в Unisendr, как формируется отправка и как статусы возвращаются обратно

Слой данных: откуда берутся контакты и события

Источники данных почти всегда несколько:

продуктовая база пользователей (backend)

клиентские события (frontend)

CRM/ERP

биллинг/платежи

Главная цель интеграции — поддерживать в Unisendr актуальные профили и события.

Слой принятия решений: сегменты, правила, частота, приоритеты

В Unisendr обычно живут правила, которые превращают “сырые данные” в “кому и что отправить”:

сегментация по атрибутам и событиям

триггеры (событие → сценарий)

расписание (когда запускать кампанию)

ограничения частоты (чтобы не спамить)

приоритизация (что важнее: сервисное уведомление или маркетинг)

Важно: качество этого слоя напрямую зависит от того, насколько корректно построена интеграция (идентификаторы, консистентность событий, своевременные обновления).

Слой доставки: постановка в очередь и отправка

Типовой жизненный цикл отправки выглядит так:

Unisendr формирует список получателей (по списку/сегменту) и контент (по шаблону).

Сообщения ставятся в очередь на отправку.

Доставка идёт через подключённых провайдеров канала.

Unisendr получает статусы: принято, доставлено, ошибка, отписка и т.д.

На практике доставка — это не “одна кнопка отправить”, а цепочка с возможными сбоями: временные ошибки провайдера, блокировки, неверные адреса, ограничения по скорости.

Слой обратной связи: статусы, отписки, аналитика

После отправки появляются данные, которые нужны и Unisendr, и вашему продукту:

доставляемость (bounces/ошибки)

вовлечённость (открытия/клики — если для канала применимо)

отписки и жалобы (критично для соблюдения правил и качества базы)

Эти данные обычно возвращаются через webhooks или выгрузки, чтобы:

не отправлять дальше на “плохие” адреса

корректно учитывать согласия

строить сквозную аналитику (сообщение → действие в продукте)

Интеграции: какие бывают и чем отличаются

С практической точки зрения интеграции с Unisendr делятся по способу доставки данных.

API-интеграция (онлайн)

Подходит, когда важно обновлять профили и отправлять события в моменте:

регистрация пользователя

подтверждение email/телефона

смена тарифа

транзакции

Плюсы: минимальная задержка, точные триггеры.

Минусы: нужно продумать надёжность (повторы запросов, идемпотентность, обработка ошибок).

Webhooks (входящие/исходящие события)

Webhooks обычно применяются для:

получения статусов доставок и отписок обратно в вашу систему

синхронизации значимых событий между системами

Ключевой момент: ваш обработчик webhook должен быть готов к повторной доставке одного и того же события (это нормальная практика у многих систем), поэтому полезно хранить event_id и обрабатывать идемпотентно.

Пакетная загрузка (batch)

Используется, когда данные обновляются периодически:

ночные выгрузки из CRM

обновление атрибутов большой аудитории

миграции и первоначальная загрузка базы

Плюсы: проще стартовать и контролировать.

Минусы: задержка, сложнее поддерживать “реал-тайм” триггеры.

Планирование рассылок: основные режимы

В Unisendr (и в подобных системах) обычно встречаются три режима запуска.

Разовая кампания

Подходит для:

объявлений

промо

информационных рассылок

Риски: легко “пережечь” базу без ограничений частоты и без корректной сегментации.

Рассылка по расписанию

Подходит для:

регулярных дайджестов

еженедельных/ежемесячных отчётов

напоминаний по календарю

Ключевой вопрос: по какому времени считать расписание (часовой пояс пользователя, компании, проекта).

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

Подходит для:

welcome-серии

брошенной корзины

реактивации

транзакционных уведомлений

Здесь особенно важны:

качество событий

защита от повторов (чтобы один и тот же триггер не отправлялся бесконечно)

окно актуальности (например, “брошенная корзина” имеет смысл в течение ограниченного времени)

Роли идентификаторов: как “склеивать” пользователя между системами

В интеграциях почти всегда есть несколько идентификаторов:

внутренний user_id (в вашем продукте)

email и/или телефон (канальные идентификаторы)

внешний идентификатор в Unisendr (если он есть)

Правило проектирования: выберите основной ключ склейки и придерживайтесь его во всех потоках данных.

Обычно удобно:

использовать user_id как главный ключ (стабильный)

хранить email/телефон как изменяемые атрибуты

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

Доставляемость и соблюдение правил: что важно с первого дня

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

Минимальный набор практик:

отправлять только тем, кто дал согласие (для маркетинговых коммуникаций)

всегда поддерживать отписку и уважать её во всех системах

не пытаться “продавить” отправку на заведомо ошибочные адреса

разделять транзакционные и маркетинговые потоки (по логике, а иногда и по доменам/провайдерам)

Если вы работаете с email, отдельно стоит заранее подготовить доменную аутентификацию (обычно SPF/DKIM/DMARC) — это часто является обязательным условием стабильной доставляемости.

Как эта статья связана с дальнейшими темами курса

Эта статья задаёт карту местности: какие сущности участвуют в рассылках и как данные проходят путь от продукта до пользователя и обратно.

Далее в курсе логично переходить к практическим вопросам:

проектирование интеграции: какие события и атрибуты нужны, как выбрать идентификаторы

подключение и проверка каналов

настройка сегментов и триггеров

планирование и ограничения частоты

обработка статусов доставки, отписок и ошибок

Подготовка: домены, SMTP/API, аутентификация и доставляемость

Как эта тема продолжает архитектуру из предыдущей статьи

В предыдущей статье мы разобрали архитектуру рассылок: данные и события попадают в Unisendr, там принимаются решения (сегменты, триггеры, расписания), далее сообщения уходят в канал доставки и возвращаются статусы.

Эта статья закрывает практический фундамент для слоя доставки и частично для слоя обратной связи: подготовку доменов, выбор способа отправки (SMTP или API провайдера), настройку аутентификации (SPF/DKIM/DMARC) и базовые шаги, чтобы письма доходили во входящие.

Термины, которые понадобятся

Домен отправителя — домен в адресе From, например example.com в no-reply@example.com.

DNS — система записей домена (где настраиваются SPF/DKIM/DMARC).

SPF — политика, какие серверы имеют право отправлять письма от имени домена.

DKIM — криптографическая подпись письма, подтверждающая, что контент не подменили и письмо отправлено уполномоченной системой.

DMARC — правило, что делать, если письмо не проходит SPF/DKIM, и куда слать отчёты.

Доставляемость — практический результат доставки: не только “принято сервером”, но и попадание во “Входящие”, отсутствие блокировок, приемлемая доля ошибок.

Репутация — оценка домена и/или IP у почтовых провайдеров (влияет на фильтрацию).

Домены отправителя: что выбрать до начала интеграции

Один домен или отдельный поддомен для рассылок

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

example.com для основного сайта и корпоративной почты

mail.example.com или news.example.com для маркетинговых рассылок

notify.example.com для транзакционных уведомлений

Плюсы поддоменов:

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

проще разделять политики (частота, контент, списки) и анализировать проблемы

проще постепенно “прогревать” репутацию

Транзакционные и маркетинговые потоки

Разделяйте потоки не только логически в Unisendr, но и на уровне отправителя:

транзакционные: чеки, подтверждения, пароли, статусы заказов

маркетинговые: промо, дайджесты, реактивации

Если всё смешать в одном домене/поддомене, то проблемы маркетинга (жалобы, отписки, спам-ловушки) могут ухудшить доставку критичных транзакционных писем.

Требования к адресу отправителя

Минимальный набор:

реальный домен, которым вы управляете (есть доступ к DNS)

адрес From и Reply-To, на который можно отвечать или который корректно обрабатывается

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

SMTP и API: как Unisendr обычно “подключается” к отправке

На практике Unisendr управляет кампанией и аудиторией, а отправка уходит через подключённого провайдера email. Подключение может быть через SMTP или через API (в зависимости от возможностей провайдера и вашей схемы).

SMTP: когда подходит

SMTP — стандартный протокол передачи почты. Многие провайдеры дают SMTP-учётные данные.

Подходит, когда:

нужна простая модель “отправить письмо” без сложных дополнительных возможностей

инфраструктура уже ориентирована на SMTP

важна совместимость и переносимость

Особенности, которые важно учесть:

ограничения по скорости отправки (throttling) задаются провайдером

статусы доставки и события (bounce, complaint) часто приходят отдельным механизмом (webhooks/фиды)

часть расширенной аналитики удобнее получать через API провайдера

Справка по протоколу: RFC 5321 (Simple Mail Transfer Protocol).

API провайдера: когда лучше

API подходит, когда важны:

точные статусы по каждому сообщению и подробные события

управление подавлениями (suppression list), отписками, жалобами на стороне провайдера

шаблоны и их версияция (если используете шаблонный движок провайдера)

Минусы:

более сильная привязка к конкретному провайдеру

иногда сложнее дебажить на уровне “сырой” доставки, чем через SMTP

Что выбрать для Unisendr

Обычно выбор определяется вашей реальностью:

если у вас уже выбран провайдер email и есть отлаженная схема статусов, SMTP часто достаточно

если вы хотите максимально прозрачную телеметрию и управление репутацией через инструменты провайдера, чаще выигрывает API

Важно: способ отправки не отменяет необходимость SPF/DKIM/DMARC. Эти механизмы проверяются принимающими почтовыми системами независимо от того, отправили вы через SMTP или API.

Аутентификация домена: SPF, DKIM, DMARC

Как это связано с доставляемостью

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

!Схема проверки SPF/DKIM и применения DMARC при доставке письма

SPF

SPF задаётся TXT-записью в DNS и перечисляет источники, которым разрешено отправлять почту для домена.

Практические правила:

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

добавляйте в SPF только нужные источники (ваш провайдер, корпоративный сервис, при необходимости IP)

избегайте “разрастания” SPF: слишком много включений может приводить к ошибкам проверки

Почитать спецификацию: RFC 7208 (Sender Policy Framework).

DKIM

DKIM добавляет в письмо подпись, а публичный ключ хранится в DNS. Получатель проверяет подпись и убеждается, что письмо действительно подписано уполномоченной системой.

Практические правила:

включайте DKIM для всех исходящих потоков (и транзакционных, и маркетинговых)

храните ключи и селекторы управляемо (например, selector1, selector2 для ротации)

при смене провайдера не забывайте обновлять DKIM-записи и отключать устаревшие

Спецификация: RFC 6376 (DomainKeys Identified Mail).

DMARC

DMARC определяет политику обработки писем, которые не проходят проверки, и включает отчётность.

Что обычно настраивают по шагам:

Начать с политики мониторинга p=none, чтобы собирать отчёты и увидеть реальную картину.

Убедиться, что все легитимные источники отправки проходят SPF и/или DKIM.

Усилить политику до p=quarantine.

Дойти до p=reject, когда уверены, что “левых” источников нет.

Отчёты DMARC:

агрегированные (обычно rua) показывают общую статистику

форензик (обычно ruf) могут содержать чувствительные данные и поддерживаются не везде

Спецификация: RFC 7489 (DMARC).

Важная деталь: согласованность доменов (alignment)

DMARC проверяет не просто “есть ли SPF/DKIM”, а согласованы ли домены с тем, что указано в From.

Пример проблемы:

From: no-reply@example.com

письмо физически отправляет провайдер, у которого SPF “проходит” для provider-mail.com

DKIM подписан доменом provider-mail.com

В этом случае SPF/DKIM могут формально пройти, но DMARC для example.com может не пройти из-за несогласованности доменов.

Практический вывод: настраивайте SPF/DKIM так, чтобы они были корректны именно для вашего домена/поддомена отправителя.

Выделенный IP и прогрев: когда это вообще нужно

Провайдеры email могут отправлять:

с общего пула IP (shared)

с выделенного IP (dedicated)

Когда чаще нужен выделенный IP:

большие объёмы отправки

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

сложные сценарии с несколькими потоками и строгими SLA

Но выделенный IP почти всегда требует прогрева:

начинать с малых объёмов

отправлять сначала самой “здоровой” аудитории (активные пользователи)

постепенно увеличивать объём и следить за ошибками, жалобами и вовлечённостью

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

Метрики доставляемости: что мониторить с первого дня

Не ограничивайтесь метрикой “отправлено”. Вам нужны показатели на всём пути.

Минимальный набор метрик

| Метрика | Что означает | Почему важно | |---|---|---| | Hard bounce | постоянная ошибка адреса (не существует) | ухудшает качество базы и репутацию | | Soft bounce | временная ошибка (ящик переполнен, временная блокировка) | сигнал о проблемах частоты или репутации | | Complaint | жалоба “это спам” | один из самых токсичных сигналов | | Unsubscribe | отписка | нормальный механизм самоочистки аудитории | | Delivery rate | доля доставленных | ранний индикатор блокировок | | Inbox placement | попадание во “Входящие” | конечная цель доставляемости |

Как использовать статусы обратно в продукт

Из предыдущей статьи помним слой обратной связи. Практические действия:

при hard bounce помечать адрес как недействительный и прекращать отправку

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

отписки синхронизировать между Unisendr и вашей базой согласий

Подписки, отписки и правовой контур как фактор доставляемости

Даже технически идеальная отправка “сломается”, если аудитория не ожидает письма.

Практические принципы:

храните согласие на маркетинговые коммуникации как отдельный флаг в профиле контакта

отделяйте транзакционные уведомления от маркетинга по смыслу и настройкам

делайте отписку простой и быстрой

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

Чеклист подготовки перед включением первых кампаний в Unisendr

Определить домены/поддомены для транзакционных и маркетинговых писем.

Подключить домен в вашей системе отправки и получить требования по DNS-записям.

Настроить SPF.

Настроить DKIM.

Настроить DMARC, начиная с мониторинга.

Проверить, что From использует домен, который проходит DMARC alignment.

Убедиться, что обработка bounce/complaint/unsubscribe возвращается в ваш контур (webhooks/интеграции), чтобы база самоочищалась.

Начать с ограниченных объёмов и активной аудитории, затем наращивать.

Инструменты для проверки

Проверка DNS и базовых ошибок конфигурации: MXToolbox

Мониторинг репутации и ошибок по домену для Gmail: Google Postmaster Tools

Что дальше по курсу

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

Импорт и управление контактами: поля, теги, сегменты и согласия

Как эта тема связана с предыдущими статьями

В первой статье мы договорились, что Unisendr — это коммуникационный слой между продуктом и пользователями: вы передаёте данные о контактах и событиях, а Unisendr по правилам (сегменты, триггеры, расписания) формирует отправки и возвращает статусы.

Во второй статье мы подготовили фундамент доставки: домены, SPF/DKIM/DMARC, выбор SMTP/API и базовую телеметрию доставляемости.

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

как импортировать контакты и обновлять их без дублей

как проектировать поля (атрибуты) контакта

чем отличаются теги, списки и сегменты

как хранить и синхронизировать согласия, отписки и ограничения

!Как данные о контакте проходят путь от импорта до сегментов и обратно через статусы

Что такое контакт в контексте импорта

Контакт — это запись о получателе, которой можно:

назначить адреса каналов (email, телефон, push-токен)

присвоить атрибуты (язык, тариф, город)

связать согласия (можно ли отправлять маркетинг)

включать или исключать из аудитории (через списки/сегменты)

Ключевой практический вопрос импорта: как Unisendr поймёт, что это тот же самый человек при повторной загрузке? Для этого нужен идентификатор.

Идентификаторы: основной ключ и канальные адреса

Основной идентификатор — стабильный ключ, по которому вы обновляете контакт (часто это user_id в вашем продукте).

Канальные идентификаторы — то, куда физически отправляется сообщение:

email

телефон

push-токен

Практическое правило интеграции:

Используйте user_id как основной ключ склейки, если он есть и не меняется.

Email/телефон храните как изменяемые поля (пользователь может их сменить).

Так вы снижаете риск дублей, когда один и тот же пользователь меняет email, а система создаёт “нового” получателя.

Проектирование полей контакта: что хранить и как

Базовые группы полей

Удобно мыслить не “все поля подряд”, а группами:

Идентификаторы: user_id, внешний ключ CRM

Канальные адреса: email, phone

Профильные атрибуты: first_name, language, plan, city

Технические атрибуты: created_at, last_seen_at, timezone

Согласия и предпочтения: маркетинг по email да/нет, дата согласия, источник

Минимальный набор полей для старта

Ниже — типовая “минималка”, которая уже позволяет сегментировать, персонализировать и корректно соблюдать согласия.

| Группа | Поле | Пример | Зачем нужно | |---|---|---|---| | Основной ключ | user_id | 842193 | обновление без дублей | | Email | email | user@example.com | канал email | | Телефон | phone | +79991234567 | канал SMS/мессенджеры | | Язык | language | ru | локализация контента | | Часовой пояс | timezone | Europe/Moscow | отправка “в локальное время” | | Тариф/роль | plan | pro | сегментация по продукту | | Согласие email-маркетинг | email_marketing_opt_in | true | законность и репутация | | Источник согласия | opt_in_source | signup_form | аудит и разбор инцидентов |

Типы данных и нормализация

Нормализация — это приведение данных к ожидаемому виду до загрузки или в момент загрузки.

Email приводите к нижнему регистру и удаляйте пробелы.

Телефон храните в едином формате (обычно E.164, например +79991234567).

Даты храните в одном стандарте (часто ISO 8601) и договоритесь, в каком часовом поясе они передаются.

Справочные поля (язык, тариф, страна) держите в ограниченном наборе значений, чтобы сегменты не “расползались” из-за опечаток.

Если данные приходят “как попало”, сегменты становятся непредсказуемыми: Plan = Pro, plan = PRO, tariff = pro — формально три разных значения.

Импорт контактов: пакетно и через API

На уровне архитектуры (из первой статьи) импорт — это часть слоя данных. Практически он делится на два режима.

Пакетный импорт

Подходит для:

первичной загрузки базы

периодических синхронизаций (например, раз в ночь)

массовых обновлений атрибутов

Что важно продумать заранее:

Формат файла и кодировка (CSV/JSON, разделители, UTF-8).

Маппинг колонок на поля контакта.

Правило обновления: перезаписывать пустыми значениями или игнорировать пустые.

Дедупликация по выбранному ключу.

Импорт через API

Подходит для:

регистрации пользователя

смены тарифа

обновления email/телефона

событий, от которых зависят триггеры

Ключевые требования к API-импорту:

Идемпотентность: повторный запрос (из-за ретрая) не должен создавать дубликаты и не должен “ломать” данные.

Upsert-поведение: если контакт существует — обновить, если нет — создать.

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

> Идемпотентность в интеграциях означает: один и тот же запрос, выполненный несколько раз, приводит к одному и тому же результату.

Сопоставление полей (маппинг): как избежать “тихих” ошибок

Ма́ппинг — это явное соответствие между полями в ваших источниках и полями контакта в Unisendr.

Пример маппинга:

| Источник | Поле в источнике | Поле контакта | Примечание | |---|---|---|---| | Backend | id | user_id | основной ключ | | Backend | email | email | нормализовать в lowercase | | Backend | locale | language | привести к ru, en и т.д. | | Billing | plan_name | plan | справочник значений | | CRM | city | city | свободный текст, но лучше справочник |

Что особенно часто ломает сегменты и согласия:

обновление “не тем ключом” (например, по email вместо user_id)

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

пустые значения затирают заполненные (если политика обновления не определена)

Дубли и конфликты: типовые сценарии и политика разрешения

Дубль — это ситуация, когда один реальный человек представлен несколькими контактами.

Частые причины:

импортировали сначала по email, потом начали импортировать по user_id

пользователь сменил email, а система создала новый контакт

в разных системах разные ключи, и нет единого “главного”

Рекомендуемая политика:

Один главный идентификатор контакта (предпочтительно user_id).

Email/телефон обновляются как атрибуты.

При конфликте (один email у двух user_id) — фиксируйте инцидент и решайте по бизнес-правилам, а не автоматически “сливайте” без аудита.

Теги, списки, сегменты: что использовать и когда

В первой статье мы различали списки и сегменты. Добавим третью сущность — теги.

Теги

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

Примеры тегов (каждый пункт — одно значение):

source_signup_form

source_webinar_2026_02

import_2026_01

vip

Когда теги особенно полезны:

Нужна быстрая фильтрация “откуда пришёл контакт”.

Нужна ручная операционная метка для команды (например, “VIP”).

Нужна привязка к разовой активности (вебинар, офлайн-мероприятие).

Списки

Список — статическая группа контактов, управляемая добавлениями и удалениями.

Списки удобно применять, когда:

аудитория определяется фактом включения (например, “участники бета-теста”)

вам важна управляемость вручную или через интеграцию “добавить/убрать”

Сегменты

Сегмент — динамическая выборка контактов по правилам, которая пересчитывается на основе актуальных данных профиля и (часто) событий.

Примеры правил сегмента:

plan = pro и last_seen_at старше 14 дней

language = ru и email_marketing_opt_in = true

Ключевая операционная разница:

список требует действий по управлению составом

сегмент требует качественных данных и корректных правил

Как проектировать сегменты так, чтобы рассылки не дублировались

Сегмент — это “вход” в кампанию, поэтому ошибки сегмента напрямую превращаются в лишние письма.

Практики, которые уменьшают дубли и неожиданное поведение:

В правилах сегмента всегда учитывайте согласие для маркетинговых коммуникаций (например, email_marketing_opt_in = true).

Добавляйте “защитные” условия, если сценарий чувствителен к времени (например, “регистрация не позже 7 дней назад”).

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

Разделяйте сервисные уведомления и маркетинг (и по сегментам, и по логике согласий).

Согласия: что это такое и почему без них нельзя масштабировать рассылки

Согласие — это зафиксированное разрешение пользователя получать определённый тип сообщений по определённому каналу.

Важно различать:

маркетинговые сообщения: промо, дайджесты, реактивации

транзакционные/сервисные сообщения: подтверждение регистрации, чек, статус заказа, безопасность

Согласия критичны по двум причинам:

правовая: во многих юрисдикциях маркетинг без согласия незаконен или требует строгих условий

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

Полезные ориентиры (не являются юридической консультацией):

Текст регламента GDPR (EU 2016/679)

Руководство FTC по CAN-SPAM для бизнеса

Модель согласий: минимум, который должен быть в данных

Рекомендуется хранить согласия раздельно:

по каналу (email, SMS)

по типу (маркетинг, сервис)

Пример минимальной матрицы:

| Поле | Тип | Пример | Комментарий | |---|---|---|---| | email_marketing_opt_in | boolean | true | можно ли отправлять маркетинг по email | | email_marketing_opt_in_at | datetime | 2026-02-01T10:15:00Z | когда получено согласие | | email_marketing_opt_in_source | string | checkout_checkbox | откуда получено согласие | | email_unsubscribed_at | datetime | 2026-02-03T12:00:00Z | когда произошла отписка |

Если вы храните только один флаг “подписан/не подписан” без даты и источника, разбор спорных ситуаций и аудит становятся значительно сложнее.

Double opt-in: когда уместен

Double opt-in — это подтверждение подписки через действие в письме (например, клик по ссылке).

Его часто применяют, когда нужно:

повысить качество базы (меньше ошибочных/чужих адресов)

уменьшить жалобы

иметь более сильное доказательство согласия

Отписки, жалобы и bounce: как они должны менять контакт

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

Практическая политика обработки:

Unsubscribe (отписка)

Прекратить маркетинговые отправки по соответствующему каналу.

Сохранить дату и источник отписки.

Complaint (жалоба “это спам”)

Немедленно исключить контакт из маркетинговых отправок.

Относиться к жалобам строже, чем к отпискам, потому что жалобы сильнее влияют на репутацию.

Hard bounce (постоянная ошибка адреса)

Пометить адрес как недействительный и остановить отправки на него.

Soft bounce (временная ошибка)

Анализировать частоту и причины; массовые soft bounce могут означать проблемы с репутацией или частотой.

Обратите внимание: список выше дан нумерованным форматом, потому что пункты являются многошаговыми правилами обработки.

Чеклист импорта и дальнейшего управления контактами

Перед импортом

Выберите основной идентификатор контакта.

Определите набор полей и их допустимые значения.

Договоритесь о политике обновлений (затираем пустыми или игнорируем пустые).

Решите, как вы храните согласия по каналам и типам сообщений.

Во время импорта

Нормализуйте email/телефон.

Логируйте ошибки строк (невалидный email, отсутствует ключ).

Отмечайте источник импорта тегом (например, import_2026_02).

После импорта

Соберите базовую статистику качества: доля пустых ключевых полей, доля невалидных адресов.

Проверьте контрольные сегменты (например, “все с email_marketing_opt_in = true”).

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

Что дальше по курсу

Когда контакты, поля и согласия управляются корректно, можно переходить к следующему практическому уровню интеграций: события и сценарии (триггерные рассылки), идемпотентность событий, предотвращение повторных отправок и планирование кампаний по расписанию с учётом часовых поясов и ограничений частоты.

Создание контента: шаблоны, персонализация, A/B и локализация

Как эта тема связана с предыдущими статьями

В предыдущих статьях мы построили фундамент:

архитектуру рассылок и место Unisendr как коммуникационного слоя

подготовку доставки (домены, SMTP/API, SPF/DKIM/DMARC, статусы)

управление контактами (поля, теги, сегменты, согласия)

Эта статья добавляет следующий уровень: контент, который будет отправляться контактам.

Практический смысл темы такой: даже при идеально настроенной доставке и данных вы получите слабые результаты, если:

шаблон не масштабируется (его сложно менять и повторно использовать)

персонализация ломается из-за качества данных

A/B тесты ставятся так, что результат нельзя интерпретировать

локализация сделана поверхностно (переведён текст, но не учтены формат даты, валюта, тональность и часовые пояса)

!Как данные и правила превращаются в персонализированное сообщение и как затем возвращается обратная связь

Базовые сущности контента

Шаблон

Шаблон — это заготовка сообщения, которую можно многократно использовать в разных кампаниях и сценариях.

Обычно шаблон содержит:

структуру (заголовки, блоки, футер)

текст и изображения

переменные персонализации

условия (показывать блок или нет)

ссылки (часто с параметрами аналитики)

Кампания

Кампания — конкретная отправка, где вы выбираете:

аудиторию (список или сегмент)

шаблон

время запуска (сразу, по расписанию, по триггеру)

параметры тестирования (если есть A/B)

Переменные персонализации

Переменная — это подстановка значения из профиля контакта или из контекста события.

Типовые примеры:

имя: first_name

тариф: plan

язык: language

часовой пояс: timezone

данные последнего события: например, last_order_total

Локаль

Локаль — набор правил, которые определяют язык и форматы (дата, время, валюта), обычно в виде комбинации языка и региона, например ru-RU или en-US.

Для обозначения языков и локалей часто используют теги по стандарту IETF: RFC 5646 (Tags for Identifying Languages).

Проектирование шаблонов, которые масштабируются

Разделяйте общие элементы и контент сценария

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

Практическая модель:

Базовый шаблон бренда

Вставляемые блоки под конкретные сценарии

Единые настройки ссылок и аналитики

Единый стиль переменных и ключей

Соглашение по именованию снижает число ошибок при персонализации и локализации.

| Что | Рекомендуемый стиль | Пример | Почему так удобнее | |---|---|---|---| | Атрибуты профиля | snake_case | first_name, last_seen_at | читаемо, легко маппить из backend | | Флаги согласий | channel_type_opt_in | email_marketing_opt_in | однозначно: канал и тип | | Локализация | ключи строк | email.welcome.title | удобно переиспользовать строки |

Динамические блоки через условия

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

Примеры задач условий:

показывать блок про апгрейд только тем, у кого plan = free

показывать блок “завершите профиль” только если отсутствует phone

не показывать персональное обращение, если имя пустое

Пример псевдосинтаксиса условий (конкретный синтаксис зависит от шаблонизатора и Unisendr-настроек):

Ключевой принцип: в шаблоне не должно быть предположений, что поле всегда заполнено.

Обязательные элементы email-контента

С точки зрения пользовательского опыта и операционной стабильности минимальный набор обычно включает:

понятный From и узнаваемое имя отправителя

тема письма (subject), соответствующая содержанию

прехедер (короткая строка, которую многие почтовые клиенты показывают рядом с темой)

понятный основной текст

видимая причина письма (почему пользователь его получил)

ссылка отписки для маркетинговых писем

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

Персонализация: как сделать её полезной и безопасной

Источники персонализации

Персонализация обычно берётся из двух источников:

Профиль контакта (атрибуты, которые вы импортируете и обновляете)

Контекст события (данные из триггера, например состав корзины)

Практическая разница:

профиль подходит для устойчивых характеристик (язык, тариф, город)

событие подходит для конкретики сценария (что именно пользователь сделал)

Стратегия по умолчанию: что делать при отсутствии данных

Если поле не заполнено, у вас должно быть решение по умолчанию.

Рекомендуемая политика:

для обращения: если first_name пустой, использовать нейтральное приветствие

для языка: если language неизвестен, использовать язык по умолчанию проекта

для времени отправки: если timezone неизвестен, отправлять по времени проекта или включать отдельный сегмент для уточнения часового пояса

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

Персонализация и доставляемость

Персонализация влияет не только на конверсию, но и на доставляемость косвенно:

более релевантные письма обычно дают меньше жалоб и больше вовлечённости

ошибки персонализации (битые переменные, “Hello, {{name}}”) ухудшают доверие и повышают жалобы

Поэтому качество полей, нормализация и дедупликация (из статьи про контакты) напрямую влияют на качество контента.

Ссылки и аналитика

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

Самый распространённый подход для веб-аналитики — UTM параметры. Описание параметров: Campaign parameters (UTM) в Google Analytics.

Практика, которая уменьшает хаос:

договориться о стандарте именования utm_campaign, utm_source, utm_medium

генерировать параметры на стороне шаблона или кампании единообразно

не смешивать “человеческие” и “технические” значения в одном поле

A/B тестирование: как ставить эксперименты в рассылках

A/B тестирование — сравнение двух вариантов (A и B), которые отличаются одним контролируемым фактором, чтобы понять, какой вариант работает лучше. Общее описание: A/B testing.

Что обычно тестируют в рассылках

Частые объекты теста:

тема письма

прехедер

первый экран (первые строки)

призыв к действию и текст кнопки

порядок блоков

уровень персонализации

Правило одного изменения

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

Пример плохого теста:

в варианте B поменяли тему

поменяли весь дизайн

поменяли аудиторию

Если B выиграет, вы не узнаете, что именно сработало.

Как запускать A/B в продуктовой реальности

Практический рабочий подход:

выбрать метрику (например, клики по ключевой ссылке или целевое событие в продукте)

определить аудиторию, которая одинакова по правилам сегментации для A и B

распределить аудиторию случайно и стабильно

запустить тест

принять решение по заранее определённому правилу

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

Типовые ошибки A/B

слишком маленькая аудитория, из-за чего выводы случайны

параллельные кампании пересекаются по аудитории и мешают результатам

метрика выбрана не по цели (например, тестируют открытия, когда цель — покупки)

разная доставляемость у вариантов из-за контентных факторов (например, вариант B чаще попадает в спам)

Локализация: язык, форматы и смысл

Локализация в рассылках — это не только перевод текста.

Уровни локализации

Текст: перевод заголовков, кнопок, юридических фраз

Форматы: дата, время, валюта, разделители

Тон и контекст: обращение на “вы/ты”, культурные ожидания

Ссылки: разные лендинги или справка на соответствующем языке

Модель данных для локализации

Чтобы локализация работала системно, обычно нужны два поля:

language или locale у контакта

язык по умолчанию проекта, если у контакта нет значения

Рекомендуемая минимальная схема:

| Поле | Пример | Назначение | |---|---|---| | language | ru | выбор языка текста | | locale | ru-RU | выбор форматов, если вы различаете регион | | timezone | Europe/Moscow | отправка по локальному времени |

Организация переводов через словарь

Чтобы не копировать шаблоны “по языкам”, часто используют словарь строк.

Пример структуры ключей:

Пример словаря для двух языков (псевдоформат):

Далее шаблон использует ключи и текущий язык контакта.

Локализация и согласия

Согласия не заменяются локализацией.

Практическая связка:

сегмент для маркетинговой рассылки должен включать условие согласия (например, email_marketing_opt_in = true)

внутри шаблона вы локализуете текст и юридические элементы (включая “Отписаться”), но не “обходите” отсутствие согласия

Чеклист перед запуском нового шаблона

Проверить, что все переменные имеют безопасные значения по умолчанию

Проверить условия показа блоков на контактах с пустыми полями

Проверить локализацию хотя бы на двух языках, включая ссылки и форматы

Проверить, что в маркетинговом письме есть корректная отписка

Проверить UTM или иной стандарт маркировки ссылок

Сделать тестовую отправку на разные почтовые сервисы и устройства

Что дальше по курсу

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

Интеграции: API, вебхуки, CRM/сайт и события пользователя

Как эта тема связывает данные, доставку и контент

В предыдущих статьях мы подготовили основу:

архитектуру Unisendr как слоя между продуктом и каналами доставки

домены и доставляемость (SPF/DKIM/DMARC, статусы)

управление контактами (поля, теги, сегменты, согласия)

шаблоны и персонализацию

Теперь собираем всё в рабочую систему: как именно данные попадают в Unisendr и как результаты рассылок возвращаются обратно.

Ключевая идея: интеграция должна обеспечивать актуальные профили, корректные события и надёжную обратную связь (отписки, ошибки, статусы), иначе сегменты, триггеры и персонализация будут работать непредсказуемо.

!Общая схема потоков данных: кто и куда отправляет API-запросы и webhooks

Базовые понятия интеграций

Источник данных

Источник данных — система, где возникает факт или хранится состояние пользователя. Типичные источники:

backend продукта (основной профиль, тариф, безопасность)

сайт и формы (подписки, лиды)

CRM (статусы лидов/сделок, менеджер, сегментация продаж)

биллинг (оплаты, чеки, возвраты)

API-интеграция

API-интеграция — вы инициируете HTTP-запросы в Unisendr, чтобы создать/обновить контакт, отправить событие или запустить сценарий.

Вебхук

Вебхук — HTTP-запрос в вашу систему, который отправляет Unisendr или провайдер доставки, чтобы сообщить о факте: доставка, ошибка, отписка, жалоба.

Событие пользователя

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

Примеры:

user_registered

email_confirmed

order_paid

trial_expiring

Паттерны интеграций: как выбрать комбинацию

На практике почти всегда используется комбинация из трёх потоков.

Онлайн API: контакт и события отправляются в момент действия.

Пакетная синхронизация: периодические выгрузки из CRM/хранилища.

Вебхуки обратно: статусы доставки и изменения согласий возвращаются в ваш контур.

Когда достаточно только пакетной синхронизации

Unisendr используется для редких маркетинговых рассылок

нет триггеров, критичных к минутам

CRM является единственным источником правды по аудитории

Минусы: сложно сделать welcome-цепочки, брошенную корзину и точные окна актуальности.

Когда нужен онлайн API

триггеры должны стартовать быстро (регистрация, оплата)

персонализация зависит от последнего действия

важно минимизировать рассинхронизацию сегментов

Почему вебхуки обычно обязательны

Без вебхуков вы теряете управление качеством базы и согласиями:

отписка может не попасть в вашу базу

hard bounce не остановит дальнейшие отправки

жалоба это спам не приведёт к немедленному исключению

API-интеграция: контакты

Основная операция: upsert контакта

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

Рекомендации к контракту данных:

один стабильный основной ключ (часто user_id)

email и телефон как изменяемые поля

согласия и их метаданные (дата, источник)

Пример полезной структуры данных контакта (псевдоформат):

Политика обновления: не затирать хорошее пустым

Определите правило для каждого поля:

если поле пришло пустым, это удаление или нет данных?

какие поля можно затирать пустым (например, city), а какие нельзя (например, email_marketing_opt_in_at)

Это напрямую влияет на корректность сегментов и персонализации.

Конфликты: один email у разных user_id

Это частый операционный инцидент (ошибка ввода, семейный ящик, перенос аккаунта).

Рекомендуемая практика:

не сливать автоматически без аудита

логировать конфликт (кто, когда, из какого источника)

решать бизнес-правилом (например, приоритет подтверждённого email)

API-интеграция: события пользователя

Зачем события, если есть поля профиля

Поля профиля описывают состояние, а события — историю и момент.

состояние: plan = pro

событие: plan_upgraded с датой и контекстом

События особенно важны для:

триггеров (запуск цепочки)

окон актуальности (например, “оплата 15 минут назад”)

персонализации контекстом (последний заказ, последняя корзина)

Минимальная схема события

Чтобы события были пригодны для триггеров и дебага, удобно иметь следующий минимум.

| Поле | Что это | Пример | Зачем нужно | |---|---|---|---| | event_name | тип события | order_paid | правила сценариев | | event_id | уникальный идентификатор | a3f2... | дедупликация | | occurred_at | время события | 2026-02-03T12:00:00Z | окна актуальности | | user_id | связь с контактом | 842193 | склейка | | properties | контекст события | { "order_total": 1990 } | персонализация |

Именование событий: как не утонуть в хаосе

Правила, которые упрощают поддержку:

используйте единый стиль (например, snake_case)

делайте названия событий действиями (order_paid, а не payment)

фиксируйте словарь событий как договор команды (продукт, маркетинг, разработка)

Пример “каркаса” словаря:

онбординг: user_registered, email_confirmed, profile_completed

покупки: checkout_started, order_paid, refund_issued

удержание: last_seen (если вы реально его отправляете событием), trial_expiring

Надёжность API: идемпотентность, ретраи и лимиты

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

Идемпотентность — свойство операции, при котором повтор запроса не меняет итоговый результат.

В рассылках это критично в двух местах:

upsert контакта

приём событий

Практика:

генерируйте event_id на вашей стороне

храните у себя журнал отправленных event_id хотя бы на окно ретраев

если ваш воркер отправил событие повторно, оно не должно создавать второй триггер

Справка про семантику идемпотентности в HTTP: RFC 9110: HTTP Semantics.

!Как ретраи не должны превращаться в дубли событий и повторные триггеры

Ретраи: какие ошибки повторять

Типичная стратегия:

повторять временные сбои сети и ответы вида 429 или 5xx

не повторять “логические” ошибки вида 400 (невалидные данные)

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

Корреляция: как связывать логи между системами

Чтобы расследовать инциденты, полезно передавать технический идентификатор запроса, например:

correlation_id в теле запроса или заголовке

Тогда вы сможете связать:

запись в ваших логах

запись в логах Unisendr

событие доставки/ошибки через вебхук

Вебхуки: обратная связь по доставке и согласиям

Какие вебхуки нужны в первую очередь

Минимальный список типов обратной связи:

доставка и ошибки: delivered, soft_bounce, hard_bounce

жалобы: complaint

отписки: unsubscribe

Точные названия зависят от Unisendr и подключённого провайдера, но смысл один: изменить профиль и согласия так, чтобы следующий сегмент не включал контакт.

Обработчик вебхуков: требования к реализации

Обработчик вебхуков должен быть:

быстрым (принять запрос и подтвердить)

идемпотентным (одно и то же событие может прийти повторно)

безопасным (проверять подпись или секрет)

Практическая схема обработки:

проверить подпись запроса (если поддерживается)

распарсить payload

проверить, что event_id или аналог ещё не обработан

записать факт в журнал

обновить профиль пользователя в вашей базе (например, выставить email_marketing_opt_in = false при отписке)

Что именно менять в данных при статусах

Полезно заранее зафиксировать таблицу соответствий.

| Входящий статус | Что это означает | Что делать в вашей базе | |---|---|---| | unsubscribe | пользователь отписался | выключить маркетинг по каналу, сохранить unsubscribed_at | | complaint | жалоба это спам | выключить маркетинг по каналу немедленно, пометить как высокорисковый | | hard_bounce | адрес не существует или запрещён | пометить адрес недействительным, остановить отправку | | soft_bounce | временная ошибка | считать и мониторить, не отключать сразу |

Безопасность вебхуков

Рекомендуемый минимум:

отдельный публичный endpoint только для вебхуков

проверка секрета/подписи (если Unisendr предоставляет)

ограничение по IP (если возможно и уместно)

защита от повторов через дедупликацию

Интеграции с сайтом: формы, лиды, подписки

Подписка через форму: что важно передавать

В форме подписки обычно рождается маркетинговое согласие, поэтому важно сразу собрать метаданные:

факт согласия (email_marketing_opt_in = true)

время (opt_in_at)

источник (opt_in_source = signup_form, landing_pricing, webinar)

Если вы используете double opt-in, то первая запись может быть как “ожидает подтверждения”, а финальный opt-in — после клика в письме подтверждения.

Сайт как источник событий

С сайта часто отправляют события верхней воронки:

просмотр ключевых страниц

начало оформления

заполнение формы

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

Интеграции с CRM: синхронизация аудитории и статусов

Два типовых сценария

CRM как источник для маркетинговой сегментации (индустрия, менеджер, стадия сделки)

CRM как источник для триггеров продаж (например, “встреча назначена” → письмо с материалами)

Почему CRM почти всегда пакетная

CRM-данные часто меняются не каждую секунду, и бизнесу обычно достаточно синхронизации:

раз в час

раз в ночь

Главное — договориться о том, какие поля CRM являются источником правды и не будут перетираться данными из продукта.

Маппинг CRM в профиль контакта

Пример, какие поля удобно синхронизировать.

| Поле CRM | Поле контакта | Пример | Использование | |---|---|---|---| | lead_stage | crm_stage | proposal | сегменты по стадии | | account_manager | crm_manager | ivan.petrov | персонализация | | industry | industry | retail | контент по отрасли |

Как связать события и контент: триггеры без дублей

Окно актуальности

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

Пример:

“брошенная корзина” актуальна 1–24 часа

“подтвердите email” актуально до подтверждения или ограниченное время

Окна актуальности снижают риск отправки нерелевантных писем при задержках синхронизации.

Защита от повторов на уровне сценария

Даже при идемпотентных событиях полезны дополнительные предохранители:

хранить флаг “письмо N сценария уже отправлено” в вашей базе или в атрибутах контакта

учитывать этот флаг в сегменте или в логике сценария

Набор практических чеклистов

Чеклист API для контактов

выбран основной ключ (user_id)

определены правила обновления полей (что можно затирать)

нормализация email и телефона сделана до отправки

согласия передаются с датой и источником

Чеклист API для событий

у каждого события есть event_id для дедупликации

фиксирован словарь событий и их properties

occurred_at передаётся в едином формате

события отправляются только из источника, который является “истиной” для этого факта

Чеклист вебхуков

обработчик идемпотентен

настроена проверка подписи/секрета

статусы меняют согласия и валидность адреса

есть журнал входящих событий для расследований

Что дальше по курсу

После того как контакты и события стабильно “ходят” через API, а вебхуки возвращают статусы и отписки, можно уверенно переходить к планированию запусков:

триггерные сценарии и их окна актуальности

расписания с учётом timezone

ограничения частоты и приоритеты кампаний

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

Планирование и автоматизация: кампании, триггеры, drip и расписания

Как эта тема продолжает интеграции, данные и контент

Ранее в курсе мы собрали фундамент:

архитектуру Unisendr как слоя между продуктом и каналами доставки

готовность доставки (домены, SPF/DKIM/DMARC, статусы)

управление контактами (поля, сегменты, согласия)

создание контента (шаблоны, персонализация, локализация)

интеграции (API, события, вебхуки, идемпотентность)

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

В этой статье мы разберём:

какие бывают кампании и чем отличаются

как строятся триггерные сценарии и drip-цепочки

как проектировать расписания с часовыми поясами

как не спамить: ограничения частоты, приоритеты, окна актуальности, дедупликация

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

!Карта автоматизации: от событий и расписаний до доставки и обратной связи

Термины планирования, которые важно различать

Кампания: конкретная отправка сообщения аудитории (разовая или по расписанию).

Триггер: правило запуска по событию или изменению состояния (например, user_registered).

Сценарий: последовательность шагов (условия, задержки, развилки), которая запускается триггером.

Drip-цепочка: частный случай сценария, серия сообщений с паузами (например, онбординг из 3 писем).

Окно актуальности: период, в течение которого событие ещё имеет смысл для коммуникации.

Ограничение частоты: правило, ограничивающее число сообщений за период (например, не больше 2 маркетинговых писем за 7 дней).

Дедупликация: защита от повторной обработки одного и того же события или шага.

Виды кампаний: когда выбирать каждый режим

Разовая кампания

Разовая кампания подходит, когда есть единичная причина отправки:

запуск акции

важное обновление продукта

разовое информационное письмо

Риски разовых кампаний обычно не технические, а операционные:

пересечение аудиторий с другими рассылками

отсутствие частотных ограничений

несогласованность с часовыми поясами

Практика: разовые кампании удобнее всего запускать по сегменту, а не по статическому списку, если аудитория определяется правилами (например, plan = pro и email_marketing_opt_in = true).

Кампания по расписанию

Кампания по расписанию нужна, когда коммуникация повторяется:

еженедельный дайджест

ежемесячный отчёт

регулярные напоминания

Ключевой выбор: по какому времени считать расписание.

по времени проекта (проще)

по локальному времени контакта (правильнее для глобальной аудитории)

Если вы отправляете “каждый понедельник в 9:00”, то без timezone это “9:00 где?” — и пользовательский опыт начнёт ухудшаться.

Триггерная кампания

Триггерная отправка запускается по факту:

регистрация

оплата

окончание пробного периода

брошенная корзина

Триггеры эффективны, потому что письмо “привязано” к контексту пользователя, но они требуют дисциплины интеграций:

корректный event_id для дедупликации

корректный occurred_at для окон актуальности

понятный контракт данных properties, чтобы персонализация не ломалась

Триггеры: проектирование, чтобы не было дублей

Источник правды: где “рождается” событие

У каждого события должен быть один “владелец”, иначе вы получите два разных триггера на одно действие.

Пример:

order_paid должен приходить из биллинга или backend-а платежей

фронтенд может прислать “намерение” (например, checkout_started), но не факт оплаты

Если источников несколько, фиксируйте правило приоритета и не отправляйте дубли.

Дедупликация событий

Механика проста: если одно и то же событие может прийти повторно из-за ретраев, у него должен быть стабильный идентификатор.

Практическое требование к событию:

event_id уникален в пределах типа события и пользователя

при повторной отправке вы используете тот же event_id

Семантика идемпотентности для HTTP описана в стандарте: RFC 9110: HTTP Semantics.

Окно актуальности

Окно актуальности защищает от поздних или нерелевантных отправок.

Примеры окон:

cart_abandoned: отправлять только если событие произошло не более 24 часов назад

email_confirmed: не отправлять “подтвердите email” после подтверждения, даже если событие регистрации пришло повторно

Практический эффект: если интеграция задержалась на 2 часа, сценарий всё равно будет корректным, а если задержалась на 3 дня, сценарий безопасно “протухнет”.

Сценарии и drip-цепочки: как собирать последовательности

Типовые элементы сценария

Обычно сценарий состоит из блоков:

старт по событию

проверка условий (сегментация внутри сценария)

задержка (например, подождать 1 день)

отправка сообщения

выход по стоп-условию (например, пользователь купил)

Важно: сценарий почти всегда требует не только события, но и актуального профиля контакта (поля, согласия, язык, часовой пояс).

Пример drip-цепочки онбординга

Цель: довести пользователя до первого “ценного действия”.

Пример логики:

Триггер: user_registered.

Сразу: письмо “Добро пожаловать”.

Через 1 день: письмо с подсказками, но только если нет события first_value_reached.

Через 3 дня: письмо с кейсами, но только если пользователь был активен хотя бы один раз (last_seen_at обновился).

Ключевой момент: drip-цепочка не должна быть “слепой”. У неё должны быть стоп-условия, иначе она продолжит отправлять письма уже конвертировавшимся пользователям.

Стоп-условия и “глушилки”

Стоп-условие — правило, которое прекращает сценарий.

Типовые стоп-условия:

пользователь совершил целевое событие (order_paid, profile_completed)

пользователь отписался от маркетинга (email_marketing_opt_in = false)

адрес стал недействительным (hard bounce)

Чтобы стоп-условия работали, нужно, чтобы вебхуки отписок и ошибок возвращались в ваш контур и обновляли профиль и согласия (см. статью про вебхуки).

Расписания: часовые пояса, “тихие часы” и контроль нагрузки

Выбор времени отправки

Есть три практические стратегии:

время проекта: проще, но хуже для распределённой аудитории

локальное время контакта: требует корректного timezone

время по сегментам: например, отдельно “Европа/Москва/Америка”, если нет надёжных часовых поясов у всех

Если вы используете локальное время, договоритесь о политике:

что делать, если timezone отсутствует

что делать, если timezone некорректен

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

“Тихие часы”

Тихие часы — диапазон времени, когда вы не хотите отправлять сообщения (например, 22:00–08:00 по локальному времени).

Это особенно важно для каналов, которые “прерывают” пользователя (push, SMS). Для email тоже полезно, если вы заботитесь о жалобах и восприятии бренда.

Планирование нагрузки и очередей

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

Что планирование должно учитывать:

пик нагрузки по времени (например, все регулярные рассылки в понедельник утром)

throttling провайдера

время, нужное на доставку в реальности (не все письма “доезжают” мгновенно)

Практика: разносите регулярные кампании во времени и задавайте “окна отправки”, а не точку в секунду.

Частота и приоритеты: как не превратить автоматизацию в спам

Ограничение частоты (frequency cap)

Ограничение частоты обычно задаётся по типам коммуникаций:

маркетинг: ограничивать строго

транзакционные: не ограничивать или ограничивать мягко, потому что они критичны

Пример политики (как принцип, не как универсальное правило):

не более 2 маркетинговых email за 7 дней

не более 1 реактивационного сценария за 30 дней

Приоритеты между кампаниями

Когда несколько кампаний претендуют на одного и того же пользователя, нужен механизм приоритета.

Распространённые правила приоритета:

транзакционные выше маркетинга

безопасность выше промо

сценарий “подтвердите email” выше “читайте блог”, пока email не подтверждён

Практика: фиксируйте приоритеты письменно и проверяйте пересечения сегментов перед запуском.

Исключения и suppress-сегменты

Suppress-сегмент — аудитория, которой нельзя отправлять конкретный класс сообщений.

Типовые suppress-условия:

email_marketing_opt_in = false

есть жалоба complaint

hard bounce по email

пользователь уже получил шаг сценария (флаг отправки)

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

Данные, которые почти всегда нужны для предсказуемого планирования

Обязательный минимум в профиле контакта

Чтобы расписания, локализация и ограничения работали стабильно, обычно нужен минимум:

user_id как основной ключ

language или locale для языка контента

timezone для локального времени

флаги согласий, например email_marketing_opt_in

Технические поля для защиты от повторов в сценариях

Сценариям часто нужны “технические” отметки.

Два типовых подхода:

хранить флаги в вашей базе и учитывать их в логике интеграции

хранить флаги в атрибутах контакта, чтобы Unisendr мог сегментировать и ветвить

Примеры полей-флагов:

welcome_step1_sent_at

welcome_step2_sent_at

reactivation_started_at

Смысл этих полей: даже если событие пришло повторно или сценарий был запущен ещё раз, вы можете проверить “уже отправляли или нет”.

Поля для операционного контроля

Планирование выигрывает от прозрачности:

last_marketing_email_at (если вы ведёте такое поле у себя)

unsubscribed_at и причина

email_valid или аналог для управления hard bounce

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

Практический процесс запуска: от идеи до стабильной автоматизации

Чтобы автоматизация не превратилась в набор случайных отправок, полезен простой жизненный цикл.

Описать цель коммуникации и метрику (что должно измениться у пользователя).

Определить аудиторию и ограничения (сегмент, suppress-сегмент, частота).

Определить событие или расписание запуска.

Задать окно актуальности и стоп-условия.

Подготовить шаблон с безопасными значениями по умолчанию (если поля пустые).

Проверить пересечения с другими активными кампаниями.

Прогнать тест: тестовые контакты, разные локали, разные почтовые сервисы.

Включить мониторинг: ошибки, отписки, жалобы, конверсию.

Типовые ошибки планирования и как их избегать

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

Нет дедупликации: повторные ретраи превращаются в повторные письма. Решение: event_id и идемпотентность.

Нет стоп-условий: drip продолжает “догонять” тех, кто уже сделал целевое действие. Решение: условия выхода и технические флаги.

Игнорируются часовые пояса: регулярные письма прилетают ночью. Решение: timezone, политика для неизвестных.

Нет частотных ограничений: параллельно идут промо, онбординг, реактивация, и пользователь получает 5 писем за 2 дня. Решение: frequency cap и приоритеты.

Что дальше по курсу

После того как вы умеете проектировать кампании, сценарии, drip-цепочки и расписания, следующий шаг в реальной эксплуатации обычно связан с аналитикой и оптимизацией:

как связывать статусы доставки и поведение в продукте

как измерять влияние сценариев на целевые действия

как безопасно масштабировать частоту и объёмы без потери доставляемости

Аналитика и оптимизация: метрики, отчёты, ретеншн и соблюдение закона

Зачем аналитика нужна именно в Unisendr

В прошлых статьях мы настроили фундамент: доставку (SPF/DKIM/DMARC и статусы), данные контактов и согласий, контент (шаблоны и персонализация), интеграции (API и вебхуки) и планирование (кампании, триггеры, drip, частота).

Аналитика закрывает две практические задачи:

понять, что реально происходит после запуска: дошло ли, прочитали ли, кликнули ли, совершили ли целевое действие

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

Ключевая мысль: в рассылках есть минимум три уровня метрик, и оптимизация работает только тогда, когда они связаны в одну цепочку.

уровень доставки: приняли ли письмо и не заблокировали ли домен

уровень вовлечённости: открыли/кликнули/отписались

уровень продукта: сделали ли покупку, активировались ли, вырос ли ретеншн

!Как связаны данные, отправка, статусы и продуктовые метрики

Базовые сущности аналитики: что именно надо уметь связывать

Кампания, сообщение и получатель

Чтобы строить отчёты без ручной магии, полезно различать три уровня идентификаторов:

campaign_id: идентификатор кампании или шага сценария (что вы запустили)

message_id: идентификатор конкретного отправленного сообщения (одна попытка отправки одному получателю)

user_id: ваш стабильный идентификатор контакта (с чем вы связываете поведение в продукте)

Практическое правило: в продуктовую аналитику должна попадать связка message_id → campaign_id → user_id.

Статусы и события: где они рождаются

события доставки и ошибок приходят от провайдера доставки и/или из Unisendr

отписки и жалобы обычно тоже приходят как события обратной связи

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

Если не построить эту связку, вы будете видеть только метрики уровня канала (открытия/клики) и не сможете уверенно оптимизировать бизнес-результат.

Метрики: что измерять и как не ошибиться в интерпретации

Метрики доставляемости

Это метрики, которые отвечают на вопрос: письмо было технически доставлено и не убивает ли это репутацию?

delivery rate: доля сообщений, принятых получателями

hard bounce: постоянная ошибка адреса

soft bounce: временная ошибка

complaint: жалоба это спам

Практические выводы:

рост hard bounce обычно означает проблему качества базы или нормализации email

рост soft bounce может означать перегрузку, throttling, временные блокировки или деградацию репутации

даже небольшой рост complaint может быстро испортить доставляемость последующих кампаний

Для email полезны внешние источники наблюдения:

Google Postmaster Tools для доменной репутации в Gmail

MXToolbox для проверки базовых DNS-настроек и диагностик

Метрики вовлечённости

Они отвечают на вопрос: пользователь взаимодействует с письмом?

open rate: открытия (для email это метрика с ограничениями и зависит от почтового клиента)

click rate: клики

unsubscribe rate: отписки

Интерпретационные ловушки:

открытия могут быть неточными, поэтому клики часто надёжнее для сравнения вариантов

высокий click rate может быть “обманом”, если письмо попало только самым активным из-за ограничений или ошибок сегмента

отписка сама по себе не всегда плохо, но её всплеск на конкретной кампании почти всегда означает проблему релевантности или частоты

Бизнес-метрики и продуктовые метрики

Эти метрики отвечают на вопрос: рассылка изменяет поведение и деньги?

activation: совершение первого ценного действия после onboarding-коммуникации

conversion: покупка, апгрейд, продление

retention: возврат и активность спустя время

LTV: совокупная ценность пользователя

Практическая дисциплина: заранее определить одно основное целевое действие для кампании и не “прыгать” между кликами и покупками по ходу анализа.

Маркировка ссылок и сквозная аналитика

UTM-параметры: минимум для веб-атрибуции

Самый распространённый способ связать переход из письма с веб-аналитикой это UTM-параметры. Описание: Campaign parameters (UTM) в Google Analytics.

Рекомендуемая дисциплина:

utm_source: источник, например unisendr

utm_medium: канал, например email

utm_campaign: имя кампании или сценария

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

Не только клики: фиксация конверсии в продукте

Чтобы доказать эффект кампании, нужно зафиксировать конверсию в продукте и связать её с рассылкой.

Типовые способы:

UTM + веб-аналитика + связка с user_id после логина

промокод, уникальный для кампании

deeplink с параметрами для мобильного приложения

внутренний correlation_id, который передаётся по ссылке и записывается в событие продукта

Важно: если вы используете персональные идентификаторы в ссылках, оцените риски приватности и утечек, и старайтесь использовать технические токены вместо открытых email.

Отчёты: как построить систему, а не набор разрозненных цифр

Три базовых дашборда

Практически полезно держать три отдельных отчёта, которые отвечают на разные вопросы.

Доставляемость и риски

- delivery, hard/soft bounce, complaint - динамика по домену отправителя и по типу кампаний - топ причин bounces

Эффективность коммуникаций

- клики, отписки, конверсия в целевое действие - сравнение по сегментам, языкам, устройствам - A/B результаты

Когортный эффект и ретеншн

- ретеншн по когортам регистрации - сравнение групп: получали сценарий или нет - влияние частоты коммуникаций на удержание

Когортный ретеншн: как его читать

Ретеншн чаще всего измеряют по когортам, чтобы сравнивать пользователей, пришедших в разные даты.

Простой вариант определения:

Где:

это доля удержания на 7-й день

размер когорты это число пользователей, зарегистрировавшихся в выбранный период

активные на 7-й день это те, у кого было целевое событие активности на 7-й день после регистрации

Практический смысл: если вы меняете onboarding-сценарий, то важно смотреть не только клики по письму, а изменение и более поздних точек.

!Пример отчёта ретеншна по когортам для сравнения сценариев

A/B тесты и оптимизация: что улучшать и как не сломать систему

Что оптимизировать по порядку

Оптимизация обычно даёт лучший эффект, если идти от фундамента к “косметике”.

качество базы и согласий

доставляемость и репутация

сегменты и релевантность

частота и приоритеты

контент и персонализация

время отправки

Если пытаться “лечить” слабую доставляемость сменой темы письма, вы потратите время и получите шум.

A/B тестирование: дисциплина интерпретации

Описание концепции: A/B testing.

Практические правила:

один тест отвечает на одну гипотезу

заранее выбранная метрика успеха, желательно ближе к продуктовой ценности

аудитории A и B должны быть сопоставимы

тест не должен конфликтовать с частотными ограничениями и другими параллельными кампаниями

Частота, suppress-сегменты и оптимизация нагрузки

Оптимизация по частоте почти всегда влияет и на репутацию, и на продуктовые метрики.

Практический подход:

фиксируйте policy по частоте для маркетинга отдельно от транзакционных сообщений

используйте suppress-сегменты как универсальный фильтр

анализируйте корреляцию: рост частоты → рост отписок/жалоб → падение доставляемости → падение конверсий

Обратная связь из вебхуков как основа “самоочищающейся” системы

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

Минимально важные правила:

unsubscribe должен выключать маркетинговое согласие по каналу и фиксировать дату

complaint должен выключать маркетинговые отправки немедленно и жёстко

hard bounce должен помечать адрес как недействительный

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

Соблюдение закона и политики: что нужно продумать технически

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

Ориентиры:

Текст регламента GDPR (EU 2016/679)

CAN-SPAM Act Compliance Guide for Business

Согласие, доказательства и аудит

Для маркетинговых коммуникаций обычно требуется доказуемость:

кто дал согласие

когда

каким способом

Практический минимум в данных контакта:

email_marketing_opt_in как флаг

email_marketing_opt_in_at как время

email_marketing_opt_in_source как источник

Право на отписку и уважение предпочтений

Технические требования, которые стоит считать обязательными:

отписка должна быть простой

отписка должна применяться быстро и надёжно

отписка должна синхронизироваться между Unisendr и вашим контуром

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

Минимизация данных и сроки хранения

Аналитика часто провоцирует собирать “всё и навсегда”, но безопаснее держать дисциплину:

собирать только то, что реально нужно для сегментов, триггеров и отчётов

хранить события и логи ограниченный срок, если нет явной причины хранить дольше

разграничивать доступ к данным: маркетингу не всегда нужен доступ к чувствительным атрибутам

Безопасность ссылок и идентификаторов

Рекомендации для практики:

не помещать открытый email в URL

использовать технические токены или message_id, который сам по себе не раскрывает персональные данные

логировать клики и конверсии так, чтобы вы могли расследовать инциденты, но не расширяли поверхность утечек

Практический чеклист: что внедрить после этой статьи

Ввести соглашение по идентификаторам: campaign_id, message_id, user_id.

Стандартизировать UTM и добавить параметр для message_id, если это уместно.

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

Собрать три дашборда: доставляемость, эффективность коммуникаций, когортный ретеншн.

Зафиксировать policy по частоте и приоритетам, затем измерять её эффект на жалобы и конверсии.

Зафиксировать модель доказательств согласия: флаг, дата, источник.

Как эта статья завершает курс

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

вы видите, где падает доставляемость и почему

вы понимаете, какие сценарии улучшают ретеншн, а какие сжигают базу

вы соблюдаете отписки и согласия так, чтобы снижать юридические и репутационные риски

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