כשפונים למשתמשים או מתחילים קמפיין שיווקי חדש, חשוב לוודא שהכל מתנהל בצורה נכונה. בדיקות A/B יכולות לעזור לכם למצוא את הניסוח וההצגה האופטימליים על ידי בדיקת וריאציות של ההודעה בחלקים נבחרים של בסיס המשתמשים. בין אם המטרה שלכם היא שיפור שיעור שימור הלקוחות או שיעור ההמרה של מבצע מסוים, בדיקת A/B יכולה לבצע ניתוח סטטיסטי כדי לקבוע אם וריאציה של הודעה מסוימת מניבה ביצועים טובים יותר מהערך הבסיסי של המטרה שבחרתם.
כדי לבצע בדיקת A/B של וריאציות של תכונות עם בסיס להשוואה, צריך לפעול לפי השלבים הבאים:
- יוצרים את הניסוי.
- כדאי לאמת את הניסוי במכשיר בדיקה.
- ניהול הניסוי.
יצירת ניסוי
ניסוי שמשתמש ב-Firebase In-App Messaging מאפשר לכם להעריך כמה וריאציות של הודעה אחת מתוך האפליקציה.
נכנסים למסוף Firebase ומוודאים ש-Google Analytics מופעל בפרויקט, כדי שלניסוי תהיה גישה לנתוני Analytics.
אם לא הפעלתם את Google Analytics כשיצרתם את הפרויקט, תוכלו להפעיל אותו בכרטיסייה Integrations (שילובים), שאליה אפשר לגשת דרך > Project settings (הגדרות הפרויקט) במסוף Firebase.
בקטע Engage בתפריט הניווט של מסוף Firebase, לוחצים על A/B Testing.
לוחצים על יצירת ניסוי ואז בוחרים באפשרות הודעות באפליקציה כשמוצגת בקשה לבחירת השירות שרוצים לבדוק.
לחלופין, בתפריט הניווט של מסוף Firebase, מרחיבים את Engage ולוחצים על In-App Messaging. לאחר מכן לוחצים על ניסוי חדש.
מזינים שם ותיאור אופציונלי לניסוי ולוחצים על הבא.
ממלאים את השדות בקטע טירגוט, וקודם בוחרים את האפליקציה שבה משתמשים בניסוי. אתם יכולים גם לטרגט קבוצת משנה של המשתמשים כדי להשתתף בניסוי, על ידי בחירת אפשרויות שכוללות את הדברים הבאים:
- גרסה: גרסה אחת או יותר של האפליקציה
- קהל משתמשים: קהלים שמשמשים לטירגוט משתמשיםAnalytics שעשויים להיכלל בניסוי
- מאפיין משתמש: מאפיין משתמש אחד או יותר לAnalyticsבחירת משתמשים שאולי ייכללו בניסוי
- מדינה או אזור: מדינה אחת או יותר או אזור אחד או יותר לבחירת משתמשים שאולי ייכללו בניסוי
- שפת המכשיר: שפה אחת או יותר ולוקאלים שמשמשים לבחירת משתמשים שאולי ייכללו בניסוי
- פתיחה ראשונה: טירגוט משתמשים על סמך הפעם הראשונה שבה הם פתחו את האפליקציה
- התעניינות אחרונה באפליקציה: טירגוט משתמשים לפי הפעם האחרונה שבה הם הביעו התעניינות באפליקציה שלכם
מגדירים את אחוז המשתמשים המטורגטים: בוחרים את אחוז בסיס המשתמשים באפליקציה שתואם לקריטריונים שהוגדרו בקטע משתמשים מטורגטים, שרוצים לחלק באופן שווה בין קו הבסיס לבין וריאציה אחת או יותר בניסוי. אפשר להזין כל אחוז בין 0.01% ל-100%. האחוזים מוקצים מחדש למשתמשים באופן אקראי לכל ניסוי, כולל ניסויים משוכפלים.
בקטע Variants (וריאציות), מגדירים הודעה בסיסית באפליקציה לשליחה לקבוצת הבסיס באמצעות ממשק עיצוב ההודעות שבו משתמשים בקמפיין רגיל של הודעות באפליקציה.
כדי להוסיף וריאציה לניסוי, לוחצים על הוספת וריאציה. כברירת מחדל, בניסוי יש קבוצת בסיס אחת וגרסה אחת.
(אופציונלי) מזינים שם תיאורי יותר לכל וריאנט.
(אופציונלי) בחלק העליון של הקטע וריאציות, לוחצים על הלחצן השוואת וריאציות כדי להשוות עוד וריאציות של הודעות זו לצד זו עם הודעת הבסיס.
מגדירים מדד יעד לניסוי כדי להשתמש בו בהערכת הווריאציות של הניסוי, וגם מדדים נוספים שרוצים להשתמש בהם מהרשימה. המדדים האלה כוללים יעדים מובנים (התעניינות, רכישות, הכנסות, שימור וכו'), Analytics אירועי המרה וAnalyticsאירועים אחרים.
מגדירים את התזמון של הניסוי:
- מגדירים תאריך התחלה ותאריך סיום לניסוי.
- הגדרת הטריגרים להצגת ההודעות באפליקציה בכל הווריאציות.
לוחצים על בדיקה כדי לשמור את הניסוי.
מותר ליצור עד 300 ניסויים לכל פרויקט, כולל עד 24 ניסויים פעילים, והשאר כטיוטות או כניסויים שהסתיימו.
אימות הניסוי במכשיר בדיקה
לכל התקנה של Firebase אפשר לאחזר את טוקן האימות של ההתקנה שמשויך אליה. אפשר להשתמש בטוקן הזה כדי לבדוק וריאציות ספציפיות של ניסוי במכשיר בדיקה שבו מותקנת האפליקציה. כדי לאמת את הניסוי במכשיר בדיקה, מבצעים את הפעולות הבאות:
- כך מקבלים את טוקן האימות של ההתקנה:
Swift
do { let result = try await Installations.installations() .authTokenForcingRefresh(true) print("Installation auth token: \(result.authToken)") } catch { print("Error fetching token: \(error)") }
Objective-C
[[FIRInstallations installations] authTokenForcingRefresh:true completion:^(FIRInstallationsAuthTokenResult *result, NSError *error) { if (error != nil) { NSLog(@"Error fetching Installation token %@", error); return; } NSLog(@"Installation auth token: %@", [result authToken]); }];
Java
FirebaseInstallations.getInstance().getToken(/* forceRefresh */true) .addOnCompleteListener(new OnCompleteListener<InstallationTokenResult>() { @Override public void onComplete(@NonNull Task<InstallationTokenResult> task) { if (task.isSuccessful() && task.getResult() != null) { Log.d("Installations", "Installation auth token: " + task.getResult().getToken()); } else { Log.e("Installations", "Unable to get Installation auth token"); } } });
Kotlin
val forceRefresh = true FirebaseInstallations.getInstance().getToken(forceRefresh) .addOnCompleteListener { task -> if (task.isSuccessful) { Log.d("Installations", "Installation auth token: " + task.result?.token) } else { Log.e("Installations", "Unable to get Installation auth token") } }
- בסרגל הניווט של Firebase console, לוחצים על A/B Testing.
- לוחצים על טיוטה (או על פועל בניסויים של הגדרת תצורה מרחוק), מעבירים את העכבר מעל הניסוי, לוחצים על תפריט ההקשר (more_vert) ואז על ניהול מכשירי בדיקה.
- מזינים את אסימון ההרשאה להתקנה של מכשיר הבדיקה ובוחרים את וריאציית הניסוי שרוצים לשלוח למכשיר הבדיקה.
- מריצים את האפליקציה ומוודאים שהווריאציה שנבחרה מתקבלת במכשיר הבדיקה.
מידע נוסף על Firebase התקנות זמין במאמר ניהול התקנות ב-Firebase.
ניהול הניסוי
אחרי שיוצרים ניסוי באמצעות Remote Config, הכלי ליצירת הודעות או Firebase In-App Messaging, אפשר לאמת ולהתחיל את הניסוי, לעקוב אחריו בזמן שהוא פועל ולהגדיל את מספר המשתמשים שנכללים בו.
כשהניסוי מסתיים, אפשר לרשום את ההגדרות שבהן נעשה שימוש בווריאציה המנצחת, ואז להחיל את ההגדרות האלה על כל המשתמשים. אפשר גם להפעיל ניסוי אחר.
התחלת ניסוי
- בקטע Engage בתפריט הניווט של מסוף Firebase, לוחצים על A/B Testing.
- לוחצים על טיוטה ואז על שם הניסוי.
- כדי לוודא שיש לאפליקציה משתמשים שייכללו בניסוי, מרחיבים את פרטי הטיוטה ובודקים אם המספר בקטע טירגוט והפצה גדול מ-0% (לדוגמה, 1% מהמשתמשים שעומדים בקריטריונים).
- כדי לשנות את הניסוי, לוחצים על עריכה.
- כדי להתחיל את הניסוי, לוחצים על התחלת הניסוי. אפשר להריץ עד 24 ניסויים לכל פרויקט בכל פעם.
מעקב אחרי ניסוי
אחרי שהניסוי פועל במשך זמן מה, אפשר לבדוק את ההתקדמות שלו ולראות את התוצאות שהתקבלו מהמשתמשים שהשתתפו בו עד עכשיו.
- בקטע Engage בתפריט הניווט של מסוף Firebase, לוחצים על A/B Testing.
לוחצים על פועל ואז לוחצים על השם של הניסוי או מחפשים אותו. בדף הזה אפשר לראות נתונים סטטיסטיים שונים שנמדדו ונוצרו על סמך מודלים לגבי הניסוי הפעיל, כולל:
- הפרש באחוזים לעומת ערך הבסיס: מדד לשיפור של מדד מסוים בווריאנט נתון בהשוואה לערך הבסיס. המדד מחושב על ידי השוואה בין טווח הערכים של הווריאציה לבין טווח הערכים של קו הבסיס.
- ההסתברות לגבור על שיעור ההמרה הבסיסי: ההסתברות המשוערת שגרסה מסוימת תשיג תוצאות טובות יותר משיעור ההמרה הבסיסי במדד שנבחר.
- observed_metric לכל משתמש: על סמך תוצאות הניסוי, זהו הטווח הצפוי שבו ערך המדד ייכלל לאורך זמן.
- סה"כ observed_metric: הערך המצטבר שנצפה עבור קו הבסיס או הווריאציה. הערך הזה משמש למדידת הביצועים של כל וריאציה בניסוי, ולחישוב המדדים שיפור, טווח ערכים, הסיכוי להשיג ביצועים טובים יותר מהביצועים הבסיסיים והסיכוי להיות הווריאציה הטובה ביותר. בהתאם למדד שנמדד, יכול להיות שהתווית של העמודה הזו תהיה 'משך הזמן לכל משתמש', 'הכנסה לכל משתמש', 'שיעור שימור' או 'שיעור המרה'.
אחרי שהניסוי פועל במשך זמן מה (לפחות 7 ימים עבור FCM ו-In-App Messaging או 14 ימים עבור Remote Config), הנתונים בדף הזה מציינים איזו וריאציה, אם בכלל, היא 'המובילה'. לחלק מהמדדים מצורף תרשים עמודות שמציג את הנתונים בפורמט חזותי.
השקת ניסוי לכל המשתמשים
אחרי שהניסוי פעל מספיק זמן כדי שיהיה וריאנט מוביל או מנצח ביחס למדד היעד, אפשר להשיק את הניסוי ל-100% מהמשתמשים. כך תוכלו לבחור וריאציה לפרסום לכל המשתמשים מעכשיו והלאה. גם אם לא נמצאה גרסה מנצחת ברורה בניסוי, אתם עדיין יכולים לבחור להשיק גרסה לכל המשתמשים.
- בקטע Engage בתפריט הניווט של מסוף Firebase, לוחצים על A/B Testing.
- לוחצים על הושלם או על פועל, לוחצים על ניסוי שרוצים להפעיל לכל המשתמשים, לוחצים על תפריט ההקשר ( ) הפעלת הווריאציה.
כדי להשיק את הניסוי לכל המשתמשים, מבצעים אחת מהפעולות הבאות:
- בניסוי שבו נעשה שימוש בכלי ליצירת הודעות, משתמשים בתיבת הדו-שיח הפעלת ההודעה כדי לשלוח את ההודעה למשתמשים הנותרים שטרגטו ולא השתתפו בניסוי.
- בניסוי Remote Config, בוחרים וריאציה כדי לקבוע אילו ערכי פרמטרים של Remote Config לעדכן. קריטריוני הטירגוט שהוגדרו כשיוצרים את הניסוי מתווספים כתנאי חדש בתבנית, כדי להבטיח שההשקה תשפיע רק על משתמשים שמטורגטים על ידי הניסוי. אחרי שלוחצים על בדיקה ב-Remote Config כדי לבדוק את השינויים, לוחצים על פרסום השינויים כדי להשלים את ההשקה.
- בניסוי In-App Messaging, משתמשים בתיבת הדו-שיח כדי לקבוע איזו וריאציה צריך להשיק כקמפיין In-App Messaging עצמאי. אחרי הבחירה, תועברו למסך הכתיבה של FIAM כדי לבצע שינויים (אם נדרשים) לפני הפרסום.
הרחבת ניסוי
אם אתם רואים שהניסוי לא מושך מספיק משתמשים כדי להכריז על גרסה מובילה, אתם יכולים להגדיל את ההפצה של הניסוי כדי להגיע לאחוז גדול יותר של בסיס המשתמשים של האפליקציה.A/B Testing
- בקטע Engage בתפריט הניווט של מסוף Firebase, לוחצים על A/B Testing.
- בוחרים את הניסוי הפעיל שרוצים לערוך.
- בסקירה הכללית של הניסוי, לוחצים על תפריט ההקשר ( ) ואז על עריכת ניסוי פעיל.
- בתיבת הדו-שיח טירגוט מוצגת אפשרות להגדלת אחוז המשתמשים שמשתתפים בניסוי הפעיל. בוחרים מספר גדול יותר מהאחוז הנוכחי ולוחצים על פרסום. הניסוי יוצג לאחוז המשתמשים שציינתם.
שכפול או הפסקה של ניסוי
- בקטע Engage בתפריט הניווט של מסוף Firebase, לוחצים על A/B Testing.
- לוחצים על הושלם או על פועל, מציבים את הסמן מעל הניסוי, לוחצים על תפריט ההקשר ( ) ואז על שכפול הניסוי או על הפסקת הניסוי.
טירגוט משתמשים
אפשר לטרגט את המשתמשים שרוצים לכלול בניסוי באמצעות הקריטריונים הבאים לטירגוט משתמשים.
קריטריון לטירגוט | מפעיל/ים | ערכים | הערה |
---|---|---|---|
גרסה | כולל,
לא כולל, התאמה מדויקת, כולל ביטוי רגולרי |
מזינים ערך לגרסה אחת או יותר של האפליקציה שרוצים לכלול בניסוי. |
כשמשתמשים באופרטורים contains, does not contain או matches exactly, אפשר לספק רשימת ערכים מופרדת בפסיקים. כשמשתמשים באופרטור contains regex, אפשר ליצור ביטויים רגולריים בפורמט RE2. הביטוי הרגולרי יכול להתאים לכל מחרוזת היעד או לחלק ממנה. אפשר גם להשתמש בסימני העיגון ^ ו-$ כדי להתאים את ההתחלה, הסוף או כל המחרוזת של מחרוזת היעד. |
קהלים של משתמשים | כולל את כל,
כולל לפחות אחד, לא כולל את כל, לא כולל לפחות אחד |
בוחרים קהל אחד או יותר Analytics לטירגוט משתמשים שעשויים להיכלל בניסוי. | יכול להיות שיחלפו כמה ימים עד שהמערכת תאסוף נתונים מניסויים שמטרגטים קהלים של Google Analytics, כי הם כפופים לAnalytics זמן האחזור של עיבוד הנתונים. העיכוב הזה צפוי להתרחש בעיקר אצל משתמשים חדשים, שבדרך כלל מצטרפים לקהלים שעומדים בדרישות תוך 24 עד 48 שעות אחרי היצירה, או בקהלים שנוצרו לאחרונה. |
מאפיין משתמש | לגבי טקסט:
מכיל, לא מכיל, תואם בדיוק, מכיל ביטוי רגולרי לגבי מספרים: <, ≤, =, ≥, > |
Analytics מאפיין משתמש משמש לבחירת משתמשים שאולי ייכללו בניסוי, עם מגוון אפשרויות לבחירת ערכים של מאפיין משתמש.
בצד הלקוח, אפשר להגדיר רק ערכי מחרוזת למאפייני משתמש. עבור תנאים שמשתמשים באופרטורים מספריים, שירות Remote Config ממיר את הערך של מאפיין המשתמש המתאים למספר שלם או למספר עשרוני. |
כשמשתמשים באופרטור contains regex, אפשר ליצור ביטויים רגולריים בפורמט RE2. הביטוי הרגולרי יכול להתאים לכל מחרוזת היעד או לחלק ממנה. אפשר גם להשתמש בסימני העיגון ^ ו-$ כדי להתאים את ההתחלה, הסוף או כל המחרוזת של מחרוזת היעד. |
ארץ/אזור | לא רלוונטי | מדינה או אזור אחד או יותר שמשמשים לבחירת משתמשים שעשויים להיכלל בניסוי. | |
שפות | לא רלוונטי | שפה אחת או יותר ולוקאלים שמשמשים לבחירת משתמשים שאולי ייכללו בניסוי. | |
פתיחה ראשונה |
יותר מ-
פחות מ- בין |
טרגוט משתמשים על סמך הפעם הראשונה שהם פתחו את האפליקציה, שצוינה בימים. | |
האינטראקציה האחרונה עם האפליקציה |
יותר מ-
פחות מ- בין |
טירגוט משתמשים על סמך הפעם האחרונה שבה הם יצרו אינטראקציה עם האפליקציה, שצוינה בימים. |
A/B Testing מדדים
כשיוצרים ניסוי, בוחרים מדד ראשי, או מדד יעד, שמשמש לקביעת הווריאנט המנצח. כדאי גם לעקוב אחרי מדדים אחרים כדי להבין טוב יותר את הביצועים של כל וריאציה בניסוי, ולעקוב אחרי מגמות חשובות שעשויות להיות שונות בכל וריאציה, כמו שימור משתמשים, יציבות האפליקציה והכנסות מרכישות באפליקציה. אפשר לעקוב אחרי עד חמישה מדדים שאינם יעדים בניסוי.
לדוגמה, נניח שהוספתם רכישות חדשות מתוך האפליקציה לאפליקציה שלכם ואתם רוצים להשוות בין היעילות של שתי הודעות שונות של "תזכורת". במקרה כזה, יכול להיות שתבחרו להגדיר את ההכנסה מרכישות כמדד היעד, כי אתם רוצים שהווריאציה המנצחת תייצג את ההתראה שהניבה את ההכנסה הכי גבוהה מרכישות בתוך האפליקציה. בנוסף, כדי לעקוב אחרי הווריאציה שהניבה יותר המרות עתידיות ושמרה על יותר משתמשים, אפשר להוסיף את המדדים הבאים אל מדדים אחרים למעקב:- סך ההכנסות המשוערות כדי לראות את ההבדלים בין שני הווריאציות בסך ההכנסות ממוצרים מתוך האפליקציה וממודעות
- Retention (1 day), Retention (2-3 days), Retention (4-7 days) כדי לעקוב אחרי שימור המשתמשים היומי או השבועי
בטבלאות הבאות מפורט אופן החישוב של מדדי היעד ומדדים אחרים.
מדדי יעדים
מדד | תיאור |
---|---|
משתמשים שהאפליקציה שלהם לא קרסה | אחוז המשתמשים שלא נתקלו בשגיאות באפליקציה שזוהו על ידי Firebase Crashlytics SDK במהלך הניסוי. |
ההכנסה המשוערת מפרסום | הרווחים המשוערים ממודעות. |
סה"כ הכנסות משוערות | הערך הכולל של רכישות והכנסות משוערות מפרסום. |
הכנסות מרכישות | הערך הכולל של כל האירועים מסוג purchase ו-in_app_purchase .
|
שימור (יום אחד) | מספר המשתמשים שחוזרים לאפליקציה שלכם על בסיס יומי. |
שימור (יומיים-שלושה) | מספר המשתמשים שחוזרים לאפליקציה שלכם תוך יומיים-שלושה. |
שימור (4-7 ימים) | מספר המשתמשים שחוזרים לאפליקציה שלכם תוך 4-7 ימים. |
שימור (8-14 ימים) | מספר המשתמשים שחוזרים לאפליקציה שלכם תוך 8 עד 14 ימים. |
שימור (15 ימים ומעלה) | מספר המשתמשים שחוזרים לאפליקציה 15 ימים או יותר אחרי השימוש האחרון שלהם באפליקציה. |
first_open | אירוע Analytics שמופעל כשמשתמש פותח אפליקציה בפעם הראשונה אחרי שהוא התקין אותה או התקין אותה מחדש. השימוש ב-Google Tag הוא חלק ממשפך המרות. |
מדדים נוספים
מדד | תיאור |
---|---|
notification_dismiss | אירוע Analytics שמופעל כשסוגרים הודעה שנשלחה על ידי הכלי ליצירת התראות (ב-Android בלבד). |
notification_receive | אירוע Analytics שמופעל כשמתקבלת הודעה שנשלחה על ידי הכלי ליצירת הודעות בזמן שהאפליקציה פועלת ברקע (Android בלבד). |
os_update | אירוע Analytics שמתעד מתי מערכת ההפעלה של המכשיר מעודכנת לגרסה חדשה.מידע נוסף זמין במאמר בנושא אירועים שנאספים באופן אוטומטי. |
screen_view | Analytics אירוע שמתעד את המסכים שנצפו באפליקציה. מידע נוסף זמין במאמר בנושא מעקב אחר צפיות במסך. |
session_start | Analytics אירוע שסופר סשנים של משתמשים באפליקציה. מידע נוסף זמין במאמר אירועים שנאספים באופן אוטומטי. |