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

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

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

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

สัญญาณคำตัดสิน

เป็นไปตามข้อใดข้อหนึ่งต่อไปนี้
ยืนยันที่อยู่

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

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

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

สัญญาณคำตัดสิน

ทุกข้อต่อไปนี้

  • validationGranularity มี ROUTE หรือดีกว่า ดูค่า granularity
  • addressComplete คือ true
  • ช่อง hasInferredComponents คือ true หรือ hasReplacedComponents คือ true
ยอมรับที่อยู่

การตอบกลับ Address Validation API จะระบุที่อยู่ที่มีคุณภาพดีเยี่ยม

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

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

สัญญาณคำตัดสิน

ทุกข้อต่อไปนี้

  • validationGranularity มี PREMISE หรือดีกว่า ดูค่ารายละเอียด
  • addressComplete คือ true
  • ไม่มีคอมโพเนนต์ที่อนุมานหรือแทนที่

คำแนะนำการใช้งาน

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

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

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

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

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

แนวทางปฏิบัติที่ดีคือเพื่อให้ระบบยอมรับรายการเดิมหากลูกค้าไม่ตอบกลับพรอมต์

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

เมื่อออกคำขอตรวจสอบที่อยู่อีกครั้ง คุณจะส่งคำขอไปยังปลายทาง provideValidationFeedback ได้ด้วย

ซึ่งจะช่วยให้ Google ทราบว่าคุณจัดการกับคำตอบสุดท้ายอย่างไร โปรดดูหัวข้อจัดการที่อยู่ที่อัปเดต

แก้ไขที่อยู่

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

แก้ไขสัญญาณ

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 ได้ที่จัดการที่อยู่ในสหรัฐอเมริกา
การตอบกลับเกี่ยวกับที่อยู่ มีช่อง missingComponentType ที่มีค่าเป็น subpremise

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

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

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

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

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

1. รายละเอียดการตรวจสอบ

อนุญาตให้ใช้ validationGranularity ตั้งแต่ PREMISE ขึ้นไป แต่ในบางกรณี ROUTE จะยังคงระบุที่อยู่สำหรับนำส่งได้

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

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

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

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

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

dpvConfirmation Y

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

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