Представьте: вы открываете приложение, чтобы в очередной раз заказать такси в часто посещаемое вами место, и, конечно, в 2017 году вы ожидаете, что все, что нужно сделать – сказать приложению «Вызывай», и такси за вами тут же выедет. А куда вы хотели ехать, через сколько минут и на какой машине — все это приложение узнает благодаря истории заказов и машинному обучению. В общем-то все, как в шутках про идеальный интерфейс с единственной кнопкой «сделать хорошо», лучше которого только экран с надписью «все уже хорошо». Звучит здорово, но как же приблизить эту реальность?



На днях мы выпустили новое приложение Яндекс.Такси для iOS. В обновленном интерфейсе один из акцентов сделан на выборе конечной точки маршрута («точки Б»). Но новая версия – это не просто новый UI. К запуску обновления мы существенно переработали технологию прогнозирования пункта назначения, заменив старые эвристики на обученный на исторических данных классификатор.

Как вы понимаете, кнопки «сделать хорошо» в машинном обучении тоже нет, поэтому простая на первый взгляд задача вылилась в довольно захватывающий кейс, в результате которого, мы надеемся, у нас получилось немного облегчить жизнь пользователей. Сейчас мы продолжаем внимательно следить за работой нового алгоритма и еще будем его менять, чтобы качество прогноза было стабильнее. На полную мощность запустимся в ближайшие несколько недель, но под катом уже готовы рассказать о том, что же происходит внутри.

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

До недавнего времени стоимость поездки в такси тоже была плавающей. Даже онлайн-сервисы рассчитывали сумму лишь примерно — окончательная стоимость формировалась только в конце пути. Тариф, как правило, включает три компонента: стоимость посадки (иногда с включенными километрами и/или минутами), стоимость километра и стоимость минуты. Конечно, можно было рассчитать примерную цену за поездку и раньше, но в конце она могла измениться из-за того, что, например, по пути водитель задержался в пробке. Понятно, что пассажирам это не всегда нравилось.

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

Вопрос расчёта lifetime value (он же LTV, customer lifetime value, CLV) рано или поздно встаёт перед разработчиками мобильных (впрочем, и не только) приложений. Методов расчёта придумано множество, и по поводу того, как считать LTV, существует сколько людей, столько же и мнений. В данном материале я решил описать наиболее распространённые методы, обозначить их плюсы и минусы. Данные методы подходят прежде всего для описания f2p-модели.

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



Все понимают, что для работы над продуктом, особенно в IT, знания технологий так или иначе необходимы. Для менеджера не должны быть новыми слова «бэкенд», «верстка», «база данных». Чтобы отлавливать баги или видеть точки роста в продукте, нужно не просто постоянно им пользоваться, но и понимать, как он устроен. К разработчикам лучше приходить с формулировками «на мобильном интернете долго отдаётся вёрстка» или «при таком сценарии не загружается часть данных», а не говорить «вот тут что-то тормозит, посмотри». Таким образом менеджер перекладывает генерацию и проверку гипотез о том, что же происходит в проблемном месте, на разработчика, у которого «такая же точно нога, но не болит».

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

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



Многим из вас знаком традиционный подход с разделением менеджеров проектов и продуктов. В Яндексе зачастую такого разделения нет, и вам, скорее всего, в работе понадобятся знания и умения обеих специализаций. Роль менеджера постоянно эволюционирует. Компании и сервисы растут, меняются процессы – это все влечет за собой постоянное переосмысление этой роли. В таких условиях есть постоянный риск того, что она превратится в неясную сущность. Спасти от этого может только постоянная рефлексия на тему того, что и как должен делать менеджер.

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

Открытый курс машинного обучения mlcourse.ai сообщества OpenDataScience – это сбалансированный по теории и практике курс, дающий как знания, так и навыки (необходимые, но не достаточные) машинного обучения уровня Junior Data Scientist. Нечасто встретите и подробное описание математики, стоящей за используемыми алгоритмами, и соревнования Kaggle Inclass, и примеры бизнес-применения машинного обучения в одном курсе. С 2017 по 2019 годы Юрий Кашницкий yorko и большая команда ODS проводили живые запуски курса дважды в год – с домашними заданиями, соревнованиями и общим рейтингом учаcтников (имена героев запечатлены тут). Сейчас курс в режиме самостоятельного прохождения.