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

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

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

ข้อมูลการตอบกลับ	What Is it?	วิธีประเมิน	AI จะช่วยได้อย่างไร
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
}

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

ในขั้นตอนนี้ คุณสามารถตรวจสอบคอมโพเนนต์ที่ขาดหายไปหรือไม่ได้รับการยืนยันได้ด้วย ซึ่งเป็นส่วนหนึ่งของออบเจ็กต์ Address ในการคืนค่า ฟิลด์ 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 สามารถระบุได้ว่าไม่มีหรือข้อมูลย่อยไม่ถูกต้องสำหรับที่อยู่ในสหรัฐอเมริกา

สัญญาณหลักๆ ที่ควรมองหามีดังนี้

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

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

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

ตัวอย่าง: ไม่มีข้อความย่อย

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

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

"missingComponentTypes": [
    "subpremise"
]

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

"dpvConfirmation": "D"

[สหรัฐอเมริกาเท่านั้น] ตรวจสอบ standardizedAddress ของ 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