Аудит та перебудова e-mail програми для B2B SaaS: доставляність, сегментація, тригери та A-B тести в Customer.io

Вихідна ситуація: B2B SaaS для HR (підписка, цикл угоди 2-6 тижнів). Зараз розсилки йдуть з Customer.io, домен відправника shared з транзакційними листами, частина подій приходить із Segment. Відкриваність по базі 18-22%, кліки 1-1.6%, помітні провали Gmail/Outlook, періодично листи потрапляють у Promotions/Spam. Відписки зростають після масових розсилок. Вирва листів зібрана «при потребі», є дублі, немає єдиної логіки сегментів та частотних обмежень.

Технічне середовище та обмеження: Customer.io + Segment (event-stream), продуктова аналітика в GA4, CRM HubSpot (тільки для читання), відправка з виділеного піддомену (можна змінювати DNS у Cloudflare). Не можна підключати нові платні сервіси та купувати нові домени. Не можна змінювати тексти продуктових листів (password reset, invoice) – лише інфраструктура та маркетингові ланцюжки. Не можна робити HTML-редизайн листів - працюємо з поточними шаблонами, допускаються точкові правки, що впливають на спам-фактори та клікабельність. Доступ до даних – через гостьові ролі, вивантаження персональних даних заборонено, працюємо з знеособленими звітами/сегментами усередині систем.

Що потрібно зробити (кілька етапів):
1) Діагностика доставляння та репутації. Перевірити SPF/DKIM/DMARC, alignment, зворотну пошту, налаштування tracking domain, наявність/коректність List-Unsubscribe. Зібрати картину провайдерів (Gmail/Outlook/Yahoo), оцінити причини потрапляння в Spam/Promotions на основі доступних сигналів в Customer.io і заголовків листів. Сформувати план виправлень із пріоритетами.
2) Перебудова структури аудиторій та частот. Проектування сегментів за життєвим циклом (trial, onboarding, activated, dormant, churn risk, paid) з правилами винятків та частотними обмеженнями, щоб один контакт не потрапляв одночасно у конфліктуючі кампанії. Облік часових поясів та робочих днів (B2B).
3) Тригерні ланцюжки. Зібрати/перезбирати мінімум 3 автоматизації в Customer.io на основі подій з Segment: onboarding (перші 14 днів), reactivation (немає ключової події 10/21 день), lead nurturing для MQL (після заявки/демо). Для кожного ланцюжка - ціль, умови входу/виходу, антидублі, throttling, контрольні метрики.
4) Експерименти. Налаштувати A-B тестування тем/прехедерів та одного контентного блоку (без повної верстки) з коректною вибіркою та критеріями зупинки. Мінімум 2 паралельні тести, щоб отримати статистично придатні результати на об'ємі.
5) Вимірювання та звітність. Налаштувати єдиний набір подій/конверсій для оцінки ефективності листів: активація продукту, запит демо, апгрейд, повернення продукт. Зв'язати кампанії/повідомлення з UTM та погодити naming convention. Підготувати дашборд/звіт у вигляді документа з метриками до/після та планом подальших ітерацій.

Конкретний результат: виправлені DNS-налаштування та параметри відправки, нова схема сегментів, мінімум 3 робочі тригерні автоматизації в Customer.io, 2 налаштовані A-B тести, документована карта подій та naming, фінальний звіт з рекомендаціями на 30 днів.

Вимірні критерії приймання (за підсумками 2 тижнів після впровадження, без урахування сезонності): відкритість по warm сегментах +20% щодо базової лінії, частка доставлених листів не нижче 99%, зниження відписок на масових відправках мінімум на 25%, зниження частки spam-репортів (якщо доступно) мінімум на 2 контактах та на 100 випадкових реальних профілях усередині Customer.io). Усі зміни задокументовані: що змінено, де і як відкотити.

Важливо: проект вимагає впевненої роботи з Customer.io, Segment event-моделлю, deliverability практиками (SPF/DKIM/DMARC, alignment, suppression, list hygiene) та розуміння B2B lifecycle маркетингу.