Проверка соответствия адреса указанному почтовому индексу до оформления заказа
Несовпадение почтового индекса и города в форме заказа выглядит мелкой опечаткой, пока не превращается в доставку совсем в другую часть страны.
Создание графика высот маршрута для приложения для бега
Бегунов, планирующих маршрут, волнуют подъёмы, и оценить их по плоской карте сложно, поскольку два маршрута одинаковой длины могут ощущаться совершенно по-разному в зависимости от того, сколько в них набора высоты. На доске запросов функций у приложения для бега одна идея месяцами держалась в числе первых: показывать профиль высот запланированного маршрута до того, как человек решится его пробежать.
Функция построения маршрутов в приложении уже выдавала последовательность координат, описывающую запланированную пробежку, построенную по начальной и конечной точкам и собственной логике поиска пути по реальным улицам и тропам. Не хватало данных о высоте для каждой точки этого пути. /v1/elevation напрямую закрыл этот пробел: список координат, отправленный одним запросом, возвращался соответствующим списком значений высоты в том же порядке, готовым для построения графика относительно накопленного расстояния бегуна вдоль маршрута.
Получившийся график высоты относительно расстояния дал бегунам именно то, о чём просили в запросе функции: ясное представление о том, где на запланированной пробежке находятся подъёмы, насколько крутым выглядит каждый из них по сравнению с остальным маршрутом, и цифру суммарного набора высоты, которая наряду с расстоянием и ожидаемым темпом стала одним из главных показателей каждого сохранённого маршрута в приложении.
Плотность выборки здесь была важна для контроля затрат, примерно так же, как подошло бы к этой задаче велосипедное приложение. Для короткой пробежки по району высоту нужно было брать довольно часто, чтобы график получался плавным и выглядел точным, а для более длинного маршрута можно было использовать более редкий шаг без заметной для бегуна разницы в графике. Поскольку в пакетном запросе высоты каждая точка считается одной оплачиваемой позицией, инженерная команда приложения настраивала шаг выборки в зависимости от длины маршрута именно для того, чтобы не запрашивать гораздо больше точек, чем реально требует визуальное разрешение графика.
Поверх тех же данных приложение добавило ещё одну небольшую функцию: значок «сложность подъёмов» на сохранённых маршрутах, рассчитываемый по суммарному набору высоты относительно расстояния. Он позволял бегунам быстро сравнить два маршрута похожей длины, не изучая полный график каждого. По сути это похоже на то, как пешеходное приложение могло бы использовать тот же расчёт для сложности троп, только с настройкой на более короткие расстояния и другие ожидания по темпу, характерные для обычной пробежки, а не похода.
После запуска функции вовлечённость пользователей в работу с сохранёнными маршрутами выросла. Команда приложения объяснила это прежде всего тем, что бегуны увереннее выбирали незнакомый маршрут, когда могли увидеть, какой набор высоты их ждёт, а не обнаруживать сложность маршрута только на середине первой пробежки.
Запросы высоты выполнялись один раз на сохранённый маршрут, а не на каждую пробежку, поскольку профиль высот маршрута между пробежками не меняется. Благодаря этому общий объём запросов был пропорционален числу разных маршрутов, созданных пользователями, а не общему использованию приложения, и для приложения со средним числом активных пользователей с запасом укладывался в бесплатную дневную квоту.
Документация по эндпоинту, включая ограничения на число точек в запросе, находится по адресу /docs/elevation-lookup/.