אישור הכתובת – דוגמאות

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

דוגמאות נפוצות: אישור

הדוגמה הבאה ממחישה מקרה של אזורים מטרופוליטניים עם שמות רחובות דומים. נניח שמשתמש רוצה להזין את הכתובת של Google Building D ב-Kirkland, WA, United States. אבל במקום להזין את העיר Kirkland, הם מזינים בטעות את העיר Seattle.

הכתובת שהזנתם אזור
Building D, 451 7th Avenue South, Seattle, WA 98033 ארה"ב

החלטה לגבי הנתונים שהוחלפו

בדוגמה הבאה מודגשים האותות החשובים מהתוצאה.

{
  "inputGranularity": "SUB_PREMISE",
  "validationGranularity": "PREMISE_PROXIMITY",
  "geocodeGranularity": "PREMISE_PROXIMITY",
  "addressComplete": true,
  "hasUnconfirmedComponents": true
  "hasReplacedComponents": true
}

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

שאילתה של רכיבי הכתובת חושפת את הבעיות הבאות:

{
  "componentName": {
    "text": "451",
  },
  "componentType": "street_number",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
...
{
  "componentName": {
    "text": "98104",
  },
  "componentType": "postal_code",
  "confirmationLevel": "CONFIRMED",
  "replaced": true
}
...
{
  "componentName": {
    "text": "Building D",
    "language_code": "en"
  },
  "componentType": "subpremise",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
}
.......

    "unconfirmedComponentTypes": [
      "street_number",
      "subpremise"
    ]

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

דוגמאות למקרי קצה: אישור

הדוגמאות הבאות ממחישות את הסוגים הבאים של מקרי קצה:

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

הסקת מסקנות קטנה שכן אושרה

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

  • עיר
  • מדינה (State)
  • מיקוד
  • מדינה

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

הכתובת שהזנתם אזור
‎1402 Allen St, MA 01118 ארה"ב

החלטה לגבי עיר חסרה

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

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

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

{
  "componentName": {
    "text": "Springfield",
    "languageCode": "en"
  },
  "componentType": "locality",
  "confirmationLevel": "CONFIRMED",
  "inferred": true
},
{
  "componentName": {
    "text": "1806"
  },
  "componentType": "postal_code_suffix",
  "confirmationLevel": "CONFIRMED",
  "inferred": true
}

רכיב לא צפוי בכתובת לא אושר

התרחיש הזה ממחיש את החשיבות של בדיקת רכיבים שלא אושרו. אם רכיב של כתובת לא צפוי, ה-Address Validation API מסיר אותו מהפלט. במקרים כאלה, אתם יכולים לאשר את הכתובת או לאמת אותה מול הלקוח, בהתאם לרמת הסיכון ולרמת הוודאות שלכם.

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

הכתובת שהזנתם אזור
‎1 Rue Grenache, la caritat 2, 34630 Saint-Thibéry צרפת

ההחלטה לגבי רכיב כתובת לא צפוי לא אושרה

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

בנוסף לפסיקה עם רכיבים לא מאושרים, ה-Address Validation API מחזיר את הכתובת הבאה בפורמט:

"formattedAddress": "1 Rue Grenache, 34630 Saint-Thibéry, France",

בסריקה של רכיבים לא מאושרים, ה-API הסיר את la caritat 2 מהכתובת שהוחזרה:

{
  "componentName": {
    "text": "la caritat 2",
    "languageCode": "fr"
  },
  "componentType": "sublocality_level_1",
  "confirmationLevel": "UNCONFIRMED_BUT_PLAUSIBLE",
  "unexpected": true
}

רכיב כתובת לא צפוי שאושר

בדוגמה הזו, הכתובת כוללת מחוז בבריטניה, וזה מקובל. עם זאת, זו לא דרישה של רשות הדואר בבריטניה, והיא מתעלמת מהמידע הזה. אפשר לעיין באתר postoffice.co.uk ובמאמר How to address UK and international mail.

לכן, כשלקוח מזין מחוז בכתובת בבריטניה, השירות מזהה את זה כקלט לא צפוי.

הכתובת שהזנתם אזור
‪33 Dunalley St, Cheltenham, Gloucestershire, GL50 4AP בריטניה

החלטה לגבי רכיב כתובת לא צפוי שאושר

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

כאן, הערך של address_complete הוא False וניתוח של רכיב הכתובת חושף דגל לא צפוי.

{
  "componentName": {
    "text": "Gloucestershire",
    "languageCode": "en"
  },
  "componentType": "administrative_area_level_2",
  "confirmationLevel": "CONFIRMED",
  "unexpected": true
}

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