מדידת ההשפעה של אימות כתובת באמצעות בדיקת A/B

במאמר הזה מתוארות שיטות שכדאי להשתמש בהן כשמבצעים בדיקת A/B של ממשקי API של Google Maps Platform: השלמה אוטומטית למקומות וAddress Validation API.

הנה כמה יתרונות לשימוש ב-השלמה אוטומטית למקומות וב-Address Validation API:

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

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

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

סקירה כללית של ארכיטקטורת המערכת

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

[System Context] A/B Testing Address Validation

המערכות שמעורבות בבדיקת A/B של הערך של Address Validation API.

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

תהליך בדיקת ה-A/B

כשחושבים על תהליך בדיקת ה-A/B הכולל, יש ארבעה שלבים שצריך לקחת בחשבון.

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

בהמשך נסביר על כל אחד מהם.

הכנה

החלטה לגבי הדרישות של בדיקת A/B

גילוי ראשוני

כדאי לשאול את עצמכם: למה אתם מוסיפים ספק לאימות כתובות או משנים את הספק הקיים? לדוגמה, שימוש בהשלמה אוטומטית של מקומות במפות Google:

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

יש הרבה יתרונות לאימות כתובות, כולל:

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

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

מחליטים איזו היפותזה רוצים לבדוק. לדוגמה:

1. שיעור המרה

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

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

2. צמצום מספר הכתובות באיכות נמוכה

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

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

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

תכנות

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

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

תרשים ארכיטקטורה

בדוגמה הבאה מוצגים מאגרי התגים שאפשר להשתמש בהם כדי ליצור בדיקת A/B בסביבת מסחר אלקטרוני:

[סביבת הרצה] A/B Testing של Address Validation

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

אימות ההטמעה

פתרון שההטמעה שלו לא טובה יניב תוצאות בדיקה לא מהימנות. לפני שמריצים את בדיקת ה-A/B, חשוב קודם לאמת את הפתרון באמצעות קבוצת משתמשים קטנה כדי לוודא שהוא פועל כמצופה. אלה יכולים להיות בודקי QA פנימיים או קבוצה נבחרת של בודקים חיצוניים שאתם סומכים עליהם שיספקו משוב בונה.

ריצה

הגדלת נפח השליחה בהדרגה

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

בדיקה מלאה

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

תיעוד מדדים

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

הנה כמה מדדים מוצעים:

השלמה אוטומטית של מקומות

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

Address Validation

הצלחת המסירה: האם חלה ירידה במספר המסירות שנכשלו בגלל איכות הכתובת?
שינויים בכתובת: האם חלה ירידה במספר החיובים על שינוי כתובת שקיבלתם מחברות שליחויות?
מגורים לעומת מסחר: האם חל שיפור בתיעוד נתונים של מגורים לעומת מסחר? (שווקים נבחרים בלבד)

ניתוח

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

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

	פתרון א'	פתרון ב'
משלוחים שנכשלו	‫1.75%	‫1.23%

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

סיכום

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

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

בדיקה מהנה!

השלבים הבאים

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

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

תורמים

המחברים העיקריים:

Henrik Valve | Google Maps Platform Solutions Engineer