チェックアウトの前に住所と記載された郵便番号が一致するか確認する
注文フォームの郵便番号と市区町村の不一致は、小さな入力ミスに見えますが、やがて国内のまったく別の地域に荷物が送られる事態につながります。
ディレクトリ掲載のために事業所の住所を検証する
投稿フォームには誰でも住所を入力できますが、入力された住所がすべて実在するわけではありません。セルフサービスでの掲載投稿を受け付けていたある地域のビジネスディレクトリは、このことを痛い目に遭って知りました。掲載された住所まで車で行ったのに何もなかったという利用者からの苦情に対応することになったのです。原因は正直な入力ミスのこともあれば、架空の地域拠点で検索順位を操作しようとする悪意ある投稿のこともありました。
このディレクトリは、投稿された掲載が公開される前に検証ステップを追加しました。投稿された住所は/v1/forwardに送られます。これは照合を試み、どの程度の確信度で解決できたかを報告するもので、きれいに一致した場合と、部分的にしか解決できなかった場合や、まったく解決できなかった場合とを区別します。それとは別に、フォームに入力された郵便番号を/v1/postcodeで照合し、同じフォームに入力された市区町村や地域と対応しているかを確認しました。これにより、投稿者が誤ってか意図的にかを問わず、まったく別の場所の郵便番号をコピーしていたという、特有でありながら意外によくあるケースを捕捉できました。
どちらかのチェックに失敗した投稿も、自動的に却下されたわけではありません。一致度が低いことは偽の住所であることと同じではなく、新築の建物や珍しい農村部の立地のために住所がうまく解決されない正当なビジネスは数多くあるためです。代わりに、フラグが付いた投稿は手動レビューのキューに移され、スタッフが公開前に簡単に確認しました。どれほど問題のない投稿であっても、すべての投稿に同じ手作業の確認が必要になる、という状態ではなくなったのです。
これにより、レビュー工程の経済性は根本から変わりました。チェック導入前は、1件ずつ手作業で確認しなければどれが疑わしいかを判別する方法がなかったため、すべての投稿に人の目が必要でした。導入後は、きれいに一致し、郵便番号が入力された市区町村と整合している大多数の投稿が自動的に公開され、スタッフの時間は、それを本当に必要とする少数の投稿、つまり検証ステップ自体がフラグを付けた投稿に集中して使われるようになりました。
このディレクトリは、社内でこの手法の限界を明確にしていました。ジオコーディングできれいに一致すれば、住所が正しい形式で、地理的に実在することは確認できます。しかし、ビジネスが実際にそこで営業していることや、ビジネス名が正確であること、あるいは住所フィールドとは無関係な点で掲載が誤解を招くものではないことまでは確認できません。検証ステップが扱ったのは信頼性の問題のうちちょうど一部分、つまり場所そのものが存在し、正しく記述されているかどうかという部分だけであり、それ以外のすべてについては、ディレクトリは既存のモデレーション手法を維持しました。
リクエスト量は投稿数にそのまま比例しました。地域のディレクトリとしては控えめで予測しやすい数で、ほとんどの月はキーに含まれる1日あたりの無料枠に十分収まりました。この変更は、スタッフのレビュー時間の削減だけで何倍もの元が取れました。行き先に何もない住所を掲載するディレクトリとして知られてしまうことによる評判上のコストを考慮に入れる前から、です。
一致の確信度がどのように表現されるかを含め、両方のエンドポイントのドキュメントは/docs/forward-geocoding/と/docs/postal-code-lookup/にあります。