สร้างตรรกะการตรวจสอบความถูกต้อง

เอกสารนี้จะอธิบายกระบวนการสร้างระบบตรวจสอบที่อยู่เพื่อ จัดการคำตอบที่หลากหลายจาก Address Validation API ซึ่งครอบคลุมถึงวิธีการ สร้างตรรกะของคุณเพื่อใช้คำตอบอย่างถูกต้อง เพื่อตรวจสอบสัญญาณอื่นๆ จาก API รวมถึงช่วงเวลาและวิธีแจ้งให้ลูกค้าสอบถามข้อมูลเพิ่มเติม

โดยทั่วไปการตอบกลับของ API จะกำหนดวิธีที่ระบบของคุณควรดำเนินการดังต่อไปนี้ จัดการที่อยู่:

• handyman แก้ไข - ที่อยู่มีคุณภาพต่ำ คุณควรแจ้งขอข้อมูลเพิ่มเติม
• edit ยืนยัน ที่อยู่มีคุณภาพสูง แต่มี เปลี่ยนแปลงจากที่อยู่ที่ป้อน คุณอาจแจ้งให้ ยืนยัน
• check ยอมรับ ที่อยู่มีคุณภาพสูง คุณสามารถ ยอมรับที่อยู่ที่ระบุ

วัตถุประสงค์หลัก

เอกสารนี้จะช่วยให้คุณแก้ไขระบบเพื่อวิเคราะห์การตอบกลับ API ได้ดีที่สุด ระบุการดำเนินการถัดไปที่จะทำกับที่อยู่ที่ระบุ ดังต่อไปนี้ Pseudocode จะแสดงขั้นตอนที่เป็นไปได้

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 อย่างสำหรับระบบของคุณ

1. เวิร์กโฟลว์ที่จะใช้ตามลักษณะการทำงานของการแก้ไข ยืนยัน และยอมรับ
2. สัญญาณแรกที่ต้องตรวจสอบจากคำตอบ สัญญาณ ที่อธิบายไว้ที่นี่มาจากพร็อพเพอร์ตี้ verdict และไม่ใช่รายการเดียว สัญญาณที่ต้องตรวจสอบ แต่ระบุตัวบ่งชี้เริ่มต้นของที่อยู่ ของคุณ ลักษณะการทํางานแต่ละประเภทสอดคล้องกับส่วนในเอกสารนี้ เพื่ออธิบายสัญญาณเพิ่มเติมที่คุณอาจต้องตรวจสอบด้วย

หลักเกณฑ์การใช้งาน

เมื่อออกแบบวิธีที่ระบบของคุณตอบสนองต่อสัญญาณจาก Address Validation API คำแนะนำต่อไปนี้จะช่วยให้คุณสร้างการตอบสนองที่มีประสิทธิภาพมากขึ้น โมเดล แต่นี่เป็นเพียงคำแนะนำ โปรดทราบว่า ควรเหมาะสมกับโมเดลธุรกิจของคุณ

แก้ไขที่อยู่

แก้ไขที่อยู่เมื่อผลการค้นหาระบุอย่างชัดเจนว่าที่อยู่ดังกล่าวไม่ใช่ที่อยู่จริง ที่สามารถส่งมอบได้ จากนั้น ระบบของคุณสามารถแจ้งให้ลูกค้าระบุข้อมูล หลังจากนั้นคุณจะต้องออกเวิร์กโฟลว์ใหม่เพื่อให้ได้รับ อีเมล

แก้ไขสัญญาณ

Address Validation API จะแสดงสัญญาณหลายอย่างให้คุณทราบหาก ควรแก้ไข

1. รายละเอียดการตรวจสอบและคอมโพเนนต์ที่ขาดหายไป

สัญญาณทั้ง 2 อย่างนี้เป็นตัวบ่งชี้ที่ดีที่สุดสำหรับที่อยู่ที่เป็นปัญหา

• เมื่อใดก็ตามที่ฟิลด์ validationGranularity คือ OTHER ระบบควร ตรวจสอบสัญญาณองค์ประกอบที่อยู่เพื่อดูข้อมูลเพิ่มเติมเกี่ยวกับตำแหน่งของข้อผิดพลาด ที่เกิดขึ้นและวิธีแก้ไข
• เมื่อใดก็ตามที่ออบเจ็กต์ address ที่ประมวลผลหลังแสดงผลแสดง missingComponentTypes ระบบควรตรวจหาคอมโพเนนต์นั้น คอมโพเนนต์ที่ขาดหายไปจะแสดงที่อยู่ที่ไม่สมบูรณ์และนำส่งไม่ได้ด้วย

2. สัญญาณอื่นๆ

นอกจากนี้ API การตรวจสอบที่อยู่ยังมีสัญญาณอื่นๆ เพื่อช่วย วินิจฉัยปัญหาที่เฉพาะเจาะจง

3. สัญญาณที่อยู่ในสหรัฐอเมริกา

ฟิลด์บางฟิลด์ที่ใช้ได้เฉพาะกับที่อยู่ในสหรัฐฯ จะให้สัญญาณที่เป็นประโยชน์ว่า จัดส่งไม่ได้และควรแก้ไข สำหรับที่อยู่ที่ต้องใช้ คุณควรเห็นสิ่งต่อไปนี้

ดูรายละเอียดเกี่ยวกับ dpvConfirmation ได้ที่ จัดการที่อยู่ในสหรัฐอเมริกา

แก้ไขตัวอย่างที่อยู่

ยืนยันที่อยู่

คุณยืนยันที่อยู่เมื่อคำตัดสินระบุว่า Address Validation API อนุมานหรือเปลี่ยนแปลงเกี่ยวกับคอมโพเนนต์ต่างๆ เพื่อสร้าง ที่อยู่ที่ยืนยันแล้ว ในกรณีเหล่านี้ คุณมีที่อยู่สำหรับนำส่ง แต่ มั่นใจว่าที่อยู่ผลลัพธ์จะเป็นที่อยู่ตามที่ ลูกค้า

ในการมอบพรอมต์ที่ถูกต้องให้ลูกค้า ตรรกะของคุณจะระบุ คอมโพเนนต์ที่บริการแจ้งว่าไม่เหมาะสมเพื่อพิจารณาการดำเนินการหรือแจ้งว่า API ไม่เหมาะสม ใช้กับคอมโพเนนต์ เช่น inferred, replaced หรือ spellCorrected ดู AddressComponent ในข้อมูลอ้างอิง

ยืนยันสัญญาณ

Address Validation API จะแสดงสัญญาณหลายอย่างให้คุณทราบหาก ที่อยู่ต้องได้รับการยืนยัน

1. รายละเอียดการตรวจสอบ

รับ validationGranularity ตั้งแต่ ROUTE ขึ้นไป ก็ได้ แต่ PREMISE หรือ SUBPREMISE จะให้สัญญาณที่ชัดเจนกว่าการนำส่งเนื้อหา

2. สัญญาณอื่นๆ

เมื่อตัดสินใจยืนยันรายการที่อยู่กับลูกค้า ผลการตัดสิน ระบุองค์ประกอบต่อไปนี้เพื่อกำหนดองค์ประกอบที่ต้องตรวจสอบ

3. สัญญาณที่อยู่ในสหรัฐอเมริกา

บางช่องที่ใช้เฉพาะกับที่อยู่ในสหรัฐอเมริกาจะระบุว่าตรรกะของคุณควร ยืนยันรายละเอียดกับลูกค้า เป็นไปตามข้อใดข้อหนึ่งต่อไปนี้

ตัวอย่างการยืนยันที่อยู่

ยอมรับที่อยู่

คุณยอมรับที่อยู่เมื่อคำตัดสินให้ความมั่นใจในระดับสูงว่า ที่อยู่ดังกล่าวนำส่งได้และสามารถใช้ได้โดยไม่ต้องมีการโต้ตอบเพิ่มเติมจากลูกค้า ในกระบวนการปลายทาง

ยอมรับสัญญาณ

Address Validation API จะแสดงสัญญาณหลายอย่างให้คุณทราบหาก ที่อยู่ต้องได้รับการยืนยัน

1. รายละเอียดการตรวจสอบ

ยอมรับ validationGranularity ที่ระดับ PREMISE หรือดีกว่า แต่ในบางกรณี กรณี ROUTE ยังคงแสดงที่อยู่สำหรับนำส่ง

2. สัญญาณอื่นๆ

การตัดสินสำหรับที่อยู่คุณภาพสูงควรระบุข้อมูลต่อไปนี้ด้วย

• ไม่มีข้อมูลที่ถูกแทนที่ ในกรณีนี้คือ hasReplacedComponents: FALSE
• ไม่มีคอมโพเนนต์ที่สรุป ในกรณีนี้คือ hasInferredComponents: FALSE

3. สัญญาณที่อยู่ในสหรัฐอเมริกา

บางช่องที่ใช้เฉพาะกับที่อยู่ในสหรัฐอเมริกาจะระบุว่าที่อยู่ที่มีคุณภาพสูง ที่สามารถนำส่งไปได้ สำหรับที่อยู่ในสหรัฐอเมริกาที่ยอมรับได้ คุณจะเห็น ดังต่อไปนี้:

ยอมรับตัวอย่างที่อยู่