Покупатель, который заполняет форму заказа автозаполнением из сохранённой в браузере записи или копирует адрес из старого письма, иногда получает почтовый индекс одного места в паре с названием города из другого. Такую ошибку легко допустить и легко пропустить, быстро просматривая заполненную форму перед нажатием кнопки отправки. Интернет-магазин, доставляющий физические товары, обнаружил, что именно это несоответствие стоит за постоянным небольшим потоком доставок не по адресу или с задержкой: каждая по отдельности мелочь, а вместе они давали ощутимые расходы на повторную отправку и раздражение клиентов.
Решением стала перекрёстная проверка, автоматически выполняемая при оформлении заказа, до его подтверждения. Почтовый индекс из формы отправлялся в /v1/postcode, который определяет, какому месту этот индекс на самом деле соответствует. Магазин сравнивал полученное местоположение с городом и регионом, которые покупатель также указал в той же форме, и при явном расхождении, вместо того чтобы пропустить заказ и узнать о несоответствии, только когда доставка ушла не туда, оформление заказа приостанавливалось с простой просьбой перепроверить почтовый индекс и город перед продолжением.
В качестве второго уровня магазин также прогонял полный введённый адрес через /v1/forward, поскольку адрес может пройти перекрёстную проверку индекса и города и всё равно содержать реальную проблему в другом месте: улицы с таким названием не существует или номер дома выходит за правдоподобный диапазон для этой улицы. Уверенность совпадения, возвращаемая вызовом прямого геокодирования, давала процессу оформления второй сигнал, который учитывался вместе со сравнением почтового индекса, и явно плохие совпадения получали такую же быструю просьбу о подтверждении.
Магазин продуманно подошёл к тому, сколько трения это добавляет. Большинство заказов мгновенно проходили обе проверки и проходили оформление вообще без видимых изменений, поскольку подавляющее большинство покупателей с первого раза правильно вводят свой адрес. Просьбу о подтверждении видела только меньшая часть заказов с реальным несоответствием, и даже тогда покупателю требовалось лишь несколько секунд, чтобы проверить и исправить адрес или подтвердить, что он введён правильно: иногда законно необычный адрес всё же мог вызвать срабатывание проверки, не будучи на самом деле ошибочным.
Такая проверка окупается именно потому, что выявить несоответствие до отправки намного дешевле, чем разбираться с заказом, который уже ушёл не туда: это повторная отправка, плюс задержанная или потерянная исходная доставка, плюс, зачастую, раздражённый клиент, который теперь с меньшей вероятностью сделает заказ снова. Исправление за несколько секунд до оформления заказа, а не за дни, которые уходят на обнаружение и исправление проблемы с доставкой постфактум, снизило эти расходы со значительных почти до нуля.
Каждый заказ вызывал одну проверку почтового индекса и одну проверку адреса: нагрузка росла прямо пропорционально объёму продаж и большую часть года укладывалась в бесплатную дневную квоту для магазина среднего размера, а предоплаченный баланс покрывал более загруженные периоды без какого-либо специального планирования заранее.
Документация по обоим эндпоинтам находится на /docs/postal-code-lookup/ и /docs/forward-geocoding/, а общая обработка ошибок для обоих описана на /docs/errors/.