בחירת פתרון לאימות כתובות

מטרה

אימות כתובות מספק ערך למגוון תרחישי שימוש, ויש שיקולים חשובים מעבר לאיכות הגולמית של תוצאות הבדיקה שכדאי לבדוק. לדוגמה: תצוגה הוליסטית של מוצרים תואמים בתהליך משתמש כמו השלמה אוטומטית של מקומות ומפות, זמינות אזורית ואמינות ומהימנות ברמת הארגון.

אחרי שמגיעים לשלב של הערכת Address Validation API, כדאי להשתמש בהנחיות הבאות כחלק מהבדיקה.

מטרות הבדיקה הזו הן:

1. מוודאים ש-Address Validation API מתאים לתרחיש השימוש שלכם.
2. בודקים איך Address Validation API עומד בדרישות של הפתרונות שלכם, למשל:
   • זיהוי כתובות באיכות טובה.
   • התראות שיעזרו לכם לטפל בנתונים באיכות נמוכה.
   • ביצוע תיקונים בנתוני כתובות, כולל הסקת מסקנות, החלפות ותיקוני איות.
   • הזנת כתובת למשלוח בפורמט מסוים.
   • התראות על נתונים חסרים או שגויים לגבי שטחים משניים (בארה"ב בלבד).
3. חשוב לוודא שתקבלו תועלת מדידה מהטמעת ה-API.

אחרי שתבצעו את הבדיקה, תוכלו לענות על השאלות שלמעלה ולקבוע אם ה-API מתאים לעסק שלכם.

הכנת הנתונים

הבדיקה צריכה להתבצע על מדגם של נתוני הכתובות הקיימים. אל תבחרו נתונים ספציפיים לבדיקה, אלא דוגמאות אקראיות שמייצגות את האזורים הגיאוגרפיים שבהם אתם פועלים. כלומר, אם אתם פועלים בארצות הברית ובבריטניה, אבל 70% מהפעילות העסקית שלכם מתבצעת בבריטניה ו-30% בארה"ב, המדגם צריך לשקף את החלוקה הזו.

שימוש בכתובות מנקודת האיסוף. לדוגמה, אם אתם מתכננים להטמיע אימות כתובות בתהליך התשלום באתר המסחר האלקטרוני שלכם, כדאי להשתמש בכתובות שהלקוחות הזינו בטופס, לפני שמתבצע עיבוד קיים שאולי יוחלף בהטמעה של Address Validation API.

מכינים מדגם בגודל של כ-5,000 עד 10,000 רשומות לבדיקה.

שליחת קריאה ל-API

דרישה מוקדמת: חשוב להבין איך שולחים בקשה לאימות כתובת.

אחרי שמכינים את הנתונים, צריך להריץ כל רשומה של כתובת מול ה-API.

במאמר Address Validation API מוסבר איך קוראים ל-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 הסיק רכיב.	True/False	ה-API יכול להוסיף רכיבים חסרים במקרים שבהם הוא יכול להסיק את הנתונים. לדוגמה, קוד מדינה חסר.
verdict.hasReplacedComponents	אותות אם ה-API החליף רכיב.	True/False	במקרים מסוימים, ה-API יכול להחליף רכיבים שגויים בנתונים הנכונים.
verdict.addressComplete	אותות אם הכתובת מלאה.	True/False	אם ה-API קובע שלכתובת הפלט יש את כל הרכיבים הדרושים, הערך יהיה true.
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	ארה"ב

פסק דין

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

בדיקת רכיבים חסרים או לא מאושרים

בשלב הזה אפשר גם לבדוק רכיבים חסרים או לא מאומתים. השדה הזה הוא חלק מאובייקט הכתובת בנתוני ההחזרה. שני השדות הם missingComponentTypes ו-unconfirmedComponentTypes.

אפשר להשתמש בשדות האלה כדי לזהות את הסיבה לכך שכתובת מסוימת מסומנת כלא תקינה על ידי ה-API, ולאסוף את המידע הנכון לגבי הכתובת כדי שהיא תהיה תקינה. לשם כך, צריך להעביר בחזרה לנקודה שבה הנתונים נאספים את השדות הספציפיים שגויים. זו דרך שבה ה-API מספק ערך בכך שהוא נותן לכם מידע ספציפי על איכות הנתונים.

דוגמה: רכיב חסר ולא מאומת

הוזנה כתובת	אזור
Fake St, New York, NY 10011	ארה"ב

פסק דין

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

רכיבים חסרים ולא מאושרים

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

בדיקת כתובות עם תיקונים

ה-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
}

[ארה"ב בלבד] בדיקת כתובת עם נתונים חסרים או שגויים של מיקום משני

ה-API לאימות כתובות יכול לקבוע אם כתובת משנה חסרה או שגויה, בכתובות בארה"ב.

האותות העיקריים שכדאי לחפש הם:

• באובייקט Address:
  • unconfirmedComponentTypes מכיל subpremise
  • missingComponentTypes מכיל subpremise
• באובייקט UspsData:
  • הערך של dpvConfirmation הוא D (חסר מיקום משני)
  • המאפיין dpvConfirmation הוא S (מיקום משנה לא מאומת)

מידע נוסף זמין במאמר בנושא טיפול בכתובות בארצות הברית.

בבדיקה הזו אפשר לראות אם יש בעיה בנתונים שקשורה לפרטים חסרים או שגויים של מיקומי משנה, כמו מספרי דירות. הדבר עלול לגרום לבעיות בהמשך, במיוחד בתרחישי שימוש שקשורים למסירה. ה-API לאימות כתובות יכול להוסיף ערך לתהליך העבודה שלכם על ידי זיהוי הבעיה בשלב מוקדם יותר, וכך לאפשר לכם להטמיע שלבים לאיסוף נתונים מתוקנים.

דוגמה: חסר מאפיין משנה של מיקום

הוזנה כתובת	אזור
‪111 8th Avenue, Manhattan, NY 10011	ארה"ב

רכיב חסר

"missingComponentTypes": [
    "subpremise"
]

אימות נתונים של USPS DPV

"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 עוד היום כדי לוודא שנתוני הכתובות מדויקים, לשפר את חוויית הלקוח ולייעל את הפעולות העסקיות. אחרי שתפעלו לפי תרחישי הבדיקה שמתוארים למעלה, יהיה לכם את המידע שדרוש כדי לקבוע אם ה-API לאימות כתובות יועיל לתהליך העבודה שלכם.

הצעות לקריאה נוספת:

• תיעוד למפתחים של Address Validation API
• שימוש ב-Address Validation API לעיבוד כתובות בכמויות גדולות
• אימות כתובת בתהליך התשלום במסחר אלקטרוני

תורמים

Henrik Valve | DevX Engineer