# A/B-тестирование в CRM-маркетинге: что тестировать, как считать и на что опираться > Плохой A/B-тест опаснее его отсутствия: команда делает неправильные выводы и масштабирует ошибку на всю базу. Показываем, как тестировать рассылки в CRM-маркетинге так, чтобы реально проверять гипотезы. **Рубрика:** Статьи **Дата:** 2026-05-27 Когда у бренда уже миллионная база и десятки сценариев в Mindbox, вопрос «какую тему письма выбрать» перестает быть вопросом вкуса. Каждая отправка — это деньги. И если команда выбирает варианты «на глазок» или потому, что «прошлый раз сработало», бизнес теряет выручку буквально на ровном месте. При этом большинство A/B-тестов, которые мы видим у клиентов, либо некорректные, либо не дают ответа на тот вопрос, ради которого затевались. Самое обидное — инструмент уже есть, он встроен в платформу, его не надо допиливать. Но пользуются им так, что лучше бы не пользовались вообще: тестируют не то, считают не так, выводы делают на 200 открытиях. Вместе с Василиной Бреусенко, CRM-маркетологом ClientCore, разбираемся, как выстроить тестирование в CRM так, чтобы оно влияло на выручку, а не украшало отчет. > **Читайте также:** [ARPU и средний чек: как считать, анализировать и увеличивать](https://blog.clientcore.ru/articles/arpu-i-sredniy-chek-kak-schitat-analizirovat-i-uvelichivat) ## Зачем вообще тестировать, если «и так работает» Главная ловушка зрелого CRM — ощущение, что система уже настроена. Welcome-цепочка крутится, брошенные корзины догоняются, реактивация уходит раз в квартал. Метрики ровные, аудитория не жалуется. Кажется, что трогать нечего. На практике в этот момент компания обычно теряет 15–30% потенциальной выручки канала. Просто потому, что сценарии написаны два года назад, аудитория с тех пор изменилась, а офферы никто не пересматривал. Тестирование в CRM-маркетинге — единственный способ это поймать, не полагаясь на интуицию маркетолога, которому «кажется». Без тестов любая гипотеза о росте упирается в спор «у нас так не работает» vs «а давайте попробуем». Спор бесконечный. A/B-тест закрывает его за две недели и переводит обсуждение из плоскости мнений в плоскость цифр. > В каждом проекте начинаю с аудита того, что команда тестировала за последний год. И в 8 из 10 случаев это либо тесты тем письма с разницей в одно слово, либо "проверки", где контрольной группы вообще не было. Команда думает, что принимает решения на основе данных, а на деле просто отправляет письма и смотрит, что получилось. > > — Василина Бреусенко, CRM-маркетолог, ClientCore **Норма** - тестируется 2–4 гипотезы в месяц на канал - у каждого теста зафиксирована метрика успеха до запуска - результаты складываются в общую базу знаний **Red flag** - «мы тестируем постоянно», но никто не помнит, что именно - решение по тесту принимается на третий день и на 500 отправках - победителя выбирают по open rate, а считают деньги по выручке ## Что тестировать в рассылках: иерархия влияния Если расставить элементы письма по силе влияния на выручку, картина получается контринтуитивной. Тема и прехедер двигают open rate, но почти не двигают деньги. Кнопка и верстка влияют на CTR. Реальная выручка живет в офферах, сегментах и тайминге. Начинать A/B-тест email-рассылки с темы письма — это как чинить машину с замены наклейки на бампере. Технически возможно, но к скорости не имеет отношения. Логика приоритетов такая: 1. **Оффер.** Скидка vs подарок vs бесплатная доставка vs ранний доступ. Разница в конверсии в заказ доходит до 40–60%. 2. **Сегмент и триггер.** Кому и в какой момент отправляем. Одно и то же письмо на «купили 1 раз 30 дней назад» и «купили 1 раз 90 дней назад» дает разный результат на порядок. 3. **Тайминг.** Час отправки, день недели, интервал между касаниями в цепочке. 4. **Контент и структура.** Длинное письмо vs короткое, один блок vs каталог, текст vs визуал. 5. **Тема и прехедер.** Влияет на доходимость до контента, но не на решение купить. 6. **Кнопки, CTA, микрокопирайт.** Тонкая настройка для уже работающих писем. Тестировать нужно то, у чего больше всего пространства для роста. Если у вас CTR 1%, проблема не в кнопке. **Норма** - приоритет отдается тестам оффера и сегментации, а не теме письма - гипотезы ранжируются по ожидаемому влиянию на выручку - микрооптимизация начинается только после проверки крупных гипотез **Red flag** - команда месяцами тестирует формулировки темы и считает это полноценным A/B-тестированием - оффер и тайминг не пересматривались больше года - выбор следующего теста продиктован тем, «что проще запустить» ## Как устроен A/B-тест в Mindbox и где обычно ошибаются В Mindbox A/B-тестирование живет на уровне рассылки и на уровне сценария. Для разовых кампаний — сплит внутри отправки: указываете долю аудитории на каждый вариант (обычно 50/50 для двух вариантов или 10/10/80, если основная масса идет на победителя предыдущего теста). Для триггеров — тест внутри сценария, где система сама распределяет клиентов между ветками. Принципиальный момент: Mindbox считает значимость автоматически, но смотреть нужно не на «зеленую галочку» в интерфейсе, а на размер выборки и продолжительность теста. Платформа покажет победителя и на 1000 отправках, если разница в open rate большая. Это не значит, что результат можно переносить на всю базу. > У одного клиента команда закрыла тест за сутки: вариант B победил с разницей в open rate 4%. Через неделю повторили тот же тест — победил вариант A. Это классика. Когда выборка маленькая, вы тестируете не варианты, а случайность. И принимаете решения на основе шума. > > — Василина Бреусенко, CRM-маркетолог, ClientCore Что важно настроить в Mindbox корректно: - **Целевая метрика.** Не open rate. Выручка на отправку или конверсия в заказ. Open rate — диагностика, а не цель. - **Размер групп.** Минимум по 5 000–10 000 человек на вариант для email, для пушей и SMS — больше. Если база меньше, копите данные на нескольких отправках. - **Длительность.** Минимум 3–5 дней после отправки, для триггеров — 2–4 недели. Поведение растягивается во времени, ранние выводы врут. - **Один тест — одна переменная.** Если меняете и тему, и оффер, и время — вы не узнаете, что сработало. **Норма** - выборка от 5 000 на вариант - одна тестируемая переменная - решение принимается по выручке, а не по открытиям **Red flag** - тест на 800 контактах - меняли «все сразу — посмотрим, что выйдет» - закрыли через 12 часов, потому что «и так все понятно» ## Статистическая значимость без формул: на пальцах В A/B-тестах важно не просто увидеть, что один вариант письма сработал лучше другого. Необходимо понять, можно ли этой разнице доверять. Представьте, что вы подбросили монетку 10 раз, и 7 раз выпал орел. Кажется, что орел выпадает чаще. Но 10 бросков — слишком мало, такой результат мог получиться случайно. А если вы подбросили монетку 1000 раз, и 700 раз снова выпал орел, это уже серьезный сигнал: результат вряд ли случайный. С A/B-тестами та же история. Когда видите «вариант B на 5% лучше», важен не сам факт разницы, а уверенность, что она не случайная. Эта уверенность напрямую зависит от размера выборки и от того, насколько большой эффект. Маленькая выборка плюс маленькая разница — почти наверняка шум. Практическое правило: если Mindbox показывает значимость 95% и выше на достаточной выборке — можно принимать решение. Если 80–90% — продолжайте набирать данные или повторите тест. Ниже 80% — у вас нет результата, как бы ни хотелось его иметь. > Меня часто спрашивают: "можно ли запустить тест на 2000 человек, у нас база маленькая". Можно, но тогда нужно либо накапливать данные за несколько отправок и объединять, либо тестировать только большие изменения — другой оффер, другой механизм. Тонкие штуки типа цвета кнопки на такой выборке не поймаются никогда. > > — Василина Бреусенко, CRM-маркетолог, ClientCore Ещe один момент — про «подсматривание». Привычка проверять тест каждые три часа и закрывать его, как только появилась разница, — это способ обмануть самого себя. Заранее зафиксируйте, на какой выборке и через сколько дней принимаете решение. И не трогайте до этого момента. **Норма** - порог принятия решения зафиксирован до запуска теста - значимость проверяется по достижении нужной выборки, а не по расписанию - результаты с значимостью ниже 95% не внедряются без повторной проверки **Red flag** - тест закрывается сразу, как появилась любая разница - «мы проверили утром — все выглядело хорошо» - статистическую значимость вообще не смотрят, решают по ощущениям ## Что тестировать в триггерных сценариях В разовых рассылках тест прямолинейный: две версии, две группы, результат. В триггерах сложнее, потому что клиент попадает в сценарий не одновременно с другими, а растянуто во времени. Самое ценное, что стоит тестировать в триггерах: - **Задержку.** Брошенная корзина через 1 час vs через 4 часа vs через 24 часа. Разница в конверсии бывает кратной. - **Количество касаний.** Одно письмо vs цепочка из трех. Часто второе и третье письма дают больше выручки, чем первое. - **Каналы.** Email vs email + push vs email + SMS. Считать нужно не только конверсию, но и стоимость канала. - **Условия входа.** Кого вообще пускать в сценарий. Часто «срезание» неподходящих сегментов поднимает конверсию сильнее, чем переписывание писем. В триггерах смотреть нужно не на разовую конверсию письма, а на накопленную выручку с клиента за период. Цепочка может «съесть» клиента, который и так бы купил, — и это плохая цепочка. А может догнать тех, кто не купил бы, — и это хорошая. **Норма** - тестируются задержка, количество касаний и условия входа, а не только текст письма - оценка триггера ведется по накопленной выручке с клиента, а не по CTR одного письма - сценарии пересматриваются минимум раз в полгода по результатам тестов **Red flag** - триггерные сценарии не трогают годами, потому что «работают» - оценка сценария — «конверсия первого письма» - условия входа в сценарий не менялись с момента запуска ## Uplift-тестирование: следующий уровень Когда команда освоила корректные A/B-тесты, наступает момент перехода на uplift-тест в CRM. Идея простая: обычный A/B сравнивает два варианта коммуникации между собой. Uplift сравнивает коммуникацию с ее отсутствием. Зачем? Потому что часть клиентов купила бы и без письма. И когда мы атрибутируем им выручку от рассылки, мы обманываем себя. Uplift-тест отвечает на вопрос: «Сколько мы реально дозаработали благодаря этой коммуникации?» Механика: берем сегмент, делим на две группы. Одна получает коммуникацию, вторая — контрольная — не получает ничего. Через период считаем выручку в обеих группах. Разница — реальный эффект CRM. В Mindbox это делается через выделение контрольной группы в сегменте или в сценарии. > Первое внедрение uplift у клиента почти всегда обнуляет несколько сценариев. Команда годами считала, что реактивация приносит миллионы, а оказывается — клиенты из контрольной группы покупают почти столько же. Это больно, но это правда. И только после такой чистки CRM-канал начинает расти, потому что ресурсы переключаются на то, что действительно работает. > > — Василина Бреусенко, CRM-маркетолог, ClientCore **Норма** - контрольная группа 5–10% от сегмента - uplift считается для всех значимых сценариев минимум раз в полгода - решения о расширении сценария принимаются по incremental revenue, а не по открытиям **Red flag** - контрольной группы нет вообще - «у нас и так все понятно, зачем нам контроль» - атрибуция по last-click без учета органической покупки ## Как встроить тестирование в работу команды Тесты сами себя не запустят. Без процесса все сводится к разовым подвигам энтузиастов, после которых ничего не меняется. > **Читайте также:** [RFM-анализ: что это, как делать и что делать с результатами](https://blog.clientcore.ru/articles/rfm-analiz-chto-eto-kak-delat-i-chto-delat-s-rezultatami) Минимальная инфраструктура: 1. **Бэклог гипотез.** Один документ, куда падают все идеи «а что если» — с приоритетом по ожидаемому эффекту и стоимости проверки. 2. **Календарь тестов.** Какой тест когда запускается, когда заканчивается, кто отвечает. 3. **База результатов.** Один файл, где собраны все проведенные тесты: гипотеза, выборка, результат, выводы, что внедрили. Через год это становится главным активом CRM-команды. 4. **Ритуал разбора.** Раз в месяц команда смотрит, что протестировали, что работает, какие гипотезы из этого вырастают. Без этой системы тестирование остается хаотичным: команда запускает отдельные проверки, но не накапливает знания и не меняет подход к коммуникациям. С процессом каждый тест становится частью общей логики — помогает уточнять гипотезы, улучшать сценарии и планомерно растить выручку CRM-канала. Не стоит сразу запускать десять тестов параллельно. Лучше выбрать две-три самые крупные гипотезы, довести до конца, зафиксировать результат — и только потом масштабировать процесс. Качество выводов важнее количества попыток. **Норма** - бэклог гипотез существует и регулярно пополняется - все результаты тестов зафиксированы с выводами и статусом внедрения - команда проводит ежемесячный разбор итогов тестирования **Red flag** - тесты запускаются спонтанно, без очереди и владельца - результаты нигде не хранятся — «мы помним» - одни и те же гипотезы проверяются повторно, потому что предыдущий результат потерян --- [Открыть статью на сайте](https://blog.clientcore.ru/articles/a-b-testirovanie-v-crm-marketinge-chto-testirovat-kak-schitat-i-na-chto-opiratsya)