יעד
כמפתחים, לעיתים קרובות אתם עובדים עם מערכי נתונים שמכילים כתובות של לקוחות, שיכול להיות שהם לא באיכות טובה. אתם צריכים לוודא שהכתובות נכונות לשימוש בתרחישים שונים, כמו אימות מספר לקוח, שליחה ועוד.
ה-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, בהתאם לתנאים ולהגבלות.
תרשים א': בתרשים הבא אפשר לראות איך אפשר לשפר את צינור הנתונים באמצעות לוגיקה לאימות כתובות בנפח גבוה.
בהתאם לתנאים ולהגבלות, אפשר לשמור במטמון את הנתונים הבאים מ-addressComponent
:
confirmationLevel
inferred
spellCorrected
replaced
unexpected
לכן, בשלב הזה של ההטמעה, נשמור את השדות המוזכרים למעלה מול ה-UserID.
מידע נוסף זמין פרטים על מבנה הנתונים בפועל.
שלב 2:
בשלב הראשון, אספנו משוב על כך שיכול להיות שחלק מהכתובות במערך הנתונים של הקלט לא באיכות גבוהה. בשלב הבא נציג את הכתובות המסומנות האלה למשתמש ונקבל את הסכמתו לתקן את הכתובת השמורה.
תרשים ב': בתרשים הזה אפשר לראות איך שילוב של תהליך ההסכמה מקצה לקצה עשוי להיראות כך:
- כשהמשתמש מתחבר, קודם כול צריך לבדוק אם שמרתם במטמון כל דגלי אימות במערכת.
- אם יש סימונים, צריך להציג למשתמש ממשק משתמש כדי לתקן ולעדכן את הכתובת.
- אפשר להפעיל שוב את Address Validation API עם הכתובת המעודכנת או השמורה במטמון, ולהציג למשתמש את הכתובת המתוקנת כדי לאשר את הפעולה.
- אם הכתובת איכותית, ה-Address Validation API מחזיר את הערך
formattedAddress
. - אפשר להציג את הכתובת למשתמש אם בוצעו תיקונים, או לאשר בשקט אם אין תיקונים.
- לאחר שהמשתמש יאשר את ההזמנה, ניתן יהיה לשמור את
formattedAddress
במטמון במסד הנתונים.
סיכום
אימות כתובות בהיקפים גדולים הוא תרחיש נפוץ לדוגמה, שאתם עשויים להיתקל בו באפליקציות רבות. במאמר הזה אנחנו מנסים להדגים כמה תרחישים ודפוס תכנון ליישום של פתרון כזה בכפוף לתנאים ולהגבלות של הפלטפורמה של מפות Google.
כתבנו עוד דוגמה ליישום של אימות כתובות בנפח גבוה כספריית קוד פתוח ב-GitHub. קראו את המאמר כדי להתחיל במהירות לבנות בעזרת אימות כתובות בנפח גבוה. קראו גם את המאמר על תבניות עיצוב לאופן השימוש בספרייה בתרחישים שונים.
השלבים הבאים
הורידו את שיפור תהליך התשלום, המסירה והתפעול באמצעות כתובות אמינות מסמך טכני וצפו בוובינר בנושא שיפור התשלום, המסירה והפעולות באמצעות אימות כתובות .
הצעות נוספות לקריאה:
- אפליקציות לאימות כתובות בנפח גדול
- ספריית Python ב-github
- הדגמת של אימות כתובות
תורמים
Google מנהלת את המאמר הזה. תורמי התוכן הבאים כתבו אותו במקור.
המחברים הראשיים:
Henrik Valve | מהנדס פתרונות
תומאס אנגלרט | מהנדס
פתרונות
סרתק גנגולי | מהנדס
פתרונות