Розробка конструктора email-розсилок під ключ

Розробка конструктора email-розсилок

Проблема створення HTML-листів, які коректно відображаються у всіх поштових клієнтах — одна з найтрудомісткіших задач email-маркетингу. Outlook рендерить через Word, Gmail обрізає довгі листи, Apple Mail підтримує сучасний CSS — в результаті універсальний конструктор повинен генерувати table-based layout з inline-стилями. Наш досвід розробки таких систем дозволяє створювати рішення, які справляються з цими обмеженнями. Ми реалізували більше 10 проєктів зі створення email-редакторів для SaaS-платформ і корпоративних порталів. На одному з проєктів для інтернет-магазину ми скоротили час верстки листа з 3 годин до 20 хвилин завдяки drag-and-drop редактору. Наші спеціалісти мають понад 5 років досвіду в розробці email-інструментів та гарантують, що ваш конструктор працюватиме у всіх поштових клієнтах. Створюючи конструктор, ви отримуєте інструмент, який автоматизує ручну верстку та підвищує конверсію листів.

Технічні обмеження email

Email-редактор зобов'язаний видавати HTML, сумісний з поштовими клієнтами — а вони підтримують різні підмножини CSS. Основні обмеження:

• Outlook 2016–2021: рендерить через Word, не підтримує flexbox/grid
• Gmail: обрізає листи > 102 КБ, інлайнить лише частину CSS
• Apple Mail: підтримує prefers-color-scheme, modern CSS

Тому будь-який drag-and-drop редактор генерує table-based layout з inline-стилями — єдиний надійний формат. Зверніть увагу: це обмеження не обійти, його потрібно прийняти. Наші інженери мають 5+ років досвіду роботи з email-версткою та гарантують сумісність з 50+ поштовими клієнтами.

Як вибрати движок для email-редактора?

Існує два основні підходи: використання фреймворку MJML та написання власного генератора на основі JavaScript. MJML компілює свій синтаксис у крос-клієнтний HTML, що прискорює розробку. Однак MJML обмежує можливості кастомізації. Власний генератор дає повний контроль, але вимагає більше часу на реалізацію.

Для більшості проєктів ми рекомендуємо комбінувати MJML з кастомними плагінами — це дозволяє отримати гнучкість без втрати швидкості.

Архітектура редактора

Редактор працює з JSON-структурою листа:

{
  "rows": [
    {
      "id": "row_1",
      "columns": 1,
      "backgroundColor": "#ffffff",
      "blocks": [
        {
          "type": "image",
          "src": "https://cdn.../banner.jpg",
          "alt": "Банер",
          "link": "https://example.com",
          "width": "100%"
        }
      ]
    },
    {
      "id": "row_2",
      "columns": 2,
      "blocks": [
        { "type": "text", "content": "<h2>Заголовок</h2><p>Текст...</p>" },
        { "type": "button", "text": "Купити", "link": "...", "bgColor": "#2563eb" }
      ]
    }
  ]
}

Генератор HTML конвертує JSON у table-based HTML з inline-стилями. Ми використовуємо цю архітектуру у всіх проєктах.

Персоналізація (Merge Tags)

Підтримка змінних у контенті: {{first_name}}, {{company}}, {{unsubscribe_url}}. При відправці змінні замінюються реальними даними з бази або через API поштового провайдера.

Більшість провайдерів (Mailchimp, SendGrid, Postmark) підтримують свій формат merge tags — потрібна адаптація при експорті. У наших конструкторах ми автоматично конвертуємо між форматами.

Як тестувати листи перед відправкою?

Тестування включає три етапи: прев'ю в редакторі (desktop/mobile), відправка тестового листа та перевірка в популярних поштових клієнтах через сервіси на кшталт Litmus. Ми використовуємо API Litmus для автоматичного створення скріншотів у 50+ клієнтах. Це дозволяє виявити проблеми з рендерингом до масової розсилки.

Експорт

• HTML — готовий inline-styled HTML
• Stripo JSON / MJML — для повторного редагування в інших інструментах
• ZIP — HTML + зображення

MJML — фреймворк для email-верстки. MJML-код компілюється у крос-клієнтний HTML. Використання MJML всередині редактора значно спрощує розробку:

<mjml>
  <mj-body>
    <mj-section background-color="#ffffff">
      <mj-column>
        <mj-text font-size="24px" font-weight="bold">Привіт, {{name}}!</mj-text>
        <mj-button href="https://example.com" background-color="#2563eb">
          Перейти
        </mj-button>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

Бібліотека шаблонів

Стартові шаблони за типами: вітальний лист, промо-акція, дайджест новин, підтвердження замовлення, покинутий кошик. Шаблони редагуються в конструкторі. Ми також пропонуємо послуги зі створення кастомних шаблонів під ваш бренд.

Що входить в роботу

• Аналітика: вивчення вашої аудиторії, типів листів, інтеграцій
• Проектування: архітектура редактора, схеми даних, API-контракти
• Розробка: frontend (React/TypeScript), backend (Node.js або Laravel), генератор HTML
• Тестування: крос-клієнтне тестування в Litmus, навантажувальне тестування
• Документація: опис компонентів редактора, інструкція з налаштування шаблонів
• Підтримка: 30 днів гарантійної підтримки після здачі

Терміни

MVP (drag-and-drop редактор, основні блоки, preview, HTML-експорт): 6–8 тижнів. Повноцінний конструктор з MJML-движком, бібліотекою шаблонів, Litmus-інтеграцією, merge tags: 3–4 місяці.

Зв'яжіться з нами для оцінки вашого проєкту. Ми надамо детальну комерційну пропозицію та терміни під ваші задачі.

Інтеграція 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+ проєктів. Замовте безкоштовний аудит поточної інтеграції — отримайте звіт з рекомендаціями.