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

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

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

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

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 ได้ที่หัวข้อจัดการที่อยู่ในสหรัฐอเมริกา

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