Проверка соответствия адреса указанному почтовому индексу до оформления заказа
Несовпадение почтового индекса и города в форме заказа выглядит мелкой опечаткой, пока не превращается в доставку совсем в другую часть страны.
Планирование вебинаров с правильным временем для каждого участника
«Присоединяйтесь к нам в четверг в 2 PM по восточному времени» звучит точно только для тех участников, которые и так мыслят восточным временем, а для всех остальных превращается в угадайку. B2B-компания по разработке ПО, регулярно проводящая вебинары для международной аудитории, обнаружила, что заметная доля неявок и опозданий объяснялась тем, что участники просто неправильно пересчитывали часовой пояс или вовсе не пересчитывали и считали, что в приглашении указано их собственное местное время 2 PM.
Форма регистрации компании уже собирала адрес электронной почты и, для целей планирования, приблизительное местоположение: либо введённое напрямую, либо определённое по IP-адресу участника в момент регистрации через /v1/ip, который возвращает координаты вместе со страной и городом. Эти координаты передавались в /v1/timezone, который возвращал название часового пояса IANA для местоположения участника, и у компании появился надёжный способ рассчитать правильное местное время вебинара именно для этого участника, не полагаясь на то, что участник пересчитает его сам.
После этого в каждом письме с подтверждением время вебинара указывалось дважды: один раз в часовом поясе ведущего для единообразия и один раз с расчётом специально для определённого часового пояса участника, простыми словами, а не в виде смещения, с которым читателю пришлось бы считать дальше. Такое же двойное отображение переносилось и в приглашение для календаря, прикреплённое к подтверждению, поэтому участник, добавив мероприятие в свой календарь, автоматически видел его в правильный местный час, и ему не нужно было доверять ручному пересчёту.
Поскольку вебинары часто планировались за несколько недель, иногда с переходом на летнее или зимнее время в одном регионе, но не в другом, компания полагалась на способность запроса часового пояса рассчитывать правильное смещение на конкретную будущую дату вебинара, а не смещение, действовавшее в день отправки приглашения. Хранение названия IANA вместо фиксированного смещения означало, что всё оставалось правильным, и никому в компании не нужно было следить, в каких регионах скоро переведут часы, и вручную исправлять приглашения.
Измеримым результатом стало заметное сокращение числа писем в поддержку и отдел продаж с просьбой подтвердить реальное местное время предстоящей сессии: это были небольшие, но регулярные затраты рабочего времени сотрудников, которые раньше считались неизбежной частью проведения международных вебинаров. Посещаемость тоже немного выросла, хотя компания подчёркивала, что рост, скорее всего, объяснялся сочетанием факторов, и более понятное отображение часового пояса было лишь одним из них, а не единственным объяснением.
Объём был небольшим и предсказуемым, один запрос на каждого участника в момент регистрации, и такая нагрузка ни разу не приблизилась к бесплатной дневной квоте даже у компании, которая часто проводит вебинары, ведь число регистраций на отдельное мероприятие редко достигает масштаба, при котором стоимость запросов становится заметным фактором.
Правильное время встречи для каждого участника в отдельности, вместо того чтобы просить каждого пересчитывать его самостоятельно, убирает небольшое, но реальное препятствие даже в таком простом деле, как подключение к запланированному звонку. Документация по обоим эндпоинтам находится на страницах /docs/ipv4-lookup/ и /docs/timezone-lookup/.