Роман Халкечев, руководитель отдела аналитики в Яндекс.Еде и Лавке

Переход в «Еду» и «Лавку»

При слиянии с «Убером» нам достался бренд и частично команда сервиса доставки еды — Uber Eats. Также Яндекс купил компанию FoodFox и объединил эти проекты. Так появилась Яндекс.Еда, которая с точки зрения организации стала частью «Такси». А спустя год внутри Яндекс.Еды зародилась Яндекс.Лавка.

Как-то генеральный директор «Такси» попросил меня помочь с «Едой» и «Лавкой»: там было много задач, связанных с аналитикой, а людей не хватало. В сентябре 2019 года меня с несколькими ребятами из «Такси» десантировали в фудтех, и я начал одновременно заниматься машинным обучением в «Такси» и аналитикой в «Еде» и «Лавке».

Заниматься двумя проектами сложно: задачи разные, я работал по 12 часов и меня всё равно не хватало. При этом в «Еде» и «Лавке» было больше личной ответственности за сервис, мы более плотно участвовали в запуске фич, это было очень интересно. Так что я решил окончательно перейти в фудтех, с мая 2020 года я здесь руководитель аналитики.

Продуктовые задачи

У Яндекс.Еды и «Лавки» много данных, которые помогают принимать продуктовые решения, зарабатывать больше денег и делать лучший сервис. Их можно разбить на несколько групп. Первая — продуктовые.

Есть отдельное приложение для Яндекс.Еды и отдельное для сервиса доставки еды Яндекс.Лавка. Есть сайт, есть приложения для курьеров и ресторанов. Чтобы развивать продукт и растить метрики, нужна аналитика.

Например, недавно мы запустили рекомендации товаров к тем, что уже есть в корзине пользователя, и нужно было понять, а это выгодно для бизнеса? Мы считаем и видим, что да — клиенты пользуются фичей, мы значимо вырастили средний чек.

Часто метрики нужно ещё декомпозировать на более мелкие, чтобы оценить эффект. Например, одна из ключевых метрик — LTV, совокупная ценность клиента. Но она мало меняется от небольших изменений. Поэтому мы раскладываем эту метрику на множество других, более чувствительных, а также делим клиентов на когорты: кто заказал один раз, кто сделал несколько заказов, кто привязал карту в приложении и так далее. И считаем ценность не всех клиентов сразу, а конкретной группы — так эффект от изменений получается более наглядными.

Маркетинговые задачи

Мы помогаем привлекать пользователей и оставаться в допустимом диапазоне затрат. Или реализовываем акции, которые придумали в маркетинге, — готовим данные, пишем алгоритмы.

Когда начался карантин, количество заказов в такси упало, а доставка еды выросла. Мы решили, что можно с помощью такси доставлять еду по всему городу. Посмотрели обезличенные данные по пользователям: кто из них часто ездил на такси в заведения, которые далеко от дома. И отправили им пуш-уведомление, что теперь они могут заказать оттуда доставку. Получили хорошую конверсию в заказы.

Задачи, связанные с операционкой

Например, есть сейлз-менеджеры, которые умеют подключать рестораны. Мы хотим получить больше заказов, а для этого нужно понять — какие рестораны нужно добавить? В новых городах или в старых? Если в старых, то в каких районах? Как понять, что в этом районе уже достаточно ресторанов и ещё один не принесёт дополнительных заказов? Мы можем оценить количество пользователей в районе, например, сравнить с данными «Такси» или Яндекса. Это поможет понять, какая доля из них что-то заказывает. Если низкая — вероятно, не хватает ресторанов.

Похожие задачи есть и у других подразделений, например, поддержки. Или тех, кто работает с уже запущенными ресторанами: помогает им делать меню, запускать промоакции. Для всех этих отделов нужна аналитика.

Задачи, связанные с эффективностью маркетплейса

У нас на площадке есть спрос — пользователи — и предложение: курьеры и рестораны. При этом нужно, чтобы и спрос, и предложение росли, но оставались в балансе. Если ресторанов будет мало, то и с заказами будет туго. Если мало курьеров — мы будем постоянно задерживать доставку и терять из-за этого деньги на промокодах. Обратное, кстати, тоже проблемно: если курьеров на линии окажется много, то каждому достанется меньше заказов, они меньше заработают и могут уйти.

Задачи «Лавки»

«Лавка» отличается от «Еды» тем, что это, по сути, наш магазин: мы управляем ассортиментом. Значит, нужно понять, что, когда и в каком количестве закупать. Закупим мало — сэкономим, но товары быстро закончатся, кому-то может не хватить. Закупим не то — останется на полках. Закупим слишком много — не поместится на склад или не успеем продать и товар испортится.

К тому же есть ограничения поставщиков: мы не можем купить пару-тройку шоколадок, только сразу сотню. А ещё нужно подстроиться под их возможности доставки.

Всем этим мы и занимаемся. Собираем и обрабатываем данные, чтобы наш бизнес развивался, а рестораны, клиенты и курьеры оставались довольны.

Что это даёт пользователям

Когда пользователь открывает приложение Яндекс.Еды, он видит список ресторанов. Конечно, можно их поставить просто по рейтингу или по времени доставки, но так может легко оказаться, что интересные места для конкретного клиента опустятся ниже, а нам хочется, чтобы он быстро нашёл, где сделать заказ. Так что с командой машинного обучения мы сделали ленту, которая учитывает интересы пользователей.

Ещё в ленте видно прогнозируемое время доставки, это тоже наша работа. Мы пытаемся предсказать, сколько времени уйдёт на приготовление и доставку заказа.

Рейтинг ресторанов тоже делает моя команда. Здесь не всё так просто: можно посчитать просто среднее по всем оценкам, но это удобно, если у заведения их уже много. Если ресторан только-только попал к нам, то каждая следующая оценка может сильно сбить рейтинг — какая тогда от него польза? Тут приходится искать другие пути. Рассказать подробнее не могу, чтобы рейтинг не накручивали.

Мультидоставка

Раньше в «Еде» один курьер мог одновременно доставлять только один заказ. Это неудобно: если пользователь сделал заказ, а за ним сразу ещё один в том же заведении в ту же квартиру, то для каждого заказа назначался отдельный курьер. Мы решили исправить это и запустили мультидоставку, чтобы один курьер мог доставить два заказа, если они, например, в одном доме и в одно время.

В такой задаче много нюансов. Нужно придумать алгоритм, который подскажет, какие заказы можно «склеить», а какие нет. Например, заказ может оказаться слишком тяжёлым и курьер его не унесёт. Или слишком объёмным и не поместится в сумку.

Затем надо сделать так, чтобы курьеры не перепутали сумки, значит, кладовщики должны их подписать. Получается, нужно подключить ещё одну команду, чтобы поддержать запуск.

А затем ещё нужно оценить, приносит ли такое нововведение преимущество для бизнеса. С одной стороны, вроде бы здорово: доставим больше заказов меньшими силами. С другой, что-то может и ухудшится, например, начнём чаще опаздывать. Или курьеры будут путать заказы, ухудшится пользовательский опыт, потеряем деньги на скидках и промокодах.

Так что идея хорошая, но нужна аналитика, чтобы понять, как её реализовать, а потом оценить, стоит ли игра свеч.

Как один сервис использует другой — и при чём тут аналитика

Вокруг ресторанов, которые подключены к «Еде», есть зона, до которой мы можем привезти заказ. Она не очень большая, чтобы блюда сохраняли нужную температуру, пока пеший курьер или курьер на велосипеде доставляет заказ. Но однажды мы подумали: а почему не доставлять заказы на такси? Тогда зона доставки может сильно расшириться, практически на весь город.

Тут как раз ударила самоизоляция, меньше людей заказывают такси, водители простаивают, а курьеров не хватает, было бы очень сподручно передавать часть заказов таксистам. Мы вместе с командой такси решили это реализовать.

Эти два сервиса — назначение водителя и доставка еды — никак не были связаны. Ребята из разработки начали реализовывать интеграцию, а мы делали аналитику: как понять, какого таксиста назначать, когда это сделать, чтобы он приехал в ресторан, когда заказ будет готов. В итоге система заработала и уже приносит значимое количество заказов.

Коэффициенты в доставке и такси

В наших сервисах есть повышающие коэффициенты на стоимость поездки или доставки — это тоже задача для аналитиков. Нам нужно держать баланс на маркетплейсе и коэффициенты — один из способов управлять спросом в периоды резкого роста.

Когда начинается дождь, пользователи чаще вызывают такси. А на самоизоляции начали чаще пользоваться доставкой. С одной стороны, для нас это хорошо. С другой — если спрос растёт быстро, мы не можем уравновесить его соответствующим объёмом предложения. Пользователь закажет еду, а доставить её будет некому.

Коэффициенты нужны, чтобы подрезать спрос. Так заказы сделают только те, кому это особенно важно, а мы сможем их все доставить. Наша задача в этом случае — определить условия, в которых нужно применять коэффициенты. Если они будут слишком часто, мы потеряем пользователей: они просто не будут заказывать там, где постоянно выходит дороже. Но и если коэффициентов не будет, то доставка не справится и мы разочаруем пользователя. Так что, как и во многих других задачах, цель аналитика — найти баланс.

Рабочий день аналитика

Обычно аналитик работает над 2–3 большими проектами и серией небольших задач. Большие проекты, как правило, длятся от месяца до полугода. Это подготовка к запуску новых функций или разработка нового алгоритма. Маленькая задача отнимает от получаса до нескольких дней. Например, научиться считать рейтинг ресторанов или посмотреть эффективность рекламной кампании.

Мы собираем и используем все данные, до которых можем дотянуться. Какие-то собираются в наших внутренних системах, например, информация о заказах. Какие-то мы получаем от других сервисов Яндекса, вроде обезличенных данных о клиентах в определённом районе. Что-то даже ищем в поиске. Храним данные в YT — это внутренняя система Яндекса. Обрабатываем их там же с помощью дополнительных библиотек.

Аналитика плотно связана с разработкой. Мы совместно готовим данные и придумываем алгоритмы, разработчики реализуют их в сервисе. Иногда бывает, что мы чего-то не учли и алгоритм не учитывает какие-то крайние случаи, тогда разработчик может попросить аналитика доработать его. И наоборот, аналитик тоже может поставить задачу разработчику. Например, логировать события, когда пользователь использовал ту или иную функцию приложения.

Подружить сервисы и ничего не сломать

«Такси» и доставка еды для пользователя — разные сервисы, но с точки зрения технологий между ними много общего. И там, и там есть задача диспетчеризации. Это когда есть заказы — на транспорт или доставку — и есть исполнители. Мы их объединяем: «Вот этот заказ ты исполняй».

Есть технология скоринга, которая выбирает, какому курьеру или водителю отдать заказ. Или технология учёта транспорта: таксист может быть с детским креслом или жёлтыми номерами, а курьер — пеший, на велосипеде или авто. Им нужно отдавать разные заказы. Общего много, но везде свои небольшие нюансы. Так что логично использовать для «Такси», «Еды» и «Лавки» общую платформу, а не три отдельных. Просто эту единую платформу нужно настроить и допилить.

В процессе интеграции участвуют несколько сторон: разработчики, продуктовые команды и те, кто занимается операционкой, обучением и наймом. Проект сложный — нужно учесть хотелки всех сервисов, спроектировать, разработать и переехать на новую платформу. Может возникнуть много нюансов технологических, финансовых и юридических, грубо говоря, как потом исполнителям зарплату платить.

Я руковожу несколькими командами, понимаю, чем занимается каждая, много общаюсь со смежниками, благодаря этому я вижу задачи с разных сторон. Я понимаю, что́ мы потенциально можем забыть при переезде, и стараюсь этого не допустить.

Код пишу мало, день состоит из встреч

Мой день состоит преимущественно из встреч, код уже почти не пишу. Иногда бывает, что-то делаю руками, например, могу скрипт на Питоне написать, чтобы извлечь данные или построить график. Но это скорее исключение.

Часть моей команды занимается «Лавкой», часть «Едой». Внутри эти команды делятся на направления: продукт, бизнес и так далее. Так что у меня много встреч один на один с тимлидами. Ещё — с моим руководителем, с основными заказчиками, встречи по проектам. Мы быстро растём, и приходится принимать много решений на лету.

Мои задачи глобально делятся на два направления: руководительские и проектные.

Руководительские — это, например, целеполагание. Договариваемся, каких целей хотим достичь, за счёт каких ресурсов, с помощью каких шагов. Или наём: определить, каких людей нанимать, подготовить тестовые задания, провести собеседования. Нужно выстраивать процессы: много заказчиков, много задач, ресурсов, как всегда, не хватает. Нужно приоритизировать, договариваться со всеми.

Есть проектные задачи. Я хожу по встречам и помогаю разобраться, что можно сделать, как можно решить определённую задачу. Иногда это сложные проекты, где нужно включиться, разобраться и помочь, там мой опыт и взгляд может быть полезен. А есть проекты, где всё идёт хорошо, но мне самому интересно в них погрузиться и я это делаю. Так было, например, с мультидоставкой.

Планы на будущее

Мои дальнейшие планы связаны с перспективами фудтех-сервисов. Они привлекательные: мы хотим создать сильный продукт, многократно вырастить его, выйти в новые ниши и побороться за долю в них. Слежу за конкурентами на западных и азиатских рынках, какие возможности они внедряют, какие технологии используют.

Иногда я чувствую, что мне не хватает знаний из смежных областей. Например, осенью прошёл в ШАДе курс по архитектуре компьютеров и операционным системам. А сейчас вообще про финансы читаю много, чтобы лучше понимать, как работает бизнес.