דף זה תורגם על ידי Cloud Translation API.

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

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

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

הדוגמה הבאה ממחישה את המקרה של אזורים מטרופוליטניים עם שמות רחובות דומים. נניח שמשתמש רוצה להזין את הכתובת של Google Building D in 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,
  "possibleNextAction": "CONFIRM"
}

הסמל possibleNextAction מציין שיש סיכוי שכדאי לאמת את הכתובת מול הלקוח. האותות האחרים בפסק הדין מספקים פרטים נוספים על הבעיות האפשריות בכתובת. הסמל 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 מצא קירוב קרוב לכתובת שסופקה בסיאטל, והוא החליף את המיקוד, רכיב ברמה גבוהה יותר, כדי להגיע לכתובת בסיאטל. יכול להיות שזו החלפה תקינה, אבל יחד עם העובדה שהרכיבים לא אושרו, כדאי לוודא שהמשתמש מתכוון להזין כתובת בסיאטל ולא משהו אחר, כמו קירקלנד.

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

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

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

מסקנות משניות שאושרו

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

עיר
מדינה
מיקוד
מדינה

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

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

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

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

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

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

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

הוזנה כתובת	אזור
‪59 Cherrydown Avenue, Chingford, London E4 8DT	בריטניה

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

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

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

"formattedAddress": "59 Cherrydown Avenue, London E4 8DT, UK",

סריקה של רכיבים לא מאומתים מראה שה-API הסיר את Chingford מהכתובת שהוחזרה:

{
  "componentName": {
    "text": "Chingford",
    "languageCode": "en"
  },
  "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",
   "possibleNextAction": "ACCEPT"
}

במקרה הזה, הערך של address_complete הוא false, וניתוח של רכיב הכתובת חושף דגל לא צפוי.

‫

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

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