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

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

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

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

จุดประสงค์หลัก

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

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

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

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

dpvConfirmation S

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

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

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

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

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

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

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

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

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

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

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

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

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

dpvConfirmation Y

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

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