A/B-тестування email-розсилок: налаштування та результати

Наша компанія займається розробкою, підтримкою та обслуговуванням сайтів будь-якої складності. Від простих односторінкових сайтів до масштабних кластерних систем, побудованих на мікро сервісах. Досвід розробників підтверджено сертифікатами від вендорів.

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

Це лише деякі з технічних типів сайтів, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
A/B-тестування email-розсилок: налаштування та результати
Середній
~3-5 днів
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1362
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1253
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    958
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1190
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    931
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    949

Зниження відкриваності листів та відсутність зростання клікабельності — частий біль email-маркетологів. Замість інтуїтивних змін A/B-тестування дає об'єктивні дані для прийняття рішень. За статистикою, 70% email-кампаній не використовують A/B-тестування, втрачаючи до 30% потенційної конверсії. Грамотно проведений A/B тест дозволяє збільшити дохід з кожного листа на 20-30% без додаткових витрат на трафік. Це підтверджується кейсами наших клієнтів: одна з компаній у сфері e-commerce після впровадження систематичного тестування збільшила CTR у 1,8 рази за три місяці, що принесло додатковий дохід у розмірі 500 000 грн щомісячно.

Правильно організований тест підвищує не тільки відкриваність, але й лояльність аудиторії. Важливо розуміти, що для достовірності результатів необхідна достатня вибірка — не менше 1000 отримувачів на варіант. Ми впровадили цю практику у 50+ проєктах і готові поділитися досвідом. Статистично значущі результати дозволяють впевнено вибирати кращий варіант і збільшувати конверсію. A/B-тестування email-розсилок у 2-3 рази ефективніше за інтуїтивні здогадки при виборі теми листа.

Проблеми, які вирішуємо

Головна помилка — тестувати без плану та без достатньої вибірки. Наприклад, відправити 200 листів з різними темами і оголосити переможця за 3 додатковими відкриттями. Це статистично незначуще. Використання недостатньої вибірки — основна причина недостовірних результатів. При open rate 20% і бажаному ефекті 5% необхідно відправити не менше 1300 листів на кожен варіант. Багато хто нехтує цим і отримує хибних переможців. Інші проблеми:

  • Перевантаження тестів: намагаються перевірити 10 гіпотез в одному спліті — втрачається чистота експерименту.
  • Невраховані зовнішні фактори: день тижня, час доби, сезонність.
  • Передчасна зупинка: переможця оголошують через годину, хоча дані ще не стабілізувалися.

Як правильно організувати A/B тест?

Процес починається з формулювання гіпотези. Наприклад: «Персоналізована тема листа підвищить open rate на 15%». Визначаємо метрику (open rate, CTR), обираємо одну змінну (subject line), розраховуємо розмір вибірки. Після розрахунку вибірки важливо правильно налаштувати сплітування. Ми використовуємо випадковий розподіл з контролем за користувацькими сегментами, щоб уникнути зміщення. Наприклад, якщо у вас є підписники з різних регіонів, переконайтеся, що вони рівномірно розподілені між варіантами. Потім налаштовуємо спліт-систему:

interface ABTestVariant {
  id: 'A' | 'B' | 'C';
  subject: string;
  templateId: string;
  weight: number;  // доля трафика, например 0.5 для 50/50
}

interface ABTest {
  id: string;
  campaignId: string;
  variants: ABTestVariant[];
  winnerMetric: 'open_rate' | 'click_rate';
  sampleSize: number;       // сколько отправить на тест
  winnerSendAt?: Date;      // когда отправить победителя остальным
}

async function sendABTest(test: ABTest, users: User[]) {
  // Перемешать пользователей случайно
  const shuffled = users.sort(() => Math.random() - 0.5);

  // Разделить на группы согласно весам
  let offset = 0;
  for (const variant of test.variants) {
    const count = Math.floor(test.sampleSize * variant.weight);
    const group = shuffled.slice(offset, offset + count);
    offset += count;

    await Promise.allSettled(
      group.map(user =>
        sendVariantEmail(user, variant, test.id)
      )
    );
  }

  // Сохранить информацию о тесте
  await db.abTests.create(test);

  // Запланировать определение победителя
  if (test.winnerSendAt) {
    await scheduleWinnerSelection(test.id, test.winnerSendAt);
  }
}

async function sendVariantEmail(user: User, variant: ABTestVariant, testId: string) {
  const html = await renderTemplate(variant.templateId, { user });
  const emailLogId = await sendEmail({
    to: user.email,
    subject: variant.subject,
    html,
  });

  await db.abTestParticipants.create({
    testId,
    variantId: variant.id,
    userId: user.id,
    emailLogId,
  });
}
Детальніше про розрахунок вибірки

Для розрахунку мінімального розміру вибірки використовуйте формулу: n = (Z^2 * p * (1-p)) / d^2, де Z=1.96 для 95% довірчого інтервалу, p — очікуваний open rate, d — мінімально значущий ефект. Наприклад, при p=25% і d=5% необхідно близько 1200 отримувачів на варіант.

Що робити, якщо результати нестатистично значущі?

Після збору даних запускаємо скрипт визначення переможця:

async function determineWinner(testId: string): Promise<'A' | 'B' | 'C'> {
  const test = await db.abTests.findById(testId);

  const stats = await db.query<{
    variant_id: string;
    sent: number;
    opened: number;
    clicked: number;
  }>(`
    SELECT
      p.variant_id,
      COUNT(DISTINCT p.id) AS sent,
      COUNT(DISTINCT oe.email_log_id) AS opened,
      COUNT(DISTINCT ce.email_log_id) AS clicked
    FROM ab_test_participants p
    LEFT JOIN email_open_events oe ON oe.email_log_id = p.email_log_id
    LEFT JOIN email_click_events ce ON ce.email_log_id = p.email_log_id
    WHERE p.test_id = $1
    GROUP BY p.variant_id
  `, [testId]);

  const withRates = stats.map(s => ({
    ...s,
    open_rate: s.opened / s.sent,
    click_rate: s.clicked / s.sent,
  }));

  // Проверить статистическую значимость (z-test для пропорций)
  const winner = withRates.reduce((best, current) => {
    const metric = test.winnerMetric === 'open_rate' ? 'open_rate' : 'click_rate';
    return current[metric] > best[metric] ? current : best;
  });

  return winner.variant_id as 'A' | 'B' | 'C';
}

// Отправить победителя оставшимся пользователям
async function sendWinnerToRemainder(testId: string) {
  const winnerId = await determineWinner(testId);
  const test = await db.abTests.findById(testId);
  const winnerVariant = test.variants.find(v => v.id === winnerId)!;

  // Пользователи, не попавшие в тест
  const participantIds = await db.abTestParticipants.getUserIdsByTest(testId);
  const remainderUsers = await db.users.findExcluding(participantIds, test.campaignId);

  await Promise.allSettled(
    remainderUsers.map(user =>
      sendVariantEmail(user, winnerVariant, testId)
    )
  );
}

Ключовий момент — перевірка статистичної значущості. Використовуємо z-тест для пропорцій. Якщо p-value більше 0.05, переможець не оголошується. У таких випадках варто продовжити тест або переглянути гіпотезу.

Метрика Формула Приклад для групи A (n=1000)
Open rate opened / sent 250/1000 = 25%
Click rate clicked / sent 50/1000 = 5%
Статистична значущість z-тест z > 1.96 → значуще
Етап Тривалість
Аналітика та гіпотези 1–2 дні
Розробка спліт-системи 3–5 днів
Пілотний тест 1–2 дні
Деплой та навчання 1–2 дні

Що входить у нашу роботу

  • Аудит поточних розсилок та формулювання гіпотез.
  • Розробка спліт-системи з інтегрованим збором метрик.
  • Налаштування автоматичного визначення переможця та до розсилки.
  • Документація з інтерпретації результатів.
  • Підтримка після впровадження — 1 місяць.
  • Все робимо під ключ: аудит, спліт-система, навчання команди. Термін — 5–10 днів. Напишіть нам для безкоштовної оцінки вашого проекту.

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

  1. Аналітика — вивчаємо вашу email-статистику, виявляємо вузькі місця.
  2. Проєктування — обираємо змінні, розраховуємо вибірку, налаштовуємо tracking.
  3. Реалізація — пишемо код спліт-системи, інтегруємо з вашою платформою.
  4. Тестування — запускаємо пілотний тест, перевіряємо логіку.
  5. Деплой — вводимо в експлуатацію, навчаємо команду.

Вартість впровадження залежить від поточної інфраструктури та кількості паралельних тестів. Середня вартість впровадження A/B-тестування для наших клієнтів становить від 10 000 до 30 000 грн. Проводимо попередній аудит і називаємо точну цифру.

Строки та результати

Середній термін впровадження — від 5 до 10 днів залежно від складності інтеграції. За цей час ви отримуєте:

  • Робочу систему A/B тестування.
  • Перші статистично значущі результати.
  • Рекомендації щодо подальшої оптимізації.

Бюджет на впровадження A/B-тестування окупається протягом першого місяця роботи. Зв'яжіться з нами для консультації по вашому проєкту. Гарантуємо професійний підхід та прозору звітність.

Досвід команди — 5+ років в email-маркетингу, більше 50 впроваджених A/B тестів, сертифіковані спеціалісти з популярних ESP.

Згідно з дослідженням Campaign Monitor, персоналізація збільшує open rate на 26%. A/B-тестування дозволяє підвищити open rate на 20-30% порівняно з однотипними розсилками. За даними досліджень, A/B-тестування в 3 рази ефективніше за інтуїтивний вибір теми листа. Замовте впровадження A/B-тестування та отримайте перші результати вже через тиждень.

Для ефективного A/B тестування email-розсилок важливо правильно вибрати інструменти email маркетингу та розрахувати вибірку для A/B тесту, щоб забезпечити статистичну значущість результатів. Спліт-тестування листів допомагає оптимізувати відкриваність та CTA.

Інтеграція 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 не відправляться на мережі МТС/МегаФон/Білайн.

Провайдер Тип Транзакційні листи Маркетингові Особливості
Unisender email+SMS Unisender Go (окремо) так Популярний в РФ, простий REST
SendPulse email+SMS+web push+Viber так так Єдиний API, омніканальність
Mailchimp email Mandrill так Аналітика, міжнародний
Twilio SMS+email так ні Глобальний, дорогий в РФ

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

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

Транзакційні листи (підтвердження замовлення, скидання пароля, статус доставки) — через окремий домен-відправник або субдомен 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 про персональні дані.

Як налаштувати DKIM для домену-відправника?

DKIM дозволяє підписувати листи цифровим підписом, що підвищує довіру поштових серверів.

  1. Згенеруйте пару ключів (наприклад, через OpenSSL: openssl genrsa -out private.key 2048).
  2. Опублікуйте публічний ключ у DNS як TXT-запис для селектора (наприклад, mail._domainkey.tx.example.com).
  3. Вкажіть селектор у провайдера (SendGrid, Mailgun, Unisender).
  4. Перевірте командою dig TXT mail._domainkey.tx.example.com.

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

Підключаємо 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 для доставності та скарг
  • Документація з експлуатації та навчання команди
  • Гарантія доставності та підтримка після запуску

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

Сценарій Термін (робочі дні) Примітка
Базові транзакційні листи (один провайдер) 5–7 днів Ціна розраховується індивідуально після аудиту
Тригерні ланцюжки + SMS + веб-пуши 10–20 днів Ціна розраховується індивідуально після аудиту
Повна омніканальна автоматизація 20–40 днів Ціна розраховується індивідуально після аудиту

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