Проверка соответствия адреса указанному почтовому индексу до оформления заказа
Несовпадение почтового индекса и города в форме заказа выглядит мелкой опечаткой, пока не превращается в доставку совсем в другую часть страны.
Инструмент страховых расчётов с учётом риска по почтовому индексу
Мгновенный онлайн-расчёт страховки должен уравновешивать две противоречащие друг другу вещи: он должен происходить быстро, в идеале после нескольких полей, и при этом опираться на достаточно реальной информации, чтобы разумно оценить полис, а не гадать. Региональный страховщик жилья, создававший инструмент мгновенного расчёта, обнаружил, что просьба ввести полный адрес ещё до показа какой-либо цены стоила ему множества посетителей, которые уходили, так и не увидев ни одной цифры, то есть именно тех посетителей, которых быстрый расчёт должен был удерживать.
Почтовый индекс оказался тем вводом, который достаточно хорошо удовлетворял оба ограничения. Одно короткое поле, достаточно быстрое, чтобы большинство посетителей вводили его не задумываясь, и достаточно конкретное, чтобы отнести объект недвижимости к району, который заметно коррелировал с факторами риска, уже используемыми в собственных актуарных моделях страховщика для расчёта полисов: региональными погодными условиями, местной историей страховых случаев и близостью к известным зонам риска наводнений или лесных пожаров, которые команда по рискам страховщика вела самостоятельно.
Инструмент расчёта отправлял введённый почтовый индекс в /v1/postcode, который определяет район, соответствующий этому индексу, а собственный движок ценообразования страховщика по этому району находил свой внутренний рейтинг риска для региона. Это были целиком собственные данные и методология страховщика, а определение почтового индекса служило лишь мостом между тем, что ввёл посетитель, и тем, какая строка собственной таблицы рисков страховщика применяется. My Geocode не участвовал в том, как страховщик взвешивал риски, и не имел к этому никакого доступа, его роль сводилась к определению того, какое местоположение на самом деле описывает данный почтовый индекс.
Полученный таким образом мгновенный расчёт был чётко помечен как предварительный, поскольку полный процесс андеррайтинга всё равно требовал полного адреса, сведений о конкретном объекте и другой информации, которую один почтовый индекс дать не может, например возраста кровли или наличия определённых средств противопожарной защиты. Задача мгновенного расчёта состояла в том, чтобы достаточно быстро дать посетителю реалистичную ориентировочную цифру и удержать его в процессе, а не в том, чтобы стать окончательной обязывающей ценой, и сайт страховщика явно подчёркивал это различие на каждом шаге.
Такой поэтапный подход, быстрая оценка сейчас и сбор полного адреса только тогда, когда человек готов перейти к оформлению реального полиса, соответствовал тому, как посетители уже себя вели: большинство людей, запрашивавших мгновенный расчёт, сравнивали предложения и хотели получить примерную цифру, прежде чем браться за длинную заявку, а просьба ввести полный адрес до того, как им эту цифру показали, стоила страховщику именно этих сравнивающих покупателей.
Трафик инструмента расчёта, как и большая часть трафика, связанного с выбором страховки, резко возрастал в сезоны продления полисов и после крупных погодных событий в регионе, из-за чего в эти периоды использование у страховщика выходило за пределы бесплатной дневной квоты и переходило на предоплаченный баланс. Эти расходы были ничтожны по сравнению с ценностью заполненной заявки на полис, полученной благодаря быстрому и удобному расчёту.
Документация по эндпоинту находится на странице /docs/postal-code-lookup/, а подробности о ценах на API на странице /pricing/.