ガイド

顧客リストの郵便番号をバッチで解決する

郵便番号の列はあるものの座標のない顧客データのエクスポートは、配送ゾーン、地域別のレポート、店舗の割り当てなどに関わるあらゆる作業のよくある出発点です。列全体を一度に解決する方が、ループを書くよりも速く済みます。

バッチを送信する

郵便番号と国のオブジェクトの配列を/v1/postcodeにPOSTします。各項目は個別に解決され、同じ順序で返ります。

POST /v1/postcode
Content-Type: application/json

[{"code": "10115", "country": "DE"}, {"code": "75001", "country": "FR"}]
{
  "status": "ok",
  "results": [
    {"postcode": "10115", "country_code": "DE", "results": [{"lat": 52.5300, "lon": 13.3800, "components": {"city": "Berlin", "region": "Berlin"}}]},
    {"postcode": "75001", "country_code": "FR", "results": [{"lat": 48.8630, "lon": 2.3360, "components": {"city": "Paris", "region": "Ile-de-France"}}]}
  ]
}

結果を顧客レコードに対応させる

リクエストを送信する前に、郵便番号と国の各組み合わせと一緒に元の行番号や顧客IDを保持しておき、その同じ位置で結果を顧客レコードに対応させます。これは、一括のジオコーディングや逆ジオコーディングで使えるのと同じ方法です。

送信前に重複を除く

ある程度の規模の顧客リストでは、一意の郵便番号の数は行数よりはるかに少なくなりがちです。同じ市区町村や地区では、多くの顧客が同じ郵便番号を共有しているからです。顧客ごとに配列の項目を1つ送って同じ郵便番号と国の組み合わせに何度も料金を払うのではなく、まず郵便番号と国の組み合わせの一意のリストを作り、その小さなリストを1回のバッチで解決してから、各郵便番号を共有するすべての顧客の行に結果を対応させてください。

解決できない郵便番号の扱い

特定の項目のresults配列が空の場合、通常はその郵便番号と国の組み合わせが存在しないことを意味します。入力ミスや古い郵便番号を含む古いエクスポートではよくあることです。そうした行はレポートから黙って除外するのではなく、手動での確認のためにフラグを付けてください。

エッジケース:書式の違い

スペースなしで「SW1A1AA」と保存された郵便番号と、スペースありで「SW1A 1AA」と保存された郵便番号が同じように解決されるかどうかは、自社のエクスポートが郵便番号をどれだけ一貫した書式にしているかによって変わります。そのため、バッチの配列を作る前にエクスポートのスペースと大文字小文字を正規化しておくと、郵便番号自体が本当に間違っているのではなく、書式だけが原因で解決に失敗する行の数を減らせます。

コスト

バッチは項目ごとに1リクエストとして課金されます。そのため、2,000行の顧客リストは、1回の一括呼び出しで送っても2,000回の個別の呼び出しで送っても、2,000リクエストになります。割り当てに対するリクエスト数はどちらでも同じですが、オーバーヘッドが減り、確認すべき割り当てのヘッダーが1組で済むため、1回の呼び出しで送る価値はあります。実際にリクエスト数を減らすのは、一括か個別かの選択ではなく、上で説明したように先に重複を除くことです。

バッチの途中で割り当てを確認する

1日あたりの無料リクエスト2,500件を超えるほど大きなリストの場合は、全体を一度に実行すると決める前にX-Quota-Free-Remainingを確認してください。一度きりの作業のためにプリペイドクレジットに移行する予定がないなら、2日ほどに分けて実行してください。

顧客リスト全体の郵便番号を1回の呼び出しで解決すれば、以前は時間のかかるバックグラウンドジョブだったものが、1回のわかりやすいリクエストになります。フィールドの一覧は郵便番号検索のドキュメントで説明しています。