Ответ на практический кейс про метрики backend-продукта API построения маршрутов
#productdo_кейс
Владимир на связи - давайте разберем кейс. Начнем с фидбека ответившим и сначала пройдемся по хорошим, но не главным метрикам. Например, "средняя длина поездки" и "расход топлива" хоть и интересные индикаторы, они не позволяют их полностью контролировать улучшением нашего продукта. Например, мы можем хоть расшибиться инновациями, но это никак не влияет на то, заказывают ли пассажиры длинные (или короткие) поездки.
Одна из хороших метрик - это время ответа. Причем не только среднего (как предложил Павел), но вместе с каким-нибудь высоким процентилем, чтобы понимать не только среднюю температуру по больнице, но и самые "медленные" ответы. Логика с этой метрикой простая - чем быстрее строим маршрут, тем больше вероятность, что пользователь не устанет ждать и уйдет к конкурентам.
То же самое со стабильностью работы. Ее можно измерять по-разному, но вполне подойдет процент возвращенных маршрутов (вместо ошибок) или доля времени работы без сбоев. Эта метрика тоже полностью в наших руках и нужна для "счастья" пользователя.
Наконец, некоторые из вас предложили измерять корректность маршрута. Это классная метрика, потому что мало вернуть и вернуть быстро, хорошо бы еще не увезти человека из центра Москувы в Малые Висюки. С измерением надо думать вместе с командой: простые схемы типа "% соотвествия маршрута фактическому" не совсем работают, так как в реальности водители объезжают пробки, ремонты дороги или пассажир хочет "вот там поехать", а это не то, на что может влиять сервис карт. Можно, наверное, как-то использовать все данные о передвижениях транспорта вообще, чтобы оптимизировать свои маршруты, и, действительно, придумать какой-то индикатор их "оптимальности". Интересная задачка для продакта этого продукта, не будем ему сильно помогать, пусть работает 🙂
Надеюсь, было полезно.
#productdo_кейс
Владимир на связи - давайте разберем кейс. Начнем с фидбека ответившим и сначала пройдемся по хорошим, но не главным метрикам. Например, "средняя длина поездки" и "расход топлива" хоть и интересные индикаторы, они не позволяют их полностью контролировать улучшением нашего продукта. Например, мы можем хоть расшибиться инновациями, но это никак не влияет на то, заказывают ли пассажиры длинные (или короткие) поездки.
Одна из хороших метрик - это время ответа. Причем не только среднего (как предложил Павел), но вместе с каким-нибудь высоким процентилем, чтобы понимать не только среднюю температуру по больнице, но и самые "медленные" ответы. Логика с этой метрикой простая - чем быстрее строим маршрут, тем больше вероятность, что пользователь не устанет ждать и уйдет к конкурентам.
То же самое со стабильностью работы. Ее можно измерять по-разному, но вполне подойдет процент возвращенных маршрутов (вместо ошибок) или доля времени работы без сбоев. Эта метрика тоже полностью в наших руках и нужна для "счастья" пользователя.
Наконец, некоторые из вас предложили измерять корректность маршрута. Это классная метрика, потому что мало вернуть и вернуть быстро, хорошо бы еще не увезти человека из центра Москувы в Малые Висюки. С измерением надо думать вместе с командой: простые схемы типа "% соотвествия маршрута фактическому" не совсем работают, так как в реальности водители объезжают пробки, ремонты дороги или пассажир хочет "вот там поехать", а это не то, на что может влиять сервис карт. Можно, наверное, как-то использовать все данные о передвижениях транспорта вообще, чтобы оптимизировать свои маршруты, и, действительно, придумать какой-то индикатор их "оптимальности". Интересная задачка для продакта этого продукта, не будем ему сильно помогать, пусть работает 🙂
Надеюсь, было полезно.