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

เอกสารนี้อธิบายกระบวนการสร้างระบบตรวจสอบที่อยู่เพื่อ จัดการการตอบกลับต่างๆ จาก 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 ได้ที่จัดการที่อยู่ในสหรัฐอเมริกา

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