สร้างตรรกะการตรวจสอบความถูกต้อง

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

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

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

วัตถุประสงค์หลัก

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

if (verdict.possibleNextAction == FIX)
    Prompt the user to fix the address.
else if (verdict.possibleNextAction == CONFIRM_ADD_SUBPREMISES)
    Prompt the user to add a unit number.
else if (verdict.possibleNextAction == CONFIRM)
    Confirm with the user that the address is correct.
else
    Continue with the address returned by the API.

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

ตัวอย่างเวิร์กโฟลว์

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

ลักษณะการทำงานของระบบ
แก้ไขที่อยู่

คำตอบจาก verdict แสดงว่าที่อยู่อาจมีปัญหาที่สำคัญ เช่น verdict.possibleNextAction คือ FIX โปรดพิจารณาแจ้งให้ลูกค้า ให้ข้อมูลเพิ่มเติม

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

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

คำตอบจาก verdict แสดงว่าที่อยู่อาจ ไม่มีสถานที่ย่อย เช่น verdict.possibleNextAction คือ CONFIRM_ADD_SUBPREMISES โปรดแจ้งให้ลูกค้า เพิ่มหมายเลขยูนิต

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

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

คำตอบจาก verdict แสดงว่าที่อยู่อาจมีปัญหาเล็กน้อย เช่น verdict.possibleNextAction คือ CONFIRM ลองแจ้งให้ลูกค้าตรวจสอบ ที่อยู่

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

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

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

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

ดำเนินการต่อโดยใช้ที่อยู่ที่ส่งคืน

ปรับแต่งตรรกะการตรวจสอบ

แม้ว่าคุณจะใช้ผลลัพธ์จากฟิลด์ verdict.possibleNextAction เพื่อ พิจารณาว่าระบบควรดำเนินการอย่างไรกับคำตอบของ API แต่คุณก็อาจ พิจารณาสร้างตรรกะที่กำหนดเอง เช่น เพื่อจัดการความต้องการเฉพาะของธุรกิจ

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

อย่างไรก็ตาม แม้ว่าคุณจะใช้เฉพาะverdict.possibleNextActionในการตัดสินใจ เกี่ยวกับขั้นตอนถัดไป สัญญาณเพิ่มเติมที่อธิบายไว้ด้านล่างก็ยังช่วยให้คุณ เข้าใจรายละเอียดเกี่ยวกับปัญหาที่อาจเกิดขึ้นกับที่อยู่ได้

การยอมรับความเสี่ยง

เมื่อออกแบบวิธีที่ระบบตอบสนองต่อสัญญาณจาก Address Validation API คำแนะนำต่อไปนี้จะช่วยให้คุณสร้างรูปแบบการตอบสนองที่มีประสิทธิภาพมากขึ้นได้ อย่างไรก็ตาม นี่เป็นเพียงคำแนะนำเท่านั้น โปรดทราบว่าการติดตั้งใช้งานควรเหมาะกับรูปแบบธุรกิจของคุณ

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

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

API การตรวจสอบที่อยู่จะแสดงสัญญาณต่างๆ ที่คุณสามารถรวมเข้ากับระดับความเสี่ยงเพื่อเพิ่มประสิทธิภาพกระบวนการตรวจสอบ ได้

เช่น หากที่อยู่มีหมายเลขถนนที่ยังไม่ได้รับการยืนยัน คุณก็ยังยอมรับได้ ในทางกลับกัน หากการดำเนินธุรกิจของคุณต้องใช้ ความแม่นยำของที่อยู่ที่มากขึ้น คุณอาจแจ้งให้ผู้ใช้ทราบ ดูตัวอย่างที่ อาจอยู่ในหมวดหมู่ใดหมวดหมู่หนึ่งได้ที่หมายเลขถนนที่ไม่ได้ยืนยันนอกสหรัฐอเมริกา ในยอมรับที่อยู่ - ตัวอย่าง

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

แนวทางปฏิบัติแนะนำคือการอนุญาตให้ระบบยอมรับรายการเดิม หากลูกค้าไม่ตอบกลับข้อความแจ้ง

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

ตัวอย่างขั้นตอนการชำระเงินที่หลีกเลี่ยงความเสี่ยง

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

if (verdict.possibleNextAction == FIX or verdict.validationGranularity
== OTHER or verdict.validationGranularity == ROUTE)
  Prompt customer to fix their address.
else if (verdict.possibleNextAction == CONFIRM_ADD_SUBPREMISES)
  Prompt customer to add a unit number.
else if (verdict.possibleNextAction == CONFIRM or verdict.validationGranularity
== PREMISE_PROXIMITY or verdict.hasSpellCorrectedComponents or
verdict.hasReplacedComponents or verdict.hasInferredComponents)
  Prompt customer to confirm their address.
else
  Proceed with the returned address.

ตัวอย่างขั้นตอนการชำระเงินที่ราบรื่น

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

if (verdict.possibleNextAction == FIX)
  Prompt customer to fix their address.
else if (verdict.hasReplacedComponents)
  Prompt customer to confirm their address.
else
  Proceed with the returned address.

สัญญาณ FIX

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

คุณใช้ช่องต่อไปนี้ของการตอบกลับจาก Address Validation API นอกเหนือจาก verdict.possibleNextAction เพื่อพิจารณาว่าที่อยู่มีปัญหาสำคัญหรือไม่ และปัญหาเหล่านั้นคืออะไรได้

รายละเอียดระดับการตรวจสอบ เมื่อการแจงนับความละเอียดของการตรวจสอบสำหรับที่อยู่เป็น OTHER แสดงว่าที่อยู่อาจไม่ถูกต้อง
ไม่มีคอมโพเนนต์ เมื่อ address.missingComponentTypes ไม่ว่าง แสดงว่าที่อยู่อาจขาดข้อมูลสำคัญ
คอมโพเนนต์ที่น่าสงสัย เมื่อการแจงนับระดับการยืนยันสำหรับคอมโพเนนต์เป็น UNCONFIRMED_AND_SUSPICIOUS แสดงว่าคอมโพเนนต์นั้น อาจไม่ถูกต้อง
คอมโพเนนต์ที่ยังไม่ได้รับการแก้ไข unresolvedToken เป็นส่วนหนึ่งของอินพุตที่ระบบไม่รู้จักว่าเป็นส่วนที่ถูกต้องของที่อยู่
การยืนยัน DPV ของ USPS เมื่อ uspsData.dpvConfirmation เป็น N หรือว่างเปล่า อาจเกิดปัญหาเกี่ยวกับที่อยู่ ฟิลด์นี้ใช้ได้กับที่อยู่ในสหรัฐอเมริกาเท่านั้น ดูรายละเอียดเพิ่มเติมเกี่ยวกับ uspsData.dpvConfirmation ได้ที่จัดการที่อยู่ในสหรัฐอเมริกา

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

สัญญาณ CONFIRM_ADD_SUBPREMISES (ที่อยู่ในสหรัฐอเมริกาเท่านั้น)

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

คุณสามารถใช้ช่องต่อไปนี้ของการตอบกลับจาก Address Validation API นอกเหนือจาก verdict.possibleNextAction เพื่อพิจารณาว่าที่อยู่น่าจะไม่มีสถานที่ย่อยหรือไม่

Missing subpremise component เมื่อฟิลด์ address.missingComponentTypes มีค่าเป็น subpremise แสดงว่าที่อยู่ไม่มีหมายเลขยูนิต
การยืนยัน DPV ของ USPS เมื่อ uspsData.dpvConfirmation เป็น S แสดงว่าหมายเลขหลักของที่อยู่ตรงกับที่อยู่ในฐานข้อมูลของ USPS อย่างไรก็ตาม คาดว่าที่อยู่ควรมีหมายเลขรองด้วย ฟิลด์นี้ใช้ได้กับที่อยู่ในสหรัฐอเมริกาเท่านั้น ดูรายละเอียดเพิ่มเติมเกี่ยวกับ uspsData.dpvConfirmation ได้ที่จัดการที่อยู่ในสหรัฐอเมริกา

ตัวอย่างการเพิ่มที่อยู่ของสถานที่ย่อย

สัญญาณ CONFIRM

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

คุณสามารถใช้ช่องต่อไปนี้ของการตอบกลับจาก Address Validation API นอกเหนือจาก verdict.possibleNextAction เพื่อพิจารณาว่าที่อยู่มีปัญหาเล็กน้อยหรือไม่ และปัญหาเหล่านั้นคืออะไร

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

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

สัญญาณ ACCEPT

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

คุณสามารถใช้ช่องต่อไปนี้ในการตอบกลับของ Address Validation API เพิ่มเติมจาก verdict.possibleNextAction เพื่อพิจารณาว่าที่อยู่มีคุณภาพที่ยอมรับได้หรือไม่

รายละเอียดระดับการตรวจสอบ validationGranularity ของ PREMISE มักจะ ยอมรับได้ แต่ค่า ROUTE อาจยังบ่งชี้ถึง ที่อยู่ที่นำส่งได้
ไม่มีข้อมูลที่อนุมาน เมื่อฟิลด์ hasInferredComponents เป็น false คุณจะทราบว่าไม่มีการอนุมานคอมโพเนนต์ใดๆ ในเอาต์พุต
ไม่มีข้อมูลที่ถูกแทนที่ เมื่อฟิลด์ hasReplacedComponents เป็น false คุณจะทราบว่าไม่มีการแทนที่ข้อมูลอินพุต
ไม่มีการแก้ไขตัวสะกด เมื่อhasSpellCorrectedComponentsฟิลด์เป็น false, คุณจะทราบว่าไม่มีการแก้ไขการสะกดคำ
การยืนยัน DPV ของ USPS เมื่อ uspsData.dpvConfirmation เป็น Y แสดงว่าที่อยู่ตรงกับที่อยู่ในฐานข้อมูลของ USPS ฟิลด์นี้ใช้ได้กับที่อยู่ในสหรัฐอเมริกาเท่านั้น ดูรายละเอียดเพิ่มเติมเกี่ยวกับ uspsData.dpvConfirmation ได้ที่ จัดการที่อยู่ในสหรัฐอเมริกา

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