Дизайн email-розсилок: шаблони, адаптивна верстка, темна тема

Уявіть: ви запускаєте промо-кампанію, лист іде 50 000 підписникам — а в Outlook він відображається білим прямокутником. Або в Gmail обрізається після першого екрана. Це типова ситуація, коли email-шаблон зверстаний без урахування обмежень поштових клієнтів. Правильно зверстаний лист дає конверсію в 2–3 рази вищу, ніж шаблон, створений без тестування. За 5 років ми розробили понад 100 шаблонів листів для інтернет-магазинів, новинних видань та SaaS-продуктів — і знаємо, як обійти підводні камені кожного клієнта.

Дизайн email-розсилки — це інженерія з жорсткими обмеженнями. Outlook рендерить через Word rendering engine, Gmail лімітує 102 КБ, Apple Mail підтримує prefers-color-scheme, а інші — ні. Наш досвід показує: коректно зверстаний лист відкривається на будь-якому пристрої. Щоб уникнути проблем з відображенням, зверніться до нас на етапі проєктування. Замовте розробку шаблону — і ми підготуємо макет, який не загубиться в папці «Спам».

Нещодавно ми робили шаблон для інтернет-магазину електроніки: після заміни табличної верстки на адаптивну відкриваність зросла на 25%, а число переходів за CTA — на 40%.

Які проблеми вирішуємо?

• Outlook: Word rendering engine ламає позиціонування, ігнорує багато CSS-властивостей. Рішення — таблична верстка з інлайн-стилями, основа Outlook-верстки. Таблиця в 2-3 рази надійніша за flexbox у поштових клієнтах.
• Gmail: ліміт 102 КБ на необроблений лист. Оптимізуємо зображення через CDN, виключаємо base64, мініфікуємо код. Економія трафіку — до 30%.
• Темна тема: Apple Mail коректно перефарбовує фон і текст, Gmail — ні. Без явних правил дизайн може інвертуватися в негатив.
• Адаптивність: мобільна версія має читатися без збільшення. Використовуємо fluid таблиці та медіа-запити.

Як забезпечити сумісність з Outlook?

Базова структура листа — таблична верстка з шириною 600px, інлайн-стилями для кожного елемента. Безпечні CSS-властивості: font-family, font-size, color, background-color, padding, margin, border, width. Flexbox, grid, position: absolute не працюють у більшості клієнтів, тому їх уникаємо.

Порівняння поштових клієнтів

Які CSS-властивості безпечні?

Чому темна тема критична?

Понад 30% користувачів вмикають темний режим на пристроях. Без медіа-запиту @media (prefers-color-scheme: dark) клієнт автоматично інвертує кольори, і ваш логотип стає невидимим. Ми додаємо явні правила:

@media (prefers-color-scheme: dark) {
  .email-bg { background-color: #1a1a2e !important; }
  .email-text { color: #e0e0e0 !important; }
}

Докладніше про prefers-color-scheme на MDN

Preheader — прихований текст, що підвищує відкриваність

Preheader — прихований текст, який відображається у списку листів поруч із темою. Він збільшує відкриваність на 15–20%. Задається через display:none на самому початку body.

Склад робіт

• Дизайн шаблону листа в Figma (десктоп і мобільний прев'ю)
• Адаптивна верстка HTML-коду email (таблиці, інлайн-стилі)
• Тестування в 10+ поштових клієнтах (Outlook, Gmail, Apple Mail, Яндекс, Mail.ru, Rambler та ін.)
• Налаштування темної теми
• Preheader, CTA-кнопка, footer з відпискою
• Документація з використання шаблону (як вставляти зображення, змінювати текст)
• Вихідники Figma та готовий HTML-файл

Процес роботи

1. Аналіз: визначаємо тип розсилки (транзакційна, новинна, промо) та цільову аудиторію.
2. Дизайн: створюємо 1–2 прототипи в Figma, узгоджуємо.
3. Верстка: табличний макет з інлайн-стилями, оптимізація зображень.
4. Тестування: перевіряємо в Litmus або Email on Acid, фіксимо баги.
5. Деплой: передаємо готовий шаблон та документацію.

Терміни та вартість

Термін розробки одного шаблону — від 2 до 5 робочих днів. Вартість розраховується індивідуально і залежить від складності дизайну, кількості ревізій та необхідних клієнтів для тестування. Зв'яжіться з нами, щоб обговорити ваш проєкт та отримати консультацію.

Замовте розробку шаблону — і ми підготуємо макет, який буде коректно відображатися у всіх поштових клієнтах.

Інтеграція email розсилок: чому вона часто ламається?

Ми стикалися з тим, що тригерний лист через 10 хвилин після реєстрації конвертує в 4–5 разів краще, ніж той самий лист через 24 години. Це не маркетинговий міф — це механіка: поки користувач теплий, поки пам'ятає контекст. Але більшість інтеграцій з розсильниками зроблені так: форма сабмітиться → синхронний HTTP-запит до API → якщо API гальмує, користувач чекає 3 секунди → лист йде або не йде, ніхто не знає.

Якщо ви зіткнулися з втраченими листами або потраплянням у спам, замовте аудит існуючої інтеграції — ми знайдемо вузькі місця за 2 дні.

Провайдери та їх API

Unisender — російський провайдер, популярний у сегменті SMB. REST API, простий. Додавання контакту: importContacts, відправка транзакційного листа: sendEmail. Важливо: для транзакційних листів (підтвердження замовлення, скидання пароля) Unisender Go — окремий сервіс з іншим API та окремою ціною. Змішувати масові розсилки та транзакційні в одному потоці — погана ідея для репутації домену.

SendPulse — надає email, SMS, web push, Viber, Telegram-боти через єдиний API. Для проєктів, де потрібен омніканал, це зручно. Automation 360 — візуальний конструктор ланцюжків, можна запустити автоматизацію через API event. SDK для PHP (sendpulse/rest-api-php-sdk) підтримується, але оновлюється нерегулярно — краще використовувати напряму через Guzzle.

Mailchimp — вибір для міжнародної аудиторії та маркетингових команд, звиклих до екосистеми Mailchimp. Transactional email — через Mandrill (дочірній сервіс). Marketing API v3 для управління списками, тегами, кампаніями. Webhook для подій: відкриття, клік, відписка, bounce.

SMS. Для Росії: СМСЦ, МТС Exolve, Devino Telecom, SMS Aero. API у всіх схожий: метод send, параметри phone, message, sender (ім'я відправника — потрібно реєструвати окремо у оператора). Один нюанс: ім'я відправника має бути зареєстровано через агрегатора з договором — без цього SMS не відправляться на мережі МТС/МегаФон/Білайн.

Як побудувати інтеграцію, щоб не втрачати листи?

Розділяємо транзакційні та маркетингові потоки

Транзакційні листи (підтвердження замовлення, скидання пароля, статус доставки) — через окремий домен-відправник або субдомен tx.example.com. Маркетингові розсилки — через mail.example.com або news.example.com. Якщо маркетингова розсилка отримає багато скарг на спам, це не повинно зачепити репутацію транзакційного потоку. Згідно з документацією SendGrid, транзакційні повідомлення слід відправляти через виділений IP-пул для запобігання перехресному впливу.

Черга та retry

Будь-який виклик до email API — через чергу (Laravel Queue, Bull, Celery). Якщо Unisender повернув 503 — задача йде в retry через 5 хвилин, потім 15, потім 60. Після 5 невдалих спроб — у dead letter queue з алертом. Користувач при цьому вже отримав свій 200 OK і не знає про проблему. Завдяки цьому підходу bounce rate на проєктах знижується до 0.5%.

Приклад job для Laravel:

public function handle(): void
{
    try {
        $response = Http::post(config('services.unisender.email_url'), $this->params);
        if ($response->failed()) {
            $this->release(300); // retry через 5 хв
        }
    } catch (\Throwable $e) {
        $this->release(300);
    }
}

Шаблони

Зберігаємо шаблони в коді (Blade, Twig, React Email), не в інтерфейсі провайдера. Причини: версіонування через Git, preview у браузері без відправки, можливість тестування. Для складних шаблонів з динамічним контентом — react-email з експортом в HTML через @react-email/render.

Валідація та згоди

Перед додаванням контакту до списку — double opt-in (лист з підтвердженням). Зберігати факт підтвердження з timestamp у своїй БД. При відписці — синхронно відписуємо і у провайдера, і в своїй базі. Ігнорувати webhook відписки — прямий шлях до блокування акаунта у провайдера. Всі процеси відповідають ФЗ-152 про персональні дані.

Моніторинг доставності

Підключаємо webhook від провайдера на події bounce (жорсткий і м'який), spam_complaint, unsubscribe. Жорсткий bounce — негайно позначаємо email як невалідний у своїй БД, більше не відправляємо. М'який bounce 3 рази поспіль — те саме. Метрики: open rate, click rate, bounce rate, unsubscribe rate — дивимося не рідше разу на тиждень. Наші сертифіковані інженери налаштовують алерти в Grafana/Prometheus.

Чому важливо розділяти потоки?

Якщо відправити маркетингову розсилку з того ж домену, що й транзакційні листи, отримавши скарги на спам, ви ризикуєте заблокувати домен — і користувачі перестануть отримувати навіть підтвердження замовлень. SPF, DKIM, DMARC (Wikipedia SPF, Wikipedia DKIM) повинні бути налаштовані окремо для кожного потоку. Ми використовуємо субдомени з різними DNS-записами.

Обсяг робіт з інтеграції

• Аудит поточних потоків комунікації та репутації домену (SPF, DKIM, DMARC)
• Вибір провайдера та схеми: транзакційний vs маркетинговий трафік
• Налаштування DNS-записів SPF, DKIM, DMARC (Wikipedia DMARC)
• Розробка шаблонів листів (HTML + динамічний контент)
• Інтеграція з бекендом через черги та API
• Налаштування webhook для доставності та скарг
• Документація з експлуатації та навчання команди
• Гарантія доставності та підтримка після запуску

Терміни та вартість

Вартість розраховується індивідуально після аудиту. Ми працюємо під ключ: від аналізу до моніторингу в продакшені. Отримайте консультацію інженера — оцінимо проєкт безкоштовно та скажемо точні терміни. Досвід більше 7 років в інтеграції поштових сервісів, реалізовано 50+ проєктів. Замовте безкоштовний аудит поточної інтеграції — отримайте звіт з рекомендаціями.