יצירת ניסויים של העברת הודעות בתוך האפליקציה עם בדיקות 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. ממלאים את השדות בקטע Targeting (טירגוט). קודם בוחרים את האפליקציה שבה רוצים להפעיל את הניסוי. אתם יכולים גם לטרגט קבוצת משנה של משתמשים שישתתפו בניסוי, על ידי בחירת אפשרויות שכוללות את הפרטים הבאים:

    • גרסה: גרסה אחת או יותר של האפליקציה
    • קהל המשתמשים: קהלים ב-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?

ניהול הניסוי

לא משנה אם אתם יוצרים ניסוי באמצעות 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)		 מזינים ערך לגרסה אחת או יותר של האפליקציה שרוצים לכלול בניסוי.

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

כשמשתמשים באופרטור מכיל ביטוי רגולרי, אפשר ליצור ביטויים רגולריים בפורמט 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.
שימור משתמשים (יום אחד) מספר המשתמשים שחוזרים לאפליקציה שלכם מדי יום.
שימור (יומיים עד 3 ימים) מספר המשתמשים שחוזרים לאפליקציה תוך יומיים-שלושה.
שימור (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 שסופר את סשני המשתמשים באפליקציה. מידע נוסף זמין במאמר אירועים שנאספים באופן אוטומטי.