Применительно к тесту количества товаров в письме: вы готовите несколько вариантов одного и того же письма, в котором отличается только число товарных предложений: 3, 6, 9, 12… Затем отправляете письма на небольшие части подписной базы, отобранные случайным образом. Лучший вариант по отклику досылаете остальным подписчикам спустя некоторое время. Таким образом, вы гарантированно повышаете отклик на кампанию.

Рекомендации:

• Строго контролируйте количество тестируемых параметров (только один параметр для А/Б-тестов, несколько параметров для многовариантных тестов, но тогда желательно – все возможные комбинации).

• Отбирайте подписчиков в тестовые группы случайным образом (это возьмет на себя рассылочный сервис).

• Включайте в каждую тестовую группу не менее 250 подписчиков (чтобы получить достоверные результаты).

• Включайте в каждую тестовую группу не более 20 000 подписчиков (дальнейшее увеличение размера группы не приведет к повышению точности тестирования).

• Проверяйте варианты на меньшей части базы (в идеале – на 10 %, чтобы как можно больше подписчиков получили наилучший вариант; тесты на 50 % базы и выше уже неэффективны).

Впрочем, иногда в тестировании можно задействовать и 100 % базы, если речь идет не о проверке какого-то текущего параметра (темы письма или призыва к действию), а чего-то более общего (цвета/размера кнопок и прочих элементов дизайна).

• Прежде чем разослать лучший вариант по всей базе, выдерживайте паузу не менее 3 часов (еще лучше – 24).

Статистика рассылок со временем меняется, и нередко вариант, лидирующий по истечении первого часа, оказывается далеко не лучшим в итоговом зачете.

Преимущества параллельного тестирования:

• Быстрота (за одну рассылку можно перебрать сразу несколько вариантов, а не уделять каждому отдельную кампанию).

• Точность (результаты можно трактовать однозначно – если достаточная часть базы отреагировала на письмо наилучшим образом, то это действительно самый эффективный вариант).

Но при каких-либо серьезных тестах (например, когда тестируется не тема письма, а формат подачи товаров) лучше все-таки повторять их несколько раз и усреднять результаты для большей достоверности.

Недостатки:

• База должна быть достаточно велика (более 1000 подписчиков).

К примеру, для простого А/Б-теста с минимальным количеством подписчиков в тестовых группах (по 250) понадобится размер выборки А+Б=250+250=500 подписчиков. Если выборка составляет 10 % от базы (идеальный вариант), то вся база должна включать не менее 5000 подписчиков (на практике можно начинать сплит-тесты уже с 1000 подписчиков).

Для многовариантного тестирования база должна быть еще больше. Если тестируется 4 варианта, то размер выборки составляет 250 x 4=1000 подписчиков. Тогда в идеальном случае база должна быть не менее 10 000 подписчиков (не меньше 2000 в не идеальном случае).

• Нужны дополнительные технические средства.

Для параллельных тестов необходим соответствующий функционал. Как правило, в рассылочных сервисах он представлен, но в разной степени. Не все сервисы поддерживают возможность многовариантного тестирования. Некоторые ограничиваются простыми А/Б-тестами по ограниченному набору параметров (имя отправителя, тема письма, время отправки).

Конечно, можно проводить тестирование отчасти вручную – формировать тестовые группы самостоятельно (при помощи программиста или специального приложения), но в таком случае трудоемкость задачи повышается.

Как уже было замечено выше, для последовательных тестов не нужно никакого вспомогательного функционала. Для параллельного тестирования такой функционал необходим.

В рассылочных сервисах – это возможность сплит-тестирования. В самом общем виде она позволяет устанавливать объем тестовой выборки, менять в письмах отдельные параметры, а также определять механизм выбора победителя: автоматически (по уровню просмотров или кликов) или вручную (на основе самостоятельной оценки всех показателей эффективности в комплексе):

Для тестов за пределами рассылочного сервиса готового функционала нет.

Например, чтобы протестировать нотификации, которые обычно отправляются через CMS, понадобятся либо последовательный подход, либо какой-то «самописный» функционал для параллельного тестирования.

Для проверки содержания сайта (форм или страниц подписки) можно использовать готовое решение – «Эксперименты» в Гугл Аналитикс. Пользоваться им достаточно просто, и помощь IT-специалиста не понадобится.