Разработка и вёрстка шаблонов транзакционных email (MJML)

Разработка шаблонов email: где рассыпается вёрстка в клиентах

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

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

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

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

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

Что даёт компонентная сборка писем на потоке

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

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

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

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

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

Способы сборки шаблонов: разметка, ручная вёрстка, конструктор

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

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

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

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

1. Аудит существующих писем. Собираем все триггеры и разбираем текущую вёрстку: вложенные таблицы, инлайн-стили, тёмную тему, прехедер. На выходе — карта шаблонов и перечень проблем, которые ломают отображение.
2. Схема блоков письма. Раскладываем каждый шаблон на переиспользуемые блоки: шапка, тело, кнопка действия, футер с юридической частью. Правка в одном блоке не задевает соседние секции.
3. Сборка и вёрстка. Собираем блоки в единую наследуемую структуру, сразу держим текстовую версию письма и адаптив под узкие экраны.
4. Проверка на почтовых клиентах. Рендерим шаблон в настольных и мобильных клиентах, в тёмной теме и при отключённых картинках — расхождения вылезают именно там.
5. Тестовая отправка. Прогоняем на живых адресах через реальный сервис: подстановка переменных, ссылки, заголовок, вид в веб-версии и попадание во «Входящие».
6. Передача шаблонов. Отдаём репозиторий, документацию по блокам и регламент: как добавить новый триггер и проверить его, не задев остальные письма.

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

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

• Исходники шаблонов писем — модульная разметка на MJML, из которой собираются все транзакционные сценарии: подтверждение заказа, сброс пароля, чек, уведомление об отгрузке.
• Библиотека блоков — шапка, кнопка, карточка товара, таблица заказа, сноска. Набор закрывает типовые письма, поэтому новая рассылка собирается из готовых частей, а не верстается заново.
• Схемы наследования — какой шаблон от какого зависит и где меняются цвета, логотип и подписи: правка в одном месте расходится по всем письмам.
• Регламент правок — что можно менять сразу, а что требует пересборки и прогона по эталонам. Правила зафиксированы, а не держатся в голове одного инженера.
• Эталонные снимки отображения — контрольные снимки каждого письма в почтовых клиентах: после правки есть с чем сверять, и регрессия видна до отправки.
• Документация по письмам — список триггеров, переменные подстановки, требования к хостингу картинок и порядок публикации, плюс инструкция для команды: новый разработчик входит в проект за день.

Кейс: как убрали расхождения между почтовыми клиентами

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

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

Метрики до и после

Раньше выпуск нового письма занимал 2–3 дня: сверка четырёх версий, ручная правка, проверки. Сейчас — 3–4 часа, включая тестовые отправки в основные почтовые клиенты. Число дефектов отображения, которые всплывали уже у живых пользователей, упало с 5–7 на релиз до нуля-одного: адаптив и выравнивание заложены в блоки, а не пишутся заново в каждой рассылке.

Добавление пятой локали теперь сводится к новому словарю и прогону проверок — вёрстку трогать не нужно. Обновление фирменного стиля — правка в одном блоке, которая уезжает во все письма при следующей сборке, без риска, что где-то останется старая кнопка.

Чем транзакционное письмо отличается от рассылки по базе

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

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

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

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

Частые технические вопросы по вёрстке писем

Сомнения на приёмке повторяются: поведение письма в разных клиентах, тёмная тема, миграция с конструктора. Проверка у нас — фиксированный набор сценариев, а не «посмотрели и вроде нормально».

Как переехать с конструктора?

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

Тёмная тема и крупный шрифт?

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

Как вносятся правки после передачи?

Правки идут через компонентный источник, а не через ручную правку собранного HTML — иначе следующая рассылка разъедется с текущей. Замена текста или ссылки — правка в одном месте и повторная сборка, смена структуры блока согласуется отдельно.

Обсудим задачу и вернёмся с оценкой и планом

Чтобы оценка была не «на глазок», на старте достаточно нескольких входных данных. Ниже — что прислать в обсуждение задачи: этого хватает, чтобы собрать шаблоны на MJML, прогнать их в реальных почтовых клиентах и вернуться с планом работ и сроками внедрения.

• 5–7 образцов писем — сброс пароля, подтверждение заказа, чек, уведомление. Лучше с реальными данными: видно длину имён, сумм и названий товаров.
• Список клиентов для проверки: Outlook в десктопе и вебе, Gmail, Apple Mail, мобильные приложения, корпоративные фильтры.
• Языки и локали: какие версии нужны, направление текста, кто даёт переводы и как в письмо подставляются переменные.
• Требования к тёмной теме: инвертируется ли фон принудительно, есть ли логотипы с прозрачностью, какие цвета допустимы.
• Точки интеграции с сервисом отправки: переменные, ссылки отписки и просмотра в браузере, уведомления о доставке.
• Доступы: тестовый домен, аккаунт сервиса отправки, место, где лежат текущие шаблоны.
• Брендбук: цвета, шрифты, логотипы в векторе, ограничения по ширине письма.

Чего-то из списка может не быть — скажите об этом прямо, часть данных соберём вместе на созвоне. Дальше мы даём оценку и план работ: разбивку по шаблонам, порядок выкатки, сроки внедрения и точку старта проекта.