ガイド

配送フォームに郵便番号からの自動入力を追加する

郵便番号、市区町村、地域の入力欄が分かれている配送フォームは、1つの郵便番号からすでにわかることが多い情報を顧客に入力させています。

郵便番号を検索する

顧客が郵便番号を入力し終えて国を選択したら、またはアカウントから国がすでにわかっている場合は、その両方を/v1/postcodeに送信します。

GET /v1/postcode?code=SW1A 1AA&country=GB
{
  "status": "ok",
  "postcode": "SW1A 1AA",
  "country_code": "GB",
  "results": [
    {"lat": 51.5014, "lon": -0.1419, "components": {"city": "London", "region": "Greater London", "country": "GB"}}
  ]
}

フォームの入力欄を埋める

結果のcomponentsオブジェクトから市区町村と地域の欄に直接入力し、入力欄を完全にロックするのではなく、顧客が確認または修正できるようにしてください。郵便番号がまれに境界をまたいでいたり、一般的に使われる複数の地名にまたがっていたりすることがあるためです。

2つ目の例:税務のために請求先の地域をあらかじめ入力する

同じ検索は、配送フォームだけでなく、税額計算のために顧客の地域が必要な新規登録フォームや請求フォームにも適しています。請求先の郵便番号が入力された時点で同じ郵便番号検索を実行すれば、まったく同じリクエストとレスポンスの形を使って、どちらの場面でも地域の欄を一貫して埋められます。そのため、同じクライアント側とサーバー側の処理コードで両方のフォームに対応できます。

適切なタイミングで検索を実行する

検索は、キーを押すたびではなく、郵便番号の入力欄からフォーカスが外れたとき、または選択した国で想定される桁数に達したときに実行してください。郵便番号は完全に入力されて初めて検索する意味があるからです。こうすれば、この機能は入力した文字ごとに1リクエストではなく、入力欄の入力が完了するごとに1リクエストで済みます。

避けるべきよくある間違い

すべての国の郵便番号の形式に対して、想定する桁数を固定でハードコードしないでください。ある国では通用する5桁という前提は、桁数が異なる国や、上の例のような英数字の形式を使う国では、検索が早すぎるタイミングで実行されたり、まったく実行されなかったりする原因になります。桁数にかかわらずフォーカスが外れたときに実行するか、最もよく対応する国で早めに実行したい場合は、国ごとの桁数を記した小さな表を管理してください。

認識されない郵便番号の扱い

空のresults配列は、その国ではその郵便番号が認識されなかったことを意味し、原因はたいてい入力ミスです。フォーム送信をブロックするのではなく、市区町村と地域の欄を空欄のままにして、顧客に手入力してもらってください。自動入力が失敗したからといって入力欄をそのまま拒否するのは、その場合に限って手入力をお願いするよりも悪い体験になるからです。

エッジケース:複数の地名にまたがる郵便番号

郵便番号によっては、地元で複数の地名で呼ばれる地域を正当に含んでいたり、一般的に使われる2つの市区町村名のちょうど境界にあったりします。その場合、返された値を固定のラベルではなく編集可能な候補として表示すれば、どちらかの名前を他方より公式またはそうでないと扱うことなく、顧客が実際に使っている名前に修正できます。

住所の入力が完了したら正確な座標を取得する

郵便番号からの自動入力で得られるのは地域レベルの位置であり、市区町村と地域の欄には十分です。しかし、顧客がさらに番地まで含む住所を入力したら、その完全な住所を/v1/forwardで処理することで、配送ラベルや配送ルートのシステムが実際に必要とする正確な座標を取得できます。

コスト

郵便番号の入力欄の入力が1回完了するごとに1リクエストが発生します。1日に多くの注文を処理する配送フォームでも、この機能の利用はキーを押すたびではなく注文ごとに1回の検索という控えめなペースです。そのため、ほとんどのストアでは、すべてのキーに含まれる1日あたりの無料リクエスト2,500件の範囲内に十分収まります。

郵便番号から市区町村と地域を自動入力すれば、有効な郵便番号を入力する大多数の顧客にとって、配送フォームの入力欄が2つ減ります。フィールドの定義の詳細は郵便番号検索のドキュメントにあります。