ユースケース

チェックアウトの前に住所と記載された郵便番号が一致するか確認する

ブラウザに保存された情報からチェックアウトフォームを自動入力したり、古いメールから住所をコピーしたりした買い物客は、ある場所の郵便番号と別の場所の市区町村名が組み合わさった状態になってしまうことがあります。これは起こしやすいミスであり、送信をクリックする前に入力済みのフォームをざっと読み返すだけでは見落としやすいミスでもあります。物理的な商品を出荷しているあるオンラインストアでは、まさにこの不一致が、誤配送や配達遅延が少しずつ絶え間なく発生する原因になっていました。1件ごとは小さくても、全体としては再発送や顧客の不満という形で実際のコストになっていました。

対策は、注文が確定する前のチェックアウト時に自動的に実行されるクロスチェックでした。フォームに入力された郵便番号は/v1/postcodeに送られ、そのコードが実際にどの場所に対応するかが解決されます。ストアは、その解決された場所と、買い物客が同じフォームに入力した市区町村や地域とを比較しました。明らかに食い違う場合は、注文をそのまま通して配達が間違った場所に届いてから不一致に気づくのではなく、チェックアウトのフローを一時停止し、先に進む前に郵便番号と市区町村を再確認するよう、わかりやすいメッセージで買い物客に求めました。

ストアはさらに、入力された住所全体を2段目のチェックとして/v1/forwardにも通しました。住所は郵便番号と市区町村のクロスチェックを通過しても、その名前の通りが存在しない、あるいはその通りとしてあり得る範囲外の番地であるなど、別の箇所に本当の問題を抱えていることがあるためです。ジオコーディングの呼び出しが返す一致の確信度は、チェックアウトのフローにとって郵便番号の比較と合わせて判断する2つ目のシグナルとなり、一致度が明らかに低いものには同じ簡単な確認メッセージを表示するフラグを付けました。

ストアは、これによって増える手間の量について意図的に検討しました。大多数の買い物客は最初から自分の住所を正しく入力するため、ほとんどの注文は両方のチェックを瞬時に通過し、目に見える変化はまったくないままチェックアウトを進みました。確認メッセージが表示されたのは本当に不一致がある少数の注文だけで、その場合でも、買い物客が確認して修正するか、入力どおりの住所で実際に正しいと確認するのにかかるのはほんの数秒でした。正当でありながら珍しい住所が、実際には間違っていないのにチェックに引っかかることもたまにあるからです。

この種のチェックが元を取れるのは、まさに出荷前に不一致を見つけるコストが、すでに間違った場所へ出荷された注文のコストよりはるかに小さいからです。後者では、再発送に加えて元の配達の遅延や紛失が起こり、さらに多くの場合、次に注文する可能性が低くなった不満を抱えた顧客が生まれます。出荷の問題を事後に発見して修正するのにかかる数日ではなく、注文が確定する前の数秒で修正することで、そのコストは大きなものからほぼゼロに近いものになりました。

注文ごとに郵便番号のチェックと住所のチェックが1回ずつ実行されました。この負荷は売上数に直接比例し、中規模のストアであれば1年の大半は1日あたりの無料枠に収まりました。繁忙期はプリペイドクレジットでまかなえるため、事前に特別な計画を立てる必要もありませんでした。

両方のエンドポイントのドキュメントは/docs/postal-code-lookup/と/docs/forward-geocoding/にあり、両方に共通するエラー処理の動作は/docs/errors/で説明しています。