Что делает ESP
ESP (Email Service Provider) — сервис, который владеет email-каналом. Его зона ответственности сводится к пяти блокам:
| Блок | Что входит |
|---|---|
| Отправка | Очереди, скорость рассылки, повторные попытки, обработка отказов |
| Доставляемость | Настройка домена и подписей SPF, DKIM, DMARC, репутация IP и домена, прогрев |
| База подписчиков | Хранение адресов, статусы, подписки и отписки, обработка жалоб |
| Контент | Редактор шаблонов, подстановка полей, A/B-тест темы письма |
| Автоматизации | Приветственные цепочки, реактивация, серии по расписанию и событиям |
Главное, за что платят ESP, — не редактор писем. Это доставляемость: набор технических и репутационных факторов, определяющих, попадёт письмо во «Входящие» или в спам. Именно поэтому ESP нельзя «собрать на коленке»: почтовые провайдеры оценивают историю отправителя, а не качество вёрстки.
Отдельная обязанность ESP — корректная работа с подписками. Отписка должна отрабатываться в момент клика и распространяться на все рассылки; жалобы на спам — учитываться автоматически. Нарушение этой механики бьёт по доставляемости всей базы.
Чем ESP не является
Термин часто используется как синоним «системы для маркетинга», из-за чего в один ряд попадают четыре разных класса продуктов. Разграничение проще всего проводить по вопросу «чем система владеет».
| Класс систем | Чем владеет | Типовые задачи | Чего не делает |
|---|---|---|---|
| ESP | Каналом email | Отправка, доставляемость, шаблоны, подписки, базовые цепочки | Не собирает поведенческий профиль по сайту, не персонализирует онсайт |
| CDP | Профилем клиента | Сбор событий, склейка идентификаторов, единый профиль, сегменты | Не отправляет письма, не владеет доменной репутацией |
| MAP | Сценарием | Мультиканальные цепочки, ветвления, паузы, выбор канала на шаге | Обычно не строит товарные рекомендации, не переранжирует каталог |
| Платформа персонализации | Контентом и подбором | Рекомендации, сортировка листингов, динамический контент на сайте и в приложении, A/B-тесты | Не отправляет письма, push и SMS — транспорта у неё нет |
Формулировка, которую стоит держать в голове при проектировании стека: ESP владеет каналом, CDP владеет профилем, MAP владеет сценарием, платформа персонализации владеет содержимым. Пересечения по функциям будут всегда, но зона ответственности при инциденте определяется именно этим разделением.
Как эти системы работают вместе
Типовая связка для интернет-магазина выглядит так:
Сайт / приложение → события → CDP (единый профиль, сегменты)
↓
MAP / автоматизации ESP → выбор момента и аудитории
↓
Платформа персонализации → товарный блок под конкретного получателя
↓
ESP → сборка письма → отправка → доставка
↓
события открытий и кликов → обратно в CDP
Разделение ролей на практике:
- Кому отправлять — определяет сегмент из CDP или условие сценария в MAP.
- Когда отправлять — определяет триггер: событие на сайте, статус заказа, расписание drip-кампании.
- Что показать внутри — определяет платформа персонализации: подборка товаров под профиль получателя, а не одинаковый для всех блок «хиты продаж».
- Как доставить — определяет ESP: сборка, отправка, обработка отказов и отписок.
Явно: платформа персонализации не заменяет ESP и не рассылает письма самостоятельно. У неё нет ни отправляющей инфраструктуры, ни доменной репутации, ни механики подписок и отписок. Её вклад в email-канал ограничен двумя вещами — содержимым товарных блоков и обменом сегментами. Это относится и к Gravity Field: платформа отдаёт рекомендации для вставки в письма стороннего сервиса рассылок, а сама отправкой не занимается.
Типичные ошибки в связке
- Дублирование сегментации в двух системах. Сегменты живут и в CDP, и в ESP, расходятся через месяц, и никто не знает, какой считать верным. Источник правды должен быть один.
- Отписка только в ESP. Если отзыв согласия не доезжает до CDP и остальных систем, человек продолжает получать коммуникации в других каналах.
- Ожидание онсайт-персонализации от ESP. Данные о поведении на сайте в ESP приходят усечёнными и с задержкой; строить на них подбор товаров в реальном времени не получится.
- Ожидание рассылок от платформы персонализации. Обратная ошибка: транспорта у неё нет, и попытка «сэкономить на ESP» упирается в отсутствие доставляемости как таковой.
- Статичный блок рекомендаций в письме. Одинаковая подборка для всей базы даёт тот же эффект, что и любой неизменный баннер, — её перестают замечать.
- Отсутствие обратного потока данных. Открытия и клики из ESP должны возвращаться в профиль, иначе данные первой стороны остаются неполными, а сегментация — грубой.
Чек-лист выбора и настройки
- Проверить поддержку SPF, DKIM, DMARC и наличие выделенного IP при объёмах от сотен тысяч писем.
- Уточнить модель тарификации — по подписчикам или по отправкам — и сверить её с планируемой частотой рассылок.
- Убедиться в наличии API и вебхуков: без них ESP не связать с CDP и платформой персонализации.
- Определить единый источник правды по сегментам и по статусу согласий.
- Настроить обратный поток событий (открытия, клики, отписки) в профиль клиента.
- Проверить, что персональные блоки в письме формируются под получателя, а не одинаковы для всей базы.
- Зафиксировать зоны ответственности между системами до запуска — при инциденте с доставляемостью или неверной подборкой это экономит дни разбирательств.