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

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

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

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

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

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

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

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

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

เมื่อออกแบบวิธีที่ระบบตอบสนองต่อสัญญาณจาก Address Validation 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 เพื่อพิจารณาว่าที่อยู่มีปัญหาสำคัญหรือไม่ และปัญหาเหล่านั้นคืออะไร

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

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

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

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

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

สัญญาณ CONFIRM

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

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

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

สัญญาณ ACCEPT

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

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

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