Делите базу на верх и низ файла - тест уже сломан, даже не начавшись. CRM почти всегда хранит контакты по дате добавления, поэтому «верх» списка часто свежее и теплее «низа». Когда вариант А обходит вариант Б в десять раз, это не победа текста - это разница в возрасте аудитории.
Большинство «A/B-тестов» в WhatsApp-рассылках на самом деле не тесты: это сравнение двух текстов на двух разных аудиториях, отправленных в разное время, с разным числом переменных одновременно. Результат выглядит убедительно, но не отвечает на вопрос «какой текст работает» - в эксперимент незаметно влезли посторонние факторы.
В 2026 году эта ошибка стоит дороже, чем раньше: WABA оценивает качество каждого шаблона отдельно, жалобы на «плохой» вариант могут увести аккаунт в Low Quality, а гипотезы без рандомизации просто сжигают номера - см. WABA и шаблоны.
После этой статьи у вас будет рабочая методика: как разделить базу, какую переменную менять, сколько контактов нужно на вариант и какую метрику считать победителем - без самообмана.
A/B-тест - это сравнение двух вариантов одного сообщения на двух сопоставимых сегментах аудитории, где отличается ровно один элемент. Если меняются оффер, длина, CTA и время отправки одновременно - это не тест, а угадывание.
Готовых инструментов для автоматического сплит-теста в WhatsApp Business Suite нет - ни механики случайного деления базы, ни калькулятора значимости. Всё это держится на маркетологе и внешней CRM.
В рассылках часто встречается и третий вариант: разослать 5–10 разных текстов с одного номера «чтобы быстрее найти креатив». Это не ускоряет поиск - одновременная отправка множества разных формулировок с одного аккаунта читается алгоритмами Meta как работа спам-скрипта, а не маркетолога, и может привести к превентивному бану сессии - см. механику банов.
Тест - это контролируемый эксперимент, а не количество выстрелов в темноту.
Самая грубая ошибка - взять файл и отправить первой половине строк вариант А, второй - вариант Б. Звучит как рандомизация, на практике это деление по хронологии.
Мини-кейс. Маркетолог интернет-магазина разделил базу из 2000 клиентов: первой тысяче строк (клиенты текущего месяца) ушёл вариант А, второй тысяче (база за два года) - вариант Б. Вариант А получил отклик 35%, вариант Б - 2% и каскадный бан номера. Вывод «текст А идеальный» оказался ошибочным: тест сравнил не тексты, а тёплую аудиторию с холодной - см. тёплая vs холодная база.
Решение - перемешать контакты перед делением (случайная функция в таблице или выборка в CRM), а не резать список по позиции. Это не делает эксперимент идеальным, но убирает самый грубый источник искажения - см. сегментацию базы.
В одном тесте меняется ровно один элемент: только первая фраза, только наличие вопроса в конце, только длина текста, только персонализация по имени через переменную {{1}}. Остальное тело сообщения - идентично.
Рабочие пары для теста:
Если поменять оффер и тон одновременно, по итогам теста нельзя сказать, что именно сработало. Результат будет, причина - нет.
Это место, где исходная цифра из плана нуждается в уточнении.
Было (исходный тезис): «Минимум 200 контактов на вариант - и результат значимый».
Стало (после проверки): 200 контактов на вариант - практический ориентир, который называют некоторые операторы рассылок, но не статистический стандарт. В профильных методичках по сплит-тестам чаще встречается планка от 500 контактов на вариант как более надёжная для фиксации разницы. Универсального числа не существует - нужная выборка зависит от базовой конверсии сегмента и от размера разницы, которую вы хотите поймать.
| Источник | Рекомендуемая выборка | Статус |
|---|---|---|
| Практика операторов рассылок | 200–500 контактов на вариант | практический ориентир |
| Методички по сплит-тестам | 500+ контактов на вариант | более строгий стандарт |
| Группы по 30–50 контактов | - | риск случайных колебаний, тест не показателен |
Если ресурс ограничен и есть только 200 контактов на вариант - тест всё равно стоит запускать, но как гипотезу, а не как окончательный вывод. Перепроверить находку на большей базе на следующей итерации - рабочая практика, а не лишняя предосторожность.
Вторая точка, где исходный тезис «считаешь не клики - считаешь ответы» нужно смягчить.
Технически в первом касании клики и не считаются: WhatsApp делает гиперссылки в сообщениях от незнакомых номеров некликабельными, пока получатель не сохранит контакт или не ответит. Дело не в том, что клики «менее важны» - в первом сообщении их физически нет как рабочей метрики.
Response Rate и число начатых диалогов - основная метрика именно первого касания - см. дашборд метрик. Когда диалог уже начат и вы переходите на второй шаг - отправляете каталог, презентацию, ссылку на сайт - клики и конверсии снова становятся осмысленной метрикой.
Read Rate (синие галочки) - самая ненадёжная цифра на дашборде - см. прочитал и не ответил. От 15% до 25% пользователей отключают отчёты о прочтении в настройках приватности, а короткие сообщения многие читают через шторку push-уведомлений без открытия чата - в CRM это останется статусом delivered.
| Метрика | Что показывает | Надёжность для теста |
|---|---|---|
| Response Rate | Доля ответивших на первое сообщение | Высокая - основной KPI первого касания |
| Read Rate | Статус «прочитано» | Низкая - искажена у 15–25% аудитории |
| CTR по ссылке | Клик по ссылке в сообщении | Бессмысленна в первом касании, полезна со второго шага |
| Жалобы (Report) | Доля нажатий «Пожаловаться» | Критична для качества шаблона в WABA |
При тестировании через официальный WABA каждый вариант регистрируется как отдельный шаблон, и Meta оценивает жалобы по каждому шаблону независимо. Если доля нажатий «Пожаловаться» по одному варианту превышает 0,1–0,2% от объёма доставок, его рейтинг может упасть до Low Quality, а сам шаблон - оказаться заблокированным до завершения теста.
Это значит, что победителя нельзя выбирать только по отклику. Вариант с более высоким Response Rate, но с растущими жалобами - не победитель, а риск для аккаунта. Смотреть нужно на пару метрик одновременно: отклик и динамику жалоб.
Варианты А и Б нужно отправлять в один день и в один час, иначе тест начинает измерять не текст, а разницу в активности аудитории по дням недели и времени суток. Запуск варианта А утром в понедельник и варианта Б вечером в пятницу обнуляет результат ещё до анализа.
Скорость рассылки и задержки между сообщениями тоже стоит держать одинаковыми для обоих вариантов. Если один аккаунт делит поток на равные группы с одинаковыми задержками, но кардинально разной семантикой текста, это может читаться системой безопасности как подбор формулировок, а не как ручная рассылка. Чем ближе оба варианта по тону, структуре и длине отправки, тем меньше повод для подобных флагов.
Компания, сдающая в аренду коммерческую недвижимость, разделила базу из 1000 холодных контактов ритейлеров на две рандомизированные группы по 500 номеров.
Вариант А - презентационный текст со ссылкой на коммерческое предложение. Вариант Б - короткий ситуационный вопрос: «вы сейчас рассматриваете расширение сети в [город] или локации заморожены?». В этом конкретном случае вариант А дал Response Rate 1,2% и потерял два номера на жалобах, вариант Б - 29% без банов; полная презентация уходила вторым шагом только тем, кто ответил на вопрос.
Это не значит, что вопрос всегда даёт в десятки раз больше ответов - разница такого масштаба специфична для холодного B2B-сегмента из этого кейса. Но направление совпадает с логикой Response Rate как метрики первого касания: сообщение, которое приглашает к диалогу, а не продаёт сразу, в среднем получает больше ответов, чем презентация.
Форумный кейс, публичной верификации методологии нет.
Если вариант Б победил на выборке 200–500 контактов, это подтверждает только первичную реакцию аудитории на текст. При раскатке того же варианта на базу в десятки тысяч контактов включаются другие ограничения: лимиты скорости отправки, серверные фильтры Meta и накопительный эффект жалоб за длительный период работы.
Победитель малого теста - рабочая гипотеза для масштабирования, а не гарантированный результат. Логичнее раскатывать вариант поэтапно, на возрастающих объёмах, и продолжать следить за жалобами на каждом шаге - см. диагностику текста vs аккаунта.
Перед следующей рассылкой откройте текущий сплит-тест и проверьте два пункта: как именно разделена база и сколько переменных отличается между вариантами. Если хотя бы по одному пункту ответ - «не уверен», результат прошлого теста стоит пересчитать, а не масштабировать.
Практическое правило:
Тест без рандомизации - это не A/B-тест, а сравнение двух аудиторий, которое случайно выглядит как сравнение двух текстов.
