Кейс с собеседования: батчинг заказов
Этот кейс встретился на тех. интервью в в суперапп из Катара, занимающийся доставкой еды, продуктов, товаров и тд.
Условие простое: Операционная команда хочет начать батчить заказы агрессивнее - назначать курьеру до трёх ближайших заказов за один выезд, чтобы снизить стоимость доставки.
Нужно дать определить ключевые метрики, сформулировать гипотезы и предложить способ оценки эффекта.
Одним словом: задизайнить а/б тест.
Давайте решать кейс по порядку.
1. Метрики
Чтобы разобраться с метриками давайте подумаем о механизме работы фичи.
Формально у нас работает трехсторонний маркетплейс: клиент - поставщик - компания.
Однако данная фича оказывает мало влияния на поставщиков, т.к. доставка осуществляется за счет сервиса, поэтому исключим их из уравнения и рассмотрим только клиентов и компанию.
Итак, про компанию.
У любого заказа есть постоянная часть расходов: подача курьера, поездка до клиента и ожидание на точке.
Допустим, у нас есть 3 заказа. Мы можем повезти их как в одной поездке, так и в нескольких.
В случае группировки всех заказов в одну поездку - расходы на курьера будут ниже, т.к. постоянная часть расходов (ставка за выезд, например) будет распределяться по 3м заказам вместо одного.
Это важно учитывать, поэтому смотрим на метрику Delivery Cost per Order, а рядом держим batch rate (количество заказов в динамике в одной поездке).
Теперь, про клиента.
Маршрут на три точки длиннее одного.
Заказ едет дольше, еда приезжает остывшей, растёт доля просрочек, клиент отменяет чаще и в следующий раз заказывает не у вас.
Смотрим на распределение времени доставки (Click-To-Eat).
Как минимум нам будут интересны среднее/ медиана и 95й перцентиль, чтобы оценить, разброс критических значений распределения.
Можно добавить еще метрик, но мы пока ограничимся.
2. Что по поводу гипотез?
Сформулируем нулевую (H0) и альтернативную (H1) гипотезы.
H0: батчинг не снижает стоимость доставки
H1: батчинг снижает стоимость на MDE%
MDE в данном случае берем по истории похожих экспов (100% они уже были) или пытаемся высчитать из юнит-экономики. Я бы целился в 2%.
Это мы и будем тестить.
3. Теперь guardrail
За барьерную метрику я бы предложил взять Средний рейтинг клиента на заказ (Average Order Rating), долю отмен (Cancelation Rate), и долю опозданий (DelayRate).
Если одна из метрик выскакивает за 2 стандартных отклонения -> стопаем эксперимент.
4. Как оценить эффект?
Третий вопрос самый интересный.
Ранее я писал про сетевой эффект и это тот самый кейс.
Курьеры у теста и контроля общие. Батчинг меняет логику диспетчеризации, и курьер, увёзший три заказа, недоступен контролю до конца маршрута.
Поэтому в нашем кейсе недостаточно делать поклиентский тест. Необходимо оценивать эффект через switchback, где единица рандомизации - пара "зона × тайм-слот".
Тайм-слот это отрезок, внутри которого в зоне работает один режим. Например час: с 12 до 13 в центре батчинг включён, с 13 до 14 выключен, порядок случайный.
Тайм-слот должен покрывать время доставки туда-обратно, чтобы весь эффект собирался в рамках одного тайм-слота, а не нескольких. Поэтому будем брать 3 часа за один тайм-слот.
Единица анализа - тоже слот, а не заказ.
Метрику агрегируют до слота и сравнивают слоты между собой. Размер выборки в данном случае - количество переключений между слотами.
По итогу у нас получился полноценный дизайн а/б теста с метриками, гипотезами и подходом к оценке, что собственно и требовалось в этом кейсе.
Ставьте 🙏, если хотите узнать и про другие этапы собеса в эту компанию.
Ставьте🔥, если хотите больше разборов кейсов.
Ну и заходите на сайт data-slice.ru, если хотите освежить знания в статистике или метриках.
Этот кейс встретился на тех. интервью в в суперапп из Катара, занимающийся доставкой еды, продуктов, товаров и тд.
Условие простое: Операционная команда хочет начать батчить заказы агрессивнее - назначать курьеру до трёх ближайших заказов за один выезд, чтобы снизить стоимость доставки.
Нужно дать определить ключевые метрики, сформулировать гипотезы и предложить способ оценки эффекта.
Одним словом: задизайнить а/б тест.
Давайте решать кейс по порядку.
1. Метрики
Чтобы разобраться с метриками давайте подумаем о механизме работы фичи.
Формально у нас работает трехсторонний маркетплейс: клиент - поставщик - компания.
Однако данная фича оказывает мало влияния на поставщиков, т.к. доставка осуществляется за счет сервиса, поэтому исключим их из уравнения и рассмотрим только клиентов и компанию.
Итак, про компанию.
У любого заказа есть постоянная часть расходов: подача курьера, поездка до клиента и ожидание на точке.
Допустим, у нас есть 3 заказа. Мы можем повезти их как в одной поездке, так и в нескольких.
В случае группировки всех заказов в одну поездку - расходы на курьера будут ниже, т.к. постоянная часть расходов (ставка за выезд, например) будет распределяться по 3м заказам вместо одного.
Это важно учитывать, поэтому смотрим на метрику Delivery Cost per Order, а рядом держим batch rate (количество заказов в динамике в одной поездке).
Теперь, про клиента.
Маршрут на три точки длиннее одного.
Заказ едет дольше, еда приезжает остывшей, растёт доля просрочек, клиент отменяет чаще и в следующий раз заказывает не у вас.
Смотрим на распределение времени доставки (Click-To-Eat).
Как минимум нам будут интересны среднее/ медиана и 95й перцентиль, чтобы оценить, разброс критических значений распределения.
Можно добавить еще метрик, но мы пока ограничимся.
2. Что по поводу гипотез?
Сформулируем нулевую (H0) и альтернативную (H1) гипотезы.
H0: батчинг не снижает стоимость доставки
H1: батчинг снижает стоимость на MDE%
MDE в данном случае берем по истории похожих экспов (100% они уже были) или пытаемся высчитать из юнит-экономики. Я бы целился в 2%.
Это мы и будем тестить.
3. Теперь guardrail
За барьерную метрику я бы предложил взять Средний рейтинг клиента на заказ (Average Order Rating), долю отмен (Cancelation Rate), и долю опозданий (DelayRate).
Если одна из метрик выскакивает за 2 стандартных отклонения -> стопаем эксперимент.
4. Как оценить эффект?
Третий вопрос самый интересный.
Ранее я писал про сетевой эффект и это тот самый кейс.
Курьеры у теста и контроля общие. Батчинг меняет логику диспетчеризации, и курьер, увёзший три заказа, недоступен контролю до конца маршрута.
Поэтому в нашем кейсе недостаточно делать поклиентский тест. Необходимо оценивать эффект через switchback, где единица рандомизации - пара "зона × тайм-слот".
Тайм-слот это отрезок, внутри которого в зоне работает один режим. Например час: с 12 до 13 в центре батчинг включён, с 13 до 14 выключен, порядок случайный.
Тайм-слот должен покрывать время доставки туда-обратно, чтобы весь эффект собирался в рамках одного тайм-слота, а не нескольких. Поэтому будем брать 3 часа за один тайм-слот.
Единица анализа - тоже слот, а не заказ.
Метрику агрегируют до слота и сравнивают слоты между собой. Размер выборки в данном случае - количество переключений между слотами.
По итогу у нас получился полноценный дизайн а/б теста с метриками, гипотезами и подходом к оценке, что собственно и требовалось в этом кейсе.
Ставьте 🙏, если хотите узнать и про другие этапы собеса в эту компанию.
Ставьте🔥, если хотите больше разборов кейсов.
Ну и заходите на сайт data-slice.ru, если хотите освежить знания в статистике или метриках.