Как сделать А/B-тест в офлайне, на примере ускорения доставки в Самокате
Привет! Меня зовут Илья, я продуктовый аналитик в Samokat.tech.
Делать A/B-тесты — довольно привычная вещь для аналитиков. Но как быть, если нужно провести эксперимент в физическом мире? Какие особенности и ограничения есть в офлайне? Как выбирать и оценивать метрики?
Давайте расскажу на примере — как мы пробовали доставлять заказы Самоката ещё быстрее.
Постараюсь рассказать про весь путь: от поиска идеи, предварительной оценки и выбора главной метрики до подведения итогов и выводов. Расскажу об ошибках и чему этот опыт нас научил. Поехали!
Продуктовая аналитика в офлайне: особенности и ограничения
Продуктовые аналитики Samokat.tech работают в одном из трёх направлений — операционном, клиентском или коммерческом. Я работаю в операционном департаменте, в команде, которая управляет нагрузкой в сборке и доставке. Наша цель — эффективно планировать интервалы доступности, чтобы заказы доставлялись быстро.
Вот примеры задач, которые мы решаем:
как правильно рассчитать, сколько курьеров-партнёров необходимо для доставки заказов в этом месяце;
что повлияло на резкий рост нагрузки на одного курьера-партнёра на прошлой неделе;
какие факторы (погодные, дорожной ситуации и прочие) нужно начать учитывать для планирования нагрузки на курьеров-партнёров на определённых дарксторах.
Делаем исследования, строим разнообразные дашборды, проводим эксперименты по улучшению бизнес-процессов. Всё это — с поправкой на ограничения физического мира.
Для продуктовой аналитики в офлайне есть особенности:
Выборка для проведения экспериментов сильно ограничена — счёт будет идти на тысячи, а не миллионы как в онлайне.
Есть большая зависимость от человеческого фактора — вы можете придумать гениальный алгоритм, который заметно улучшит жизнь использующим его людям, но чтобы они начали им пользоваться — отдельная большая сложная задача. Нужно «продать» идею и проследить за её реализацией.
Как учитывать эти ограничения для проведения A/B-тестов — давайте расскажу на примере реальной истории.
Кейс: как сделать экспресс-доставку ещё быстрее
В приложении Самоката есть плашка со сроками доставки заказа — от 15 или от 30 минут. Это время зависит от того, насколько далеко вы находитесь от ближайшего даркстора.
У каждого даркстора есть две зоны: в первой мы доставляем заказы от 15 минут, а во второй — от 30 минут.
Радиус доставки определяется примерно так: все адреса пользователей, которые находятся не дальше 1200 метров от ближайшего даркстора попадают в зону экспресс-доставки — от 15 минут, а которые находятся дальше — от 30 минут.
Однако форма зон доставки в реальности вовсе не круглая и зависит от конкретного географического полигона (заранее определенной территории, которая обозначает зону доставки).
Так выглядят зоны доставки.
Так выглядят зоны доставки.
Чем выше в городе или районе спрос на доставку, тем больше и плотнее располагаются дарксторы. Описываемый ниже кейс начался с вопроса »А что если эти стандартные границы взять и подвинуть? ».
Идея возникла, когда мы переезжали с одного навигатора на другой. С их помощью мы определяем расстояние от даркстора до адреса доставки, но для одного и того же адреса разные навигаторы могут показывать разное расстояние.
Это нормальная ситуация, все они работают по своей логике. Но нам нужно было понять, понесём ли мы издержки в связи со сменой инструмента. Из-за разниц в расчетах часть адресов из 30-минутной зоны доставки должна была перейти в 15-минутную и наоборот. Как на эти изменения отреагируют пользователи, будут ли курьеры-партнёры успевать на те же адреса с ускоренным SLA — это были главные вопросы, на которые мы искали ответы.
В процессе анализа потенциальных эффектов от таких изменений, мы подумали –, а что, если самим увеличить зону доставки от 15 минут для части дарксторов в качестве эксперимента?
Как насчёт SLA в этом случае? Где тот идеальный радиус, когда мы не увеличим опоздания и повысим скорость доставки?
Неужели за столько лет никто не пробовал менять зоны доставки, не пытался подобрать оптимальный радиус для каждого отдельного даркстора? Покопавшись в чертогах Confluence, мы выяснили, что ранее предпринимались попытки найти ответ на вопрос о возможности ускорения доставки. Окончательного ответа к этому моменту найти не удалось — не было тестовой группы, сравнивалось «до / после»; использовались метрики, наблюдение за которыми не дало искомого результата.
В этот раз мы решили сделать все как в классическом эксперименте: подобрать похожие группы А и Б, сформулировать ключевую гипотезу, параллельно отслеживать другие важные метрики, чтобы их не уронить, рассчитать ожидаемые изменения, экономический эффект от них, а также необходимое время для проведения теста.
A/B-тест в офлайне: в поисках главной метрики
В поисках главной метрики для эксперимента первым делом мы сократили список возможных вариантов до трех:
Лично я настаивал на метрике по конверсии — интуитивно казалось, если клиент сомневается заказывать или нет, и видит, что заказ доставят от 15 минут (быстро), а не за 30 как у него было раньше, то он закажет с большей вероятностью.
Интуиция — хорошо, но этого недостаточно. Из трех метрик хотелось выбрать одну и с обоснованием — количество дарксторов для проведения эксперимента ограничено, и проверять все подряд будет нецелесообразно. К тому же чем больше гипотез за раз мы захотим проверить, тем больше вероятность поймать ошибку I-го рода — найти отличия там, где их на самом деле нет. Можно использовать поправки, но опять же из-за малого числа дарксторов мы жертвуем мощностью — вероятностью найти улучшения в случае, если они будут.
К счастью, у нас уже есть две группы с доставкой от 15 и 30 минут, где мы на исторических данных можем оценить ожидаемый эффект от изменений, что поможет решить, какую из трех метрик стоит взять за главную.
Ниже для наглядности нам понадобятся численные показатели — это будут выдуманные числа (NDA), но надеюсь, общую логику и ход наших рассуждений они помогут продемонстрировать.
Возьмем конверсию. Мы знаем, что у группы пользователей, которым мы доставляем заказы от 30 минут она равняется 12.3%, а кому за 15 минут — 15.7%.
На картинке — рандомные значения, для примера.
Предположим, что у тестовых пользователей, которым вместо 30 начнут доставлять заказы за 15 минут конверсия увеличится до середины, то есть на 15.7%-12.3% = 1.7%. Тогда несложно посчитать экономический эффект от такого роста — зная количество пользователей, на которых мы раскатим изменения в случае успешного эксперимента:
Проделав такое упражнение для каждой из трех метрик, мы можем в первом приближении понять, у какой из гипотез в случае успешного исхода эксперимента мы увидим значимое увеличение выручки (GMV).
Величина среднего чека — вымышленная; нужна, чтобы показать логику рассуждений.
В итоге получилось, что потенциально ощутимый эффект мы можем получить, лишь увеличив среднюю частоту заказов в месяц.
Ход эксперимента
Итак, мы запустили классический оффлайн A/B-тест. Взяли две группы по 50 даксторов с похожей частотой заказов. В тестовой группе расширили зону доставки на 100 метров, в контрольной — нет. Эксперимент запустили на месяц, чтобы пользователи успели заметить изменение скорости доставки с 30 до 15 минут и (возможно) начать заказывать в Самокате чаще. Также этот срок нужен, чтобы мы собрали необходимые данные для расчета значимого отличия метрик, если они будут.
Помимо частоты заказов на дашборде мы мониторили и другие важные метрики, которые важно не ухудшить: процент опозданий и нагрузку на курьеров-партнеров (сколько заказов в час им приходится доставлять);, а также информационную метрику для проверки, действительно ли изменения зон включились (доля заказов с SLA 15).
Так выглядит одна из вкладок отчета.
Что-то пошло не так
У нас сильно выросли опоздания. Опытные курьеры-партнеры привыкают к маршрутам и адресам, по которым возят заказы за 30 минут, а тут вдруг монитор показывает, что надо успевать за 15. Мы ожидали, что опоздания могут подрасти, но не так сильно.
Пунктирной линией показан день запуска расширения зоны — у тестовой группы сразу возрастают опоздания.
Так как эксперимент проводился на очень малом количестве пользователей, мы не стали экстренно отменять эксперимент. Издержки от этого были сильно меньше возможного эффекта, который мы хотели поймать.
Итоги теста
По остальным метрикам получилось следующее:
Опоздания > 1 минуты → +30%
Опоздания > 10 минут → +15%
Нагрузка, простой → без изменений
Общее увеличение доли заказов SLA 15 → +10%
К сожалению, частоту заказов увеличить не удалось. Мы проверили гипотезу, которая выглядело перспективно, она не подтвердилась — это тоже считаем положительным результатом.
Что ещё улучшить? Как сделать проще?
Помимо ограниченной выборки в офлайн-экспериментах есть другое важное отличие от онлайна — зачастую мы пробуем изменять процессы, которые происходят в реальной жизни каждый день. Как курьеры-партнеры выходят на доставку, везут заказы, по каким маршрутам они перемещаются и так далее.
В этой статье мы постарались показать, что иногда идеи эксперимента могут рождаться просто из гипотезы »а что будет, если вот эту привычную штуку мы попробуем немного поменять? ».
Вторая более практичная идея: если вы выбираете между множеством метрик для теста и не уверены, на что вы влияете, то иногда можно использовать довольно простой способ — отбросить метрики по ожидаемому эффекту, который вы можете от них получить в приблизительной оценке в деньгах или других важных для вас параметрах.
Есть более продвинутые и действенные способы: использовать поправки на множественные проверки гипотез и применять PSM, чтобы и тестовая, и контрольная группы были максимально похожи друг на друга по выбранным вами метрикам. Но иногда могут подойти и более простые способы.
