เอกสารนี้จะอธิบายกระบวนการสร้างระบบตรวจสอบที่อยู่เพื่อจัดการคำตอบที่หลากหลายจาก Address Validation API ซึ่งจะครอบคลุมวิธีสร้างตรรกะเพื่อใช้คำตอบอย่างถูกต้อง ตรวจสอบสัญญาณอื่นๆ จาก API รวมถึงกรณีที่ควรแจ้งให้ลูกค้าทราบข้อมูลเพิ่มเติม
โดยทั่วไปการตอบกลับของ API จะกำหนดวิธีที่ระบบของคุณควรใช้ในการจัดการที่อยู่
- แก้ไข - ที่อยู่มีคุณภาพต่ำ คุณควรแจ้งขอข้อมูลเพิ่มเติม
- ยืนยัน ที่อยู่มีคุณภาพสูง แต่มีการเปลี่ยนแปลงจากที่อยู่ที่ป้อน ระบบอาจแจ้งให้ยืนยัน
- ยอมรับ ที่อยู่มีคุณภาพสูง คุณ ยอมรับที่อยู่ที่ระบุได้
วัตถุประสงค์หลัก
เอกสารนี้จะช่วยให้คุณแก้ไขระบบเพื่อให้วิเคราะห์การตอบสนองของ API ได้ดีที่สุดและระบุการดำเนินการถัดไปที่จะทำกับที่อยู่ที่ระบุ Pseudocode ต่อไปนี้แสดงขั้นตอนที่เป็นไปได้
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 อย่างสำหรับระบบของคุณ
- เวิร์กโฟลว์ที่จะใช้ตามลักษณะการทำงานของการแก้ไข ยืนยัน และยอมรับ
- สัญญาณแรกที่ต้องตรวจสอบจากคำตอบ สัญญาณที่อธิบายไว้ที่นี่มาจากพร็อพเพอร์ตี้
verdict
และไม่ใช่สัญญาณเดียวที่ต้องตรวจสอบ แต่เป็นตัวบ่งชี้เริ่มต้นเกี่ยวกับคุณภาพที่อยู่ ลักษณะการทำงานแต่ละประเภทจะสอดคล้องกับหัวข้อในเอกสารนี้ ซึ่งจะอธิบายสัญญาณเพิ่มเติมที่คุณอาจต้องตรวจสอบด้วย
การทำงานของระบบ | |||
---|---|---|---|
แก้ไขที่อยู่ |
การตอบกลับจาก
|
||
ยืนยันที่อยู่ |
การตอบกลับจาก
|
||
ยอมรับที่อยู่ |
การตอบกลับ Address Validation API ระบุว่าเป็นที่อยู่ที่มีคุณภาพดีมาก
|
หลักเกณฑ์การใช้งาน
เมื่อออกแบบวิธีที่ระบบตอบสนองต่อสัญญาณจาก Address Validation API คำแนะนำต่อไปนี้จะช่วยคุณสร้างโมเดลการตอบสนองที่มีประสิทธิภาพยิ่งขึ้น แต่นี่เป็นเพียงคำแนะนำเท่านั้น โปรดทราบว่าการติดตั้งใช้งานควรเหมาะกับโมเดลธุรกิจของคุณ
คำแนะนำ | รายละเอียด | |
---|---|---|
ระดับความเสี่ยง |
คำนึงถึงระดับการยอมรับสถานการณ์ของคุณเมื่อต้องสร้างความสมดุลระหว่างการแจ้งเพื่อให้แก้ไขและการยอมรับที่อยู่ตามที่ป้อน |
Address Validation API จะแสดงสัญญาณต่างๆ ที่คุณใช้ร่วมกับระดับความเสี่ยงเพื่อเพิ่มประสิทธิภาพกระบวนการตรวจสอบได้ ตัวอย่างเช่น หากที่อยู่มีเลขที่ถนนที่ยังไม่ได้ยืนยัน คุณก็ยังยอมรับได้ ในทางกลับกัน หากการดำเนินธุรกิจต้องการความแม่นยำด้านที่อยู่มากกว่า คุณอาจแจ้งให้ผู้ใช้ทราบ ดูตัวอย่างที่อาจอยู่ในหมวดหมู่ใดหมวดหมู่หนึ่ง โปรดดูเลขที่ถนนที่ยังไม่ได้ยืนยันที่ไม่ใช่ของสหรัฐอเมริกาในยอมรับที่อยู่ - ตัวอย่าง |
ยอมรับที่อยู่ |
ควรอนุญาตให้ระบบยอมรับรายการเดิมในกรณีที่ลูกค้าไม่ตอบกลับข้อความแจ้ง |
ในกรณีเหล่านี้ ลูกค้าอาจป้อนที่อยู่ที่ไม่ได้อยู่ในระบบ เช่น สำหรับการก่อสร้างใหม่ |
แสดงความคิดเห็น |
เมื่อออกคำขอตรวจสอบที่อยู่อีกครั้ง คุณจะส่งคำขอไปยังปลายทาง |
ซึ่งจะช่วยให้ 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
ดูรายละเอียดเกี่ยวกับ |
---|---|
ที่อยู่ตอบกลับ | มีช่อง missingComponentType ที่มีค่าเป็น subpremise
|
ยอมรับที่อยู่
คุณยอมรับที่อยู่เมื่อคำตัดสินให้ความมั่นใจในระดับสูงว่าที่อยู่นั้นนำส่งได้ และสามารถใช้งานได้โดยไม่ต้องมีการโต้ตอบเพิ่มเติมจากลูกค้าในกระบวนการดาวน์สตรีม
ยอมรับสัญญาณ
Address Validation API จะแสดงสัญญาณหลายอย่างเพื่อแจ้งให้คุณทราบหากที่อยู่ควรได้รับการยืนยัน
1. รายละเอียดการตรวจสอบ
ระบบยอมรับ validationGranularity
ที่มีค่าเป็น PREMISE
หรือสูงกว่า แต่ในบางกรณี ROUTE
ยังคงเป็นที่อยู่สำหรับนำส่งสินค้า
2. สัญญาณอื่นๆ
การตัดสินสำหรับที่อยู่คุณภาพสูงควรระบุข้อมูลต่อไปนี้ด้วย
- ไม่มีข้อมูลที่ถูกแทนที่ ในกรณีนี้คือ
hasReplacedComponents: FALSE
- ไม่มีคอมโพเนนต์ที่สรุป ในกรณีนี้คือ
hasInferredComponents: FALSE
3. สัญญาณที่อยู่ในสหรัฐอเมริกา
บางช่องที่ใช้เฉพาะที่อยู่ในสหรัฐอเมริกาจะระบุว่าที่อยู่คุณภาพสูงที่นำส่งได้ สำหรับที่อยู่ในสหรัฐอเมริกาที่ยอมรับได้ คุณจะเห็นข้อมูลต่อไปนี้
dpvConfirmation
|
Y
ดูรายละเอียดเกี่ยวกับ |
---|