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

תרשים זרימה שמציג סקירה כללית של שלבי הבדיקה.

מטרה

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

אחרי שמגיעים לשלב של הערכת 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.

הוראות להפעלת ה-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 הסיק רכיב.

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
}

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

בשלב הזה אפשר גם לבדוק רכיבים חסרים או לא מאומתים. הוא חלק מאובייקט Address בנתוני ההחזרה. שני השדות הם 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 is 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 לאימות כתובות יועיל לתהליך העבודה שלכם.

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

תורמים

Henrik Valve | DevX Engineer