チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
掲載サイトのために賃貸物件の住所を確認する
バケーションレンタルに到着したゲストが、地図上のピンが空き地や、まったく別の建物、あるいは実際の物件から数ブロック離れた場所を指していることに気づくのは、ホストだけでなくプラットフォームの評判にも関わる悪い体験です。セルフサービスでの掲載作成を認めていたあるバケーションレンタルのプラットフォームでは、これが頻繁に起きていたため、誤った住所を事後にゲストの苦情で見つけることに頼るのではなく、本格的な対策が必要だと判断しました。
ほとんどのケースは意図的な詐欺ではありませんでした。住所を手入力するホストがよくある入力ミスをしたり、新しい掲載を設定する際に実際の物件から少しずれた位置にピンを置いたり、同じフォームの別の箇所に入力した市区町村や通りと一致しない郵便番号を入力したりしていたのです。より意図的に見えるケースも少数ありました。主張されている場所とはまったく別の場所に解決される住所で、掲載が主張どおりのものではないことを示す他の兆候と結びついていることもありました。
このプラットフォームは、掲載作成のフローに検証ステップを追加しました。ホストが入力した住所は/v1/forwardに送られ、一致結果とともにどの程度の確信度で解決されたかが報告されます。プラットフォームは、その解決された位置と、ホストが設定中に地図上に別途置いたピンとを比較し、両者が小さな許容範囲を超えて食い違う掲載にフラグを付けました。本当に正確な掲載であれば両者はほぼ一致するはずなので、これは入力された住所か置かれたピンのどちらかが間違っていることを強く示すシグナルです。入力された郵便番号は別途/v1/postcodeで照合し、フォームに入力された市区町村と対応していないケースを捕捉しました。
両方のチェックを通過した掲載は通常どおり公開されました。入力された住所と置かれたピンが一致しない掲載や、郵便番号が入力された住所の他の部分と整合しない掲載は、簡単な手動レビューのために保留されるか、場合によっては、フラグが付いたフィールドを再確認して修正するよう具体的に促すメッセージとともにホストに差し戻され、修正しない限り公開できないようにしました。これにより、ゲストがその情報をもとに予約して移動してしまう前、つまり最も簡単かつ安く修正できる時点で誤りを捕捉できました。
このプラットフォームは社内で、この検証が確認するのは住所が正しい形式でピンの位置と整合していることであり、物件そのものが写真や説明とその他の点で一致していることではない、と明確にしていました。それは信頼と安全のプロセスの別の部分であり、住所チェックが解決しようとするものではありません。住所チェックに無理のある役割を求めるのではなく、より広い信頼の仕組みの中の、範囲が狭く明確に定義された1つの要素として扱ったことで、社内でも、ホストへの機能説明においても、期待を現実的なものに保てました。
リクエスト量は新規掲載の作成と既存掲載の住所編集に比例しました。プラットフォームの総予約数と比べれば控えめで予測しやすい負荷であり、中規模のプラットフォームであれば1日あたりの無料枠に余裕をもって収まりました。
両エンドポイントのドキュメントは/docs/forward-geocoding/と/docs/postal-code-lookup/にあります。