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

MAATRIX

«Mautic бесплатный» — первая фраза, которую слышит любой, кто ищет альтернативу платному email-сервису. И это правда: лицензия открытая, платить за сам продукт не нужно. Но за первым письмом, отправленным со своего Mautic, обычно следует второй вопрос — почему открываемость упала вдвое, а часть писем вообще не доехала. Бесплатность здесь касается только строчки в прайсе за софт, а реальный счёт приходит по другим статьям: доставляемость, время администратора и инфраструктура вокруг очереди отправки. Разберём, из чего на самом деле складывается стоимость владения Mautic.

Что в Mautic действительно бесплатно, а что нет

Сам код Mautic распространяется с открытой лицензией — вы можете скачать, установить и модифицировать платформу без единого платежа разработчикам. Это честно закрывает одну статью расходов SaaS-сервисов: ежемесячную плату за платформу, привязанную к числу контактов или писем. На объёмах в сотни тысяч писем в месяц эта экономия действительно заметна.

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

• Сервер — VPS с ресурсами под веб-приложение, базу данных и фоновые задачи.
• Репутация отправителя — то, что бесплатно даёт SaaS-сервис за счёт масштаба своих клиентов, вам придётся строить с нуля на собственном домене и IP.
• Время администратора — настройка, мониторинг очередей, разбор блокировок, обновления после каждого релиза.
• Транспорт — либо свой почтовый сервер с собственной репутацией, либо стороннее SMTP-реле, за использование которого платите по тарифу провайдера.

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

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

Mautic — тяжеловесное PHP-приложение поверх Symfony, с базой MySQL или MariaDB, очередями заданий и веб-интерфейсом, который активно ходит в базу при построении сегментов. На небольшой базе контактов (до нескольких тысяч) хватает скромного VPS: 2 ядра CPU и 4 ГБ RAM для связки Mautic плюс MySQL уже дают рабочую конфигурацию, если не гонять тяжёлые сегменты каждую минуту.

По мере роста базы и частоты кампаний растёт и нагрузка — в первую очередь на MySQL, потому что пересчёт динамических сегментов на десятках тысяч контактов с несколькими условиями фильтрации — это полноценные SQL-запросы с джойнами, и они не бесплатны по CPU. На базах от нескольких десятков тысяч контактов с активными сценариями практический минимум — 4 ядра и 8 ГБ RAM, отдельно вынесенная база на SSD и настроенный кэш (Redis или Memcached) под сессии и очереди. Точные цифры зависят от количества полей в сегментации и частоты запуска кампаний — воспринимайте это как ориентир, а не как гарантированный порог.

Отдельная деталь, которую часто упускают при переезде с SaaS: Mautic не «просто работает» после установки — веб-сервер должен обслуживать не только интерфейс, но и постоянный поток cron-задач, о которых дальше.

Доставляемость — вот где начинается настоящий счёт

SaaS-сервисы email-маркетинга годами нарабатывали репутацию своих отправляющих IP и доменов у Gmail, Mail.ru и Яндекса. Когда вы отправляете письмо через такой сервис, вы частично пользуетесь чужой репутацией, встроенной в инфраструктуру провайдера. Переходя на свой Mautic, вы теряете этот бонус полностью: новый IP и новый домен для писем воспринимаются почтовыми системами как незнакомые, а незнакомое — это по умолчанию подозрительное.

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

1. SPF, DKIM, DMARC — три DNS-записи, без которых крупные почтовые провайдеры либо сразу отправляют письма в спам, либо не принимают их вовсе. Настройка каждой описана в отдельном материале — если вы ещё не разбирались с этими тремя записями, начните с SPF, DKIM и DMARC простыми словами, а конкретные шаги для VPS — в гайде по настройке SPF, DKIM и DMARC на VPS.
2. Прогрев IP и домена — резкий старт рассылки с нового IP на объём в тысячи писем в день выглядит для почтовых систем как поведение спам-бота. Репутацию нужно нарабатывать постепенно: начинать с малых объёмов на самых лояльных сегментах (те, кто недавно сам подписался и активно открывает письма), и в течение нескольких недель плавно увеличивать объём.
3. Мониторинг репутации — постоянное отслеживание bounce rate, жалоб на спам и попадания в блэклисты. Google Postmaster Tools и аналогичные инструменты дают обратную связь, но её нужно кто-то регулярно читать и реагировать на просадки.

Здесь и находится главная скрытая статья расходов Mautic: доставляемость — не разовая настройка, а постоянный процесс. SaaS-сервис берёт его на себя и включает в подписку. При самостоятельном хостинге его берёте на себя вы — либо своим временем, либо временем нанятого специалиста.

Очереди отправки: там, где Mautic превращается в devops-задачу

Mautic не отправляет письма мгновенно из веб-интерфейса — он ставит их в очередь и обрабатывает через набор консольных команд, которые должны запускаться по cron с определённой периодичностью. Минимальный рабочий набор задач, которые нужно прописать в crontab:

* * * * * php /var/www/mautic/bin/console mautic:segments:update --env=prod
* * * * * php /var/www/mautic/bin/console mautic:campaigns:rebuild --env=prod
* * * * * php /var/www/mautic/bin/console mautic:campaigns:trigger --env=prod
* * * * * php /var/www/mautic/bin/console mautic:emails:send --env=prod --message-limit=200

Это не разовая настройка «поставил и забыл». За каждой из этих команд нужно следить:

• Отставание очереди. Если объём писем растёт быстрее, чем успевает обрабатывать mautic:emails:send, письма начинают уходить с задержкой в часы, а не минуты — для триггерных писем (подтверждение регистрации, восстановление пароля) это критично.
• Обработка отказов (bounce). Mautic умеет разбирать входящие уведомления о недоставке через IMAP-ящик или через вебхуки транспортного провайдера, но этот канал нужно явно настроить и проверять, что он действительно работает — иначе база копит мёртвые адреса, а доставляемость тихо падает.
• Блокировки и повторные попытки. Временные отказы (4xx-коды от принимающего сервера) требуют повторной отправки с задержкой, постоянные (5xx) — исключения адреса из будущих рассылок. Логику нужно проверять по логам, а не предполагать, что она сама справится в любой ситуации.
• Масштабирование воркеров. На больших объёмах одного cron-запуска раз в минуту с лимитом писем недостаточно — нужно либо увеличивать message-limit, либо переходить на очередь через Redis/RabbitMQ с несколькими параллельными обработчиками, что уже требует отдельной настройки очереди сообщений.

Каждый из этих пунктов — не разовая работа, а процесс, который нужно поддерживать постоянно, особенно после обновлений Mautic, когда поведение команд иногда меняется. Именно это обслуживание составляет ту часть TCO, которая не видна на этапе установки, но накапливается каждый месяц.

Транспорт: свой почтовый сервер или внешнее SMTP-реле

Mautic не отправляет письма сам по себе — ему нужен транспорт: либо собственный MTA (обычно Postfix), либо стороннее SMTP-реле стороннего провайдера транзакционной почты, подключённое через встроенный коннектор.

Свой Postfix на том же или соседнем сервере — вариант с максимальным контролем и без ограничений по объёму со стороны третьей стороны, но с полным грузом ответственности за репутацию IP на себе. Здесь работают те же правила, что и для любой самостоятельной рассылки: открытый порт 25 у части хостинг-провайдеров заблокирован по умолчанию именно из-за спама, PTR-запись должна соответствовать имени сервера, а первые недели отправки — это осторожный прогрев, а не полный объём с первого дня. Частые проблемы такой связки и их решения разобраны в материале про массовую рассылку с сервера: частые ошибки и решения — рекомендуем прочитать до, а не после первой волны писем.

Внешнее SMTP-реле снимает часть заботы о репутации IP — у специализированных провайдеров транзакционной почты она уже наработана и распределена между множеством клиентов, а Mautic просто передаёт письма через API или SMTP. Но это уже не «бесплатная» часть системы: тарификация идёт по объёму отправленных писем, и на больших объёмах счёт от такого провайдера может свести на нет всю экономию от отказа от платного email-сервиса. Уточняйте тарифы конкретного провайдера под ваш объём — универсальной цифры здесь нет, у каждого сервиса своя модель.

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

Время на сегментацию и сценарии — вторая по величине статья расходов

Готовые SaaS-сервисы email-маркетинга годами вкладывались в удобство: библиотеки готовых шаблонов писем, преднастроенные сценарии (брошенная корзина, приветственная серия, реактивация), понятный интерфейс сегментации с примерами. Mautic даёт мощный конструктор кампаний и сегментов, но без готовых заготовок под конкретные задачи — конструктор нужно освоить и настроить с нуля под каждый сценарий.

Это выливается в конкретные часы работы:

• Освоение построителя сегментов. Фильтры по полям контакта, действиям, тегам, вовлечённости — логика мощная, но требует понимания, как Mautic хранит и индексирует данные о контактах, иначе сложный сегмент будет пересчитываться заметно дольше, чем ожидается.
• Сборка кампаний в визуальном builder'е. Условные ветвления, задержки, точки принятия решений — каждый сценарий собирается вручную из блоков, и на первую серию писем (например, welcome-цепочку из 4-5 писем с условиями) закладывайте не один час работы, особенно если делаете это впервые.
• Вёрстка писем. Встроенный редактор писем в Mautic функциональный, но менее отполирован, чем у специализированных email-конструкторов — адаптивная вёрстка под разные почтовые клиенты иногда требует ручной правки HTML, а не только drag-and-drop.
• Тестирование после обновлений. Mautic активно развивается, и обновление минорной версии иногда меняет поведение отдельных модулей (особенно кастомных полей и сторонних плагинов) — сценарии и сегменты стоит перепроверять после каждого апдейта, а не только на этапе первичной настройки.

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

Считаем TCO: свой Mautic против SaaS

Сведём все статьи расходов в одну таблицу, чтобы сравнение было предметным, а не абстрактным:

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

Когда свой Mautic оправдан, а когда нет

Самостоятельный хостинг Mautic имеет смысл, если совпадает несколько условий одновременно:

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

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

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