上限に達する前にキーの使用状況を監視する
割り当てヘッダーを随時確認しておけば、リクエストが実際に拒否されるよりずっと前に、上限が近づいていることが分かります。
CRMのエクスポートは通常、顧客レコードを並べたフラットなファイルで、位置に関係するものは住所フィールドだけです。座標も、検証済みの構成要素もありません。これを地図に表示したり地域別に分類したりできる形にするには、エクスポート全体をジオコーディングする必要があります。
CRMのエクスポートから住所の列をシンプルな配列として取り出します。後で結果をレコードに対応付ける必要があるため、顧客IDは位置によって各住所とそろえたままにしておきます。
POST /v1/forward
Content-Type: application/json
["1600 Pennsylvania Avenue, Washington", "221B Baker Street, London"]{
"status": "ok",
"results": [
{"formatted": "1600 Pennsylvania Avenue NW, Washington, DC 20500", "lat": 38.8977, "lon": -77.0365, "type": "address", "precision": "house", "confidence": 0.97, "place_id": "def456", "components": {}},
{"formatted": "221B Baker Street, London, UK", "lat": 51.5237, "lon": -0.1585, "type": "address", "precision": "house", "confidence": 0.95, "place_id": "abc123", "components": {}}
]
}リクエストを送る前に記録しておいた位置によって各結果を顧客に対応付け、CRMがサポートしている方法に応じて、CRM自身のAPIまたは一括インポートで座標と構成要素をCRMに書き戻します。confidenceとprecisionのフィールドも保存しておけば、一致の弱いものを検証済みとして扱うのではなく、整理対象としてフラグを立てられます。
複数の国に顧客がいるCRMでは、地域ごとのバッチにcountriesパラメーターを付けると効果的です。候補となる一致を想定される国に限定でき、複数の国でよく使われる通り名が誤った国の住所として解決されるというまれなケースを減らせます。エクスポートを国ごとのバッチに分け、それぞれを個別の一括リクエストとして送れば、ワークフローのほかの部分を何も変えずにこれを適用できます。
元の顧客IDへの対応を別に保持しないまま、住所の配列を送る前に重複を取り除いたり並べ替えたりしないでください。結果は送った配列と同じ順序で返ってきます。保存したインデックスなしにその順序が顧客レコードと切り離されてしまうと、後から座標の組を正しい顧客に対応付ける確実な方法はありません。処理が終わるまでの間、位置とIDの対応をメモリ上か一時的な列に保持しておいてください。
最初のエクスポートをジオコーディングし終えたら、後で顧客全体を再び処理する必要はありません。どのレコードにすでに座標があるかを記録し、次回以降の実行では新しいレコードや住所が更新されたレコードだけをエンドポイントに送ります。そうすれば、継続的なリクエストの使用量は顧客の総数ではなく、新しい動きに比例したものになります。
信頼度スコアが低いレコードや、想定される構成要素がいくつも欠けているレコードは、完全に検証済みのレコードと一緒に黙って書き込むのではなく、確認キューでフラグを立てる価値があります。そうすれば、不正確な住所が、補完したデータから作った地域別のレポートや地図表示を知らないうちに汚してしまうことを防げます。
既存のCRMを一度だけ補完する場合の費用は、住所のある顧客レコード1件につき1件のリクエストで、1回の一括呼び出しか、いくつかのまとまりに分けて実行します。顧客が数千人いるCRMでは、一度に1日あたりの無料リクエスト2,500件を超えることがあります。その場合は、処理を2、3日に分けるか、一度限りの作業としてプリペイドクレジットに移行するのが妥当です。
補完が終われば、新規顧客の継続的なジオコーディングは、定期的な一括処理ではなく、少量で安定したものになります。リクエストとレスポンスの完全な構造はジオコーディングのドキュメントをご覧ください。