Проверка соответствия адреса указанному почтовому индексу до оформления заказа
Несовпадение почтового индекса и города в форме заказа выглядит мелкой опечаткой, пока не превращается в доставку совсем в другую часть страны.
Как превратить таблицу адресов в карту торговых территорий
Одиннадцать тысяч строк с адресами клиентов лежали в таблице, полезные для выставления счетов и бесполезные для планирования. Команда по организации продаж хотела перекроить свои территории с учётом того, где клиенты находятся на самом деле, а не по границам округов, выбранным кем-то много лет назад, но таблицу, полную уличных адресов, нельзя отсортировать по географии. Её можно отсортировать только по алфавиту, а это не одно и то же.
Решением стало одно пакетное задание. Команда выгрузила все уникальные адреса из своего списка клиентов и отправила их на /v1/forward одним пакетным запросом, поскольку в списке адресов каждый элемент учитывается как один оплачиваемый запрос, а не тарифицируется за каждый вызов, как было бы при одиннадцати тысячах отдельных запросов. В ответ пришло совпадение местоположения для каждого адреса, включая широту и долготу, то есть структурированные координаты, с которыми реально может работать картографический инструмент или формула в таблице.
Когда у каждого клиента появились координаты, перепланировка территорий превратилась из задачи на угадывание в задачу на работу с данными. Команда смогла группировать клиентов по близости, измерять, насколько равномерно выручка распределяется по предлагаемому набору регионов, и сразу видеть, когда граница территории без веских причин разрезает пополам плотное скопление клиентов. Ничего из этого не было видно, пока единственным полем местоположения был текстовый адрес, по которому таблица не могла измерить расстояние.
Команда также сверила поля страны и региона каждого совпадения с текущим закреплением клиентов за менеджерами, и это выявило несколько клиентов, которые со временем оказались не на своей территории: компании, сменившие офис, или клиенты, по ошибке закреплённые много лет назад за менеджером из соседнего региона и так и не переназначенные. Исправление этого стало побочным эффектом, который никто не планировал, и для справедливости планов продаж он оказался важнее, чем сама перепланировка территорий.
Поскольку весь список клиентов был геокодирован за один проход, а не поступал постепенно, это было скорее разовым проектом, чем постоянной интеграцией. Команда запустила пакет, выгрузила результаты обратно в свою таблицу планирования и не должна была снова обращаться к эндпоинту до следующего крупного пересмотра территорий. Для такой нагрузки бесплатной суточной квоты хватило на весь прогон вообще без предоплаченного баланса, и весь проект занял одну половину дня, а не многонедельную работу по картографированию со сторонним подрядчиком.
Более серьёзный сдвиг произошёл в том, как команда стала думать о собственных данных после этого. Как только у адресов появились координаты, вопросы, для которых раньше требовался консультант, например какие регионы недостаточно охвачены или перегружены относительно плотности клиентов, стали вопросами, на которые команда могла ответить сама с помощью таблицы и небольшой арифметики. Геокодирование было единственной частью, для которой потребовался внешний сервис, и одновременно самой маленькой частью проекта.
Пакет адресов не обязательно должен быть списком клиентов. Расположение магазинов, зоны обслуживания, места проведения мероприятий, всё, что хранится в таблице в виде текстового адреса, можно пропустить через тот же процесс. Ограничения пакетов и формат запросов описаны на страницах /docs/forward-geocoding/ и /docs/rate-limits/.