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