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

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

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

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

ขั้นตอนการทำงาน

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

สัญญาณคำตัดสิน

รายการใดก็ได้ต่อไปนี้

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

การตอบกลับจาก 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 ยังมีสัญญาณอื่นๆ เพื่อช่วยวินิจฉัยปัญหาที่เฉพาะเจาะจงด้วย

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

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

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

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

โปรดดูรายละเอียดเกี่ยวกับ dpvConfirmation ที่หัวข้อจัดการที่อยู่ของสหรัฐอเมริกา

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

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

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

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

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

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

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

validationGranularity ที่มีค่า ROUTE ขึ้นไปถือว่ายอมรับได้ แต่ PREMISE หรือ SUBPREMISE จะแสดงถึงความสามารถในการนำส่งได้ดีกว่า

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

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

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

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

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

dpvConfirmation S

โปรดดูรายละเอียดเกี่ยวกับ dpvConfirmation ที่หัวข้อจัดการที่อยู่ของสหรัฐอเมริกา

ตอบกลับ มีช่อง missingComponentTypes ที่มีค่าเป็น subpremise

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

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

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

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

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

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

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

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

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

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

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

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

dpvConfirmation Y

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

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