Menambahkan sub-lahan ke alamat - contoh (khusus AS)
Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Dokumen ini menjelaskan sejumlah skenario dunia nyata saat Address Validation API memberikan sinyal respons yang memerlukan perilaku tambahkan sub-lokasi dari sistem Anda. Sinyal ini hanya tersedia untuk alamat di Amerika Serikat.
Lihat Contoh alur kerja di
Membangun logika validasi Anda untuk mendapatkan konteks.
Contoh umum: menambahkan sub-lokasi
Skenario ini menggambarkan alamat yang mungkin meminta pelanggan untuk menambahkan nomor unit ke alamat.
Alamat dimasukkan
Wilayah
1450 Brickell Avenue, Miami, FL 33131-4065
US
Putusan untuk alamat yang tidak memiliki sub-lokasi
Contoh berikut mencakup situasi saat verdict menunjukkan masalah kualitas alamat yang memerlukan penyelidikan lebih lanjut. Contoh ini juga
mengilustrasikan cara logika Anda dapat berpindah dari putusan ke komponen alamat
untuk mendapatkan gambaran yang lebih lengkap guna meningkatkan logika sistem Anda.
Sub-ruang yang tidak ada serta komponen yang disimpulkan dan diganti
Contoh ini menggambarkan entri alamat AS dengan lokalitas yang tidak ada dan kode pos yang salah.
Alamat dimasukkan
Wilayah
1450 Brickell Avenue, FL 33132-4065
US
Putusan untuk sub-lokasi yang tidak ada serta komponen yang disimpulkan dan diganti
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Informasi yang saya butuhkan tidak ada","missingTheInformationINeed","thumb-down"],["Terlalu rumit/langkahnya terlalu banyak","tooComplicatedTooManySteps","thumb-down"],["Sudah usang","outOfDate","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Masalah kode / contoh","samplesCodeIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-08-31 UTC."],[],[],null,["This document describes a number of real-world scenarios where the\nAddress Validation API provides response signals that warrant an *add subpremises*\nbehavior from your system. These signals are only available for US addresses.\nSee [Example workflows](/maps/documentation/address-validation/build-validation-logic#example-workflows) in\n**Build your validation logic** for context.\n| **Note:** The examples here are illustrative, but don't cover all scenarios.\n\nCommon example: add subpremises\n\nThis scenario illustrates an address in which your system might prompt a\ncustomer to add a unit number to the address.\n\n| Address entered | Region |\n|--------------------------------------------|--------|\n| 1450 Brickell Avenue, Miami, FL 33131-4065 | US |\n\nVerdict for an address missing a subpremises\n\nThe example below highlights the important signal. \n\n {\n \"inputGranularity\": \"PREMISE\",\n \"validationGranularity\": \"PREMISE\",\n \"geocodeGranularity\": \"PREMISE\",\n \"possibleNextAction\": \"CONFIRM_ADD_SUBPREMISES\"\n }\n\n| **Action:** For this address, you might prompt your user to add a unit number.\n\nEdge case example: add subpremises\n\nThe following example covers a situation in which the `verdict` indicates\naddress quality issues that warrant further investigation. This examples also\nillustrates how your logic can travel from the verdict to the address components\nto obtain a more complete picture in order to enhance your system logic.\n\nMissing subpremises and inferred and replaced components\n\nThis example illustrates entry of a US address with a missing locality and an\nincorrect postal code.\n\n| Address entered | Region |\n|-------------------------------------|--------|\n| 1450 Brickell Avenue, FL 33132-4065 | US |\n\nVerdict for a missing subpremises and inferred and replaced components \n\n {\n \"inputGranularity\": \"PREMISE\",\n \"validationGranularity\": \"PREMISE\",\n \"geocodeGranularity\": \"PREMISE\",\n \"hasInferredComponents\": true,\n \"hasReplacedComponents\": true,\n \"possibleNextAction\": \"CONFIRM_ADD_SUBPREMISES\"\n }\n\nFurther investigation of the address components reveals that the locality has\nbeen inferred, and the postal code has been replaced. \n\n {\n \"componentName\": {\n \"text\": \"33131\",\n }\n \"componentType\": \"postal_code\",\n \"confirmationLevel\": \"CONFIRMED\",\n \"replaced\": true\n },\n {\n \"componentName\": {\n \"text\": \"Miami\",\n \"languageCode\": \"en\"\n }\n \"componentType\": \"locality\",\n \"confirmationLevel\": \"CONFIRMED\",\n \"inferred\": true\n }\n\n| **Action:** For this address, you might prompt your user to add a unit number, or prompt them to review the entire address."]]
