คู่มือโซลูชันการตรวจสอบความถูกต้องของที่อยู่

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

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

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

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

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

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

เตรียมข้อมูลของคุณ

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

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

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

เรียก API

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

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

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

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

ดูผลลัพธ์

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

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

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

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

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

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

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

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

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

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

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

ที่อยู่ที่ป้อน	ภูมิภาค
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 เพื่อประมวลผลที่อยู่จำนวนมาก
• Address Validation สำหรับการชำระเงินอีคอมเมิร์ซ

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

Henrik Valve | วิศวกร DevX