Аудит тарифа сервиса рассылок: пошаговая проверка до оплаты

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

Есть и более неприятная ловушка: показатель Delivered не означает, что письмо оказалось во «Входящих». Чаще всего это лишь подтверждение того, что сервер получателя принял сообщение к обработке. Дальше письмо может попасть в «Спам», отдельную вкладку, карантин или внутреннюю систему фильтрации провайдера. Поэтому проверка тарифа сервиса email рассылок должна включать не только арифметику, но и технический, операционный и юридический аудит.

Модели тарификации: почему выбор между базой и объёмом писем определяет бюджет

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

Оплата по числу контактов

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

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

• еженедельные или ежедневные кампании;
• постоянные welcome-цепочки;
• триггеры по действиям пользователя;
• реактивационные сценарии;
• сегментированные рассылки по нескольким направлениям.

Главный риск здесь — платить за адреса, которые фактически не участвуют в коммуникации. В базу могут попадать дубли, неактивные подписчики, отписавшиеся контакты и технические записи, которые нужны только для хранения истории. Одни платформы считают все такие адреса, другие — только активные, третьи предлагают архивировать неактивных контактов за отдельную плату.

До оплаты нужно выяснить, что именно сервис называет контактом. Это может быть уникальный email-адрес, запись в конкретном списке, профиль с несколькими адресами или даже контакт, который уже отписался, но остался в аккаунте.

Оплата по объёму отправок

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

Модель по объёму может оказаться удобнее при нерегулярной работе:

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

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

Оплата за проверку или валидацию адресов

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

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

Что включить в расчёт

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

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

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

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

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

Скрытые лимиты и функциональные ограничения: за что придётся доплачивать сверх тарифа

Тарифная таблица редко показывает весь рабочий процесс. На лендинге может быть указано, что в сервисе есть автоматизация, сегментация и A/B-тесты, но не сказано, в каком объёме и на каком плане. Для практической оценки важен не сам факт наличия функции, а границы её применения.

Автоматические сценарии

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

Существенны и другие ограничения:

• можно ли разделять путь пользователя по открытию и клику;
• доступна ли остановка сценария после покупки;
• можно ли передавать событие из интернет-магазина или CRM;
• поддерживаются ли цели и конверсии;
• можно ли редактировать активную цепочку без остановки;
• есть ли лимит на количество одновременно работающих автоматизаций.

Линейная серия из нескольких писем и поведенческий сценарий — разные по сложности продукты. Если тариф позволяет только первый вариант, это нужно учитывать ещё до проектирования коммуникаций.

Сегментация и динамический контент

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

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

A/B-тесты

Название A/B-тестирования может скрывать разные возможности. Один сервис просто отправляет две версии части базы, другой умеет автоматически выбрать вариант-победитель и отправить его остальным получателям. Проверьте:

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

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

Пользователи и права доступа

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

Проверьте, входят ли в тариф:

• отдельные учётные записи;
• роли и права доступа;
• журнал изменений;
• согласование кампании перед отправкой;
• ограничение доступа к контактам и отчётам.

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

Брендинг, домен и шаблоны

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

Уточните также:

• можно ли использовать собственные HTML-шаблоны;
• сохраняются ли версии писем;
• доступна ли библиотека блоков;
• можно ли экспортировать шаблоны при миграции;
• кто владеет загруженными изображениями;
• как долго хранятся архивы отправленных кампаний.

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

Частотные и инфраструктурные ограничения

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

До оплаты задайте оператору несколько прямых вопросов:

1. Что произойдёт при достижении лимита?

2. Остановится ли отправка или автоматически включится доплата?

3. Какие операции считаются в лимит: тесты, ошибки, повторы, транзакционные письма?

4. Есть ли отдельные ограничения для API и вебхуков?

5. Можно ли выгрузить базу, историю согласий, статистику и шаблоны?

6. Как меняется цена при переходе на следующий тариф в середине периода?

Тариф нужно оценивать не в идеальном сценарии, а в момент роста. Хороший план — не тот, который дешевле в первый месяц, а тот, где понятен следующий шаг и нет неприятного разрыва между уровнями.

Технический фундамент: проверка поддержки SPF, DKIM и DMARC до начала работы

Доменная аутентификация не является гарантией попадания письма во «Входящие», но без неё усложняется подтверждение легитимности отправителя и контроль почтового потока. Результат зависит от политики конкретного провайдера, репутации домена и IP, содержания письма, поведения получателей и множества других факторов. Поэтому корректная формулировка здесь — не «без аутентификации письмо обязательно попадёт в спам», а «отсутствие или неправильная настройка аутентификации повышает риск проблем с приёмом и фильтрацией».

SPF

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

У SPF есть техническое ограничение на количество DNS-запросов при проверке. Если бездумно объединять записи разных поставщиков, политика может перестать работать корректно. Кроме того, SPF проверяет путь отправки, но сам по себе не защищает видимое поле From от подмены во всех сценариях.

DKIM

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

Именно поэтому описание, будто клиент получает от ESP и публичный, и приватный ключ, некорректно как универсальное правило. На практике заказчику чаще передают имя селектора и значение публичной DNS-записи либо CNAME, указывающий на запись платформы. Проверьте:

• кто генерирует ключ;
• где хранится закрытая часть;
• можно ли менять селектор;
• поддерживается ли ротация ключей;
• входит ли DKIM в выбранный тариф;
• подписываются ли маркетинговые и транзакционные письма одинаково.

DMARC

DMARC задаётся владельцем домена в DNS и определяет, как получателю трактовать сообщения, которые не проходят проверку SPF и DKIM с учётом выравнивания доменов. Политика может быть наблюдательной или более строгой. Выбор режима — ответственность владельца домена, а не автоматическая функция ESP.

Сервис может помочь подготовить запись, предоставить инструкции, собирать отчёты или предложить отдельный инструмент анализа. Но это не означает, что ESP «включает DMARC» вместо клиента. До перехода к строгой политике нужно понимать, какие легитимные источники отправки уже работают от имени домена: CRM, сайт, бухгалтерская система, служба поддержки и другие платформы.

Что запросить у сервиса

До оплаты попросите документацию по доменной настройке и проверьте:

1. Какие записи нужны для SPF, DKIM и собственного домена ссылок.

2. Можно ли настроить аутентификацию на выбранном тарифе.

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

4. Кто отвечает за генерацию и хранение DKIM-ключей.

5. Есть ли проверка DNS в интерфейсе.

6. Можно ли получить сведения о неудачных проверках и причинах ошибок.

7. Как изменится настройка при миграции на другой IP или тариф.

8. Предоставляет ли оператор рекомендации по DMARC-отчётам, но не подменяет ли ими полноценный контроль домена.

После публикации записей сделайте тестовую отправку на несколько почтовых систем и изучите заголовки. Ищите Authentication-Results, Received-SPF, DKIM-Signature и сведения о проверке DMARC. Наличие подписи ещё не доказывает, что письмо будет принято одинаково всеми провайдерами, но отсутствие ожидаемых результатов укажет на проблему до запуска полноценной кампании.

Вопрос о выделенном IP и обратной DNS-записи тоже уместен, но не превращайте его в универсальное требование. Dedicated IP имеет смысл при достаточном и стабильном объёме отправок, когда команда готова самостоятельно поддерживать репутацию и проходить процедуру разогрева. Для небольшого объёма общий пул может быть практичнее: его репутацией управляет провайдер, хотя клиент при этом зависит от качества соседних отправителей.

Доменная аутентификация подтверждает право отправлять почту, но не обещает место во «Входящих». Это фундамент доверия, а не билет в обход фильтров.

Реальная доставляемость против отчётов ESP: почему 99% успешных отправок — не Inbox

В отчёте ESP показатель Delivered обычно означает, что сервер получателя принял сообщение на определённом этапе SMTP-обмена. Ответ 250 OK важен, но он не равен факту прочтения и не доказывает размещение во «Входящих».

После принятия письмо может:

• оказаться во вкладке «Промоакции» или другой категории;
• попасть в папку «Спам»;
• пройти дополнительную проверку после завершения SMTP-сеанса;
• быть отфильтровано по внутренним правилам организации;
• попасть в карантин;
• быть удалено или скрыто системой провайдера без подробного сигнала отправителю.

Inbox Placement Rate — показатель размещения во «Входящих» — требует отдельного измерения. Большинство ESP не могут достоверно определить эту метрику для всей базы только по стандартному отчёту отправки. Поэтому обещание высокой доставляемости нужно разбирать по определению, а не принимать как гарантию видимости.

Что смотреть в отчётности

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

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

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

Проверка до запуска

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

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

Дополнительно проверьте:

• репутацию домена отправителя;
• репутацию выделенного или общего IP-пула;
• наличие ограничений для нового домена;
• порядок разогрева нового IP, если он используется;
• рекомендации по объёму первой отправки;
• процедуру приостановки кампании при росте отказов или жалоб.

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

Юридическая чистота и локализация: требования 152-ФЗ и особенности оплаты для бизнеса в РФ

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

Локализация первичного сбора

Требования 152-ФЗ к локализации нельзя пересказывать как универсальное правило о том, что любая обработка персональных данных граждан РФ всегда должна происходить исключительно на российских серверах. Важен конкретный сценарий: какие данные собираются, для какой цели, кто является оператором, какие действия выполняются при первичном сборе и где находится используемая информационная система.

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

Трансграничная передача

При использовании иностранной платформы выясните:

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

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

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

Оплата и документы

Для российского юридического лица стоимость тарифа — только одна сторона вопроса. Важны также:

• возможность оплаты от имени организации;
• валюта и способ выставления счёта;
• комплект закрывающих документов;
• наличие договора или оферты с понятными реквизитами;
• порядок возврата средств;
• налоги и комиссии;
• поддержка закупочной процедуры компании;
• возможность быстро получить подтверждение оплаты.

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

Конфиденциальность и использование данных

Terms of Service и Privacy Policy нужно читать не только ради формального согласия. Ищите положения об использовании загруженных контактов, содержимого писем, событий, аналитики и технических логов. Важно понять, может ли оператор:

• передавать данные подрядчикам;
• использовать их для собственных аналитических целей;
• хранить их после удаления аккаунта;
• объединять данные с другими продуктами;
• менять условия обработки в одностороннем порядке;
• использовать содержимое писем для обучения или улучшения сервисов.

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

Как провести проверку до оплаты

Аудит удобнее проводить не по рекламной странице, а по собственному рабочему сценарию. Возьмите одну реальную рассылку, автоматическую цепочку и, если они есть, транзакционные письма. Затем последовательно проверьте их на выбранном тарифе.

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

2. Оцените размер активной базы и отдельно зафиксируйте неактивные, отписавшиеся и архивные контакты.

3. Рассчитайте объём писем по каждому сценарию, включая ветвления и повторные отправки.

4. Сравните стоимость модели по базе и модели по отправкам, если сервис предлагает обе.

5. Проверьте срок действия пакета, правила докупки и последствия превышения лимита.

6. Убедитесь, что нужные автоматизации, сегменты, A/B-тесты и роли пользователей доступны именно на выбранном плане.

7. Запросите инструкции по SPF и DKIM, а DMARC рассматривайте как политику, которую владелец домена настраивает и контролирует самостоятельно.

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

9. Изучите отчётность по отказам, жалобам и доменам получателей, не подменяя её показателем Delivered.

10. Уточните правила разогрева, ограничения для нового домена и ответственность за общий IP-пул.

11. Для бизнеса в РФ проверьте локализацию первичного сбора, трансграничную передачу, договор, документы и порядок удаления данных.

12. Сравните помесячную и годовую оплату не только по скидке, но и по условиям возврата, изменения тарифа и миграции.

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

Заключение

Проверка тарифа сервиса email рассылок — это не поиск самой низкой цены в таблице. Нужно понять, как платформа считает контакты и отправки, какие функции потребуются через несколько месяцев, кто отвечает за доменную аутентификацию, что именно означает отчёт о доставке и как сервис работает с персональными данными.

Особенно осторожно относитесь к универсальным обещаниям. Высокий процент Delivered не гарантирует попадание во «Входящие». Наличие SPF, DKIM и DMARC улучшает контроль над отправителем, но не отменяет фильтрацию по репутации и содержанию. Зарубежная инфраструктура не всегда автоматически нарушает требования 152-ФЗ, однако требует отдельного анализа первичного сбора, хранения и трансграничной передачи.

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

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

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