Сервис онлайн-записи для салонов красоты в Алматы берёт с салона 12 000 ₸ в месяц после двух бесплатных недель. Чтобы салон начал принимать записи, администратор добавляет мастеров, услуги и расписание и включает онлайн-запись. Команда сделала пошаговую настройку и месяц показывала её половине новых салонов. В пятницу продакт-менеджер пишет в общий чат: «С пошаговой настройкой онлайн-запись включили 75% салонов, которые открыли расписание, а без неё 50%. Раскатываем на всех?» Цифры в уроке условные.
Знаменатель меняет вывод
| Салоны | А: пустой календарь | Б: пошаговая настройка |
|---|---|---|
| Назначены в вариант | 100 | 100 |
| Открыли расписание | 80 | 40 |
| Включили онлайн-запись | 40 | 30 |
| Доля среди открывших | 50% | 75% |
| Доля среди назначенных | 40% | 30% |
По плану считают от назначенных. На 100 салонах в группе оснований объявлять победителя нет.
Чем тест фичи отличается от теста посадочной
В A/B-тесте формы записи посетителей делят по cookie, человек заходит раз-другой, и заявку он оставляет в тот же визит. В продукте всё устроено иначе:
- человек входит в аккаунт и возвращается неделями, с телефона и с ноутбука;
- в одном аккаунте работают несколько человек: администратор и мастера салона видят один календарь;
- результат созревает за дни: онлайн-запись салон включает не в первый вход, а в течение недели;
- изменение встречают люди, которые привыкли к старому интерфейсу;
- ошибка стоит дороже: сломанный экран у платящего салона - это обращения в поддержку и отказ от подписки;
- новых аккаунтов мало: у сервиса около 200 новых салонов в месяц, а не тысячи посетителей в неделю.
Поэтому в тесте фичи появляются вещи, которых не было в тесте формы: единица деления, флаг и эффект новизны, а защитных метрик становится больше. Выборку и правило остановки считают так же, как там, и здесь они не повторяются.
Кого делить: салон, а не сессию
Первое решение в продуктовом тесте - что считать единицей, то есть кого сервис случайно отправляет в А или в Б. Для пошаговой настройки варианты такие:
| Единица | Что получится |
|---|---|
| Сессия | Администратор настраивает салон за три-четыре захода и видит то пошаговую настройку, то пустой календарь. Включённую запись не к чему привязать |
| Устройство | Днём администратор работает с ноутбука, вечером с телефона и попадает в обе группы |
| Пользователь | Администратору досталась пошаговая настройка, а мастеру из того же салона пустой календарь, и они заполняют одно расписание по разным инструкциям |
| Салон | Все сотрудники салона на всех устройствах видят один вариант |
Делят салоны, и считают тоже салоны: в выводе 100 салонов в группе, а не 1 400 нажатий их сотрудников. Крупный салон с десятью мастерами нажимает больше, чем десять маленьких, но остаётся одним наблюдением.
Сервисы для тестов решают это по-разному. Amplitude Experiment советует обычно делить по пользователю, а в части B2B-задач - по ID компании: тогда все сотрудники одной компании видят один вариант. Firebase A/B Testing распределяет по идентификатору установки (Firebase installation ID), так что человек с двумя устройствами может попасть в обе группы, а сотрудники одного салона и подавно. Для теста, где единица - салон, он не подходит.
Фича за флагом
Флаг (feature flag) - переключатель в коде. Пошаговую настройку выпускают обычным релизом для всех, но показывает её флаг, и только салонам группы Б. Остальные видят прежний пустой календарь. В GrowthBook флаги - самый распространённый способ провести эксперимент.
Флаг даёт три вещи. Первая - постоянная группа. Сервис вычисляет вариант из ID, который вы ему передали: GrowthBook хеширует его вместе с ключом эксперимента, и один и тот же ID всегда получает один вариант. Передайте ID салона, а не пользователя, и администратор с мастерами на любых устройствах окажутся в одной группе.
Вторая - выключатель. Если пошаговая настройка сломалась, флаг выключают, и все салоны видят старый экран без нового релиза.
Третья - осторожный старт. Тест можно сначала включить на 10% новых салонов, а когда станет ясно, что ничего не ломается, расширить на всех, оставив деление пополам. По той же справке GrowthBook, салоны, которые уже в тесте, останутся в своих группах. А вот соотношение вариантов посреди теста не меняют: если из 50/50 сделать 70/30, часть салонов перейдёт в другую группу и увидит оба варианта.
Ещё одно условие: в момент, когда салон получил вариант, в аналитику должно уйти событие с этим вариантом. Без него результат по группам не посчитать.
Постепенное включение - ещё не тест. Если на прошлой неделе настройку видели 10% салонов, а на этой все, сравнение недель смешает её с сезоном, рекламой и всем, что ещё поменялось за неделю. Тест - это две группы в одни и те же дни.
План до запуска
| Что | Решение команды |
|---|---|
| Что меняем | Пошаговая настройка вместо пустого календаря у новых салонов |
| Единица | Салон, флаг по ID салона |
| Кто в тесте | Все салоны, зарегистрированные за время теста, пополам |
| Основная метрика | Доля назначенных салонов, которые включили онлайн-запись за 7 дней после регистрации. Сейчас 40% |
| Защитные метрики | Обращения в чат поддержки на 100 салонов за первые 7 дней. Доля салонов, оплативших подписку после бесплатных двух недель |
| Когда считаем | Запись - когда у последнего салона прошло 7 дней, оплату - через две недели после его регистрации |
| Решение | Настройку оставляем, если запись включают чаще, а обращений и отказов от оплаты не больше |
Защитная метрика (guardrail) - та, которую стараются не испортить. Пошаговая настройка может поднять долю салонов с онлайн-записью и при этом завалить поддержку вопросами. Или салоны включат запись, а платить после пробного периода не станут. Двух-трёх защитных метрик хватает: GrowthBook предупреждает, что если добавить в тест все метрики подряд, случайные колебания дадут ложные срабатывания.
Знаменатель основной метрики записан в плане: все назначенные салоны. Через месяц именно он решит спор в чате.
Что показал первый месяц
| Салоны | А: пустой календарь | Б: пошаговая настройка |
|---|---|---|
| Назначены в вариант | 100 | 100 |
| Открыли расписание | 80 | 40 |
| Включили онлайн-запись | 40 | 30 |
| Доля среди открывших расписание | 50% | 75% |
| Доля среди назначенных | 40% | 30% |
75% из чата - доля среди открывших расписание. Но в Б до расписания дошли 40 салонов из 100: пошаговая настройка сначала просит добавить мастеров и услуги, и расписание открывается только после этого. Случайное деление делает сравнимыми целые группы по 100 салонов. Сорок салонов, которые добрались до расписания в Б, и восемьдесят в А отобрал уже сам вариант, и чем они отличаются друг от друга, по таблице не скажешь.
По плану считаем от назначенных: 30% в Б против 40% в А. На ста салонах в группе такая разница может оказаться случайной: калькулятор хи-квадрат из урока про A/B-тесты даст p около 0,14. Утверждать, что пошаговая настройка хуже, по этим данным нельзя. Но и победителем её не назовёшь: если разница настоящая, с новой настройкой сервис недосчитается 20 настроенных салонов из 200 в месяц. Раскатывать её на всех, как просит продакт-менеджер, оснований нет.
Сузить анализ до тех, кого изменение коснулось, можно только по условию, которое одинаково для обеих групп и записывается и в контрольной группе (triggered analysis у Microsoft), а «открыл расписание» не годится: путь до расписания в вариантах разный.
Когда салонов мало
Сколько салонов нужно, чтобы тест заметил разницу в 10 пунктов? Откройте на странице калькуляторов планировщик A/B-теста, тот же, что для формы записи: базовая конверсия 40%, минимально различимый эффект 25% (это с 40% до 50%), значимость 5%, мощность 80%. Калькулятор покажет 380 салонов на вариант, 760 на два. При 200 новых салонах в месяц это почти четыре месяца. А на ста салонах в группе тест заметит разве что скачок с 40% до 60%: поставьте эффект 50%, и калькулятор попросит 95 салонов на вариант.
Когда новых аккаунтов мало, вариантов несколько:
- Держите тест дольше. Если решение подождёт четыре месяца, флаг остаётся на 50/50, а салоны копятся.
- Не делите по сессиям ради большой выборки. На бумаге наблюдений станет в несколько раз больше, но сессии одного салона не независимы, и тест покажет уверенность, которой у вас нет.
- Если тест невозможен, выпускайте фичу флагом по частям: 10% салонов, потом половина, потом все, и следите за защитными метриками и ошибками. В отчёте так и пишите: «Выпустили без измерения эффекта, ошибок и роста обращений не было».
А чтобы понять, где салоны застревают, посмотрите воронку настройки и созвонитесь с пятью администраторами. Пять разговоров не заменят тест, но подскажут, что тестировать следующим.
Эффект новизны
Для пошаговой настройки он почти не мешает: новый салон видит настройку впервые в любом варианте, ему не с чем сравнивать. Новые пользователи эффекта новизны почти не испытывают: для него нужны ожидания от продукта, а их у нового салона ещё нет.
Другое дело - изменение для тех, кто привык. Следующей идеей команда хочет показать 1 200 действующим салонам кнопку «Свободные окна», которая рассылает клиентам свободное время на завтра. Допустим, в первую неделю кнопкой пользуются 45% салонов группы Б, а к третьей - 15%. Если по первой неделе решить, что кнопка нужна почти каждому второму салону, вывод завышен втрое.
Что с этим делать:
- держите тест не меньше трёх полных недель, даже если выборка набралась раньше: за неделю-две всплеск любопытства не отличить от эффекта, который останется;
- Statsig советует смотреть результат по дням с момента попадания в тест (days since exposure): итог за весь срок прячет, гаснет ли эффект;
- решение принимайте по тем неделям, где эффект перестал меняться.
Бывает и наоборот: привыкшие пользователи сначала встречают изменение в штыки, и в первые недели эффект занижен. Поэтому смотрят не на первую неделю, а на то, где кривая выровнялась.
Задание: план теста для своей фичи
Нужен продукт с личным кабинетом: сервис вашего клиента, приложение, с которым вы работаете, или кабинет ученика онлайн-школы. Возьмите одно изменение, которое команда хочет выпустить, и заполните план по образцу таблицы выше.
Выполнено 0 из 6
Если единицей вышел пользователь, а в аккаунте работают несколько человек, вернитесь к таблице единиц: коллеги увидят разные варианты и начнут путать друг друга. Если в знаменателе стоит «открыли новую функцию», вы повторили историю с 75%. Если планировщик насчитал больше года, тест не провести: выпускайте флагом по частям и так и пишите в отчёте, что эффект не измерен. А если защитных метрик набралось больше трёх, оставьте те, ухудшение которых остановит выпуск, остальные смотрите, но решение по ним не принимайте.
В итоге у вас план на полстраницы, который можно показать команде до запуска. Он и спасает от сообщения «75%, раскатываем?» в пятницу вечером.
Видео: основы A/B-тестирования
Вводный ролик Noukash о том, как устроен A/B-тест.