Розробка шаблонів email: де розсипається верстка в клієнтах
Транзакційні листи читають у моменті: чек про оплату, відновлення доступу, підтвердження замовлення. Від того, як відкриється такий лист, залежить, чи повернеться людина в продукт, чи піде шукати форму зворотного зв’язку.
Верстка листів тут не про красу — про те, що один і той самий лист має зібратися однаково в клієнтах, між якими немає жодної згоди.
Основні точки відмови відомі заздалегідь. Частина поштових клієнтів відмальовує лист на рушії текстового редактора, а не браузера: плаваючі блоки зриваються в стовпчик, відступи рахуються інакше, кнопки втрачають клікабельну область.
Розробка шаблонів email без табличної основи та без урахування цих відмінностей дає листи, які в одному клієнті виглядають як макет, а в іншому — як роз’їханий текст.
Окремо відмовляє обрізання: довгий лист клієнт згортає на середині, і посилання на підтвердження залишається за межами видимої частини.
Темна тема листа — свій клас відмов. Поштовий клієнт інвертує кольори автоматично, і логотип на прозорому фоні перетворюється на невидиму пляму, а світлий текст на світлій плашці стає нечитабельним.
Лікується це не підбором «універсального» кольору, а явними значеннями для кожного смислового блоку в обох схемах.
Спам-фільтри дивляться на розмітку, а не на сенс: вкладені таблиці глибоко одна в одній, картинка замість тексту, відсутність текстової версії, посилання на сторонні домени без зв’язку з відправником. Лист потрапляє до папки, куди отримувач не заглядає, і весь ланцюжок сповіщень обривається.
Ми збираємо шаблони на MJML — декларативній мові, яка сама розгортає конструкцію в сумісну розмітку, — і проганяємо результат через реальні клієнти, включно з темною схемою. Розбираємо, як це закривається на кожному етапі.
Що дає компонентне складання листів на потоці
Компонентне складання листів — це коли лист збирається з готових блоків: шапка, товарна картка, кнопка, футер із відпискою.
Повторне використання блоків знімає головну причину ручних правок: верстку не пишуть заново під кожен лист, а підставляють перевірений фрагмент із уже налаштованими відступами та поведінкою в поштових клієнтах.
Швидкість випуску шаблонів змінюється помітно: лист на готових блоках збирається за години замість днів, бо зникає етап налагодження зовнішнього вигляду в різних поштових програмах.
Єдиний стиль листів тримається не на дисципліні верстальника, а на самих блоках — відступи, кеглі та кольори задані один раз у спільній темі оформлення.
Зменшення ручних правок вимірне: заміна речення, порядок блоків, банер акції — це те, що маркетолог робить сам, не чекаючи розробки. Частка звернень, закритих без верстальника, на потоці стає переважною, і черга дрібних задач перестає накопичуватися.
Окремо закривається цілий клас дефектів. Спільні блоки зібрані за правилами, які розуміють і веб-версія, і настільні, і мобільні поштові клієнти, а кожне складання проходить попередній перегляд у списку програм. «З’їхала» кнопка або розвалений футер не повертаються в кожному новому листі.
Кількість клієнтів, де лист уже перевірено, теж стає керованою: шаблон обкатується на одному потоці розсилок, а далі тиражується без повторного налагодження. Підсумок — передбачуваний строк випуску нового листа й однакова якість на всьому обсязі.
Способи складання шаблонів: розмітка, ручна верстка, конструктор
Вибір способу складання листа визначає, як швидко виходить нова розсилка і наскільки передбачувано вона відобразиться в отримувача.
Ключовий компроміс — між швидкістю правок і контролем над розміткою: адаптивність листа та сумісність зі старими поштовими клієнтами даються різною ціною.
Нижче — варіанти, між якими реально обирають під час розробки шаблонів email, з їхніми обмеженнями. На практиці частіше виграє гібридна схема: каркас збирається з готових компонентів, а нестандартні блоки верстаються точково.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручна верстка, таблична верстка листа | Нестандартний макет, потрібен повний контроль над відображенням у старих клієнтах | Кожна розсилка верстається заново, правки довгі, адаптивність легко зламати |
| MJML-розмітка | Потрібні адаптивні листи під усі клієнти з єдиного джерела | З’являється етап складання, частину тонких рішень доводиться дописувати вручну |
| Компонентний шаблонізатор | Багато регулярних розсилок із повторюваними блоками | Потребує дисципліни в структурі компонентів, інакше шаблони розходяться |
| Візуальний конструктор листів | Правки силами маркетингу без участі розробника | Обмежена сітка, складні макети й точна адаптивність недосяжні |
| Текстові шаблони без розмітки | Транзакційні листи, де важлива доставлюваність | Немає оформлення й брендування, частину сценаріїв не покрити |
| Гібридна схема | Каркас компонентний, разові блоки верстаються точково | Складніше тримати єдиний стиль, потрібен регламент на правки |
Порядок впровадження: від аудиту листів до передачі проєкту
Транзакційні листи надсилаються за тригером, а не за розкладом: рахунок, відновлення доступу, підтвердження замовлення. Помилка в такому шаблоні ламає сценарій повністю, тому порядок робіт фіксуємо до складання першого рядка розмітки. Нижче — шість етапів, які проходимо на кожному проєкті.
- Аудит наявних листів. Збираємо всі тригери й розбираємо поточну верстку: вкладені таблиці, інлайн-стилі, темну тему, прехедер. На виході — карта шаблонів і перелік проблем, які ламають відображення.
- Схема блоків листа. Розкладаємо кожен шаблон на блоки, які можна перевикористовувати: шапка, тіло, кнопка дії, футер із юридичною частиною. Правка в одному блоці не зачіпає сусідні секції.
- Складання та верстка. Збираємо блоки в єдину успадковану структуру, одразу тримаємо текстову версію листа й адаптив під вузькі екрани.
- Перевірка на поштових клієнтах. Рендеримо шаблон у настільних і мобільних клієнтах, у темній темі та з вимкненими картинками — розходження вилазять саме там.
- Тестове надсилання. Проганяємо на живих адресах через реальний сервіс: підстановка змінних, посилання, заголовок, вигляд у веб-версії та потрапляння у «Вхідні».
- Передача шаблонів. Віддаємо репозиторій, документацію по блоках і регламент: як додати новий тригер і перевірити його, не зачепивши інші листи.
Що ви отримуєте на руки: джерельні файли, схеми, регламенти
Передача — не архів верстки, а робочий комплект, із яким ваша команда веде листи далі самостійно. Шаблони збираються із загальної бібліотеки блоків, тому нова розсилка — це копіювання блоку й правка тексту, а не верстка з нуля. Ось що йде разом із проєктом.
- Джерельні файли шаблонів листів — модульна розмітка на MJML, з якої збираються всі транзакційні сценарії: підтвердження замовлення, скидання пароля, чек, сповіщення про відвантаження.
- Бібліотека блоків — шапка, кнопка, картка товару, таблиця замовлення, виноска. Набір закриває типові листи, тому нова розсилка збирається з готових частин, а не верстається заново.
- Схеми наслідування — який шаблон від якого залежить і де змінюються кольори, логотип і підписи: правка в одному місці розходиться по всіх листах.
- Регламент правок — що можна змінювати одразу, а що потребує перескладання й прогону за еталонами. Правила зафіксовані, а не тримаються в голові одного інженера.
- Еталонні знімки відображення — контрольні знімки кожного листа в поштових клієнтах: після правки є з чим звіряти, і регресія видна до надсилання.
- Документація по листах — список тригерів, змінні підстановки, вимоги до хостингу картинок і порядок публікації, плюс інструкція для команди: новий розробник входить у проєкт за день.
Кейс: як прибрали розходження між поштовими клієнтами
Клієнт — сервіс із транзакційними листами чотирма мовами: підтвердження замовлення, скидання пароля, зміна статусу доставки. Верстка жила в чотирьох окремих файлах, які поступово розходилися: правку кнопки або футера вносили в кожен вручну, частина змін губилася по дорозі.
Один і той самий сценарій у російській та англійській версії відрізнявся відступами, шириною кнопок і порядком блоків — підтримка перетворювалася на постійне звіряння копій.
Ми зібрали єдину бібліотеку блоків: шапка, футер, кнопка, таблиця замовлення, трекінг, юридичний блок. Розмітка шаблонів збирається з цих блоків, а тексти винесені в окремі словники за мовами.
Складання йде з одного джерела через MJML — розкладка на таблицях та інлайн-стилі, які розуміють поштові клієнти, генеруються автоматично.
Метрики до і після
Раніше випуск нового листа займав 2–3 дні: звіряння чотирьох версій, ручна правка, перевірки. Зараз — 3–4 години, включно з тестовими надсиланнями в основні поштові клієнти.
Кількість дефектів відображення, які спливали вже в живих користувачів, упала з 5–7 на реліз до нуля-одного: адаптив і вирівнювання закладені в блоки, а не пишуться заново в кожній розсилці.
Додавання п’ятої локалі тепер зводиться до нового словника й прогону перевірок — верстку чіпати не потрібно. Оновлення фірмового стилю — правка в одному блоці, яка вирушає в усі листи під час наступного складання, без ризику, що десь залишиться стара кнопка.
Чим транзакційний лист відрізняється від розсилки по базі
Транзакційний лист запускається подією: пройшла оплата, змінився статус замовлення, запросили відновлення доступу. Один отримувач — один лист із конкретного приводу, і піти він має за лічені секунди після події.
Масова розсилка влаштована інакше: один матеріал іде сегменту бази за розкладом, і затримка на хвилину нічого не ламає.
Звідси розходяться вимоги до підстановки даних отримувача. У транзакційному шаблоні поля приходять із події — номер замовлення, вміст, персональне посилання з одноразовим токеном, — і за неповного набору лист краще не надсилати взагалі, ніж показати порожній рядок або чужі дані.
У розсилці підстановки спільні для сегмента: ім’я, місто, знижка, — і помилка коштує репутації, але не розриває сценарій.
Складання теж різне. Транзакційний шаблон — набір компонентів з умовними блоками: доставка, повернення, позиції замовлення, мовні версії. Масовий ближчий до журнальної верстки: однакові секції, обов’язкова відписка, єдиний візуальний каркас. Обидва типи збираємо компонентною розміткою MJML — поштові клієнти досі ріжуть гнучкі стилі.
Найбільше відрізняється навантаження. Подієве надсилання дає піки: розпродаж або збій платежів піднімає потік у рази за хвилини.
Тому транзакції виносять в окрему чергу з пріоритетом над розсилкою, додають ключ ідемпотентності проти дублів, повторні спроби при відмові поштового шлюзу та карантин для недоставлених. Розсилку планують заздалегідь і розподіляють у часі.
Часті технічні питання щодо верстки листів
Сумніви на прийманні повторюються: поведінка листа в різних клієнтах, темна тема, міграція з конструктора. Перевірка в нас — фіксований набір сценаріїв, а не «подивилися і начебто нормально».
Перевірка перед надсиланням — що до неї входить?
Матриця сценаріїв: десктопний і мобільний Outlook, Gmail у вебі та застосунку, Apple Mail, перегляд із вимкненими картинками. На кожен — скриншот і висновок, що перебудувалося: колонки, системний шрифт, alt-текст.
Як переїхати з конструктора?
Знімаємо структуру поточного листа, повторюємо блоки компонентною розміткою та звіряємо з оригіналом пліч-о-пліч. Посилання на відписку, піксель аналітики та підстановочні змінні зберігають попередні імена, тому сегменти залишаються на місці.
Темна тема й великий шрифт?
Клієнти інвертують кольори самі, тому фон і колір тексту задаємо явно на кожному рівні, логотип віддаємо у двох варіантах.
За збільшеного шрифту розкладка переходить в одну колонку без горизонтального прокручування, кнопка зберігає велику зону натискання; доступність листа — alt-тексти й контраст — перевіряється в тій самій матриці.
Як вносяться правки після передачі?
Правки йдуть через компонентне джерело, а не через ручну правку зібраного HTML — інакше наступна розсилка розійдеться з поточною. Заміна тексту або посилання — правка в одному місці та повторне складання, зміна структури блоку узгоджується окремо.
Обговоримо задачу й повернемося з оцінкою та планом
Щоб оцінка була не «на око», на старті достатньо кількох вхідних даних. Нижче — що надіслати в обговорення задачі: цього достатньо, щоб зібрати шаблони на MJML, прогнати їх у реальних поштових клієнтах і повернутися з планом робіт і строками впровадження.
- 5–7 зразків листів — скидання пароля, підтвердження замовлення, чек, сповіщення. Краще з реальними даними: видно довжину імен, сум і назв товарів.
- Список клієнтів для перевірки: Outlook у десктопі та вебі, Gmail, Apple Mail, мобільні застосунки, корпоративні фільтри.
- Мови та локалі: які версії потрібні, напрям тексту, хто дає переклади й як у лист підставляються змінні.
- Вимоги до темної теми: чи інвертується фон примусово, чи є логотипи з прозорістю, які кольори допустимі.
- Точки інтеграції із сервісом надсилання: змінні, посилання відписки й перегляду в браузері, сповіщення про доставку.
- Доступи: тестовий домен, акаунт сервісу надсилання, місце, де лежать поточні шаблони.
- Брендбук: кольори, шрифти, логотипи у векторі, обмеження за шириною листа.
Чогось зі списку може не бути — скажіть про це прямо, частину даних зберемо разом на дзвінку. Далі ми даємо оцінку та план робіт: розбивку за шаблонами, порядок викочування, строки впровадження й точку старту проєкту.
