![](https://habrastorage.org/getpro/habr/upload_files/2d0/6aa/e05/2d06aae05bb6dd6a206de931c2b93194.png)
Привет! Меня зовут Илья, я продуктовый аналитик в Samokat.tech.
Делать A/B-тесты – довольно привычная вещь для аналитиков. Но как быть, если нужно провести эксперимент в физическом мире? Какие особенности и ограничения есть в офлайне? Как выбирать и оценивать метрики?
Давайте расскажу на примере – как мы пробовали доставлять заказы Самоката ещё быстрее.
Постараюсь рассказать про весь путь: от поиска идеи, предварительной оценки и выбора главной метрики до подведения итогов и выводов. Расскажу об ошибках и чему этот опыт нас научил. Поехали!
Продуктовая аналитика в офлайне: особенности и ограничения
Продуктовые аналитики Samokat.tech работают в одном из трёх направлений — операционном, клиентском или коммерческом. Я работаю в операционном департаменте, в команде, которая управляет нагрузкой в сборке и доставке. Наша цель – эффективно планировать интервалы доступности, чтобы заказы доставлялись быстро.
Вот примеры задач, которые мы решаем:
как правильно рассчитать, сколько курьеров-партнёров необходимо для доставки заказов в этом месяце;
что повлияло на резкий рост нагрузки на одного курьера-партнёра на прошлой неделе;
какие факторы (погодные, дорожной ситуации и прочие) нужно начать учитывать для планирования нагрузки на курьеров-партнёров на определённых дарксторах.
Делаем исследования, строим разнообразные дашборды, проводим эксперименты по улучшению бизнес-процессов. Всё это – с поправкой на ограничения физического мира.
Для продуктовой аналитики в офлайне есть особенности:
Выборка для проведения экспериментов сильно ограничена – счёт будет идти на тысячи, а не миллионы как в онлайне.
Есть большая зависимость от человеческого фактора – вы можете придумать гениальный алгоритм, который заметно улучшит жизнь использующим его людям, но чтобы они начали им пользоваться – отдельная большая сложная задача. Нужно «продать» идею и проследить за её реализацией.
Как учитывать эти ограничения для проведения A/B-тестов – давайте расскажу на примере реальной истории.
Кейс: как сделать экспресс-доставку ещё быстрее
В приложении Самоката есть плашка со сроками доставки заказа – от 15 или от 30 минут. Это время зависит от того, насколько далеко вы находитесь от ближайшего даркстора.
![](https://habrastorage.org/getpro/habr/upload_files/048/ec9/66b/048ec966b5fbfd39472f1b955bec953b.png)
У каждого даркстора есть две зоны: в первой мы доставляем заказы от 15 минут, а во второй – от 30 минут.
![](https://habrastorage.org/getpro/habr/upload_files/922/448/86b/92244886b2e42908953c44e1571a6548.png)
Радиус доставки определяется примерно так: все адреса пользователей, которые находятся не дальше 1200 метров от ближайшего даркстора попадают в зону экспресс-доставки – от 15 минут, а которые находятся дальше – от 30 минут.
Однако форма зон доставки в реальности вовсе не круглая и зависит от конкретного географического полигона (заранее определенной территории, которая обозначает зону доставки).
![Так выглядят зоны доставки. Так выглядят зоны доставки.](https://habrastorage.org/getpro/habr/upload_files/d55/384/d25/d55384d257a98597a771224b021d1bfb.png)
![Так выглядят зоны доставки. Так выглядят зоны доставки.](https://habrastorage.org/getpro/habr/upload_files/4aa/001/dea/4aa001deaf62439b5f775ab6ba8a1234.png)
Чем выше в городе или районе спрос на доставку, тем больше и плотнее располагаются дарксторы. Описываемый ниже кейс начался с вопроса «А что если эти стандартные границы взять и подвинуть?».
Идея возникла, когда мы переезжали с одного навигатора на другой. С их помощью мы определяем расстояние от даркстора до адреса доставки, но для одного и того же адреса разные навигаторы могут показывать разное расстояние.
Это нормальная ситуация, все они работают по своей логике. Но нам нужно было понять, понесём ли мы издержки в связи со сменой инструмента. Из-за разниц в расчетах часть адресов из 30-минутной зоны доставки должна была перейти в 15-минутную и наоборот. Как на эти изменения отреагируют пользователи, будут ли курьеры-партнёры успевать на те же адреса с ускоренным SLA – это были главные вопросы, на которые мы искали ответы.
В процессе анализа потенциальных эффектов от таких изменений, мы подумали – а что, если самим увеличить зону доставки от 15 минут для части дарксторов в качестве эксперимента?
Как насчёт SLA в этом случае? Где тот идеальный радиус, когда мы не увеличим опоздания и повысим скорость доставки?
![](https://habrastorage.org/getpro/habr/upload_files/3fc/c22/e3a/3fcc22e3abbe069986e87f8688f415a8.png)
Неужели за столько лет никто не пробовал менять зоны доставки, не пытался подобрать оптимальный радиус для каждого отдельного даркстора? Покопавшись в чертогах Confluence, мы выяснили, что ранее предпринимались попытки найти ответ на вопрос о возможности ускорения доставки. Окончательного ответа к этому моменту найти не удалось – не было тестовой группы, сравнивалось “до / после”; использовались метрики, наблюдение за которыми не дало искомого результата.
В этот раз мы решили сделать все как в классическом эксперименте: подобрать похожие группы А и Б, сформулировать ключевую гипотезу, параллельно отслеживать другие важные метрики, чтобы их не уронить, рассчитать ожидаемые изменения, экономический эффект от них, а также необходимое время для проведения теста.
A/B-тест в офлайне: в поисках главной метрики
![](https://habrastorage.org/getpro/habr/upload_files/903/660/2e8/9036602e801ab8668de4eb00fa21d67c.png)
В поисках главной метрики для эксперимента первым делом мы сократили список возможных вариантов до трех:
увеличение конверсии в заказ;
частота заказов;
средний чек.
Лично я настаивал на метрике по конверсии — интуитивно казалось, если клиент сомневается заказывать или нет, и видит, что заказ доставят от 15 минут (быстро), а не за 30 как у него было раньше, то он закажет с большей вероятностью.
Интуиция – хорошо, но этого недостаточно. Из трех метрик хотелось выбрать одну и с обоснованием – количество дарксторов для проведения эксперимента ограничено, и проверять все подряд будет нецелесообразно. К тому же чем больше гипотез за раз мы захотим проверить, тем больше вероятность поймать ошибку I-го рода – найти отличия там, где их на самом деле нет. Можно использовать поправки, но опять же из-за малого числа дарксторов мы жертвуем мощностью – вероятностью найти улучшения в случае, если они будут.
К счастью, у нас уже есть две группы с доставкой от 15 и 30 минут, где мы на исторических данных можем оценить ожидаемый эффект от изменений, что поможет решить, какую из трех метрик стоит взять за главную.
Ниже для наглядности нам понадобятся численные показатели – это будут выдуманные числа (NDA), но надеюсь, общую логику и ход наших рассуждений они помогут продемонстрировать.
Возьмем конверсию. Мы знаем, что у группы пользователей, которым мы доставляем заказы от 30 минут она равняется 12.3%, а кому за 15 минут – 15.7%.
![На картинке – рандомные значения, для примера. На картинке – рандомные значения, для примера.](https://habrastorage.org/getpro/habr/upload_files/af0/d2d/098/af0d2d098f7f37ada5243e23e1f75829.png)
Предположим, что у тестовых пользователей, которым вместо 30 начнут доставлять заказы за 15 минут конверсия увеличится до середины, то есть на 15.7%-12.3% = 1.7%. Тогда несложно посчитать экономический эффект от такого роста – зная количество пользователей, на которых мы раскатим изменения в случае успешного эксперимента:
![](https://habrastorage.org/getpro/habr/upload_files/104/646/362/1046463623942bca378f4cea2fd56397.png)
Проделав такое упражнение для каждой из трех метрик, мы можем в первом приближении понять, у какой из гипотез в случае успешного исхода эксперимента мы увидим значимое увеличение выручки (GMV).
![Величина среднего чека – вымышленная; нужна, чтобы показать логику рассуждений. Величина среднего чека – вымышленная; нужна, чтобы показать логику рассуждений.](https://habrastorage.org/getpro/habr/upload_files/84b/eec/7ea/84beec7ea69b56aa1e77053efba2f4dc.png)
В итоге получилось, что потенциально ощутимый эффект мы можем получить, лишь увеличив среднюю частоту заказов в месяц.
Ход эксперимента
Итак, мы запустили классический оффлайн A/B-тест. Взяли две группы по 50 даксторов с похожей частотой заказов. В тестовой группе расширили зону доставки на 100 метров, в контрольной — нет. Эксперимент запустили на месяц, чтобы пользователи успели заметить изменение скорости доставки с 30 до 15 минут и (возможно) начать заказывать в Самокате чаще. Также этот срок нужен, чтобы мы собрали необходимые данные для расчета значимого отличия метрик, если они будут.
Помимо частоты заказов на дашборде мы мониторили и другие важные метрики, которые важно не ухудшить: процент опозданий и нагрузку на курьеров-партнеров (сколько заказов в час им приходится доставлять); а также информационную метрику для проверки, действительно ли изменения зон включились (доля заказов с SLA 15).
![Так выглядит одна из вкладок отчета. Так выглядит одна из вкладок отчета.](https://habrastorage.org/getpro/habr/upload_files/586/5a1/624/5865a1624043714b0affb4b4ca1053a6.png)
Что-то пошло не так
У нас сильно выросли опоздания. Опытные курьеры-партнеры привыкают к маршрутам и адресам, по которым возят заказы за 30 минут, а тут вдруг монитор показывает, что надо успевать за 15. Мы ожидали, что опоздания могут подрасти, но не так сильно.
![Пунктирной линией показан день запуска расширения зоны — у тестовой группы сразу возрастают опоздания. Пунктирной линией показан день запуска расширения зоны — у тестовой группы сразу возрастают опоздания.](https://habrastorage.org/getpro/habr/upload_files/fe5/2ea/4d8/fe52ea4d86b7d8ab8b67f14c5692ca9f.png)
Так как эксперимент проводился на очень малом количестве пользователей, мы не стали экстренно отменять эксперимент. Издержки от этого были сильно меньше возможного эффекта, который мы хотели поймать.
Итоги теста
![](https://habrastorage.org/getpro/habr/upload_files/60a/28a/6a4/60a28a6a40f3619e453fe8fcbfcbb048.png)
По остальным метрикам получилось следующее:
Опоздания > 1 минуты → +30%
Опоздания > 10 минут → +15%
Нагрузка, простой → без изменений
Общее увеличение доли заказов SLA 15 → +10%
К сожалению, частоту заказов увеличить не удалось. Мы проверили гипотезу, которая выглядело перспективно, она не подтвердилась – это тоже считаем положительным результатом.
Что ещё улучшить? Как сделать проще?
Помимо ограниченной выборки в офлайн-экспериментах есть другое важное отличие от онлайна – зачастую мы пробуем изменять процессы, которые происходят в реальной жизни каждый день. Как курьеры-партнеры выходят на доставку, везут заказы, по каким маршрутам они перемещаются и так далее.
В этой статье мы постарались показать, что иногда идеи эксперимента могут рождаться просто из гипотезы «а что будет, если вот эту привычную штуку мы попробуем немного поменять?».
Вторая более практичная идея: если вы выбираете между множеством метрик для теста и не уверены, на что вы влияете, то иногда можно использовать довольно простой способ – отбросить метрики по ожидаемому эффекту, который вы можете от них получить в приблизительной оценке в деньгах или других важных для вас параметрах.
Есть более продвинутые и действенные способы: использовать поправки на множественные проверки гипотез и применять PSM, чтобы и тестовая, и контрольная группы были максимально похожи друг на друга по выбранным вами метрикам. Но иногда могут подойти и более простые способы.