Dokumen ini menjelaskan proses untuk membangun sistem pemeriksaan alamat guna menangani berbagai respons dari Address Validation API. Panduan ini membahas cara membangun logika untuk menggunakan respons dengan benar, menyelidiki sinyal lain dari API, serta kapan dan cara meminta informasi lebih lanjut kepada pelanggan.
Secara umum, respons API menentukan cara berikut yang harus dilakukan sistem Anda untuk menangani alamat:
- Perbaiki—alamat berkualitas rendah. Anda harus meminta informasi lebih lanjut.
- Konfirmasi—alamat berkualitas tinggi, tetapi memiliki perubahan dari alamat input. Anda mungkin akan diminta untuk memberikan konfirmasi.
- Terima—alamat berkualitas tinggi. Anda dapat menerima alamat yang diberikan.
Tujuan utama
Dokumen ini membantu Anda memodifikasi sistem untuk menganalisis respons API dengan sebaik-baiknya dan menentukan tindakan berikutnya yang harus dilakukan dengan alamat yang diberikan. Pseudocode berikut mengilustrasikan kemungkinan alur.
if (the API response indicates significant problems in the address)
FIX - prompt the user to fix the address
else if (the API response indicates less significant problems in the address)
CONFIRM - confirm with the user that the address is correct
else
ACCEPT - continue with the address returned by the API.
Logika yang tepat bergantung pada situasi Anda; lihat Panduan penerapan untuk mengetahui detail selengkapnya. Anda juga dapat menggunakan implementasi open source kami untuk logika ini, yang ada di Extended Component Library.
Ringkasan alur kerja
Tabel di bawah merangkum dua tindakan untuk sistem Anda:
- Alur kerja yang akan digunakan berdasarkan perilaku perbaiki, konfirmasi, terima.
- Sinyal pertama yang harus diperiksa dari respons. Sinyal yang dijelaskan di sini berasal dari properti
verdictdan bukan satu-satunya sinyal yang harus diperiksa, tetapi memberikan indikator awal kualitas alamat. Setiap jenis perilaku sesuai dengan bagian dalam dokumen ini yang menjelaskan sinyal lebih lanjut yang mungkin juga perlu Anda selidiki.
| Perilaku sistem Anda | |||
|---|---|---|---|
| Perbaiki alamat |
Respons dari
|
||
| Konfirmasi alamat |
Respons dari
|
||
| Terima alamat |
Respons Address Validation API menunjukkan alamat dengan kualitas yang sangat baik.
|
||
Panduan implementasi
Saat mendesain cara sistem merespons sinyal validasi alamat, rekomendasi berikut dapat membantu Anda membangun model respons yang lebih efektif. Namun, ini hanyalah rekomendasi, jadi perlu diingat bahwa penerapan Anda harus sesuai dengan model bisnis Anda.
| Panduan | Detail | |
|---|---|---|
| Tingkat risiko |
Pertimbangkan tingkat toleransi untuk situasi Anda saat menyeimbangkan antara meminta koreksi dan menerima alamat seperti yang dimasukkan. |
Address Validation API menampilkan berbagai sinyal yang dapat Anda gabungkan dengan tingkat risiko untuk mengoptimalkan proses validasi. Misalnya, jika alamat memiliki nomor jalan yang belum dikonfirmasi, Anda masih dapat menerimanya. Di sisi lain, jika operasi bisnis Anda memerlukan presisi alamat yang lebih tinggi, Anda dapat meminta pengguna. Untuk contoh yang dapat termasuk dalam salah satu kategori, lihat Nomor jalan yang belum dikonfirmasi di luar AS di Terima alamat - contoh. |
| Menerima alamat |
Sebaiknya izinkan sistem Anda menerima entri asli jika pelanggan tidak merespons perintah. |
Dalam kasus ini, pelanggan mungkin telah memasukkan alamat yang tidak ada dalam sistem, seperti untuk konstruksi baru. |
Perbaiki alamat
Perbaiki alamat jika hasilnya dengan jelas menunjukkan bahwa alamat tersebut tidak dapat dikirimi paket. Sistem Anda kemudian dapat meminta pelanggan untuk memberikan informasi yang diperlukan, setelah itu Anda menerbitkan ulang alur kerja untuk mendapatkan alamat yang dapat dikirim.
Perbaiki sinyal
Address Validation API menyediakan sejumlah sinyal untuk memberi tahu Anda jika alamat perlu diperbaiki.
1. Tingkat perincian validasi dan komponen yang tidak ada
Kedua sinyal ini memberikan indikasi terbaik terkait alamat yang bermasalah:
- Setiap kali kolom
validationGranularitybernilaiOTHER, sistem Anda harus menyelidiki sinyal komponen alamat untuk mempelajari lebih lanjut tempat terjadinya error dan cara memperbaikinya. - Setiap kali objek
addresspascapemrosesan menampilkan kolommissingComponentTypes, sistem Anda harus memeriksa komponen tersebut. Komponen yang tidak ada juga membuat alamat tidak lengkap dan tidak dapat dikirim.
2. Sinyal lainnya
Address Validation API juga menyediakan sinyal lain untuk membantu mendiagnosis masalah tertentu:
| Komponen yang mencurigakan | Jika enum tingkat konfirmasi untuk komponen adalah
UNCOMFIRMED_AND_SUSPICIOUS, kemungkinan komponen tersebut
salah.
|
|---|---|
| Komponen yang belum terselesaikan | unresolvedToken adalah bagian dari input yang tidak dikenali sebagai bagian alamat yang valid. |
3. Sinyal alamat AS
Kolom tertentu yang hanya berlaku untuk alamat AS memberikan sinyal yang berguna bahwa alamat tersebut tidak dapat dikirim dan harus diperbaiki. Untuk alamat yang perlu diperbaiki, Anda akan melihat hal berikut:
dpvConfirmation
|
N, D, atau kosong.
|
|---|
Untuk mengetahui detail tentang dpvConfirmation, lihat
Menangani alamat Amerika Serikat.
Mengonfirmasi alamat
Anda mengonfirmasi alamat saat keputusan menunjukkan bahwa Address Validation API menyimpulkan atau membuat perubahan pada komponen alamat untuk menghasilkan alamat yang divalidasi. Dalam kasus ini, Anda memiliki alamat yang dapat dikirimi, tetapi lebih memilih keyakinan yang lebih besar bahwa alamat yang dihasilkan adalah alamat yang dimaksud oleh pelanggan.
Untuk memberikan perintah yang benar kepada pelanggan, logika Anda akan mengidentifikasi
komponen yang ditandai oleh layanan untuk menentukan tindakan atau tanda yang diterapkan API
pada komponen, seperti inferred, replaced, atau spellCorrected.
Lihat AddressComponent dalam referensi.
Konfirmasi sinyal
Address Validation API memberikan sejumlah sinyal untuk memberi tahu Anda apakah alamat harus dikonfirmasi.
1. Perincian Validasi
validationGranularity
ROUTE atau yang lebih baik dapat diterima, tetapi PREMISE atau SUBPREMISE
memberikan sinyal kemampuan pengiriman yang lebih kuat.
2. Sinyal lainnya
Saat memutuskan untuk mengonfirmasi entri alamat dengan pelanggan, verdict juga memberikan hal berikut untuk menentukan komponen yang akan diselidiki:
| Data yang disimpulkan | Jika kolom
hasInferredComponents adalah true, Anda tahu bahwa API mengisi informasi yang diperoleh dari komponen alamat lainnya.
|
|---|---|
| Data yang diganti | Jika kolom
hasReplacedComponents adalah true, API akan mengganti data yang dimasukkan dengan data yang dianggap membuat alamat valid.
|
3. Sinyal alamat AS
Kolom tertentu yang hanya berlaku untuk alamat AS menunjukkan bahwa logika Anda harus mengonfirmasi detail dengan pelanggan. Salah satu dari hal berikut berlaku:
dpvConfirmation
|
S
Untuk mengetahui detail tentang |
|---|---|
| Respons alamat | Berisi kolom missingComponentTypes dengan nilai
subpremise.
|
Menerima alamat
Anda menerima alamat jika hasil memberikan tingkat keyakinan yang tinggi bahwa alamat tersebut dapat dikirim dan dapat digunakan tanpa interaksi pelanggan lebih lanjut dalam proses downstream.
Menerima sinyal
Address Validation API memberikan sejumlah sinyal untuk memberi tahu Anda apakah alamat harus dikonfirmasi.
1. Perincian Validasi
validationGranularity dari PREMISE atau yang lebih baik dapat diterima, tetapi dalam beberapa
kasus, ROUTE masih menunjukkan alamat yang dapat dikirimi paket.
2. Sinyal lainnya
Penilaian untuk alamat berkualitas tinggi juga harus memberikan hal berikut:
- Tidak ada data yang diganti. Dalam kasus ini,
hasReplacedComponents: FALSE. - Tidak ada komponen yang disimpulkan. Dalam kasus ini,
hasInferredComponents: FALSE.
3. Sinyal alamat AS
Kolom tertentu yang hanya berlaku untuk alamat di Amerika Serikat menunjukkan alamat berkualitas tinggi yang dapat menerima pengiriman. Untuk alamat AS yang dapat diterima, Anda akan melihat hal berikut:
dpvConfirmation
|
Y
Untuk mengetahui detail tentang
|
|---|