เอกสารนี้อธิบายกระบวนการสร้างระบบตรวจสอบที่อยู่เพื่อ จัดการการตอบกลับต่างๆ จาก Address Validation API โดยจะครอบคลุมวิธีสร้างตรรกะเพื่อใช้การตอบกลับอย่างถูกต้อง วิธีตรวจสอบ สัญญาณอื่นๆ จาก API รวมถึงเวลาและวิธีแจ้งให้ลูกค้าให้ข้อมูลเพิ่มเติม
โดยทั่วไป การตอบกลับจาก API จะกำหนดวิธีต่อไปนี้ที่ระบบของคุณควรใช้จัดการที่อยู่
- แก้ไข - ที่อยู่มีคุณภาพต่ำ คุณควรขอข้อมูลเพิ่มเติม
- ยืนยัน - ที่อยู่มีคุณภาพสูง แต่มีการเปลี่ยนแปลงจากที่อยู่ที่ป้อน คุณอาจได้รับแจ้งให้ ยืนยัน
- ยอมรับ - ที่อยู่มีคุณภาพสูง คุณ ยอมรับที่อยู่ที่ระบุได้
วัตถุประสงค์หลัก
เอกสารนี้จะช่วยคุณปรับเปลี่ยนระบบเพื่อวิเคราะห์การตอ��กลับของ API ได้ดีที่สุด และ พิจารณาการดำเนินการถัดไปที่จะทำกับที่อยู่ที่ระบุ รหัสเทียมต่อไปนี้แสดงขั้นตอนที่เป็นไปได้
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.
ตรรกะที่แน่นอนจะขึ้นอยู่กับสถานการณ์ของคุณ ดูรายละเอียดเพิ่มเติมได้ที่คำแนะนำในการติดตั้งใช้งาน คุณยังใช้การติดตั้งใช้งานแบบโอเพนซอร์สของตรรกะนี้ได้ด้วย ซึ่งอยู่ในไลบรารีคอมโพเนนต์แบบขยาย
ภาพรวมของเวิร์กโฟลว์
ตารางด้านล่างสรุปการดำเนินการ 2 อย่างสำหรับระบบของคุณ
- เวิร์กโฟลว์ที่จะใช้ตามลักษณะการทำงานของแก้ไข ยืนยัน ยอมรับ
- สัญญาณแรกที่ต้องตรวจสอบจากคำตอบ สัญญาณที่อธิบายไว้ที่นี่มาจากพร็อพเพอร์ตี้
verdict
และไม่ใช่สัญญาณเดียวที่ต้องตรวจสอบ แต่เป็นตัวบ่งชี้เบื้องต้นเกี่ยวกับคุณภาพของที่อยู่ พฤติกรรมแต่ละประเภทจะสอดคล้องกับส่วนในเอกสารนี้ ซึ่งอธิบายสัญญาณเพิ่มเติมที่คุณอาจต้องตรวจสอบด้วย
ลักษณะการทำงานของระบบ | |||
---|---|---|---|
แก้ไขที่อยู่ |
คำตอบจาก
|
||
ยืนยันที่อยู่ |
คำตอบจาก
|
||
ยอมรับที่อยู่ |
การตอบกลับของ Address Validation API จะระบุที่อยู่ที่มีคุณภาพยอดเยี่ยม
|
คำแนะนำในการติดตั้งใช้งาน
เมื่อออกแบบวิธีที่ระบบตอบสนองต่อสัญญาณการตรวจสอบความถูกต้องของที่อยู่ คำแนะนำต่อไปนี้จะช่วยให้คุณสร้างโมเดลการตอบสนองที่มีประสิทธิภาพมากขึ้นได้ อย่างไรก็ตาม นี่เป็นเพียงคำแนะนำเท่านั้น โปรดทราบว่าการติดตั้งใช้งานควรเหมาะกับรูปแบบธุรกิจของคุณ
คำแนะนำ | รายละเอียด | |
---|---|---|
ระดับความเสี่ยง |
โปรดคำนึงถึงระดับ ความคลาดเคลื่อนสำหรับสถานการณ์ของคุณเมื่อพิจารณาว่าจะแจ้งให้ แก้ไขหรือยอมรับที่อยู่ที่ป้อน |
API การตรวจสอบที่อยู่จะแสดงสัญญาณต่างๆ ที่คุณสามารถรวมเข้ากับระดับความเสี่ยงเพื่อเพิ่มประสิทธิภาพกระบวนการตรวจสอบ ได้ เช่น หากที่อยู่มีหมายเลขถนนที่ยังไม่ได้รับการยืนยัน คุณก็ยังยอมรับได้ ในทางกลับกัน หากการดำเนินธุรกิจของคุณต้องใช้ ความแม่นยำของที่อยู่ที่มากขึ้น คุณอาจแจ้งให้ผู้ใช้ทราบ ดูตัวอย่างที่อาจ อยู่ในหมวดหมู่ใดหมวดหมู่หนึ่งได้ที่หมายเลขถนนที่ไม่ได้ยืนยันในประเทศที่ไม่ใช่สหรัฐอเมริกา ในยอมรับที่อยู่ - ตัวอย่าง |
ยอมรับที่อยู่ |
แนวทางปฏิบัติแนะนำคือการอนุญาตให้ระบบยอมรับรายการเดิม หา��ลูกค้าไม่ตอบกลับข้อความแจ้ง |
ในกรณีเหล่านี้ ลูกค้าอาจป้อนที่อยู่ที่ไม่ได้อยู่ในระบบ เช่น ที่อยู่ของสถานที่ก่อสร้างใหม่ |
แก้ไขที่อยู่
แก้ไขที่อยู่เมื่อผลการค้นหาระบุอย่างชัดเจนว่าที่อยู่นั้นนำส่งไม่ได้ จากนั้นระบบจะแจ้งให้ลูกค้าให้ข้อมูลที่จำเป็น หลังจากนั้นคุณจะออกเวิร์กโฟลว์อีกครั้งเพื่อรับที่อยู่ที่จัดส่งได้
แก้ไขสัญญาณ
Address Validation API มีสัญญาณหลายอย่างที่ช่วยให้คุณทราบว่าควรแก้ไขที่อยู่หรือไม่
1. ระดับความละเอียดของการตรวจสอบความถูกต้องและคอมโพเนนต์ที่ขาดหายไป
สัญญาณ 2 อย่างนี้เป็นตัวบ่งชี้ที่ดีที่สุดว่าที่อยู่มีปัญหา
- เมื่อใดก็ตามที่ฟิลด์
validationGranularity
เป็นOTHER
ระบบควรตรวจสอบสัญญาณของคอมโพเนนต์ที่อยู่ เพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับตำแหน่งที่เกิดข้อผิดพลาดและวิธีแก้ไข - เมื่อใดก็ตามที่ออบเจ็กต์
address
ที่ประมวลผลภายหลังแสดงผลฟิลด์missingComponentTypes
ระบบของคุณควรตรวจสอบคอมโพเนนต์นั้น นอกจากนี้ หากไม่มีส่วนประกอบ ที่อยู่จะถือว่าไม่สมบูรณ์และนำส่งไม่ได้
2. สัญญาณอื่นๆ
นอกจากนี้ Address Validation API ยังมีสัญญาณอื่นๆ ที่ช่วย วินิจฉัยปัญหาที่เฉพาะเจาะจงด้วย
คอมโพเนนต์ที่น่าสงสัย | เมื่อการแจงนับระดับการยืนยันสำหรับคอมโพเนนต์เป็น
UNCOMFIRMED_AND_SUSPICIOUS แสดงว่าคอมโพเนนต์นั้น
อาจไม่ถูกต้อง
|
---|---|
คอมโพเนนต์ที่ยังไม่ได้รับการแก้ไข | unresolvedToken เป็นส่วนหนึ่งของอินพุตที่ระบบไม่รู้จักว่าเป็นส่วนที่ถูกต้องของที่อยู่ |
3. สัญญาณที่อยู่ของสหรัฐอเมริกา
ฟิลด์บางรายการที่ใช้ได้กับที่อยู่ในสหรัฐอเมริกาเท่านั้นจะให้สัญญาณที่เป็นประโยชน์ว่า ที่อยู่นำส่งไม่ได้และควรแก้ไข สำหรับที่อยู่ที่ต้อง แก้ไข คุณควรเห็นสิ่งต่อไปนี้
dpvConfirmation
|
N , D หรือว่างก็ได้
|
---|
ดูรายละเอียดเกี่ยวกับ dpvConfirmation
ได้ที่
จัดการที่อยู่ในสหรัฐอเมริกา
ยืนยันที่อยู่
คุณยืนยันที่อยู่เมื่อผลการตัดสินระบุว่า Address Validation API อนุมานหรือทำการเปลี่ยนแปลงคอมโพเนนต์ของที่อยู่เพื่อสร้าง ที่อยู่ที่ผ่านการตรวจสอบแล้ว ในกรณีเหล่านี้ คุณมีที่อยู่ที่นำส่งได้ แต่ต้องการความมั่นใจมากขึ้นว่าที่อยู่ที่ได้จะเป็นที่อยู่ที่ลูกค้าต้องการ
ตรรกะของคุณจะระบุคอมโพเนนต์ที่บริการแจ้งว่าไม่เหมาะสมเพื่อพิจารณาว่า API ใช้การดำเนินการหรือการแจ้งว่าไม่เหมาะสมใดกับคอมโพเนนต์ เช่น inferred
, replaced
หรือ spellCorrected
เพื่อให้ลูกค้าได้รับข้อความแจ้งที่ถูกต้อง
ดู AddressComponent ในข้อมูลอ้างอิง
ยืนยันสัญญาณ
Address Validation API มีสัญญาณหลายอย่างที่ช่วยให้คุณทราบว่าควรยืนยันที่อยู่หรือไม่
1. ความละเอียดของการตรวจสอบ
validationGranularity
ROUTE
ขึ้นไปถือว่าใช้ได้ แต่ PREMISE
หรือ SUBPREMISE
จะให้สัญญาณที่แรงกว่าในเรื่องความสามารถในการนำส่ง
2. สัญญาณอื่นๆ
เมื่อตัดสินใจที่จะยืนยัน��ายการที่อยู่กับลูกค้า คำตัดสินยังระบุข้อมูลต่อไปนี้เพื่อพิจารณาว่าควรตรวจสอบคอมโพเนนต์ใด
ข้อมูลที่อนุมาน | เมื่อฟิลด์
hasInferredComponents เป็น true แสดงว่า
API ได้ป้อนข้อมูลที่รวบรวมจากคอมโพเนนต์ที่อยู่อื่นๆ
|
---|---|
ข้อมูลที่ถูกแทนที่ | เมื่อฟิลด์
hasReplacedComponents เป็น true API จะแทนที่ข้อมูลที่ป้อนด้วยข้อมูลที่ API พิจารณาว่าทำให้ที่อยู่ถูกต้อง
|
3. สัญญาณที่อยู่ของสหรัฐอเมริกา
ฟิลด์บางช่องที่ใช้ได้กับที่อยู่ในสหรัฐอเมริกาเท่านั้นระบุว่าตรรกะของคุณควร ยืนยันรายละเอียดกับลูกค้า กรณีใดกรณีหนึ่งต่อไปนี้
dpvConfirmation
|
S
ดูรายละเอียดเกี่ยวกับ |
---|---|
การตอบกลับที่อยู่ | มีฟิลด์ missingComponentTypes ที่มีค่า
subpremise
|
ยอมรับที่อยู่
คุณยอมรับที่อยู่เมื่อผลการวินิจฉัยมีความมั่นใจสูงว่า ที่อยู่นั้นนำส่งได้และสามารถใช้ได้โดยไม่ต้องมีการโต้ตอบกับลูกค้าเพิ่มเติม ในกระบวนการดาวน์สตรีม
ยอมรับสัญญาณ
Address Validation API มีสัญญาณหลายอย่างที่ช่วยให้คุณทราบว่าควรยืนยันที่อยู่หรือไม่
1. ความละเอียดของการตรวจสอบ
validationGranularity
PREMISE
หรือดีกว่านั้นเป็นที่ยอมรับ แต่ในบางกรณี ROUTE
ยังคงระบุที่อยู่ที่นำส่งได้
2. สัญญาณอื่นๆ
คำตัดสินสำหรับที่อยู่ที่มีคุณภาพสูงควรระบุข้อมูลต่อไปนี้ด้วย
- ไม่มีข้อมูลที่ถูกแทนที่ ในกรณีนี้คือ
hasReplacedComponents: FALSE
- ไม่มีคอมโพเนนต์ที่อนุมาน ในกรณีนี้คือ
hasInferredComponents: FALSE
3. สัญญาณที่อยู่ของสหรัฐอเมริกา
ฟิลด์บางรายการที่ใช้ได้กับที่อยู่ในสหรัฐอเมริกาเท่านั้นจะระบุที่อยู่ที่มีคุณภาพสูง ซึ่งนำส่งได้ หากที่อยู่ในสหรัฐอเมริกาเป็นที่อยู่ที่ยอมรับ���ด้ คุณควรเห็นข้อมูลต่อไปนี้
dpvConfirmation
|
Y
ดูรายละเอียดเกี่ยวกับ
|
---|