Перенос базы рассылки: чеклист перед сменой ESP

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

Перенос базы контактов в новый сервис рассылок — не копирование CSV-файла. Это смена инфраструктуры, на которую одновременно смотрят почтовые провайдеры, ваша CRM, отдел продаж и сами подписчики. Если торопиться, письма начинают попадать во «Входящие» хуже, автоматизации стреляют мимо, а в первую кампанию внезапно всплывают адреса людей, которые давно отписались.

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

Технический фундамент: готовим DNS до первой отправки

Переезд на другой сервис рассылок стоит начинать не с экспорта базы подписчиков из ESP, а с домена. Новый сервис должен получить право отправлять письма от вашего имени — и это право должно быть понятно Gmail, Mail.ru, Outlook и корпоративным почтовым шлюзам.

Минимальный набор — SPF, DKIM и DMARC.

• SPF показывает, какие серверы могут отправлять письма от имени домена. Здесь особенно легко ошибиться, если в компании уже работают CRM, корпоративная почта, сервис транзакционных писем и старый ESP. SPF-запись должна быть одна: несколько отдельных SPF-записей в DNS не складываются в красивую картину, а создают путаницу при проверке.
• DKIM добавляет криптографическую подпись письму. Новый ESP обычно отдаёт селектор и публичный ключ, которые нужно внести в DNS. После этого проверьте не только факт публикации записи, но и то, что подпись действительно появляется в исходниках тестового письма.
• DMARC связывает всё вместе: он говорит провайдеру, что делать с письмами, которые не проходят проверку SPF или DKIM. При миграции разумнее начинать с режима наблюдения, собирать отчёты и только потом ужесточать политику, если домен к этому готов.

Не отправляйте кампанию в ту же минуту, когда опубликовали записи. DNS обновляется не синхронно: часть резолверов увидит новые данные быстро, часть — позже. Дайте изменениям распространиться, проверьте их через несколько независимых DNS-проверок и отправьте тесты на разные почтовые ящики. В исходнике письма должны корректно проходить SPF и DKIM, а домен в поле From должен быть согласован с политикой DMARC.

Отдельное внимание — техническим адресам, которые часто остаются «за кадром»:

• Поддомен для маркетинговых рассылок. Если основной домен обслуживает корпоративную почту, лучше отделить маркетинговый поток: например, использовать mail.brand.ru или news.brand.ru. Это не магический щит от проблем, но полезная изоляция репутации: ошибки в промо-кампаниях не так прямо бьют по деловой переписке.
• Return-Path и envelope sender. Бounces, технические отказы и часть служебных уведомлений должны возвращаться на корректно настроенный адрес. Иначе вы увидите красивый отчёт в интерфейсе ESP, но не сможете нормально понять, что происходит на уровне доставки.
• Ссылочный домен. Если сервис позволяет брендировать домен трекинга, настройте его заранее. Когда ссылки в письме ведут через чужой технический домен, это выглядит менее последовательно и для подписчика, и для фильтра.
• Postmaster-инструменты. Подключите Gmail Postmaster Tools и Microsoft SNDS, если объёмы и условия доступа позволяют. С Яндекс.Постмастером рассчитывать на прежнюю детальную картину не стоит: сервис закрыт, поэтому доставляемость на адреса @yandex.ru придётся оценивать по собственной статистике ESP, ответам серверов и динамике вовлечённости.

Сохранение репутации домена при переносе начинается именно здесь. Не с красивого шаблона и не с сегмента «VIP», а с того, что письмо технически доказывает своё происхождение.

Гигиена данных: что выгружать и куда складывать

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

Новый ESP не знает истории этой базы. Для него это просто массив адресов, который внезапно начал получать письма с нового технического контура. Поэтому чеклист миграции email базы лучше строить вокруг статусов, а не вокруг одной кнопки «Экспортировать всё».

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

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

3. Разберите холодный хвост. Давняя неактивность не делает контакт автоматически «плохим», но и не делает его подходящим для старта. До миграции уместна реактивационная кампания в старом сервисе, где уже есть наработанная репутация. Тех, кто не отреагировал, лучше не тащить в первую отправку нового ESP. Иногда честнее оставить такой сегмент в архиве, чем пытаться реанимировать его ценой репутации всего домена.

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

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

Стоп-лист — не архив прошлого ESP, а часть вашей репутации. Он должен переехать вместе с активной базой, а не когда уже пришли первые жалобы.

Импортировать исключения нужно именно в механизм подавления отправок нового сервиса: suppression list, blacklist, exclusion list — названия отличаются, смысл один. Просто сохранить файл в папке проекта недостаточно. После загрузки сделайте контрольный поиск по нескольким адресам из стоп-листа и убедитесь, что ESP действительно не позволяет включить их в кампанию или сценарий.

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

Сохранение контекста: метаданные решают всё

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

Если при переезде потерять эту биографию, новый сервис формально будет заполнен контактами, но команда начнёт работать почти вслепую. Вместо письма о повторной покупке уйдёт общий дайджест, вместо локального предложения — акция для другого города, а клиент, который уже получил welcome-цепочку, снова увидит «рады знакомству».

При экспорте базы подписчиков из ESP заранее составьте карту полей: как называется атрибут в старом сервисе, как он будет называться в новом и какой у него тип. Особенно опасны поля с датами, булевыми значениями, списками и валютами: 01.02.2024 может стать текстом, «да/нет» — пустым значением, а несколько интересов в одном поле — нечитаемой строкой.

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

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

Отдельно выпишите автоматизации, которые нельзя выключать безболезненно: welcome-серии, письма о восстановлении пароля, чеки, уведомления о заказе, брошенные корзины, напоминания о продлении. Маркетинговые и транзакционные потоки нередко живут в разных системах, но для получателя это всё один бренд. Если в день миграции он получит два одинаковых письма о заказе или, наоборот, не получит ни одного, репутация пострадает быстрее любого графика прогрева.

Стратегия прогрева: от первых 1 500 писем к рабочему объёму

Новый отправляющий контур для провайдеров — это новая история наблюдений. Даже если бренд, домен и база знакомы аудитории, меняются IP-адреса, подписи, технические заголовки, ссылка трекинга и паттерн отправки. Поэтому резкий выход на полный объём — плохая идея.

Стартовать можно с 1 500 писем по самому активному сегменту, отправляя их равномерно, а не одним залпом. Дальше объём увеличивают примерно на 20% от текущего уровня после нескольких стабильных отправок или через два-три дня, если метрики не дают повода остановиться.

Важно не рисовать себе календарь, который не сходится с арифметикой. При росте примерно на 20% шаг за шагом 1 500 писем превращаются в 1 800, затем в 2 160, 2 590, 3 110 и так далее. До десятков тысяч отправок в день такой путь занимает заметно больше времени, чем пара недель. И это нормально: прогрев не должен соответствовать презентации для руководителя, он должен соответствовать реакции получателей и почтовых провайдеров.

Рабочая логика выглядит так:

• Первый этап: отправляйте только наиболее вовлечённым контактам. Это не время для экспериментов с агрессивной распродажей, редизайном и сложной механикой. Нужны ожидаемые письма с понятной темой и знакомым отправителем.
• Следующие шаги: наращивайте объём приблизительно на пятую часть от предыдущего уровня, если нет аномального роста отказов, жалоб и падения вовлечённости. При сомнении лучше повторить текущий объём, чем «догонять план».
• Подключение тёплого сегмента: добавляйте его не одной большой пачкой, а в пределах очередного роста. Так будет понятно, какой именно сегмент изменил картину.
• Холодные контакты: не смешивайте их с активной базой ради красивого общего объёма. Их реактивация требует отдельного сообщения, отдельной частоты и готовности спокойно остановиться, если аудитория не отвечает.
• Полный объём: достигается тогда, когда несколько последовательных отправок проходят устойчиво, а не в день, который заранее поставили в таблице.

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

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

1. Жёсткие и мягкие отказы. Жёсткий bounce обычно означает, что адрес недоступен и его нужно исключить. Мягкий — что проблема может быть временной: переполнен ящик, недоступен сервер, есть ограничение на стороне получателя. Резкий всплеск любого типа — причина притормозить, а не просто ждать следующей рассылки.

2. Жалобы на спам. Это самый болезненный сигнал: получатель не просто проигнорировал письмо, а сообщил провайдеру, что не хочет его видеть. При росте жалоб сначала проверьте сегмент, стоп-лист, частоту и соответствие обещанию подписки. Потом уже спорьте с темой письма.

3. Клики, покупки, ответы и отписки. Открытие может быть технически искажено, а вот осмысленное действие получателя — более надёжный признак, что письмо дошло до нужной аудитории и не вызвало раздражения.

4. Разрез по почтовым доменам. Gmail, Mail.ru, Яндекс, Outlook и корпоративные адреса могут реагировать по-разному. Общая метрика иногда выглядит терпимо, пока один крупный провайдер уже начал ограничивать поток. Делите отчёты хотя бы по ключевым доменам.

5. Стабильность ритма. После старта не исчезайте на несколько недель и не устраивайте резкий всплеск в день акции. Провайдерам проще интерпретировать предсказуемый поток, а подписчикам — привычную частоту.

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

Оптимизация контента: почему размер письма критичен для доставляемости

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

Gmail обрезает HTML-письма, когда размер их кода превышает примерно 102 КБ. Подписчик видит сообщение не целиком и кнопку «Показать письмо целиком». Это особенно неприятно, если ниже линии обрезки оказались важный блок с товарами, юридическая информация или ссылка на отписку.

Здесь важно не путать вес HTML и вес картинок. Если изображение подгружается с сервера, его байты не раздувают HTML-код до лимита Gmail, но тяжёлая картинка всё равно влияет на скорость загрузки, расход мобильного трафика и общее ощущение от письма. А base64-вставки изображений в код — почти гарантированный способ сделать шаблон неповоротливым.

Держать HTML заметно ниже порога обрезки помогают несколько привычек:

1. Проверяйте итоговый код именно после сборки в ESP. Редактор может добавить лишние стили, служебные комментарии, дублирующиеся блоки и трекинговую разметку. Исходный шаблон в Figma или вёрстке ещё ничего не говорит о реальном весе письма.

2. Не копируйте блоки бесконечно. Карточки товаров, повторяющиеся кнопки и скрытые версии для мобильной адаптации быстро раздувают письмо. Лучше сократить число блоков, чем надеяться, что почтовый клиент всё стерпит.

3. Чистите inline-стили и старые фрагменты. В email-вёрстке inline CSS часто необходим, но после нескольких итераций в шаблоне остаются неиспользуемые правила и вложенные таблицы, которые никто уже не контролирует.

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

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

Перед первой массовой отправкой откройте письмо не только в редакторе нового ESP, но и на реальных ящиках: Gmail в браузере и приложении, Mail.ru, Яндекс, Outlook, корпоративная почта. Проверьте тему, прехедер, отображение картинок, работу ссылок, наличие отписки, корректность персонализации и отсутствие «дыр» в вёрстке. Миграция — плохой момент для надежды, что шаблон «наверняка раньше работал».

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

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

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

Особенно внимательно смотрите на три ситуации:

• Письма доставлены, но действия пропали. Возможно, после импорта потерялись теги, сломалась персонализация или письмо пришло не той аудитории.
• Растут отказы. Проверьте возраст контактов, источник подписки, корректность адресов и то, не попал ли в отправку сегмент, который планировали оставить на потом.
• Появились жалобы. Не пытайтесь залить их новым объёмом, чтобы «усреднить статистику». Остановите расширение, разберите последние получатели, проверьте исключения и обещание, которое человек видел при подписке.

Перенос базы в новый ESP — это перезапуск процесса, а не переезд мебели из одной комнаты в другую. Подготовленный DNS, чистые статусы, сохранённые метаданные, перенесённый стоп-лист и последовательный прогрев делают смену сервиса управляемой. А попытка просто выгрузить всё, загрузить всё и отправить всем обычно заканчивается тем, что команда несколько недель чинит то, что можно было спокойно предусмотреть до первой кампании.