במסמך הזה מתוארות שיטות שכדאי לשקול כשמבצעים בדיקת A/B של ממשקי ה-API של הפלטפורמה של מפות Google השלמה אוטומטית של מקומות ואימות כתובות.
יש כמה יתרונות לשימוש בהשלמה אוטומטית של מקומות ובממשק API לאימות כתובות:
- חוויית לקוח משופרת:אם תציעו ללקוחות בזמן אמת הצעות לכתובות ומקומות, תוכלו לעזור להם להשלים את תהליך התשלום במהירות ובקלות. כך אפשר לשפר את חוויית הלקוח.
- דיוק נתונים משופר: ה-Places השלמה אוטומטית ו-Address Validation API יכולים לעזור לכם לשפר את הדיוק של נתוני הלקוחות. זה עשוי להיות קריטי במיוחד במסחר אלקטרוני, כי אנחנו מסתמכים על נתוני כתובות מדויקים כדי לשלוח חבילות בהצלחה.
כדי לשפר את איכות הכתובות, מומלץ להריץ בדיקת A/B כדי להעריך איזה פתרון אימות מתאים לצרכים שלכם. כך תוכלו להחליט מבחינה כמותית איזה מוצר הוא המתאים ביותר לתרחיש לדוגמה שלכם.
באמצעות בדיקת A/B אפשר להשוות בין שתי גרסאות של דף אינטרנט או של אפליקציה. זהו סוג של ניסוי מבוקר שמשמש לקביעת ההשפעה של שינוי במשתנה על תוצאה שניתנת למדידה.
כדי לבצע בדיקת A/B, צריך ליצור שתי גרסאות של דף או אפליקציה: אחת כקבוצת בקרה והשנייה עם השינויים שניתנים למדידה. לאחר מכן תוכלו להציג את הגרסאות האלה למשתמשים שונים ולמדוד את האינטראקציה שלהם איתם. הגרסה עם הביצועים הטובים יותר היא המנצחת.
סקירה כללית של ארכיטקטורת המערכת
נבחן עכשיו את האפשרות של אימות כתובות במסגרת בדיקת A/B, לדוגמה במסחר אלקטרוני. תרשים הארכיטקטורה הבא מראה את האינטראקציה של הלקוח עם חוויית המסחר שלכם, וכך מאפשר לכם לקבוע מהי אסטרטגיית האימות היעילה יותר.
[הקשר מערכת] אימות כתובות בבדיקת A/B
המערכות שמעורבים בתהליך בדיקת ה-A/B של הערך של Address Validation API.
תהליך בדיקת A/B
כשחושבים על התהליך הכולל של בדיקת A/B, צריך לקחת בחשבון ארבעה שלבים.
- Prep – זיהוי דרישות הבדיקה, ההיקף ולוח הזמנים.
- Build – מטמיעים את ה-API להשלמה אוטומטית של מקומות ולאימות כתובות בסביבה שעליה רוצים להריץ את הבדיקה.
- הפעלה – אפשר לאסוף מדדים בזמן שהבדיקה פועלת, עד שיתקבלו תוצאות משמעותיות או עד שהזמן יעבור.
- ניתוח – משווים את התוצאות להשערה ומזהים את השלבים הבאים.
נדבר על כל אחד מהדברים האלה בזה אחר זה.
הכנה
קבלת החלטות לגבי הדרישות לבדיקת A/B
גילוי ראשוני
תשאלו את עצמכם: למה אתם מוסיפים או משנים ספק לאימות כתובת? לדוגמה, באמצעות השלמה אוטומטית של מקומות במפות Google:
- חיסכון בזמן: לא צריך להקליד את השם המלא של המקום כדי להתחיל להקליד ולראות הצעות מופיעות.
- מפחית שגיאות: אם שגית באיות שם המקום, ההשלמה האוטומטית של 'מקומות Google' עדיין תציע את המקום הנכון.
לאימות האימות יש הרבה יתרונות, למשל:
- שיעורי מסירה משופרים: אימות הכתובת עוזר לשפר את שיעורי המסירה, כי הוא מאפשר לוודא שהדואר והחבילות נשלחים לכתובת הנכונה. כך תוכלו לחסוך זמן וכסף, ולשפר את שביעות הרצון של הלקוחות.
- שיפור באיכות הנתונים: אימות הכתובת עוזר לשפר את איכות הנתונים על ידי זיהוי ותיקון שגיאות בכתובות. כך ניתן לשפר את הדיוק של קמפיינים שיווקיים ויוזמות אחרות שמבוססות על נתונים.
קבלת החלטה לגבי השערה
החלטו מהי ההשערה שתיבדק. לפניך שתי דוגמאות:
1. שיעור המרה (CVR)
כשמוסיפים פתרון מסוג בהמשך, בדרך כלל תבחינו בעלייה קלה בשיעורי ההמרות, וזה מדד טוב למעקב. אם אתה משנה את הפתרון שלך מספק אחר, צפוי שיעור המרה קבוע. אם שיעור ההמרה יורד, הדבר הראשון שצריך לבדוק הוא ההטמעה.
שיעור המרות הוא חשוב, אבל ייתכן שהוא לא יספר את כל הסיפור. הוספת פתרון לאימות כתובות נועדה לגרום לאנשים לשלוח כתובות באיכות נמוכה בכניסה למערכת, ועשויה להוסיף חיכוך טבעי בתרחישים מסוימים. הדבר עשוי להוביל לירידה בשיעורי ההמרות הכוללים, אבל זה לא בהכרח דבר רע. יכול להיות שההזמנות שלא הושלמו עקב הוספת אימות כתובת היו קשורות לנתוני כתובת באיכות נמוכה שהיו יכולים להוביל לעלויות בעסק כתוצאה מהחזרים כספיים בעקבות משלוחים.
2. צמצום של כתובות באיכות נמוכה
במקרה כזה, פתרון טוב לאימות כתובת יכול להיות מצוין. לאחר ההטמעה של אימות כתובות, צפויה ירידה בנתוני כתובות באיכות נמוכה.
אם משווים בין פתרון חדש לפתרון קיים, מפתה להשוות רק בין שיעורי ההתאמה של 'כתובת טובה', ולבחור את השירות שמספק אחוז לקוחות גבוה יותר של בקשות שמולאו. הדפוס הזה עלול להיות מטעה, כי שירות אחד מספק יותר תוצאות חיוביות שקריות מאשר שירות אחר.
במקום זאת, המדד בעל ההשפעה הרבה יותר הוא להשוות בין התוצאות המוצלחות של השימוש בנתוני הכתובת. אם ניקח לדוגמה את המסחר האלקטרוני, התוצאה הרצויה של תיעוד כתובת תהיה מסירה מוצלחת של חבילה בסופו של דבר.
פיתוח פתרונות
זהו החלק המרגש! הגיע הזמן לפתח פתרון חדש ללקוחות. כבר יש לנו מדריך שימושי ליישום השלמה אוטומטית של מקומות ו-Address Validation API בשלב תשלום במסחר אלקטרוני. מומלץ לבדוק את המידע הזה במהלך ביצוע השלב הזה.
גם אם אתם לא בונים במיוחד למסחר אלקטרוני, חלק גדול מהמידע עדיין רלוונטי, במיוחד ההנחיות לקביעת איכות הכתובת מהפלט של Address Validation API.
תרשים הארכיטקטורה
לפניכם דוגמה למאגרים שבהם ניתן להשתמש כדי לבנות בדיקת A/B בסביבת מסחר אלקטרוני:
[סביבת ביצוע] אימות כתובת לבדיקת A/B
האפליקציות, השירותים ומאגרי הנתונים החשובים במערכות המפתחות שמפעילים את הארכיטקטורה. (אפשר ללחוץ כדי להגדיל).
אימות ההטמעה
פתרון שמיושם בצורה גרועה יניב תוצאות בדיקה לא אמינות. לפני שמפעילים בדיקת A/B, חשוב קודם לאמת את הפתרון עם קבוצת משתמשים קטנה כדי לוודא שהוא פועל כצפוי. אנשי הצוות יכולים להיות בודקים פנימיים של בקרת איכות, או קבוצה נבחרת של בודקים חיצוניים, שאתם סומכים עליהם שיתנו משוב בונה.
ריצה
הגברה איטית
גם לאחר שהפתרון אומת, עדיין כדאי להגדיל את הבדיקה לאט, ולהתחיל עם קבוצה קטנה של משתמשים. כך אפשר לאתר באגים או בעיות אחרות בשלב מוקדם ולטפל בהן במהירות, בלי להשפיע על אחוז גדול מהמשתמשים.
בדיקה מלאה
לאחר שהפתרון נבדק על ידי קבוצה קטנה של משתמשים והבעיה נפתרה, אפשר להתחיל בבדיקת A/B מלאה. זה לא חייב להיות חלוקה אמיתית של 50/50 של התנועה, אבל את הגודל שלה צריך להשוות עם קבוצה אקראית של שימוש בזמן אמת.
לכידת מדדים
במהלך הבדיקה, עליך לוודא שנקלטו הנתונים המתאימים שיתמכו בהשערה שלך. תוכלו להשתמש בפלטפורמה לבדיקות A/B במשך התהליך הזה, כדי להקל על איסוף הנתונים ועל הניתוח מאוחר יותר. הפלטפורמה של מפות Google אוספת גם מדדי שימוש ב-API שעשויים להיות בשימוש. מידע נוסף על השימוש בכלי הדוחות זמין בדף הזה.
אלה כמה מהמדדים המוצעים:
השלמה אוטומטית של מקומות
שיעור המרה: האם שיעור ההמרה/ההשלמה של הטופס השתפר בהשוואה לזה שלא הייתה בו בעבר פתרון השלמה אוטומטית?
אינטראקציה עם הכלי: האם יותר משתמשים מצליחים לבצע אינטראקציה עם ההשלמה האוטומטית של מקומות בהשוואה לפתרון הקודם?
אימות כתובת
המסירה הסתיימה בהצלחה: האם הייתה ירידה במספר המשלוחים שנכשלו בגלל איכות הכתובת?
שינויי כתובת: האם קיבלתם ירידה במספר החיובים על שינוי כתובת שקיבלתם מחברות השליחויות?
מגורים לעומת מסחריים: האם היה שיפור באיסוף הנתונים לגבי מגורים לעומת מסחר? (בשווקים נבחרים בלבד)
ניתוח
כעת הבדיקה הסתיימה, והגיע הזמן לנתח את התוצאות לפי ההשערה והקריטריונים המקוריים של הבדיקה. אם השתמשתם בפלטפורמה לבדיקות A/B כדי להשלים את התהליך, יכול להיות שחלק מהמידע כבר זמין לכם.
אם חוזרים לקטע 'צמצום של כתובות באיכות נמוכה' שלמעלה, אפשר להשתמש גם במדדים אחרים שאולי לא תועדו על ידי פלטפורמת בדיקות ה-A/B. זה יכול להיות שיעור המסירה של ניסיונות שנכשלו בין תרחישי הבדיקה, עם נתונים לדוגמה כמו:
| פתרון א' | פתרון ב' | |
|---|---|---|
| מסירות שנכשלו | 1.75% | 1.23% |
אם נסתכל על הדוגמה הבסיסית שלמעלה, יהיה ברור שפתרון ב' עדיף במקרים האלה.
סיכום
אנחנו מקווים שהמדריך הזה נתן לכם מספיק מידע כדי שתוכלו להתחיל לעבוד עם בדיקות A/B. למרות שהשתמשנו בדוגמאות מתחום המסחר האלקטרוני, ניתן ליישם את אותם עקרונות בסיסיים בכל התחומים. הציגו את התוצאה המוצלחת של איסוף נתוני כתובת איכותיים בעסק שלכם, ועקבו אחריהן בתור ההשערה העיקרית שלכם.
צירפנו שוב את הקישורים שמוזכרים במדריך, כהצעות לקריאה נוספת.
בהצלחה בבדיקות!
השלבים הבאים
מורידים את המסמך שיפור תהליך התשלום, המשלוח והתפעול באמצעות כתובות אמינות וכדאי לקרוא את הוובינר בנושא שיפור תהליך התשלום, המשלוח והתפעול .
הצעות נוספות לקריאה:
- אימות כתובת עבור תשלום במסחר אלקטרוני
- מסמכי תיעוד להשלמה אוטומטית של מקומות
- מסמכי תיעוד של ה-Address Validation API
- דיווח בפלטפורמה של מפות Google
תורמים
מחברים ראשיים:
הנריק Valve | מהנדס הפתרונות של הפלטפורמה של מפות Google