שימוש ב-Address Authentication API לעיבוד כתובות בנפח גבוה

מטרה

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

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

תרחישים לדוגמה

עכשיו נבין את התרחישים לדוגמה שבהם אימות כתובות בנפח גדול הוא שימושי.

בדיקה

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

אימות חד-פעמי של כתובות

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

אימות חוזר של כתובות

יש מספר תרחישים של קריאה לאימות כתובות על בסיס קבוע:

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

ניתוח טכני מעמיק

למטרות המסמך הזה, אנחנו מניחים כי:

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

מטמון לשימוש בסביבת ייצור

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

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

  • נתונים מה-AddressComponent אובייקט
    • confirmationLevel
    • inferred
    • spellCorrected
    • replaced
    • unexpected

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

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

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

הסבר על התשובה

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

  • הסמן addressComplete בפסק הדין האובייקט הוא true,
  • validationGranularity בפסק הדין האובייקט הוא PREMISE או SUB_PREMISE
  • אף אחד מהAddressComponent מסומנות בתור:
    • Inferred(הערה: inferred=trueיכולה לקרות במקרים הבאים addressComplete=true)
    • spellCorrected
    • replaced
    • unexpected, וגם
  • confirmationLevel רמת האישור בדף AddressComponent מוגדר ל-CONFIRMEDאוUNCONFIRMED_BUT_PLAUSIBLE

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

  • formattedAddress
  • postalAddress
  • addressComponent componentNames או
  • UspsData standardizedAddress

הטמעת אימות כתובת ללא GUI

בהתאם לדיון שלמעלה:

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

בחלק הבא נדון בתהליך דו-שלבי המבוסס על לתנאים ולהגבלות ולהטמיע אימות כתובות בהיקף גבוה.

שלב 1:

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

תרשים א': בתרשים הבא אפשר לראות איך אפשר לשפר צינור נתונים עם לוגיקה של אימות כתובות בנפח גבוה.

alt_text

בהתאם לתנאים ולהגבלות, אפשר לשמור את הנתונים הבאים במטמון addressComponent:

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

לכן, במהלך השלב הזה של ההטמעה נשמור במטמון את מול ה-UserID.

לקבלת מידע נוסף, ראו פרטים על הנתונים בפועל של המבנה.

שלב 2:

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

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

alt_text

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

סיכום

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

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

השלבים הבאים

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

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

תורמים

Google מתחזקת את המאמר הזה. המחברים הבאים כתבו את הספר במקור.
מחברים ראשיים:

Henrik Valve | מהנדסי פתרונות
תומס אנגלרט | פתרונות מהנדסים
סרתאק גאנגולי | פתרונות מהנדסים