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

יעד

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

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

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

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

בדיקה

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

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

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

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

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

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

ניתוח טכני מפורט

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שלב 1:

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

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

alt_text

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

  • confirmationLevel
  • inferred
  • spellCorrected
  • replaced
  • unexpected

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

מידע נוסף זמין פרטים על מבנה הנתונים בפועל.

שלב 2:

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

תרשים ב': בתרשים הזה אפשר לראות איך שילוב של תהליך ההסכמה מקצה לקצה עשוי להיראות כך:

alt_text

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

סיכום

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

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

השלבים הבאים

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

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

תורמים

Google מנהלת את המאמר הזה. תורמי התוכן הבאים כתבו אותו במקור.
המחברים הראשיים:

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