สร้างตรรกะการตรวจสอบ

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

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

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

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

เอกสารนี้จะช่วยคุณแก้ไขระบบเพื่อวิเคราะห์การตอบกลับจาก 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 อย่างสำหรับระบบของคุณ

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

การตอบกลับจาก verdict บ่งชี้ว่ามีข้อมูลสำคัญที่ขาดหายไป ซึ่งควรระบุ ที่อยู่ที่ API แสดงผลอาจ มีคุณภาพไม่เพียงพอสำหรับการจัดส่ง

เวิร์กโฟลว์

  1. ตรวจสอบคอมโพเนนต์ที่อยู่หากจำเป็น
  2. แจ้งให้ลูกค้าแก้ไขปัญหาเกี่ยวกับที่อยู่
  3. ขอการตรวจสอบที่อยู่ที่อัปเดต
  4. ดำเนินการต่อโดยใช้ที่อยู่

สัญญาณการตัดสิน

มีเงื่อนไขต่อไปนี้อย่างน้อย 1 ข้อ
ยืนยันที่อยู่

การตอบกลับจาก verdict บ่งชี้ว่าที่อยู่สามารถจัดส่งได้ แต่มีการเปลี่ยนแปลงที่อยู่ที่ป้อนไว้เดิม เช่น การอนุมานข้อมูลที่ สะกดผิดหรือข้อมูลที่ยืนยันได้

เวิร์กโฟลว์

  1. ต้องมีการแก้ไข
    1. ตรวจสอบคอมโพเนนต์ที่อยู่หากจำเป็น
    2. ขอการตรวจสอบที่อยู่ที่อัปเดต
    3. ดำเนินการต่อโดยใช้ที่อยู่
  2. ไม่ต้องมีการแก้ไข
  3. ดำเนินการต่อโดยใช้ที่อยู่

สัญญาณการตัดสิน

มีเงื่อนไขต่อไปนี้ทั้งหมด
ยอมรับที่อยู่

การตอบกลับจาก Address Validation API บ่งชี้ว่าที่อยู่มีคุณภาพยอดเยี่ยม

เวิร์กโฟลว์

ดำเนินการต่อโดยใช้ที่อยู่ที่แสดงผล

สัญญาณการตัดสิน

มีเงื่อนไขต่อไปนี้ทั้งหมด

  • validationGranularity มี PREMISE หรือดีกว่า
  • addressComplete เป็น true.
  • ไม่มี คอมโพเนนต์ที่อนุมานหรือแทนที่

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

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

คำแนะนำ รายละเอียด
ระดับความเสี่ยง

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

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

เช่น หากที่อยู่มีหมายเลขถนนที่ยังไม่ได้รับการยืนยัน คุณก็ยังยอมรับที่อยู่นั้นได้ ในทางกลับกัน หากการดำเนินธุรกิจของคุณต้องใช้ที่อยู่ที่แม่นยำมากขึ้น คุณอาจแจ้งให้ผู้ใช้ป้อนที่อยู่ใหม่ ดูตัวอย่างที่ อาจอยู่ในหมวดหมู่ใดหมวดหมู่หนึ่งได้ที่หมายเลขถนนที่ยังไม่ได้รับการยืนยันซึ่งไม่ใช่ของสหรัฐอเมริกา ในส่วนยอมรับที่อยู่ - ตัวอย่าง
ยอมรับที่อยู่

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

ในกรณีเหล่านี้ ลูกค้าอาจป้อนที่อยู่ที่ไม่มีอยู่ในระบบ เช่น ที่อยู่ของสิ่งก่อสร้างใหม่

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

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

สัญญาณการแก้ไข

Address Validation API มีสัญญาณจำนวนหนึ่งเพื่อแจ้งให้คุณทราบว่าควรแก้ไขที่อยู่หรือไม่

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

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

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

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

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

คอมโพเนนต์ที่น่าสงสัย เมื่อ Enum ระดับการยืนยันของคอมโพเนนต์เป็น UNCOMFIRMED_AND_SUSPICIOUS แสดงว่าคอมโพเนนต์นั้นน่าจะไม่ถูกต้อง
คอมโพเนนต์ที่ยังไม่ได้รับการแก้ไข An unresolvedToken คือส่วนหนึ่งของอินพุตที่ระบบไม่รู้จักว่าเป็นส่วนที่ถูกต้องของที่อยู่

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

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

dpvConfirmation N, D หรือว่าง

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

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

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

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

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

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

Address Validation API มีสัญญาณจำนวนหนึ่งเพื่อแจ้งให้คุณทราบว่าควรยืนยันที่อยู่หรือไม่

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

A validationGranularity ที่มีค่า ROUTE หรือดีกว่าถือว่ายอมรับได้ แต่ PREMISE หรือ SUBPREMISE จะเป็นสัญญาณที่ชัดเจนกว่าว่าที่อยู่สามารถจัดส่งได้

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

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

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

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

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

dpvConfirmation S

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

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

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

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

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

Address Validation API มีสัญญาณจำนวนหนึ่งเพื่อแจ้งให้คุณทราบว่าควรยืนยันที่อยู่หรือไม่

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

validationGranularity ที่มีค่า PREMISE หรือดีกว่าถือว่ายอมรับได้ แต่ในบางกรณี ROUTE ยังคงบ่งชี้ว่าที่อยู่สามารถจัดส่งได้

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

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

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

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

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

dpvConfirmation Y

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

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