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

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

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

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

הכתובת שהוזנה	אזור
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"
    ]

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

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

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

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

מסקנות קלות שאושרו ב-ARE

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

• עיר
• ארץ
• מיקוד
• מדינה

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

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

תוצאה של עיר חסרה

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

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

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

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

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

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

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

הכתובת שהוזנה	אזור
1 Rue Grandache, 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 ובמאמר איך מטפלים בדואר בבריטניה ובדואר בינלאומי.

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

הכתובת שהוזנה	אזור
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
}

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