เลือกโซลูชันการตรวจสอบที่อยู่

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

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

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

เป้าหมายของการทดสอบนี้คือ

1. ยืนยันว่า Address Validation API เหมาะสมกับ Use Case ของคุณ
2. ตรวจสอบว่า Address Validation API ตรงตามข้อกำหนดของโซลูชันหรือไม่ เช่น
   • การระบุที่อยู่ที่มีคุณภาพดี
   • การแจ้งเตือนเพื่อแก้ไขข้อมูลที่มีคุณภาพต่ำ
   • แก้ไขข้อมูลที่อยู่ รวมถึงการอนุมาน การแทนที่ และการแก้ไขการสะกดคำ
   • ระบุที่อยู่ที่จัดรูปแบบสำหรับการจัดส่ง
   • การแจ้งเตือนเมื่อไม่มีข้อมูลย่อยหรือข้อมูลไม่ถูกต้อง (สหรัฐอเมริกาเท่านั้น)
3. ตรวจสอบว่าคุณจะได้รับประโยชน์ที่วัดผลได้จากการติดตั้งใช้งาน API

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

เตรียมข้อมูล

คุณควรทำการทดสอบกับตัวอย่างข้อมูลที่อยู่ที่มีอยู่ อย่าเลือกข้อมูลสำหรับการทดสอบด้วยตนเอง แต่ให้เลือกตัวอย่างแบบสุ่มที่ เป็นตัวแทนของภูมิศาสตร์ที่คุณดำเนินการอยู่ ซึ่งหมายความว่าหากคุณ ดำเนินธุรกิจทั้งในสหรัฐอเมริกาและสหราชอาณาจักร แต่ 70% ของ ธุรกิจของคุณดำเนินการในสหราชอาณาจักรและ 30% ในสหรัฐอเมริกา ตัวอย่างควรแสดง การแยกดังกล่าว

ใช้ที่อยู่จากจุดที่จับภาพ เช่น หากคุณวางแผนที่จะ ใช้การตรวจสอบที่อยู่ในขั้นตอนชำระเงินของอีคอมเมิร์ซ ให้ใช้ที่อยู่ตามที่ลูกค้าป้อนในแบบฟอร์ม ก่อนที่จะมีการประมวลผลใดๆ ที่อาจถูกแทนที่ด้วยการใช้ Address Validation API

เตรียมขนาดตัวอย่างประมาณ 5,000 - 10,000 รายการสำหรับการทดสอบ

เรียก API

ข้อกำหนดเบื้องต้นของส่วน: ทำความเข้าใจวิธี ส่งคำขอ การตรวจสอบที่อยู่

เมื่อเตรียมข้อมูลแล้ว คุณจะต้องเรียกใช้แต่ละระเบียนที่อยู่ กับ API

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

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

ดูผลลัพธ์

ข้อกำหนดเบื้องต้นของส่วน: ทำความเข้าใจวิธี จัดการการตอบกลับการตรวจสอบ โดยเฉพาะแนวคิดเรื่องแก้ไข ยืนยัน และยอมรับ

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

ภาพรวมของฟิลด์ API ที่สำคัญซึ่งกล่าวถึงในเอกสารนี้

ข้อมูลการตอบกลับ	ฟีเจอร์นี้คืออะไร	วิธีประเมิน	ฟีเจอร์นี้ช่วยอะไรได้บ้าง
verdict.inputGranularity	อธิบายระดับความละเอียดของอินพุตของที่อยู่	SUB_PREMISE PREMISE PREMISE_PROXIMITY บล็อก ROUTE อื่นๆ	ช่วยให้คุณพิจารณาได้ว่าที่อยู่ที่ป้อนมีข้อมูลเพียงพอที่จะอาจถูกต้องหรือไม่
verdict.validationGranularity	อธิบายการตรวจสอบเอาต์พุตโดยรวมของที่อยู่	SUB_PREMISE PREMISE PREMISE_PROXIMITY บล็อก ROUTE อื่นๆ	ช่วยให้คุณกำหนดคุณภาพที่อยู่โดยรวมในเอาต์พุตจาก API ได้
verdict.hasInferredComponents	ส่งสัญญาณหาก API อนุมานคอมโพเนนต์	จริง/เท็จ	API สามารถเพิ่มคอมโพเนนต์ที่ขาดหายไปในกรณีที่อนุมานข้อมูลได้ เช่น ไม่มีรหัสรัฐ
verdict.hasReplacedComponents	ส่งสัญญาณหาก API แทนที่คอมโพเนนต์	จริง/เท็จ	ในบางสถานการณ์ API สามารถแทนที่คอมโพเนนต์ที่ไม่ถูกต้องด้วยข้อมูลที่ถูกต้องได้
verdict.addressComplete	สัญญาณหากที่อยู่สมบูรณ์	จริง/เท็จ	หาก API ระบุว่าที่อยู่เอาต์พุตมีคอมโพเนนต์ที่จำเป็นทั้งหมด ค่าจะเป็นจริง
address.missingComponentTypes	ส่งสัญญาณเพื่อเตือนหากที่อยู่ไม่มีคอมโพเนนต์	ดู ตารางที่ 2เพื่อดูค่า	ไฮไลต์องค์ประกอบที่ขาดหายไปจากที่อยู่ที่ไม่สมบูรณ์

ตรวจสอบที่อยู่ที่ถูกต้อง

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

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

ดูข้อมูลเพิ่มเติมได้ที่ยอมรับที่อยู่

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

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

ตัวอย่าง: ที่อยู่ที่ถูกต้อง

ป้อนที่อยู่แล้ว	ภูมิภาค
76 Buckingham Palace Road, London SW1W 9TQ	สหราชอาณาจักร

คำตัดสิน

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "PREMISE",
  "geocodeGranularity": "PREMISE",
  "addressComplete": true
}

ตรวจสอบที่อยู่ที่ไม่ถูกต้อง

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

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

• verdict.validationGranularity ตั้งค่าเป็น OTHER หรือ ROUTE ขึ้นอยู่กับระดับความเสี่ยง
• verdict.addressComplete คือfalse

ดูข้อมูลเพิ่มเติมได้ที่แก้ไขที่อยู่

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

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

ตัวอย่าง: ที่อยู่ไม่ถูกต้อง

ป้อนที่อยู่แล้ว	ภูมิภาค
21 45 40th street	USA

คำตัดสิน

{
  "inputGranularity": "PREMISE",
  "validationGranularity": "OTHER",
  "geocodeGranularity": "OTHER",
  "hasUnconfirmedComponents": true
}

ตรวจสอบคอมโพเนนต์ที่ขาดหายไปหรือยังไม่ได้รับการยืนยัน

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

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

ตัวอย่าง: คอมโพเนนต์ขาดหายไปและไม่ได้รับการยืนยัน

ป้อนที่อยู่แล้ว	ภูมิภาค
Fake St, New York, NY 10011	USA

คำตัดสิน

{
     "inputGranularity": "ROUTE",
     "validationGranularity": "OTHER",
     "geocodeGranularity": "OTHER",
     "hasUnconfirmedComponents": true
}

คอมโพเนนต์ที่ขาดหายไปและไม่ได้รับการยืนยัน

"missingComponentTypes": [
    "street_number"
],
"unconfirmedComponentTypes": [
    "route"
]

ตรวจสอบที่อยู่ที่แก้ไขแล้ว

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

สัญญาณสำคัญที่ควรสังเกตมีดังนี้

• inferred, replaced หรือ spellCorrected ตั้งค่าเป็น true ใน addressComponents
• verdict.hasInferredComponents หรือ verdict.hasReplacedComponents ตั้งค่าเป็น true

ดูข้อมูลเพิ่มเติมได้ที่ยืนยันที่อยู่

ผลลัพธ์ของการดำเนินการนี้ควรเป็นชุดข้อมูลย่อยของข้อมูลที่อยู่ซึ่ง API ได้ทำการแก้ไขแล้ว

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

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

ป้อนที่อยู่แล้ว	ภูมิภาค
76 Bruckingm Palace Road, London SW1W 9TQ	สหราชอาณาจักร

เส้นทาง addressComponent

{
    "componentName": {
        "text": "Buckingham Palace Road",
        "languageCode": "en"
    },
    "componentType": "route",
    "confirmationLevel": "CONFIRMED",
    "spellCorrected": true
}

[สหรัฐอเมริกาเท่านั้น] ตรวจสอบที่อยู่ที่ไม่มีข้อมูลสถานที่ย่อยหรือข้อมูลไม่ถูกต้อง

Address Validation API สามารถระบุได้ว่าสถานที่ย่อยในที่อยู่ของสหรัฐอเมริกา ขาดหายไปหรือไม่ถูกต้อง

สัญญาณสำคัญที่ควรสังเกตมีดังนี้

• ในออบเจ็กต์ที่อยู่ ให้ทำดังนี้
  • unconfirmedComponentTypes มี subpremise
  • missingComponentTypes มี subpremise
• ในออบเจ็กต์ UspsData ให้ทำดังนี้
  • dpvConfirmation คือ D (ไม่มีสถานที่ย่อย)
  • dpvConfirmation เป็น S (ยังไม่ยืนยันสถานที่ย่อย)

ดูข้อมูลเพิ่มเติมได้ที่จัดการที่อยู่ในสหรัฐอเมริกา

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

ตัวอย่าง: ไม่มีสถานที่ย่อย

ป้อนที่อยู่แล้ว	ภูมิภาค
111 8th Avenue, Manhattan, NY 10011	สหรัฐอเมริกา

ไม่มีคอมโพเนนต์

"missingComponentTypes": [
    "subpremise"
]

การยืนยัน DPV ของข้อมูล USPS

"dpvConfirmation": "D"

[สหรัฐอเมริกาเท่านั้น] ตรวจสอบที่อยู่ที่ได้มาตรฐานของ USPS

นอกจากนี้ Address Validation API ยังแสดงที่อยู่ที่ได้มาตรฐานของ USPS สำหรับที่อยู่ในสหรัฐอเมริกาด้วย ซึ่งสำคัญอย่างยิ่งหากคุณต้องการให้พิมพ์ที่อยู่ที่จัดรูปแบบ USPS บนป้ายกำกับการจัดส่ง

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

ตัวอย่าง: ที่อยู่ที่ได้มาตรฐานของ USPS

"standardizedAddress": {
    "firstAddressLine": "111 8TH AVE FL 11",
    "cityStateZipAddressLine": "NEW YORK NY 10011-5201",
    "city": "NEW YORK",
    "state": "NY",
    "zipCode": "10011",
    "zipCodeExtension": "5201"
}

บทสรุป

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

อ่านเพิ่มเติมที่

• เอกสารประกอบสำหรับนักพัฒนาซอฟต์แวร์ Address Validation API
• ใช้ Address Validation API เพื่อประมวลผลที่อยู่จำนวนมาก
• การตรวจสอบความถูกต้องของที่อยู่สำหรับการชำระเงินอีคอมเมิร์ซ

ผู้ร่วมให้ข้อมูล

Henrik Valve | วิศวกร DevX