Справка: тест на конверсию
Конверсия — доля пользователей, которые совершили нужное действие хотя бы один раз. Эта вкладка помогает спланировать тест на конверсию и понять его итог.
Что это за метрика
У каждого пользователя есть только два исхода: сделал действие или не сделал. Примеры:
- доля посетителей, оформивших покупку;
- доля новых пользователей, прошедших регистрацию;
- доля открывших письмо, перешедших по ссылке;
- доля пользователей, вернувшихся на следующий день.
Если важно не «сделал или нет», а сколько (сумма покупок, число заказов), используйте вкладку «Среднее». Если метрика — отношение событий (клики на показы), — вкладку «Ratio-метрики».
Шаг 1. Планирование: «Расчёт размера выборки»
- Базовая конверсия — текущее значение в контроле. Возьмите его из свежих данных за несколько недель для той же аудитории и того же шага воронки.
- MDE (минимальный эффект) — самое маленькое улучшение, которое вам важно не пропустить. Его можно задать в процентах от текущего значения («на 10% больше») или в процентных пунктах («с 10% до 11%»). Выбирайте исходя из бизнеса: какой рост окупит внедрение. Чем меньше MDE, тем больше нужно пользователей — уменьшение эффекта вдвое требует примерно вчетверо больше трафика.
- Уровень значимости — насколько вы готовы рискнуть «найти» эффект, которого нет. Обычно 0,05, то есть 5%.
- Мощность — вероятность заметить эффект, если он действительно есть. Обычно 0,8 (80%); для важных решений — 0,9.
- Тип гипотезы — двусторонняя проверяет изменение в обе стороны и подходит почти всегда. Односторонняя требует меньше трафика, но не позволяет честно заявить об ухудшении.
- Число групп и доля контроля — для классического A/B оставьте 2 группы и 50%. Если вариантов несколько, включите поправку Бонферрони.
- Трафик в день — сколько пользователей в сутки попадает в тест. Калькулятор посчитает длительность; округлите её вверх до целых недель.
- CUPED — необязательно. Если есть история пользователей, выборку можно уменьшить. В блоке «Расчёт CUPED» загрузите два CSV (столбцы user_id и метрика) за соседние периоды той же длины, что и будущий тест, и нажмите «Рассчитать CUPED». Для теста в августе: период 1 (X) — июнь, период 2 (Y) — июль. Сайт посчитает корреляцию и подставит её в поле. Кто есть только в периоде 1, в расчёт не войдёт; у тех, кто есть только в периоде 2, за период 1 ставится 0. Примеры файлов — во вкладке «Вики» → «Примеры CSV».
Как провести тест
- Зафиксируйте план заранее: метрику, ожидаемый эффект, уровень значимости, мощность и длительность. Менять их по ходу теста нельзя.
- Не подглядывайте. Не принимайте решение, как только результат «стал значимым». Если смотреть каждый день и остановиться при первом успехе, ложных побед будет в разы больше, чем обещает уровень значимости.
- Длительность — целыми неделями. Поведение в будни и выходные разное, поэтому тест должен идти минимум 1–2 полные недели, даже если выборка набралась раньше.
- Один пользователь — одна группа. Пользователь не должен попадать то в контроль, то в тест.
- Не меняйте ничего во время теста: ни долю трафика, ни сам вариант. Если пришлось — запускайте тест заново.
Шаг 2. Анализ: «Анализ результатов»
- Введите для каждой группы число пользователей и сколько из них совершили целевое действие.
- Укажите тот же уровень значимости и тип гипотезы, что и при планировании.
- Заполните ожидаемую долю контроля (для проверки SRM) и запланированный MDE — тогда калькулятор скажет, хватило ли выборки.
Как читать результат
- Вердикт
- Зелёная плашка — конверсия в тестовой группе значимо выше, красная — значимо ниже, серая — разница не доказана.
- p-value
- Показывает, насколько удивительным был бы такой результат, если бы изменение на самом деле ни на что не влияло. Чем меньше p-value, тем меньше похоже на случайность. Если оно меньше выбранного уровня значимости (обычно 0,05) — результат считается значимым. p-value — это не «вероятность, что гипотеза верна» и не размер эффекта.
- Доверительный интервал
- Диапазон правдоподобных значений настоящего эффекта. Правильно говорить так: «если повторять эксперимент много раз, интервалы, построенные этим способом, в 95% случаев накроют настоящий эффект». Если весь интервал выше нуля — эффект положительный, если ниже — отрицательный, если захватывает ноль — нулевой эффект исключить нельзя. Широкий интервал означает, что данных мало и эффект оценён неточно.
- Мощность для MDE
- Хватило ли пользователей, чтобы заметить запланированный эффект. Если мощность ниже цели (обычно 80%), «нет значимости» почти ничего не говорит.
- SRM
- Проверка, что пользователи разделились между группами так, как задумывалось (например, поровну). Красное предупреждение SRM означает поломку в разбиении или в сборе данных — такому тесту доверять нельзя, пока не найдена причина.
- Доверительные интервалы групп
- Показывают точность оценки конверсии в каждой группе отдельно. Для решения важнее интервал разницы между группами.
Что делать в каждом случае
- Значимо лучше и нет предупреждений. Изменение можно внедрять. Посмотрите на нижнюю границу интервала: даже в худшем правдоподобном случае эффект должен окупать внедрение.
- Значимо хуже. Не внедряйте. Разберитесь, почему вариант навредил, — это тоже ценный результат.
- Не значимо, выборки было достаточно. Скорее всего, эффекта такого размера нет. Решайте по другим соображениям или проверяйте более смелую идею.
- Не значимо, выборки не хватило. Вывод сделать нельзя. Можно продлить тест до запланированного размера (не подглядывая) или запустить заново с большим трафиком.
- Есть SRM. Не принимайте никаких решений, сначала найдите и исправьте причину, затем перезапустите тест.
Типичные ошибки
- Считать конверсию по сессиям или визитам, когда пользователи делились на группы целиком: один пользователь даёт много сессий, и точность получается завышенной.
- Останавливать тест при первом значимом результате.
- Говорить «эффекта нет», когда выборки просто не хватило.
- Проверять сразу много метрик и радоваться той, что «выстрелила», — для этого есть вкладка «Мульти-метрики» с поправками.
- Игнорировать предупреждение SRM.
- Брать базовую конверсию из другого сегмента (например, по всем пользователям, а тест — только на новых).
Справка: тест на среднее значение метрики на пользователя
Эта вкладка — для метрик, где у каждого пользователя есть число: сколько он потратил, сколько сделал заказов, сколько минут провёл в приложении.
Что это за метрика
Сравниваются средние значения на пользователя в группах. Примеры:
- выручка на пользователя (включая тех, кто ничего не купил);
- средний чек среди покупателей;
- число заказов или просмотренных страниц на пользователя;
- время в приложении за неделю.
Если считаете «средний чек» как сумму всех покупок, делённую на число заказов, а пользователь может сделать несколько заказов, — это ratio-метрика, используйте вкладку «Ratio-метрики».
Шаг 1. Планирование: «Расчёт размера выборки»
- Базовое среднее — текущее значение метрики в контроле по историческим данным.
- Стандартное отклонение — насколько сильно пользователи отличаются друг от друга. Его легко посчитать в SQL или Excel по данным за прошлые недели. Это главный фактор размера выборки: чем больше разброс, тем больше нужно пользователей. У денежных метрик разброс часто больше самого среднего — это нормально.
- MDE — минимальный эффект, который важно заметить: в процентах от среднего или в рублях.
- Уровень значимости и мощность — обычно 0,05 и 0,8.
- Число групп, доля контроля, трафик в день — как в других вкладках; длительность округляйте до целых недель.
- CUPED — необязательное поле, если вы планируете использовать данные пользователей до теста (см. ниже). В блоке «Расчёт CUPED» загрузите два CSV (столбцы user_id и метрика) за соседние периоды той же длины, что и будущий тест, и нажмите «Рассчитать CUPED». Для теста в августе: период 1 (X) — июнь, период 2 (Y) — июль. Сайт посчитает корреляцию и подставит её в поле. Кто есть только в периоде 1, в расчёт не войдёт; у тех, кто есть только в периоде 2, за период 1 ставится 0. Примеры файлов — во вкладке «Вики» → «Примеры CSV».
CUPED простыми словами
Пользователи сильно различаются: кто-то всегда тратит много, кто-то мало. Этот разброс — главный «шум», который мешает увидеть эффект. Но многое о пользователе известно ещё до теста: сколько он тратил в прошлом месяце.
CUPED использует это знание. Он «вычитает» из результата ту часть, которую можно было предсказать по прошлому поведению, и сравнивает группы уже по очищенной метрике. Эффект изменения от этого не меняется, а шум уменьшается — тест становится чувствительнее, как будто пользователей стало больше.
- Чем сильнее метрика во время теста похожа на ту же метрику до теста, тем больше выигрыш. При хорошей связи нужно почти вдвое меньше пользователей.
- Данные «до теста» должны быть собраны до старта эксперимента — изменение не должно на них влиять.
- Новым пользователям без истории можно поставить ноль — метод останется корректным, просто выигрыш будет меньше.
- CUPED подходит и для конверсии: по каждому пользователю ставьте 1 или 0 и используйте режим «Сырые данные + CUPED».
Как провести тест
- Зафиксируйте план заранее: метрику, ожидаемый эффект, уровень значимости, мощность и длительность. Менять их по ходу теста нельзя.
- Не подглядывайте. Не принимайте решение, как только результат «стал значимым». Если смотреть каждый день и остановиться при первом успехе, ложных побед будет в разы больше, чем обещает уровень значимости.
- Длительность — целыми неделями. Поведение в будни и выходные разное, поэтому тест должен идти минимум 1–2 полные недели, даже если выборка набралась раньше.
- Один пользователь — одна группа. Пользователь не должен попадать то в контроль, то в тест.
- Не меняйте ничего во время теста: ни долю трафика, ни сам вариант. Если пришлось — запускайте тест заново.
Шаг 2. Анализ: «Анализ результатов»
Есть три режима ввода:
- Сводные статистики — если у вас уже посчитаны по группам число пользователей, среднее и стандартное отклонение.
- Сырые данные — значения по каждому пользователю (можно загрузить CSV). Дополнительно считаются бутстрап (проверка, не опирающаяся на «правильную» форму распределения), критерий Манна–Уитни и анализ выбросов.
- Сырые данные + CUPED — для каждого пользователя метрика во время теста и до теста. Результат показывается рядом: без CUPED и с ним.
Как читать результат
- Вердикт
- Зелёная плашка — среднее в тестовой группе значимо выше, красная — значимо ниже, серая — разница не доказана.
- p-value
- Показывает, насколько удивительным был бы такой результат, если бы изменение на самом деле ни на что не влияло. Чем меньше p-value, тем меньше похоже на случайность. Если оно меньше выбранного уровня значимости (обычно 0,05) — результат считается значимым. p-value — это не «вероятность, что гипотеза верна» и не размер эффекта.
- Доверительный интервал
- Диапазон правдоподобных значений настоящего эффекта. Правильно говорить так: «если повторять эксперимент много раз, интервалы, построенные этим способом, в 95% случаев накроют настоящий эффект». Если весь интервал выше нуля — эффект положительный, если ниже — отрицательный, если захватывает ноль — нулевой эффект исключить нельзя. Широкий интервал означает, что данных мало и эффект оценён неточно.
- Мощность для MDE
- Хватило ли пользователей, чтобы заметить запланированный эффект. Если мощность ниже цели (обычно 80%), «нет значимости» почти ничего не говорит.
- SRM
- Проверка, что пользователи разделились между группами так, как задумывалось (например, поровну). Красное предупреждение SRM означает поломку в разбиении или в сборе данных — такому тесту доверять нельзя, пока не найдена причина.
- Выбросы
- Несколько очень больших значений (оптовые покупки, боты) могут сильно сдвинуть среднее. Если калькулятор предупреждает о выбросах, проверьте данные и сравните вывод с бутстрапом.
- Сравнение «без CUPED / с CUPED»
- Оценки эффекта должны быть близки, а интервал с CUPED — уже. Если оценки сильно расходятся, проверьте, что данные «до теста» действительно собраны до старта.
Что делать в каждом случае
- Значимо лучше и нет предупреждений. Изменение можно внедрять. Посмотрите на нижнюю границу интервала: даже в худшем правдоподобном случае эффект должен окупать внедрение.
- Значимо хуже. Не внедряйте. Разберитесь, почему вариант навредил, — это тоже ценный результат.
- Не значимо, выборки было достаточно. Скорее всего, эффекта такого размера нет. Решайте по другим соображениям или проверяйте более смелую идею.
- Не значимо, выборки не хватило. Вывод сделать нельзя. Можно продлить тест до запланированного размера (не подглядывая) или запустить заново с большим трафиком.
- Есть SRM. Не принимайте никаких решений, сначала найдите и исправьте причину, затем перезапустите тест.
Типичные ошибки
- Не учитывать выбросы: один крупный заказ может «создать» или «спрятать» эффект.
- Считать средний чек только среди покупателей и делать вывод о выручке: если изменение повлияло на то, кто покупает, такое сравнение искажено. Для выручки берите всех пользователей.
- Брать для CUPED данные, на которые уже повлиял тест.
- Оценивать разброс по слишком короткому периоду — тест получится недооценённым по выборке.
- Подглядывать и останавливать тест досрочно.
Справка: ratio-метрики
Ratio-метрика — это отношение двух сумм, когда пользователей делили на группы целиком, а считаем события.
Что это за метрика
- CTR — все клики, делённые на все показы;
- средний чек — вся выручка, делённая на все заказы (если пользователь делает несколько заказов);
- заказы на сессию, время на просмотр, доля успешных поисков и т.п.
Отличие от обычной конверсии и среднего: в группу попадает пользователь, а в знаменателе — его события, и их у разных пользователей разное количество.
Почему нельзя считать каждый показ отдельно
Кажется естественным взять все показы как независимые наблюдения. Но показы одного человека связаны: активный пользователь, который любит кликать, даёт сотни «наблюдений» с похожим поведением. Если этого не учесть, калькулятор будет думать, что данных гораздо больше, чем на самом деле. Итог — слишком маленькие p-value и много ложных «побед».
Поэтому разброс нужно оценивать по пользователям. Калькулятор показывает для сравнения и «наивный» результат, чтобы было видно, насколько он ошибается.
Дельта-метод простыми словами
Для каждого пользователя известны две величины: сколько у него было событий в знаменателе (например, показов) и в числителе (кликов). Дельта-метод — способ правильно оценить точность отношения, учитывая, что обе величины у пользователя случайны и связаны между собой: у активных пользователей больше и показов, и кликов. Он превращает ratio в «почти обычное среднее по пользователям», для которого уже работают привычные тесты и доверительные интервалы.
Для проверки калькулятор дополнительно считает бутстрап по пользователям: много раз заново собирает выборку из ваших же пользователей целиком (со всеми их событиями) и смотрит, как меняется результат. Если дельта-метод и бутстрап согласуются — всё в порядке.
Шаг 1. Планирование: «Расчёт размера выборки»
- Проще всего — загрузить CSV предпериода (одна строка — один пользователь, столбцы числителя и знаменателя) и нажать «Оценить параметры». Калькулятор сам заполнит все поля.
- Базовое значение — текущее значение метрики в контроле, например CTR 5%.
- Среднее знаменателя на пользователя, разбросы и связь числителя со знаменателем — характеристики пользователей по историческим данным. Если считать их вручную, используйте таблицу «один пользователь — одна строка».
- MDE, уровень значимости, мощность, трафик — как в других вкладках. Размер выборки получается в пользователях, а не в показах.
- CUPED — необязательно. В блоке «Расчёт CUPED» загрузите два CSV за соседние периоды той же длины, что и будущий тест (в каждом — user_id, числитель и знаменатель) и нажмите «Рассчитать CUPED». Для теста в августе: период 1 (X) — июнь, период 2 (Y) — июль. Сайт сначала переведёт ratio каждого пользователя в одну величину (числитель минус общее отношение × знаменатель), потом посчитает корреляцию и подставит ρ в поле. Кто есть только в периоде 1, в расчёт не войдёт; у тех, кто есть только в периоде 2, за период 1 ставится 0. Примеры файлов — во вкладке «Вики» → «Примеры CSV».
Как провести тест
- Зафиксируйте план заранее: метрику, ожидаемый эффект, уровень значимости, мощность и длительность. Менять их по ходу теста нельзя.
- Не подглядывайте. Не принимайте решение, как только результат «стал значимым». Если смотреть каждый день и остановиться при первом успехе, ложных побед будет в разы больше, чем обещает уровень значимости.
- Длительность — целыми неделями. Поведение в будни и выходные разное, поэтому тест должен идти минимум 1–2 полные недели, даже если выборка набралась раньше.
- Один пользователь — одна группа. Пользователь не должен попадать то в контроль, то в тест.
- Не меняйте ничего во время теста: ни долю трафика, ни сам вариант. Если пришлось — запускайте тест заново.
Шаг 2. Анализ: «Анализ результатов»
- Сырые данные — загрузите CSV: столбец группы, числитель и знаменатель на каждого пользователя. Выберите столбцы и какое значение означает контроль, а какое тест.
- Сводные статистики — если вы уже посчитали в SQL по каждой группе средние, разбросы и связь числителя и знаменателя.
Как читать результат
- Вердикт
- Зелёная плашка — значение метрики в тестовой группе значимо выше, красная — значимо ниже, серая — разница не доказана.
- p-value
- Показывает, насколько удивительным был бы такой результат, если бы изменение на самом деле ни на что не влияло. Чем меньше p-value, тем меньше похоже на случайность. Если оно меньше выбранного уровня значимости (обычно 0,05) — результат считается значимым. p-value — это не «вероятность, что гипотеза верна» и не размер эффекта.
- Доверительный интервал
- Диапазон правдоподобных значений настоящего эффекта. Правильно говорить так: «если повторять эксперимент много раз, интервалы, построенные этим способом, в 95% случаев накроют настоящий эффект». Если весь интервал выше нуля — эффект положительный, если ниже — отрицательный, если захватывает ноль — нулевой эффект исключить нельзя. Широкий интервал означает, что данных мало и эффект оценён неточно.
- Мощность для MDE
- Хватило ли пользователей, чтобы заметить запланированный эффект. Если мощность ниже цели (обычно 80%), «нет значимости» почти ничего не говорит.
- SRM
- Проверка, что пользователи разделились между группами так, как задумывалось (например, поровну). Красное предупреждение SRM означает поломку в разбиении или в сборе данных — такому тесту доверять нельзя, пока не найдена причина.
- Дельта-метод и бутстрап
- Два интервала на графике должны быть похожи. Если они сильно различаются, данных мало или есть экстремальные пользователи — больше доверяйте бутстрапу.
- Наивный тест по событиям
- Показан только для сравнения. Не принимайте решения по нему.
Что делать в каждом случае
- Значимо лучше и нет предупреждений. Изменение можно внедрять. Посмотрите на нижнюю границу интервала: даже в худшем правдоподобном случае эффект должен окупать внедрение.
- Значимо хуже. Не внедряйте. Разберитесь, почему вариант навредил, — это тоже ценный результат.
- Не значимо, выборки было достаточно. Скорее всего, эффекта такого размера нет. Решайте по другим соображениям или проверяйте более смелую идею.
- Не значимо, выборки не хватило. Вывод сделать нельзя. Можно продлить тест до запланированного размера (не подглядывая) или запустить заново с большим трафиком.
- Есть SRM. Не принимайте никаких решений, сначала найдите и исправьте причину, затем перезапустите тест.
Типичные ошибки
- Считать каждый показ, сессию или заказ отдельным наблюдением.
- Путать отношение сумм со средним отношений по пользователям — это разные метрики.
- Планировать выборку в событиях, а не в пользователях.
- Удалять пользователей без событий в знаменателе без причины — это может исказить сравнение, если тест влияет на активность.
- Подглядывать и останавливать тест досрочно.
Справка: несколько метрик и guardrails
В реальном эксперименте смотрят не одну метрику, а сразу несколько. Эта вкладка помогает не обмануться случайными «победами» и не выкатить изменение, которое что-то сломало.
Роли метрик
- Целевая
- Главная метрика, ради которой делается изменение. По ней принимается решение. Лучше всего — одна.
- Вторичные
- Помогают понять, как именно сработало изменение (например, конверсия выросла — а что с чеком и кликами?). Решение по ним не принимается.
- Guardrail («ограничители»)
- Метрики безопасности, которые не должны заметно ухудшиться: скорость загрузки, отмены, возвраты, жалобы, ошибки.
Для каждой метрики укажите направление: для выручки «рост лучше», для времени загрузки или возвратов — «снижение лучше».
Почему нужны поправки на множественные сравнения
Каждая проверка с уровнем значимости 5% — это небольшой шанс случайно увидеть эффект, которого нет. Если проверить 10 метрик, шанс хотя бы одной ложной «победы» уже около 40%. Чем больше метрик и вариантов, тем больше случайных находок.
Поправка делает каждую проверку строже, чтобы общий риск ошибиться оставался под контролем:
- Без поправки — только если метрика одна или вы сознательно смотрите на остальные как на подсказки.
- Бонферрони — самый простой и самый строгий способ: общий риск хотя бы одной ложной находки не больше выбранного уровня. Минус — легко пропустить настоящий эффект.
- Холм — даёт ту же гарантию, что и Бонферрони, но находит эффекты чаще. Хороший выбор по умолчанию.
- Бенджамини–Хохберг — мягче: гарантирует, что среди найденных «значимых» метрик в среднем не больше 5% ложных. Удобен, когда вторичных метрик много и они нужны для исследования.
Поправка охватывает все целевые и вторичные метрики во всех тестовых вариантах.
Guardrails простыми словами
«Ухудшение не значимо» не значит «ухудшения нет» — может, просто мало данных. Поэтому для guardrail-метрик вопрос ставится иначе: можно ли доказать, что метрика ухудшилась не больше допустимого?
- Заранее договоритесь о допустимом ухудшении (пороге): например, «время загрузки может вырасти не больше чем на 3%». Это бизнес-решение, а не статистика.
- Калькулятор проверяет, лежит ли весь правдоподобный диапазон изменения по «безопасную» сторону от порога.
- Статусы: ок — доказано, что ухудшение меньше порога; не доказано, что не хуже — данных недостаточно, диапазон заходит за порог; значимо ухудшилась — метрика точно стала хуже.
Guardrails обычно не корректируют: чтобы сказать «все guardrails в порядке», должна пройти каждая проверка, и это само по себе достаточно строго. Включить поправку можно, если нужен особенно осторожный режим.
Как пользоваться вкладкой
- Выберите уровень значимости, способ поправки, уровень значимости для guardrails и число тестовых вариантов.
- Добавьте метрики: вручную (сводные данные по группам) или из CSV по пользователям — выберите столбец группы, контроль и по очереди нужные столбцы метрик.
- Для каждой метрики проверьте тип, роль и направление; для guardrails задайте порог.
- Нажмите «Проанализировать все метрики».
Список метрик, их роли и пороги нужно определить до запуска теста. Если добавлять метрики после того, как увидели результаты, поправки теряют смысл.
Как провести тест
- Зафиксируйте план заранее: метрику, ожидаемый эффект, уровень значимости, мощность и длительность. Менять их по ходу теста нельзя.
- Не подглядывайте. Не принимайте решение, как только результат «стал значимым». Если смотреть каждый день и остановиться при первом успехе, ложных побед будет в разы больше, чем обещает уровень значимости.
- Длительность — целыми неделями. Поведение в будни и выходные разное, поэтому тест должен идти минимум 1–2 полные недели, даже если выборка набралась раньше.
- Один пользователь — одна группа. Пользователь не должен попадать то в контроль, то в тест.
- Не меняйте ничего во время теста: ни долю трафика, ни сам вариант. Если пришлось — запускайте тест заново.
Как читать итоговое решение
- Катить — целевая метрика значимо улучшилась с учётом поправки, а все guardrails в статусе «ок».
- Не катить — целевая метрика значимо ухудшилась, какой-то guardrail значимо ухудшился, улучшение не найдено или есть SRM.
- Нужно больше данных — эффект по целевой метрике в нужную сторону, но не доказан, или безопасность guardrails пока не доказана. Продлите тест до запланированного размера или запустите заново с большим трафиком.
- p и p скорректированное
- Решение принимается по скорректированному значению. Метрика может быть «значима» без поправки, но перестать быть значимой с поправкой — значит, такой результат вполне мог быть случайным.
- Доверительные интервалы
- С поправкой они шире обычных — это честная плата за проверку многих метрик.
- SRM
- Если размеры групп не соответствуют задуманному разбиению, решение — «Не катить», пока не найдена причина.
- Вторичные метрики
- Значимые изменения вторичных метрик — повод для новых гипотез и тестов, а не основание для решения.
Типичные ошибки
- Смотреть на десяток метрик без поправки и выкатывать по той, что «выросла».
- Назначать целевой ту метрику, которая выросла, уже после теста.
- Считать guardrail безопасным только потому, что ухудшение «не значимо».
- Задавать слишком широкий порог для guardrails, чтобы тест «прошёл».
- Добавлять много тестовых вариантов при небольшом трафике: поправка становится строже, и шансов найти эффект меньше.
Подсказки: как выбрать метрику и не попасть в ловушку
Короткие практические заметки к калькулятору. Без формул — про то, какую вкладку открыть и о чём помнить, пока эксперимент ещё не запущен.
Какую вкладку выбрать
Сначала решите, что именно вы сравниваете у одного пользователя или у потока событий. От этого зависит и вкладка, и метод.
| Что измеряете | Примеры | Вкладка | Как считают |
|---|---|---|---|
| Доля пользователей с событием «да / нет» | Покупка, регистрация, клик по письму, возврат на 7-й день, отток | Конверсия | Один бинарный исход на пользователя |
| Число на каждого пользователя, включая нули | Выручка на пользователя (ARPU), заказы на пользователя, минуты в приложении за неделю | Среднее | Одно число на человека, сравнивают средние |
| Число только среди тех, кто совершил действие | ARPPU — средний чек среди купивших | Среднее | Тоже среднее, но это уже не про всю выручку: часть эффекта «ушла» в конверсию |
| Отношение двух сумм, когда у людей разное число событий | Клики / показы (CTR), выручка / заказы (средний чек заказа), минуты / сессии | Ratio-метрики | Дельта-метод или бутстрап по пользователям |
| Сразу несколько метрик и «красные линии» | Целевая + вторичные + скорость загрузки, жалобы, отток | Мульти-метрики | Поправки на множественные сравнения и отдельно guardrails |
Выручка: ARPU, а не сумма по группе
Если цель теста — понять, приносит ли изменение больше денег, основная метрика почти всегда ARPU: средняя выручка на пользователя, включая тех, кто ничего не купил (у них значение — ноль). Это как раз случай для вкладки «Среднее».
Сравнивать суммарную выручку групп не стоит. Сумма растёт просто потому, что в группу попало больше людей. Даже небольшая ошибка сплита или разный доходивший трафик сделает «победителя» из той группы, где пользователей оказалось больше. Среднее на человека от размера группы само по себе не зависит.
Историческую выручку того же пользователя до теста полезно взять ковариатой: во вкладке «Среднее» это CUPED. У денежных метрик корреляция «до / во время» часто высокая, и шум заметно падает, а смысл эффекта остаётся тем же — «на сколько изменилась выручка на пользователя».
ARPU, ARPPU и конверсия: не путайте разложение
Выручку на пользователя можно мысленно разложить: доля купивших × средний чек среди купивших (ARPPU). Решение о выкатке лучше принимать по ARPU — он уже содержит оба куска.
ARPPU смотреть полезно, чтобы понять как изменилась выручка, но опасно делать его главной метрикой. Типичная ловушка: изменение приводит новых покупателей с небольшими заказами. Конверсия растёт, ARPU растёт или держится, а ARPPU падает — среднее среди покупателей «размылось» мелкими чеками. Это не обязательно провал: просто покупать стали чаще.
Обратная ловушка: отсечь дешёвые заказы или новичков и радоваться росту ARPPU, хотя людей, которые платят, стало меньше, и общая выручка просела.
Если всё же сравниваете ARPPU, помните: вы смотрите условное среднее «среди купивших». Состав купивших в A и B может стать разным — это уже не тот же набор людей.
Нули оставляют. Их удаление меняет вопрос
Ноль — честный ответ: пользователь ничего не купил, не заказал, не провёл времени. Если выкинуть нули «чтобы не портили среднее», вы незаметно переходите от ARPU к ARPPU (или от времени на всех к времени только среди заходивших) и теряете эффект на сам факт действия.
Оставляйте нули в данных для вкладки «Среднее». Если нулей очень много и распределение похоже на «сначала конверсия, потом сумма среди купивших», разложите метрику и смотрите обе части — но решение держите на полной средней, со всеми пользователями.
Киты, тяжёлые хвосты и винзоризация заранее
У выручки несколько крупных покупателей («китов») могут раскачать среднее сильнее, чем вся остальная группа. Отсюда огромное стандартное отклонение и выборка, которая «не сходится». Это нормально для денег, а не ошибка в SQL — хотя выброс-баг, конечно, стоит отдельно проверить.
Винзоризация — заранее выбранное правило вроде «значения выше такого-то процентиля подрезать до него». Его фиксируют до запуска и применяют одинаково к обеим группам. Нельзя сначала посмотреть p-value, потом отрезать неудобных китов: так легко подогнать значимость.
При сильной скошенности на небольших выборках обычный t-тест для среднего бывает неточен. Тогда смотрят бутстрап доверительного интервала для среднего (во вкладке «Среднее» он есть в режиме сырых данных). Критерий Манна–Уитни отвечает на другой вопрос: склонен ли случайный пользователь B оказаться «выше» случайного пользователя A. Он не проверяет равенство средних и может стать значимым, когда среднее почти не сдвинулось (и наоборот).
Время на сайте, длительность сессии и «больше — не всегда лучше»
Время в продукте на пользователя за период (одна сумма минут на человека, включая тех, кто не заходил — у них ноль) — обычное среднее. Его считают во вкладке «Среднее».
Средняя длительность сессии — это уже отношение: сумма длительностей всех сессий, делённая на число сессий. У разных людей разное число сессий, поэтому усреднять «длительность сессии» как будто у каждого пользователя один одинаково важный замер нельзя. Это ratio-метрика, вкладка «Ratio-метрики».
Больше времени — не всегда победа. Человек мог заблудиться в меню, ждать медленную загрузку или не найти кнопку. Если оптимизируете вовлечённость, заранее поставьте guardrail во вкладке «Мульти-метрики»: например, конверсию в целевое действие, жалобы или скорость загрузки не должны просесть.
Средний чек заказа, CTR и когда нужен дельта-метод
Если «средний чек» считают как всю выручку, делённую на все заказы, а пользователь может сделать несколько заказов, это не среднее на пользователя. Числитель и знаменатель — суммы по событиям, и у людей разный вклад. Считайте это во вкладке «Ratio-метрики».
С CTR та же история. «Клики, делённые на показы» по всей группе — общий CTR, его стандартную ошибку оценивают дельта-методом (или бутстрапом) по пользователям. А «средний CTR пользователей», где человек с одним показом и человек с тысячей показов имеют одинаковый вес, — другая метрика. Она не равна общему CTR.
Пользователей сплитовали — анализируйте пользователей. Если сделать вид, что каждый показ независим, разброс будет занижен: показы одного человека похожи друг на друга, и ложных срабатываний станет больше.
Удержание, отток и счётчики
Retention («вернулся на 7-й день / не вернулся») и отток («ушёл / не ушёл») — бинарные исходы на пользователя. Это конверсия, даже если в отчётах их не называют этим словом. Считайте во вкладке «Конверсия»; для оттока заранее отметьте, что снижение — это хорошо.
Счётчики вроде «число заказов на пользователя» или «число сессий за неделю» — обычные средние (вкладка «Среднее»), если у каждого человека одно число. Если же метрика звучит как «заказы на сессию» или «ошибки на запрос», снова получается отношение сумм — «Ratio-метрики».
Единица рандомизации и единица анализа
Кого делили на группы, того и анализируйте. Чаще всего сплитуют пользователя. Тогда строка данных — тоже пользователь, а его заказы, сессии и показы только складываются внутри него.
Если сплитовали пользователей, а в тест отправили каждую сессию или каждый заказ как независимое наблюдение, наблюдения одного человека коррелируют. Формально выборка кажется больше, чем есть на самом деле, доверительные интервалы становятся узкими, и «значимость» появляется слишком часто.
И наоборот: если рандомизировали торговую точку, школу или кластер, а считают так, будто независимы отдельные люди внутри кластера, ошибка та же. Нужна оценка, которая уважает кластеры.
SRM: когда размеры групп «не те»
SRM (несовпадение доли групп с планом) — один из самых важных предупреждающих сигналов. Если делили 50/50, а получилось 48/52 на большой выборке, дело почти наверняка не в случае, а в сплиттере, в фильтре, в том, что одно из событий логируется только в варианте, или в том, что часть людей отсеялась по-разному.
Калькулятор проверяет SRM сам. Если он сработал, не интерпретируйте эффект, пока не найдёте причину. Сдвинутый сплит легко имитирует рост или падение метрики.
Подглядывание, фиксированная длительность и полные недели
Размер выборки и дату остановки задают заранее. Каждый день открывать отчёт и выключать тест, едва p-value пересекло 0,05, — значит многократно давать себе шанс «поймать» случайность. Доля ложных побед становится заметно выше обещанных пяти процентов.
Длительность округляйте до целых недель: так в обеих группах будет одинаковая смесь будней и выходных. Иначе легко сравнить «контрольную пятницу» с «тестовыми выходными» или поймать зарплатный день только в одной календарной нарезке. Сезонность (праздники, распродажи, погода) тоже должна одинаково покрывать группы — поэтому эксперимент лучше не начинать и не резать ровно накануне чёрной пятницы без плана.
Эффект новизны и привыкания
Старые пользователи часто активно исследуют новое в первые дни (новизна), а потом возвращаются к привычкам. Бывает и наоборот: сначала все путаются, а через неделю осваиваются (привыкание, primacy). Короткий тест легко принять первый всплеск или первую просадку за постоянный эффект.
Имеет смысл смотреть динамику по дням и отдельно новых пользователей (для них интерфейс и так новый) и старых. Не останавливайте тест в понедельник после громкого запуска в пятницу.
Сетевые эффекты
Классический A/B предполагает, что пользователь в варианте не влияет на пользователя в контроле. В ленте, мессенджере, маркетплейсе или при общем складе это часто не так: контент, цена или курьер «перетекают» между группами.
Тогда эффект размывается или вообще меняет знак, и обычный тест врёт в любую сторону. Нужен другой дизайн: кластеры (гео, социальные группы), двусторонняя рандомизация на маркетплейсе и честное признание, что «простое A/B» здесь слабый инструмент.
Откуда берётся MDE
MDE — не «какой эффект мы надеемся увидеть» и не «что получится за неделю трафика». Это самый маленький эффект, который вам важно не пропустить: внедрение окупится, пользователи заметят, риск оправдан.
Считайте размер выборки от бизнеса, а не подгоняйте MDE под уже выбранную дату окончания. Если на честный MDE не хватает трафика, это повод удлинить тест, сузить аудиторию, взять CUPED, укрупнить изменение — а не тихо поставить MDE «+20% к выручке» только чтобы формула выдала две недели.
A/A-тесты
A/A — это тот же пайплайн, но обеим группам показывают одно и то же. Так проверяют сплиттер, логирование, SRM, расчёт метрик и то, что «ложных побед» примерно столько, сколько обещает уровень значимости (около одного из двадцати при пороге 0,05).
Если A/A регулярно «находит» эффект, чинить нужно инфраструктуру, а не запускать на ней продуктовые тесты. Исторический A/A на старых логах тоже полезен: на нём отлаживают CUPED и поправки, не сжигая живой трафик.
Несколько метрик сразу
Чем больше метрик смотрите без поправки, тем выше шанс, что хоть одна «выйдет» случайно. До запуска назначьте одну целевую, список вторичных и отдельно guardrails — метрики, которые нельзя сильно ухудшить (надёжность, скорость, жалобы, отток).
Для целевых и вторичных калькулятор во вкладке «Мульти-метрики» умеет поправки Бонферрони, Холма и Бенджамини–Хохберга. Guardrails обычно не «премируют» за множественность: чтобы выкатить изменение, ни одна красная линия не должна быть пробита. Порог «на сколько можно просесть» тоже фиксируют заранее, а не подбирают по итогам.
Примеры CSV
Файлы, которые можно загрузить в калькулятор. Для каждого — зачем он нужен, какие столбцы обязательны, первые строки и ссылка, чтобы скачать полный пример.