יצירת ניסויים של העברת הודעות בתוך האפליקציה עם בדיקות A/B

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

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

  1. יוצרים את הניסוי.
  2. מאמתים את הניסוי במכשיר בדיקה.
  3. מנהלים את הניסוי.

יצירת ניסוי

ניסוי שמשתמש ב-Firebase In-App Messaging מאפשר לכם להעריך כמה וריאציות של הודעה אחת באפליקציה.

  1. נכנסים למסוף Firebase ומוודאים ש-Google Analytics מופעל בפרויקט, כדי שלניסוי תהיה גישה לנתוני Analytics.

    אם לא הפעלתם את Google Analytics בזמן יצירת הפרויקט, תוכלו להפעיל אותו בכרטיסייה Integrations. אפשר לגשת לכרטיסייה הזו דרך > Project settings במסוף Firebase.

  2. בקטע התעניינות בתפריט הניווט של מסוף Firebase לוחצים על A/B Testing.

  3. לוחצים על Create experiments (יצירת ניסוי) ואז בוחרים באפשרות In-App Messaging (העברת הודעות בתוך האפליקציה) כשמוצגת בקשה לשירות שבו רוצים להתנסות.

  4. לחלופין, בתפריט הניווט של מסוף Firebase, מרחיבים את האפשרות Engage ולוחצים על In-App Messaging. לאחר מכן לוחצים על ניסוי חדש.

  5. מזינים שם ותיאור אופציונלי לניסוי, ולוחצים על הבא.

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

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

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

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

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

  10. (אופציונלי) כדאי להזין שם תיאורי יותר לכל וריאציה.

  11. (אופציונלי) בחלק העליון של הקטע וריאציות, לוחצים על הלחצן השוואת הווריאציות כדי להשוות בין וריאנט נוסף של ההודעה לבין הודעת הבקרה.

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

  13. מגדירים את התזמון של הניסוי:

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

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

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

אימות הניסוי במכשיר בדיקה

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

  1. מקבלים את טוקן האימות של ההתקנה באופן הבא:

    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");
        }
    }
});
    MainActivity.java

    Kotlin+KTX

    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")
        }
    }
    MainActivity.kt
  2. בסרגל הניווט של מסוף Firebase, לוחצים על בדיקות A/B.
  3. לוחצים על טיוטה (ו/או על הפעלה לניסויים בהגדרת תצורה מרחוק), מעבירים את העכבר מעל הניסוי, לוחצים על תפריט ההקשר () ואז על ניהול מכשירי הבדיקה.
  4. מזינים את אסימון האימות של ההתקנה למכשיר הבדיקה ובוחרים את הווריאנט של הניסוי שרוצים לשלוח למכשיר הבדיקה הזה.
  5. מריצים את האפליקציה ומוודאים שהגרסה שנבחרה מתקבלת במכשיר הבדיקה.

למידע נוסף על התקנות של Firebase, ראו ניהול התקנות ב-Firebase.

ניהול הניסוי

אחרי שיוצרים ניסוי עם Remote Config, עם הכלי 'התראות' או עם Firebase In-App Messaging, אפשר לאמת את הניסוי ולהתחיל אותו, לעקוב אחרי הניסוי בזמן שהוא פועל ולהגדיל את מספר המשתמשים שנכללים בניסוי הפעיל.

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

התחלת ניסוי

  1. בקטע התעניינות בתפריט הניווט של מסוף Firebase לוחצים על A/B Testing.
  2. לוחצים על טיוטה ואז על שם הניסוי.
  3. כדי לוודא שיש באפליקציה משתמשים שייכללו בניסוי, מרחיבים את פרטי הטיוטה ובודקים אם מופיע מספר גבוה מ-0% בקטע טירגוט והפצה (לדוגמה, 1% מהמשתמשים שעומדים בקריטריונים).
  4. כדי לשנות את הניסוי, לוחצים על עריכה.
  5. כדי להתחיל את הניסוי, לוחצים על התחלת הניסוי. אפשר להריץ עד 24 ניסויים בכל פרויקט בכל פעם.

מעקב אחרי ניסוי

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

  1. בקטע Engage בתפריט הניווט של מסוף Firebase, לוחצים על A/B Testing.

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

    • % difference from baseline: מדד לשיפור המדד של וריאנט נתון בהשוואה לערך הבסיס. הערך מחושב על ידי השוואה בין טווח הערכים של הווריאנט לבין טווח הערכים של הבקרה.
    • ההסתברות לגבור על שיעור ההמרה הבסיסי: ההסתברות המשוערת שגרסת המשנה מסוימת תגבר על שיעור ההמרה הבסיסי של המדד שנבחר.
    • observed_metric לכל משתמש: על סמך תוצאות הניסוי, זהו הטווח הצפוי שבו הערך של המדד ייכלל לאורך זמן.
    • סה"כ observed_metric: הערך המצטבר שנצפה של הבסיס או הווריאנט. הערך הזה משמש למדידת הביצועים של כל וריאנט בניסוי, ולחישוב הערכים של שיפור, טווח ערכים, הסתברות לחרוג מהבסיס והסתברות להיות הווריאנט הטוב ביותר. בהתאם למדד שנמדד, העמודה הזו עשויה להיקרא 'משך זמן לכל משתמש', 'הכנסה לכל משתמש', 'שיעור שימור' או 'שיעור המרה'.

  3. אחרי שהניסוי יפעל במשך זמן מה (לפחות 7 ימים ל-FCM ול-In-App Messaging או 14 ימים ל-Remote Config), הנתונים בדף הזה יציינו איזו וריאציה, אם בכלל, היא 'המובילה'. חלק מהמדידות מלוות בתרשים עמודות שמציג את הנתונים בפורמט חזותי.

השקת ניסוי לכל המשתמשים

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

  1. בקטע Engage בתפריט הניווט של מסוף Firebase, לוחצים על A/B Testing.
  2. לוחצים על הושלם או על בפעילות, לוחצים על הניסוי שרוצים להשיק לכל המשתמשים, לוחצים על תפריט ההקשר () השקת הווריאנט.

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

    • בניסוי שבו נעשה שימוש במלחין ההתראות, תוכלו להשתמש בתיבת הדו-שיח הפעלת ההודעה כדי לשלוח את ההודעה לשאר המשתמשים המטורגטים שלא היו חלק בניסוי.
    • בניסוי מסוג Remote Config, בוחרים וריאנט כדי לקבוע אילו ערכי פרמטר של Remote Config לעדכן. קריטריוני הטירגוט שמוגדרים כשיוצרים את הניסוי נוספים כתנאי חדש לתבנית, כדי להבטיח שההשקה תשפיע רק על משתמשים שהניסוי מטרגט. אחרי שלוחצים על בדיקה ב-Remote Config כדי לבדוק את השינויים, לוחצים על פרסום השינויים כדי להשלים את ההשקה.
    • בניסוי מסוג In-App Messaging, משתמשים בתיבת הדו-שיח כדי לקבוע איזה וריאנט צריך להשיק כקמפיין In-App Messaging נפרד. לאחר הבחירה, תועברו למסך הכתיבה של FIAM כדי לבצע שינויים (אם יש צורך) לפני הפרסום.

הרחבת ניסוי

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

  1. בקטע Engage בתפריט הניווט של מסוף Firebase, לוחצים על A/B Testing.
  2. בוחרים את הניסוי שפועל שרוצים לערוך.
  3. בדף סקירה כללית של הניסוי, לוחצים על תפריט הסיטואציה () ואז על עריכת הניסוי שפועל.
  4. בתיבת הדו-שיח טירגוט מוצגת אפשרות להגדיל את אחוז המשתמשים שנכללים בניסוי שפועל. בוחרים מספר גבוה יותר מהאחוז הנוכחי ולוחצים על פרסום. הניסוי יוצג לאחוז המשתמשים שציינתם.

שכפול או הפסקה של ניסוי

  1. בקטע Engage בתפריט הניווט של מסוף Firebase, לוחצים על A/B Testing.
  2. לוחצים על Complete או על running, מעבירים את העכבר מעל הניסוי, לוחצים על תפריט ההקשר () ואז לוחצים על שכפול הניסוי או הפסקת הניסוי.

טירגוט משתמשים

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

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

כשמשתמשים באופרטורים מסוג contains, does not contains או בהתאמה מדויקת, אפשר לספק רשימת ערכים שמופרדים בפסיקים.

כשמשתמשים באופרטור 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.
שימור (יום אחד) מספר המשתמשים שחוזרים לאפליקציה שלכם מדי יום.
שימור (2-3 ימים) מספר המשתמשים שחוזרים לאפליקציה תוך 2-3 ימים.
שימור (4 עד 7 ימים) מספר המשתמשים שחוזרים לאפליקציה תוך 4-7 ימים.
שימור משתמשים (8 עד 14 ימים) מספר המשתמשים שחוזרים לאפליקציה תוך 8 עד 14 ימים.
שימור (15 יום ומעלה) מספר המשתמשים שחוזרים לאפליקציה 15 ימים או יותר אחרי השימוש האחרון שלהם בה.
first_open אירוע Analytics שמופעל כשמשתמש פותח אפליקציה בפעם הראשונה אחרי שהוא מתקין אותה או מתקין אותה מחדש. משמש כחלק ממשפך המרות.

מדדים נוספים

מדד תיאור
notification_dismiss אירוע Analytics שמופעל כשהתראה שנשלחה על ידי הכלי ליצירת התראות נסגרת (Android בלבד).
notification_receive אירוע Analytics שמופעל כשמתקבלת התראה שנשלחה על ידי הכלי ליצירת התראות בזמן שהאפליקציה פועלת ברקע (ב-Android בלבד).
os_update אירוע ב-Analytics שעוקב אחרי העדכון של מערכת ההפעלה של המכשיר לגרסה חדשה.מידע נוסף זמין במאמר אירועים שנאספים באופן אוטומטי.
screen_view אירוע Analytics שמאפשר לעקוב אחרי המסכים שנצפו באפליקציה. למידע נוסף, ראו מעקב אחרי צפיות במסכים.
session_start אירוע Analytics שמספר את הסשנים של המשתמשים באפליקציה. מידע נוסף זמין במאמר אירועים שנאספים באופן אוטומטי.