Memilih solusi Address Validation

Tujuan

Validasi Alamat memberikan nilai untuk berbagai kasus penggunaan dan ada pertimbangan utama di luar kualitas mentah hasil pengujian yang sebaiknya Anda jelajahi. Misalnya: tampilan menyeluruh tentang produk yang kompatibel dalam alur penggunaan seperti Place Autocomplete dan Maps, ketersediaan regional, dan kepercayaan & keandalan perusahaan.

Setelah Anda sampai pada tahap mengevaluasi Address Validation API, berikut beberapa panduan yang sebaiknya Anda gunakan sebagai bagian dari pengujian.

Tujuan pengujian ini adalah untuk:

1. Pastikan Address Validation API sesuai untuk kasus penggunaan Anda.
2. Verifikasi cara Address Validation API memenuhi persyaratan solusi Anda, seperti:
   • Mengidentifikasi alamat berkualitas baik.
   • Memberi tahu untuk mengatasi input yang berkualitas buruk.
   • Melakukan koreksi pada data alamat, termasuk inferensi, penggantian, dan koreksi ejaan.
   • Memberikan alamat berformat untuk pengiriman.
   • Memberi tahu tentang data sub-premis yang tidak ada atau salah (khusus Amerika Serikat).
3. Pastikan Anda akan menerima manfaat yang dapat diukur dari penerapan API.

Setelah melakukan pengujian, Anda akan dapat menjawab pertanyaan di atas, dan menentukan apakah API cocok untuk bisnis Anda.

Menyiapkan data

Pengujian harus dilakukan terhadap sampel data alamat yang ada. Jangan memilih data secara manual untuk pengujian, tetapi pilih sampel acak yang mewakili geografi tempat Anda beroperasi. Artinya, jika Anda beroperasi di Amerika Serikat dan Inggris Raya, tetapi 70% bisnis Anda dilakukan di Inggris Raya dan 30% di Amerika Serikat, sampel harus mencerminkan pembagian tersebut.

Gunakan alamat dari titik pengambilan. Misalnya, jika Anda berencana untuk menerapkan validasi alamat dalam checkout e-commerce, gunakan alamat seperti yang dimasukkan oleh pelanggan di formulir, sebelum pemrosesan yang ada terjadi yang dapat diganti dengan menerapkan Address Validation API.

Siapkan ukuran sampel sekitar 5.000 - 10.000 data untuk pengujian.

Memanggil API

Prasyarat bagian: Pahami cara mengirim permintaan validasi alamat.

Setelah menyiapkan data, Anda harus menjalankan setiap data alamat terhadap API.

Lihat dokumentasi Address Validation API untuk mendapatkan panduan tentang cara memanggil API. Kami juga memiliki artikel yang menjelaskan praktik terbaik untuk menggunakan Address Validation API untuk memproses alamat dalam volume tinggi.

Hasil dari langkah ini adalah output data dari API untuk setiap data alamat. Kemudian, Anda dapat menganalisis hasilnya untuk menentukan kesesuaian API untuk kasus penggunaan Anda. Anda dapat menggunakan spreadsheet, database, atau alat lain.

Meninjau hasil

Prasyarat bagian: Pahami cara menangani respons validasi, terutama konsep Perbaiki, Konfirmasi, dan Terima.

Di bagian ini, kita akan membahas skenario output yang dapat Anda analisis untuk menilai kesesuaian solusi.

Ringkasan kolom API utama yang dibahas dalam dokumen ini

Meninjau alamat yang valid

Urutkan data yang ditampilkan dari API untuk menentukan kumpulan alamat yang akan diterima sistem Anda sebagai valid. Sinyal utama yang harus dicari dari API adalah:

• verdict.validationGranularity berisi PREMISE atau lebih baik.
• verdict.addressComplete adalah true.
• Tidak ada komponen yang disimpulkan atau diganti.

Lihat menerima alamat untuk mengetahui informasi selengkapnya.

Output latihan ini harus berupa subset data alamat yang akan diterima sebagai valid oleh sistem Anda. Pada tahap ini, Anda dapat menentukan:

• Apakah tingkat persentase penerimaan dapat diterima?
• Jika Anda menggunakan alur kerja validasi alamat yang ada, apakah rasio penerimaannya setara atau lebih baik?

Contoh: Alamat yang valid

Putusan

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "addressComplete": true
}

Meninjau alamat yang tidak valid

Langkah ini adalah kesempatan untuk meninjau secara manual beberapa data alamat yang telah ditandai sebagai tidak valid, dan melihat apakah, tanpa menggunakan Address Validation API, alamat yang tidak valid tersebut dapat menyebabkan masalah downstream.

Urutkan data yang ditampilkan dari API untuk menentukan kumpulan alamat yang akan ditandai oleh sistem Anda sebagai tidak valid. Sinyal utama yang harus dicari dari API adalah:

• verdict.validationGranularity ditetapkan ke OTHER atau ROUTE bergantung pada tingkat risiko Anda.
• verdict.addressComplete adalah false.

Lihat memperbaiki alamat untuk mengetahui informasi selengkapnya.

Output dari latihan ini harus berupa subset data alamat yang akan ditandai sebagai tidak valid oleh sistem Anda. Pada tahap ini, Anda dapat menentukan apakah tarif persentase yang tidak valid dapat diterima.

Penting untuk diperhatikan bahwa menandai alamat sebagai tidak valid adalah bagian inti dari fungsi Address Validation API, dan tingginya rasio alamat yang ditandai sebagai tidak valid tidak selalu mencerminkan kualitas API yang buruk. API memberi Anda informasi bahwa ada yang salah dengan alamat, dan hal ini dapat meningkatkan efisiensi alur kerja Anda dengan mendeteksi error lebih awal, sebelum menyebabkan masalah downstream.

Contoh: Alamat tidak valid

Putusan

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "OTHER",
  "geocodeGranularity": "OTHER",
  "hasUnconfirmedComponents": true
}

Meninjau komponen yang tidak ada atau belum dikonfirmasi

Pada tahap ini, komponen yang tidak ada atau belum dikonfirmasi juga dapat ditinjau. Ini adalah bagian dari objek Address dalam nilai yang ditampilkan. Kedua kolom tersebut adalah missingComponentTypes dan unconfirmedComponentTypes.

Gunakan kolom ini untuk membantu mendeteksi alasan alamat ditandai sebagai tidak valid oleh API, dan mengumpulkan informasi yang benar untuk alamat yang akan membuatnya valid, dengan memberikan masukan ke titik pengumpulan data kolom tertentu yang salah. Ini adalah cara API memberikan nilai dengan memberi Anda informasi spesifik tentang kualitas data Anda.

Contoh: Komponen yang tidak ada & tidak dikonfirmasi

Putusan

{
     "inputGranularity": "ROUTE",
     "validationGranularity": "OTHER",
     "geocodeGranularity": "OTHER",
     "hasUnconfirmedComponents": true
}

Komponen tidak ada & tidak dikonfirmasi

"missingComponentTypes": [
    "street_number"
],
"unconfirmedComponentTypes": [
    "route"
]

Meninjau alamat dengan koreksi

Address Validation API dapat melakukan koreksi pada data input, mengambil input alamat yang berpotensi tidak valid, dan menghasilkan data alamat yang valid. Ini adalah salah satu cara API menambahkan nilai, dan penting untuk menangkapnya sebagai bagian dari pengujian.

Sinyal utama yang harus dicari adalah:

• inferred, replaced, atau spellCorrected ditetapkan ke true di salah satu addressComponents.
• verdict.hasInferredComponents, atau verdict.hasReplacedComponents disetel ke true.

Lihat mengonfirmasi alamat untuk informasi selengkapnya.

Output latihan ini harus berupa subkumpulan data alamat yang telah menerapkan koreksi oleh API.

Sebagian data ini dapat ditinjau secara manual untuk menentukan apakah API melakukan koreksi pada data Anda yang akan mengurangi hambatan dalam alur kerja downstream.

Contoh: Alamat dengan koreksi

Rute addressComponent

{
    "componentName": {
        "text": "Buckingham Palace Road",
        "languageCode": "en"
    },
    "componentType": "route",
    "confirmationLevel": "CONFIRMED",
    "spellCorrected": true
}

[Khusus Amerika Serikat] Meninjau alamat dengan data sub-premis yang tidak ada atau salah

Address Validation API dapat menentukan apakah sub-premis tidak ada atau salah, untuk alamat di Amerika Serikat.

Sinyal utama yang harus dicari adalah:

• Di objek Address:
  • unconfirmedComponentTypes berisi subpremise
  • missingComponentTypes berisi subpremise
• Dalam objek UspsData:
  • dpvConfirmation adalah D (subpremis tidak ada)
  • dpvConfirmation adalah S (sub-premis belum dikonfirmasi)

Lihat menangani alamat Amerika Serikat untuk mengetahui informasi selengkapnya.

Pengujian ini akan menunjukkan apakah ada masalah dalam data Anda dengan sub-premis yang tidak ada atau salah seperti nomor apartemen. Hal ini dapat menyebabkan masalah downstream, terutama untuk kasus penggunaan pengiriman. Address Validation API dapat memberikan nilai tambah ke alur kerja Anda dengan mengidentifikasi hal ini lebih awal, sehingga Anda dapat menerapkan langkah-langkah untuk mengumpulkan data yang telah dikoreksi.

Contoh: Subpremis tidak ada

Komponen tidak ada

"missingComponentTypes": [
    "subpremise"
]

Konfirmasi DPV data USPS

"dpvConfirmation": "D"

[Khusus Amerika Serikat] Meninjau standardizedAddress USPS

Address Validation API juga menampilkan alamat standar USPS untuk alamat Amerika Serikat. Hal ini sangat penting jika Anda memerlukan alamat berformat USPS untuk dicetak pada label pengiriman.

UspsAddress dapat ditinjau untuk melihat data ini, dan menentukan apakah data tersebut memberikan nilai tambah ke alur kerja Anda.

Contoh: Alamat standar USPS

"standardizedAddress": {
    "firstAddressLine": "111 8TH AVE FL 11",
    "cityStateZipAddressLine": "NEW YORK NY 10011-5201",
    "city": "NEW YORK",
    "state": "NY",
    "zipCode": "10011",
    "zipCodeExtension": "5201"
}

Kesimpulan

Mulai pengujian - mulai pengujian Address Validation API sekarang untuk memastikan data alamat yang akurat, meningkatkan pengalaman pelanggan, dan menyederhanakan operasi bisnis Anda. Setelah mengikuti skenario pengujian yang diuraikan di atas, Anda akan memiliki informasi yang diperlukan untuk menentukan apakah Address Validation API akan memberikan nilai tambah pada alur kerja Anda.

Bacaan lebih lanjut yang disarankan:

• Dokumentasi developer Address Validation API
• Menggunakan Address Validation API untuk memproses alamat dalam volume tinggi
• Validasi Alamat untuk Checkout E-commerce

Kontributor

Henrik Valve | DevX Engineer