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

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

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

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

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

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

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

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

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

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

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

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

dpvConfirmation S

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

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

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

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

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

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

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

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

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

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

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

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

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

dpvConfirmation Y

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

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