A/B-тесты в аналитике: чек-лист перед запуском и после

Сначала проверьте, что именно сравниваете

Если вариант A и вариант B получают разную аудиторию, а события в аналитике теряются или дублируются, результат теста будет убедительным только на вид. Перед запуском проверьте гипотезу, распределение пользователей и метрики; после — качество данных и способ принятия решения. Ниже — чек-лист для продуктовых и веб-команд, без привязки к конкретной платформе или её API.

Начните с одного изменения и одного основного вопроса. Например: «Увеличит ли новый порядок полей долю пользователей, завершивших оформление?» Формулировка «посмотрим, что будет» не задаёт ни сравниваемые варианты, ни критерий успеха.

Термин. Единица рандомизации — объект, которому назначают вариант эксперимента: пользователь, сессия, аккаунт или другой устойчивый идентификатор. От неё зависит, увидит ли один и тот же человек разные версии.

Чек-лист до запуска

1. Запишите гипотезу и решение. Укажите, что меняется, для кого и какой результат подтвердит гипотезу. Заранее решите, что будете делать при росте основной метрики, её снижении или неопределённом результате. Проверка: команда может объяснить цель эксперимента одним предложением и знает, какое решение примет по итогам.
2. Выберите единицу распределения. Для интерфейса, который человек видит многократно, обычно важно сохранять назначенный вариант между визитами. Рандомизация по сессиям может привести к тому, что один пользователь увидит обе версии. Для командного продукта иногда логичнее назначать вариант на уровне аккаунта, чтобы его участники не работали в разных условиях. Проверка: повторные визиты и разные устройства не меняют назначение там, где оно должно быть постоянным.
3. Определите популяцию и исключения. Зафиксируйте, кто участвует: новые пользователи, все авторизованные клиенты или конкретный сегмент. Отдельно перечислите технические исключения, например внутренний трафик, если вы умеете надёжно его распознать. Не придумывайте исключения после просмотра результата: это даёт возможность незаметно подогнать выборку под желаемый вывод. Проверка: правила включения применяются одинаково к обеим группам и сохраняются в описании эксперимента.
4. Назначьте основную метрику и защитные метрики. Основная отвечает на гипотезу, защитные помогают заметить вред: например, рост отмен заказов при улучшении конверсии. Не превращайте десятки показателей в десятки шансов найти случайный «успех». Зафиксируйте, как считаются числитель, знаменатель и период наблюдения. Проверка: аналитик может получить метрику из событий по записанному правилу, а не по ручной интерпретации.
5. Проверьте события до эксперимента. Убедитесь, что событие назначения варианта и ключевые события воронки отправляются для обеих групп. Проверьте свойства, идентификаторы, повторную отправку, задержку и связку анонимного пользователя с авторизованным. Проверка: тестовые действия видны в аналитике с правильным вариантом, а одно действие не превращается в несколько конверсий.
6. Рассчитайте нужный объём данных. До запуска задайте минимальный эффект, который имеет смысл для бизнеса, и оцените необходимую выборку с учётом базового уровня метрики и выбранного статистического метода. Меньший эффект обычно требует больше наблюдений. Если трафика недостаточно, тест может закончиться без ответа — это не доказательство равенства вариантов. Проверка: записаны плановый объём и условия остановки; цифра не взята из чужого эксперимента без расчёта.
7. Проведите проверку на малой доле трафика. Сначала убедитесь, что вариант действительно показывается, назначение сохраняется, а события поступают. Затем расширяйте охват по плану. Проверка: нет массовых ошибок интерфейса и явных провалов в сборе данных ни в одной группе.

Выбор единицы рандомизации: цена ошибки

Выбирайте не самую простую единицу для аналитики, а ту, на которой реально возникает эффект. Если изменение затрагивает совместную работу, раздавать варианты отдельным сотрудникам одного аккаунта опасно: они могут обмениваться результатами и влиять друг на друга.

Надёжный A/B-тест начинается не с кнопки «запустить», а с ответа на вопрос: какое наблюдение убедит вас изменить продукт — и какое заставит отказаться от изменения?

Во время теста: не подглядывайте без плана

Промежуточные данные полезны для контроля поломок, но постоянная проверка статистической значимости и остановка при первом «победителе» повышают риск ложного вывода. Если вам нужен последовательный анализ или заранее заданные промежуточные проверки, используйте методику, рассчитанную на такой режим. Обычный фиксированный план нельзя незаметно превратить в него, просто проверяя результат каждый день.

• Следите за долями назначений: при плановом распределении группы не должны необъяснимо разъезжаться. Сильное расхождение — повод проверить фильтры, идентификаторы и логику назначения, а не объявлять победителя.
• Проверяйте технические ошибки, задержку событий и резкие изменения объёма трафика. Падение конверсии может оказаться проблемой сбора данных или доставки варианта.
• Не меняйте одновременно гипотезу, аудиторию, основную метрику и срок. Если условия эксперимента пришлось изменить, зафиксируйте это и оцените, можно ли интерпретировать накопленные данные.
• Не останавливайте тест только потому, что график выглядит убедительно. Дождитесь заранее заданного объёма и полного цикла поведения, который важен для продукта. Для сезонного бизнеса это может означать учёт рабочих и выходных дней; универсального числа дней нет.

После остановки: проверьте, прежде чем внедрять

Сначала подтвердите, что данные пригодны для анализа. Проверьте, не было ли перекоса распределения вариантов, пропусков событий, смены логики эксперимента или заметного различия в составе групп. Затем посчитайте основную метрику выбранным заранее методом, покажите оценку эффекта и интервал неопределённости. Одного значения p-value недостаточно, чтобы понять размер возможного эффекта или его практическую цену.

Если результат неубедителен, не называйте тест «ничьей» без оговорок. Возможно, данных хватило, чтобы исключить важный для бизнеса эффект; возможно, интервал всё ещё широк. Это разные выводы. Если результат положительный, проверьте защитные метрики и убедитесь, что выигрыш не куплен ростом ошибок, возвратов или нагрузки на поддержку.

Где чек-лист не спасает

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

Для продакшена отдельно проверьте, что назначение варианта и отправка событий переживают обновления приложения, повторные запросы и смену идентификатора пользователя. Храните описание эксперимента, даты, правила исключения и версию расчёта рядом с результатами. Иначе через месяц команда может не понять, какие именно данные привели к решению.

Что делать дальше

Перед следующим запуском проведите короткое ревью с продуктом, аналитиком и инженером: пусть каждый проверит гипотезу, назначение варианта и путь события до отчёта. После старта смотрите не только на конверсию, но и на качество данных, ошибки и перекос групп. А при выборе статистического метода сверяйтесь с документацией вашей платформы: формулы, учёт повторных наблюдений и поддержка последовательного анализа различаются.