Menggunakan Address Validation API untuk memproses alamat dengan volume tinggi

Tujuan

Sebagai pengembang, Anda sering bekerja dengan {i>dataset <i}yang berisi alamat pelanggan yang mungkin tidak berkualitas baik. Anda perlu memastikan bahwa alamat sudah benar untuk berbagai kasus penggunaan, mulai dari verifikasi ID pelanggan, pengiriman, dan lainnya.

Validasi Alamat API adalah produk dari Google Maps Platform yang dapat Anda gunakan untuk memvalidasi alamat. Namun, hanya memproses satu alamat pada satu waktu. Dalam dokumen ini, kita akan mempelajari cara menggunakan Validasi Alamat Volume Tinggi dalam berbagai skenario, mulai dari pengujian API validasi alamat satu kali dan berulang.

Kasus penggunaan

Sekarang kita akan memahami kasus penggunaan di mana Validasi Alamat Volume Tinggi berada berguna

Pengujian

Anda sering kali ingin menguji Address Validation API dengan menjalankan ribuan untuk alamat internal dan eksternal. Anda mungkin memiliki alamat dalam file {i>Comma Separated Value<i} dan ingin untuk memvalidasi kualitas alamat.

Validasi alamat satu kali

Saat melakukan orientasi ke Address Validation API, Anda ingin memvalidasi {i>database<i} alamat yang ada terhadap {i>database <i}pengguna.

Validasi alamat berulang

Sejumlah skenario memerlukan validasi alamat secara berulang:

• Anda mungkin memiliki tugas terjadwal untuk memvalidasi alamat guna mengetahui detail yang diambil pada siang hari misalnya, dari pendaftaran pelanggan, detail pesanan, pengiriman jadwal proyek.
• Anda mungkin menerima {i>dump data<i} yang berisi alamat dari departemen yang berbeda, misalnya, dari penjualan hingga pemasaran. Departemen baru yang menerima sering kali ingin memvalidasi mereka sebelum digunakan.
• Anda mungkin mengumpulkan alamat selama survei, atau berbagai promosi, dan kemudian tentang pembaruan dalam sistem {i>online<i}. Anda ingin memvalidasi bahwa alamatnya adalah benar saat memasukkannya ke dalam sistem.

Pembahasan mendalam teknis

Untuk tujuan dokumen ini, kami berasumsi bahwa:

• Anda memanggil Address Validation API dengan alamat dari pelanggan database (yaitu database dengan detail pelanggan)
• Anda dapat meng-cache tanda validitas terhadap setiap alamat dalam database Anda.
• Tanda validitas diambil dari Address Validation API saat sebuah pelanggan individual {i>login<i}.

Coba sekarang: Buka konsol Google Cloud dan aktifkan Address Validation API.

Cache untuk penggunaan produksi

Catatan: Elemen respons spesifik yang dijelaskan dalam dapat disimpan maksimal selama 30 hari kalender berturut-turut. Semua elemen respons ini HARUS dihapus setelah batas 30 hari.

Saat menggunakan Address Validation API, Anda sering kali ingin meng-cache beberapa bagian dari respons dari panggilan API. Meskipun Persyaratan Batas layanan data apa yang dapat di-cache, data apa pun yang dapat di-cache dari Address Validation API harus di-cache terhadap akun pengguna. Ini berarti bahwa dalam {i>database<i}, metadata alamat harus di-cache di alamat email pengguna, atau ID utama lainnya.

Untuk kasus penggunaan Validasi Alamat Volume Tinggi, penyimpanan data dalam cache harus mengikuti Address Validation API Layanan Khusus Persyaratan, diuraikan dalam Bagian 11.3. Berdasarkan informasi ini, Anda akan dapat menentukan apakah alamat pengguna mungkin tidak valid, dalam hal ini Anda akan meminta pengguna untuk alamat yang dikoreksi selama interaksi mereka berikutnya dengan aplikasi.

• Data dari AddressComponent objek
  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

Jika Anda ingin meng-{i>cache<i} informasi apa pun tentang alamat yang sebenarnya, maka data tersebut harus di-cache hanya dengan persetujuan pengguna. Hal ini memastikan bahwa pengguna tahu mengapa layanan tertentu menyimpan alamatnya dan mereka setuju dengan persyaratan untuk membagikan alamat mereka.

Contoh izin pengguna adalah interaksi langsung dengan alamat e-commerce formulir di laman {i>checkout<i}. Ada pemahaman bahwa Anda akan meng-{i>cache<i} dan memproses alamat untuk tujuan pengiriman paket.

Dengan izin pengguna, Anda dapat menyimpan formattedAddress dan komponen kunci lainnya ke dalam cache dari respons. Namun, dalam skenario headless, pengguna tidak dapat memberikan karena validasi alamat terjadi dari backend. Oleh karena itu, Anda dapat meng-cache informasi yang sangat terbatas dalam skenario headless ini.

Memahami respons

Catatan: Tersedia juga panduan bagus Membangun validasi Anda logika yang menjelaskan cara menafsirkan respons tersebut.

Jika respons Address Validation API berisi penanda berikut, Anda harus dapat meyakini bahwa alamat input memiliki kualitas hasil:

• Penanda addressComplete di Verdict objek true adalah
• validationGranularity dalam Verdict objek adalah PREMISE atau SUB_PREMISE
• Tidak ada AddressComponent ditandai sebagai:
  • Inferred(Catatan: inferred=truedapat terjadi jika addressComplete=true)
  • spellCorrected
  • replaced
  • unexpected, dan
• confirmationLevel: Tingkat konfirmasi di AddressComponent ditetapkan keCONFIRMEDatauUNCONFIRMED_BUT_PLAUSIBLE

Jika respons API tidak berisi penanda di atas, berarti alamat input cenderung berkualitas buruk, dan Anda dapat menyimpan tanda di cache dalam database untuk itu. Tanda dalam cache menunjukkan bahwa alamat secara keseluruhan berkualitas buruk, sementara penanda yang lebih rinci seperti Dikoreksi Ejaan menunjukkan jenis untuk mengatasi masalah kualitas. Pada interaksi pelanggan berikutnya dengan alamat yang ditandai berkualitas buruk, Anda dapat memanggil Address Validation API dengan alamat IPv6 Address Validation API akan menampilkan alamat yang dikoreksi yang dapat ditampilkan menggunakan prompt UI. Setelah pelanggan menerima alamat yang telah diformat Anda dapat membuat cache yang berikut dari respons:

• formattedAddress
• postalAddress
• addressComponent componentNamesatau
• UspsData standardizedAddress

Mengimplementasikan validasi Alamat headless

Catatan: Apa itu headless? Perangkat lunak yang dapat bekerja pada perangkat tanpa antarmuka pengguna grafis, seperti skrip yang dijalankan sisi server atau baris perintah. Kami akan menggunakan istilah ini untuk menjelaskan kapan software digunakan tanpa GUI.

Berdasarkan diskusi di atas:

• Sering kali, beberapa bagian respons perlu di-cache dari Validation API untuk alasan bisnis.
• Namun, Persyaratan Layanan Layanan di Google Maps Platform membatasi data yang dapat di-cache.

Di bagian berikut, kita akan membahas proses dua langkah tentang cara mematuhi ke Persyaratan Layanan dan menerapkan validasi alamat bervolume tinggi.

Langkah 1:

Pada langkah pertama, kita akan mempelajari cara menerapkan alamat volume tinggi skrip validasi dari pipeline data yang ada. Proses ini akan memungkinkan Anda untuk menyimpan kolom tertentu dari respons Address Validation API dalam Persyaratan Dengan cara yang sesuai dengan layanan.

Diagram A: Diagram berikut menunjukkan bagaimana pipeline data dapat ditingkatkan dengan logika Validasi Alamat Volume Tinggi.

Menurut Persyaratan Layanan, Anda dapat meng-cache data berikut dari addressComponent:

• confirmationLevel
• inferred
• spellCorrected
• replaced
• unexpected

Jadi, selama langkah implementasi ini, kita akan meng-cache hal yang disebutkan di atas kolom terhadap UserID.

Untuk informasi selengkapnya, lihat detail tentang data aktual struktur.

Langkah 2:

Pada langkah 1, kami mengumpulkan umpan balik bahwa beberapa alamat dalam {i>dataset<i} input mungkin tidak berkualitas tinggi. Pada langkah berikutnya, kami akan mengambil alamat yang ditandai ini dan menunjukkannya kepada pengguna lalu mendapatkan izin mereka untuk memperbaiki alamat IPv6

Diagram B: Diagram ini menunjukkan bagaimana integrasi pengguna secara menyeluruh alur persetujuan bisa terlihat seperti:

1. Saat pengguna login, periksa terlebih dahulu apakah Anda telah meng-cache flag validasi dalam sistem Anda.
2. Jika ada penanda, Anda harus menampilkan UI kepada pengguna untuk memperbaiki dan memperbarui alamatnya.
3. Anda dapat memanggil lagi Address Validation API dengan ID yang diupdate atau dan menyajikan alamat yang sudah dikoreksi kepada pengguna untuk dikonfirmasi.
4. Jika alamatnya berkualitas baik, Address Validation API akan menampilkan formattedAddress.
5. Anda dapat menunjukkan alamat itu kepada pengguna jika telah dikoreksi dibuat, atau diam-diam menerima jika tidak ada koreksi.
6. Setelah pengguna menerima, Anda dapat meng-cache formattedAddress di database.

Catatan: Setelah alur kerja ini selesai, validationFlags yang di-cache harus dihapus.

Kesimpulan

Validasi Alamat Volume Tinggi adalah kasus penggunaan umum yang kemungkinan Anda temui dalam banyak aplikasi. Dokumen ini mencoba mendemonstrasikan beberapa skenario dan sebuah pola desain tentang cara menerapkan solusi seperti itu sesuai dengan kebijakan Google Maps Persyaratan Layanan Platform.

Kami telah menulis lebih lanjut implementasi referensi untuk Alamat Volume Tinggi Validasi sebagai library open source di GitHub. Periksa untuk memulai membangun solusi dengan Validasi Alamat Volume Tinggi dengan cepat. Baca juga artikel tentang pola desain tentang cara menggunakan pustaka itu dalam berbagai skenario.

Langkah Berikutnya

Download panduan Tingkatkan checkout, pengiriman, dan operasi dengan alamat yang tepercaya Laporan resmi dan lihat Meningkatkan checkout, pengiriman, dan operasi dengan Alamat Validasi Webinar.

Saran bacaan lebih lanjut:

• Penerapan Validasi Alamat Bervolume Tinggi
• Library Python di github
• Pelajari demo Alamat Validasi

Kontributor

Google mengelola artikel ini. Kontributor berikut awalnya yang menulisnya.
Penulis utama:

Valve Henrik | Engineer Solusi
Thomas Anglaret | Solusi Teknisi
Sarthak Ganguly | Solusi Insinyur