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

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

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

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

יצירת ניסוי

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

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

    אם לא הפעלתם את Google Analytics כשיצרתם את הפרויקט, אתם יכולים להפעיל אותו בכרטיסייה Settings > Integrations במסוף Firebase.

  2. במסוף Firebase, מתחילים ניסוי ב-Firebase In-App Messaging באחת מהאפשרויות הבאות:

    • מאת A/B Testing:

      1. עוברים אל DevOps & Engagement (DevOps ומעורבות) > A/B Testing (בדיקת A/B).

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

    • מאת In-App Messaging:

      1. עוברים אל DevOps & Engagement (DevOps ומעורבות) > Messaging (העברת הודעות).

      2. לוחצים על In-App Messaging ואז על ניסוי חדש.

  3. מזינים שם ותיאור (אופציונלי) לניסוי ולוחצים על הבא.

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

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

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

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

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

  8. (אופציונלי) מזינים שם תיאורי יותר לכל וריאציה.

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

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

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

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

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

בכל פרויקט אפשר להגדיר עד 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");
        }
    }
});

    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")
        }
    }

    אינטרנט

          import { getInstallations, getToken } from "firebase/installations";

      const installations = getInstallations(app);
      const installationAuthToken = getToken(installations);
  2. במסוף Firebase, עוברים אל DevOps & Engagement (DevOps ומעורבות) > A/B Testing (בדיקת A/B).
  3. לוחצים על טיוטה (או על פועל בניסויים בהגדרת תצורה מרחוק), מעבירים את העכבר מעל הניסוי, לוחצים על תפריט ההקשר () ואז על ניהול מכשירי הבדיקה.
  4. מזינים את אסימון האימות של ההתקנה במכשיר הבדיקה ובוחרים את וריאנט הניסוי שרוצים לשלוח למכשיר הבדיקה הזה.
  5. מפעילים את האפליקציה ומוודאים שהווריאנט שנבחר מתקבל במכשיר הבדיקה.

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

ניהול הניסוי

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

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

התחלת ניסוי

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

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

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

  1. במסוף Firebase, עוברים אל DevOps & Engagement (DevOps ומעורבות) > A/B Testing (בדיקת A/B).

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

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

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

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

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

  1. במסוף Firebase, עוברים אל DevOps & Engagement (DevOps ומעורבות) > A/B Testing (בדיקת A/B).
  2. לוחצים על Completed או על Running, לוחצים על הניסוי שרוצים להשיק לכל המשתמשים, לוחצים על תפריט ההקשר () ואז על Roll out variant.

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

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

הרחבת ניסוי

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

  1. במסוף Firebase, עוברים אל DevOps & Engagement (DevOps ומעורבות) > A/B Testing (בדיקת A/B).
  2. בוחרים את הניסוי הפעיל שרוצים לערוך.
  3. בקטע Experiment overview, לוחצים על תפריט ההקשר () ואז על Edit running experiment.
  4. בתיבת הדו-שיח Targeting מוצגת אפשרות להגדיל את אחוז המשתמשים שמשתתפים בניסוי הפעיל. בוחרים מספר שגבוה מהאחוז הנוכחי ולוחצים על פרסום. הניסוי יופץ לאחוז המשתמשים שציינתם.

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

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

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

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

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

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

כשמשתמשים באופרטור מכיל ביטוי רגולרי, אפשר ליצור ביטויים רגולריים בפורמט RE2. הביטוי הרגולרי יכול להתאים לכל המחרוזת של גרסת היעד או לחלק ממנה. אפשר גם להשתמש בעוגנים ^ ו-$ כדי להתאים את ההתחלה, הסוף או כל מחרוזת היעד.
קהל או קהלים של משתמשים כולל את כל,
כולל לפחות אחד מתוך,
לא כולל את כל,
לא כולל לפחות אחד מתוך		 בוחרים קהל אחד או יותר ב-Analytics כדי לטרגט משתמשים שעשויים להיכלל בניסוי. בחלק מהניסויים שמטרגטים קהלים מסוג Google Analytics, יכול להיות שיעברו כמה ימים עד שיצטברו נתונים, כי הם כפופים לזמן אחזור של עיבוד נתונים של Analytics. סביר להניח שתיתקלו בעיכוב הזה עם משתמשים חדשים, שבדרך כלל מתווספים לקהלים שעומדים בדרישות תוך 24 עד 48 שעות אחרי היצירה, או עם קהלים שנוצרו לאחרונה.
מאפיין משתמש לטקסט:
מכיל,
לא מכיל,
תואם בדיוק,
מכיל ביטוי רגולרי (regex)

למספרים:
<, ≤, =, ≥, > 		מאפיין משתמש של Analytics משמש לבחירת משתמשים שעשויים להיכלל בניסוי, עם מגוון אפשרויות לבחירת ערכים של מאפייני משתמשים.

בצד הלקוח, אפשר להגדיר רק ערכי מחרוזת למאפייני משתמש. בתנאים שמשתמשים באופרטורים מספריים, שירות Remote Config ממיר את הערך של מאפיין המשתמש התואם למספר שלם או למספר ממשי.		 כשמשתמשים באופרטור מכיל ביטוי רגולרי, אפשר ליצור ביטויים רגולריים בפורמט RE2. הביטוי הרגולרי יכול להתאים לכל המחרוזת של גרסת היעד או לחלק ממנה. אפשר גם להשתמש בעוגנים ^ ו-$ כדי להתאים את ההתחלה, הסוף או כל מחרוזת היעד.
ארץ/אזור לא רלוונטי מדינה אחת או יותר, או אזור אחד או יותר, שמשמשים לבחירת משתמשים שעשויים להיכלל בניסוי.  
שפות לא רלוונטי שפה אחת או יותר ולוקאלים שמשמשים לבחירת משתמשים שעשויים להיכלל בניסוי.  
פתיחה ראשונה יותר מ-
פחות מ-
בין 		טירגוט משתמשים לפי הפעם הראשונה שהם פתחו את האפליקציה, בימים.
האינטראקציה האחרונה עם האפליקציה יותר מ-
פחות מ-
בין 		טירגוט משתמשים על סמך הפעם האחרונה שבה הם קיימו אינטראקציה עם האפליקציה, במספר ימים.

‫A/B Testing מדדים

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

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

  • סה"כ הכנסות משוערות כדי לראות את ההבדל בין שתי הגרסאות בהכנסות המשולבות מרכישות באפליקציה וממודעות.
  • שימור (יום אחד), שימור (2-3 ימים), שימור (4-7 ימים) כדי לעקוב אחרי שימור המשתמשים היומי או השבועי.

בטבלאות הבאות מוסבר איך מחושבים מדדי היעדים ומדדים אחרים.

מדדי יעדים

מדד תיאור
משתמשים שהאפליקציה שלהם לא קרסה אחוז המשתמשים שלא נתקלו באפליקציה בשגיאות שזוהו על ידי ה-SDK של Firebase Crashlytics במהלך הניסוי.

הערה: אין תמיכה ב-Firebase Crashlytics באפליקציות אינטרנט.
הכנסות משוערות מפרסום רווחים משוערים ממודעות.
ההכנסה הכוללת המשוערת הערך המשולב של הכנסות מרכישות והכנסות משוערות מפרסום.
הכנסות מרכישות הערך המשולב של כל האירועים מסוג purchase ו-in_app_purchase.
שימור משתמשים (יום אחד) מספר המשתמשים שחוזרים לאפליקציה שלכם על בסיס יומי.
שימור (יומיים-שלושה) מספר המשתמשים שחוזרים לאפליקציה תוך יומיים-שלושה.
שימור (4-7 ימים) מספר המשתמשים שחוזרים לאפליקציה תוך 4 עד 7 ימים.
שימור משתמשים (8-14 ימים) מספר המשתמשים שחוזרים לאפליקציה תוך 8 עד 14 ימים.
שימור (15 ימים ומעלה) מספר המשתמשים שחוזרים לאפליקציה 15 ימים או יותר אחרי הפעם האחרונה שהם השתמשו בה.
first_open אירוע Analytics שמופעל כשמשתמש פותח אפליקציה בפעם הראשונה אחרי שהוא התקין או התקין אותה מחדש. משמש כחלק ממשפך המרות.

מדדים נוספים

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

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