Проверка соответствия адреса указанному почтовому индексу до оформления заказа
Несовпадение почтового индекса и города в форме заказа выглядит мелкой опечаткой, пока не превращается в доставку совсем в другую часть страны.
Каждое дополнительное поле на странице оформления заказа стоит магазину какой-то доли покупателей, которые бросают корзину, не желая его заполнять. Выбор страны кажется мелким полем, но это ещё одно решение именно в тот момент покупки, когда покупатель скорее всего уйдёт, и интернет-магазин, продающий в дюжину стран, решил полностью от него отказаться.
Его заменил серверный запрос, выполнявшийся до отрисовки страницы оформления заказа. /v1/ip принимает IP-адрес посетителя и возвращает страну, регион, город, почтовый индекс и координаты, и всё это берётся из того же запроса, который уже привёл покупателя на сайт. Магазин использовал поле страны, чтобы заранее выбрать страну доставки, настроить предлагаемые способы оплаты и переключить язык интерфейса там, где для этого рынка доступно несколько языков. Покупатель из страны, куда магазин не доставляет, сразу видел соответствующее сообщение, а не заполнял всю форму, чтобы упереться в тупик на этапе оплаты.
При этом покупатель ни к чему не был привязан. Заранее выбранную страну можно было изменить, поскольку IP-геолокация отражает сеть, из которой пришёл запрос, а не всегда платёжный адрес, который человек хочет указать, особенно если он в поездке или в корпоративной сети, направляющей трафик через другую страну. Отношение к определённой стране как к разумному значению по умолчанию, а не как к факту, избавило покупателей от раздражения из-за страницы оформления, которая отказывается верить, где клиент на самом деле живёт.
Поверх того же определения магазин выстроил ценообразование. Для некоторых рынков цены корректировались с учётом местной покупательной способности и стоимости доставки: это заранее решала команда мерчандайзинга, а применялось оно просто в зависимости от того, какое значение поля страны вернул запрос. Это бизнес-решение, которое магазин принимает с помощью собственного механизма ценообразования, а не то, что решает сам запрос геолокации, но для работы ему нужен надёжный сигнал о стране. Чтение этого сигнала на стороне сервера означало, что цена, которую видел покупатель, совпадала с ценой, которую реально спишут при оформлении, в отличие от клиентского скрипта, которым можно манипулировать или который может просто не загрузиться.
Поскольку запрос выполняется один раз за сеанс оформления заказа, а не при каждом просмотре страницы, объём оставался умеренным даже в удачный месяц продаж и большую часть года укладывался в бесплатную дневную квоту, входящую в ключ магазина. В сезонный пик аккаунт ненадолго переходил на предоплаченный баланс по 0,0001 € за запрос, и эта сумма была настолько мала, что ни разу не стала статьёй расходов, достойной обсуждения.
В итоге изменение убрало одно поле из формы и заменило его запросом, которого никто не замечает. Покупатели заметили лишь то, что сайт как будто уже знает, где они находятся, и в этом вся цель подобной персонализации: она должна ощущаться как меньшее количество препятствий, а не как новая функция. Описание полей и доступных форматов приведено на /docs/ipv4-lookup/ и /docs/ipv6-lookup/.