יצירת ניסויים של הגדרת תצורה מרחוק ב-Firebase עם בדיקות A/B

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

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

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

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

יצירת ניסוי

Remote Config ניסוי מאפשר להעריך כמה וריאנטים על פרמטר אחד או יותר של Remote Config.

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

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

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

  3. לוחצים על יצירת ניסוי ואז על Remote Config כשמוצגת בקשה לבחירת השירות שרוצים לבדוק.

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

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

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

    • פתיחה ראשונה: טירגוט משתמשים על סמך הפעם הראשונה שהם פתחו את האפליקציה

      טירגוט משתמשים לפי זמן הפתיחה הראשון זמין אחרי שבוחרים אפליקציית Android או iOS. הוא נתמך בגרסאות הבאות של SDK: ‏ Apple platforms SDK v9.0.0+‎ ו-Android SDK v21.1.1+‎ (Firebase BoM v30.3.0+‎).Remote Config

      בנוסף, צריך להפעיל את Analytics בלקוח במהלך אירוע הפתיחה הראשון.

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

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

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

    • app_install
    • app_remove
    • app_update
    • dynamic_link_first_open

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

  9. בקטע וריאנטים, בוחרים קמפיין בסיסי ולפחות וריאנט אחד לניסוי. משתמשים ברשימה Choose or create new (בחירה או יצירה של פרמטר חדש) כדי להוסיף פרמטר אחד או יותר לניסוי. אפשר ליצור פרמטר שלא נעשה בו שימוש בעבר במסוף Firebase, אבל הוא צריך להיות קיים באפליקציה כדי שתהיה לו השפעה. כדי להוסיף עוד פרמטרים לניסוי, חוזרים על השלב הזה.

  10. (אופציונלי) כדי להוסיף יותר מווריאציה אחת לניסוי, לוחצים על הוספת וריאציה נוספת.

  11. משנים פרמטר אחד או יותר של וריאציות ספציפיות. כל הפרמטרים שלא השתנו זהים למשתמשים שלא נכללים בניסוי.

  12. מרחיבים את הקטע Variant Weights (חלוקת התנועה בין הווריאנטים) כדי לראות או לשנות את חלוקת התנועה בין הווריאנטים בניסוי. כברירת מחדל, אחוז המשתמשים מתחלק בין הווריאנטים באופן שווה. חשוב לשים לב שחלוקה לא שווה עשויה להאריך את משך הזמן שנדרש לאיסוף הנתונים, ולאחר הפעלת הניסוי לא ניתן לשנות את החלוקה לאחוזים.

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

מותר ליצור עד 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

    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

    C++‎

    ‫
    firebase::InitResult init_result;
auto* installations_object = firebase::installations::Installations::GetInstance(
    firebase::App::GetInstance(), &init_result);
installations_object->GetToken().OnCompletion(
    [](const firebase::Future<std::string>& future) {
      if (future.status() == kFutureStatusComplete &&
          future.error() == firebase::installations::kErrorNone) {
        printf("Installations Auth Token %s\n", future.result()->c_str());
      }
    });

    Unity

    Firebase.Installations.FirebaseInstallations.DefaultInstance.GetTokenAsync(forceRefresh: true).ContinueWith(
  task => {
    if (!(task.IsCanceled || task.IsFaulted) && task.IsCompleted) {
      UnityEngine.Debug.Log(System.String.Format("Installations token {0}", task.Result));
    }
  });
  2. בסרגל הניווט של Firebase console, לוחצים על A/B Testing.
  3. לוחצים על טיוטה (או על פועל בניסויים של הגדרת תצורה מרחוק), מעבירים את העכבר מעל הניסוי, לוחצים על תפריט ההקשר () ואז על ניהול מכשירי בדיקה.
  4. מזינים את אסימון ההרשאה להתקנה של מכשיר הבדיקה ובוחרים את וריאציית הניסוי שרוצים לשלוח למכשיר הבדיקה.
  5. מריצים את האפליקציה ומוודאים שהווריאציה שנבחרה מתקבלת במכשיר הבדיקה.

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

ניהול הניסוי

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

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

התחלת ניסוי

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

במקרה של Remote Config, המשמעות היא שגם אם משתמש עומד בדרישות להכללה בקהל, אם Analytics עדיין לא הוסיף את המשתמש לקהל כשמופעלת הפונקציה fetchAndActivate(), המשתמש לא ייכלל בניסוי.

מאפיין משתמש לגבי טקסט:
מכיל,
לא מכיל,
תואם בדיוק,
מכיל ביטוי רגולרי

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

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

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

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

טירגוט משתמשים לפי פתיחה ראשונה זמין אחרי שבוחרים אפליקציה ל-Android או ל-iOS. התכונה נתמכת כרגע בגרסאות ה-SDK הבאות: Apple platforms SDK v9.0.0+‎ ו-Android SDK v21.1.1+‎ (Firebase BoM v30.3.0+‎).Remote Config

בנוסף, צריך להפעיל את Analytics בלקוח במהלך אירוע הפתיחה הראשון.

‫A/B Testing מדדים

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

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

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

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

מדדי יעדים

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

ייצוא נתונים ל-BigQuery

בנוסף לצפייה בנתוני הניסוי במסוף A/B Testing, אפשר לבדוק ולנתח את נתוני הניסוי ב-BigQuery.Firebase למרות של-A/B Testing אין טבלה נפרדת של BigQuery, חברות בניסויים ובגרסאות מאוחסנת בכל אירוע Google Analytics בטבלאות האירועים Analytics.

מאפייני המשתמש שמכילים מידע על הניסוי הם מהצורה userProperty.key like "firebase_exp_%" או userProperty.key = "firebase_exp_01", כאשר 01 הוא מזהה הניסוי וuserProperty.value.string_value מכיל את האינדקס (מבוסס-אפס) של וריאנט הניסוי.

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

כדי להתחיל, צריך לבצע את הפעולות הבאות כמו שמתואר במדריך הזה:

  1. הפעלת ייצוא של BigQuery ל-Google Analytics במסוף Firebase
  2. גישה לנתונים של A/B Testing באמצעות BigQuery
  3. דוגמאות לשאילתות

הפעלת ייצוא של BigQuery אל Google Analytics במסוף Firebase

אם אתם רשומים לתוכנית Spark, אתם יכולים להשתמש בBigQueryארגז החול כדי לגשת אל BigQuery ללא עלות, בכפוף למגבלות ארגז החול. מידע נוסף זמין במאמר בנושא תמחור וBigQueryארגז חול.

קודם כול, מוודאים שמייצאים את נתוני Analytics אל BigQuery:

  1. פותחים את הכרטיסייה Integrations (שילובים), שאליה אפשר לגשת באמצעות > Project settings (הגדרות הפרויקט) במסוף Firebase.
  2. אם אתם כבר משתמשים ב-BigQuery עם שירותים אחרים של Firebase, לוחצים על Manage (ניהול). אחרת, לוחצים על קישור.
  3. בודקים את המידע במאמר מידע על קישור Firebase אל BigQuery ואז לוחצים על הבא.
  4. בקטע Configure integration (הגדרת שילוב), מעבירים את המתג Google Analytics למצב מופעל.

  5. בוחרים אזור ומגדירים את הגדרות הייצוא.

  6. לוחצים על קישור אל BigQuery.

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

גישה לנתוני A/B Testing ב-BigQuery

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

  • מזהה הניסוי: אפשר להשיג אותו מכתובת ה-URL של הדף סקירה כללית של הניסוי. לדוגמה, אם כתובת ה-URL שלכם נראית כך: https://console.firebase.google.com/project/my_firebase_project/config/experiment/results/25, מזהה הניסוי הוא 25.
  • Google Analytics מזהה הנכס: זהו מזהה הנכס בן 9 הספרות.Google Analytics אפשר למצוא את המזהה הזה ב-Google Analytics. הוא מופיע גם ב-BigQuery כשמרחיבים את שם הפרויקט כדי להציג את השם של טבלת האירועים Google Analytics (project_name.analytics_000000000.events).
  • תאריך הניסוי: כדי ליצור שאילתה מהירה ויעילה יותר, מומלץ להגביל את השאילתות למחיצות של טבלת האירועים היומית Google Analyticsשמכילות את נתוני הניסוי – טבלאות שמזוהות עם סיומת YYYYMMDD. לכן, אם הניסוי שלכם פעל מ-2 בפברואר 2024 עד 2 במאי 2024, תציינו _TABLE_SUFFIX between '20240202' AND '20240502'. לדוגמה, אפשר לעיין במאמר בנושא בחירת ערכים של ניסוי ספציפי.
  • שמות האירועים: בדרך כלל, השמות האלה תואמים למדדי היעד שהגדרתם בניסוי. לדוגמה, in_app_purchaseאירועים, ad_impression או user_retention אירועים.

אחרי שאוספים את המידע שדרוש ליצירת השאילתה:

  1. פותחים את BigQuery במסוף Google Cloud.
  2. בוחרים את הפרויקט ואז בוחרים באפשרות יצירת שאילתת SQL.
  3. מוסיפים את השאילתה. דוגמאות לשאילתות שאפשר להריץ זמינות במאמר דוגמאות לשאילתות.
  4. לוחצים על Run.

הפעלת שאילתות על נתוני ניסוי באמצעות שאילתה שנוצרה אוטומטית במסוף Firebase

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

כדי לקבל ולהריץ את השאילתה שנוצרה אוטומטית:

  1. במסוף Firebase, פותחים את A/B Testing ובוחרים את ניסוי A/B Testing שרוצים לשלוח לו שאילתה כדי לפתוח את הסקירה הכללית של הניסוי.
  2. בתפריט 'אפשרויות', מתחת לשילוב של BigQuery, בוחרים באפשרות שאילתת נתוני ניסוי. הפרויקט ייפתח ב-BigQuery במסוף Google Cloud, ותוצג שאילתה בסיסית שאפשר להשתמש בה כדי ליצור שאילתה של נתוני הניסוי.

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

  /*
    This query is auto-generated by Firebase A/B Testing for your
    experiment "Winter welcome experiment".
    It demonstrates how you can get event counts for all Analytics
    events logged by each variant of this experiment's population.
  */
  SELECT
    'Winter welcome experiment' AS experimentName,
    CASE userProperty.value.string_value
      WHEN '0' THEN 'Baseline'
      WHEN '1' THEN 'Welcome message (1)'
      WHEN '2' THEN 'Welcome message (2)'
      END AS experimentVariant,
    event_name AS eventName,
    COUNT(*) AS count
  FROM
    `analytics_000000000.events_*`,
    UNNEST(user_properties) AS userProperty
  WHERE
    (_TABLE_SUFFIX BETWEEN '20240202' AND '20240502')
    AND userProperty.key = 'firebase_exp_25'
  GROUP BY
    experimentVariant, eventName

דוגמאות נוספות לשאילתות זמינות במאמר דוגמאות לשאילתות.

דוגמאות לשאילתות

בקטעים הבאים מופיעות דוגמאות לשאילתות שאפשר להשתמש בהן כדי לחלץ A/B Testing נתוני ניסויים מטבלאות של אירועים ב-Google Analytics.

חילוץ ערכי סטיית תקן של רכישות וניסויים מכל הניסויים

אתם יכולים להשתמש בנתוני התוצאות של הניסוי כדי לאמת באופן עצמאי את התוצאות של Firebase A/B Testing. ההוראה הבאה של BigQuery SQL מחילה חילוץ של וריאציות של ניסויים, מספר המשתמשים הייחודיים בכל וריאציה וסכום ההכנסה הכוללת מאירועים מסוג in_app_purchase ו-ecommerce_purchase, וכן סטיות תקן לכל הניסויים בטווח הזמן שצוין כתאריכי ההתחלה והסיום של _TABLE_SUFFIX. אתם יכולים להשתמש בנתונים שמתקבלים מהשאילתה הזו עם מחולל מובהקות סטטיסטית למבחני t חד-זנביים, כדי לוודא שהתוצאות ש-Firebase מספקת תואמות לניתוח שלכם.

מידע נוסף על אופן החישוב של ההסקה ב-A/B Testing זמין במאמר הסבר על תוצאות הבדיקה.

  /*
    This query returns all experiment variants, number of unique users,
    the average USD spent per user, and the standard deviation for all
    experiments within the date range specified for _TABLE_SUFFIX.
  */
  SELECT
    experimentNumber,
    experimentVariant,
    COUNT(*) AS unique_users,
    AVG(usd_value) AS usd_value_per_user,
    STDDEV(usd_value) AS std_dev
  FROM
    (
      SELECT
        userProperty.key AS experimentNumber,
        userProperty.value.string_value AS experimentVariant,
        user_pseudo_id,
        SUM(
          CASE
            WHEN event_name IN ('in_app_purchase', 'ecommerce_purchase')
              THEN event_value_in_usd
            ELSE 0
            END) AS usd_value
      FROM `PROJECT_NAME.analytics_ANALYTICS_ID.events_*`
      CROSS JOIN UNNEST(user_properties) AS userProperty
      WHERE
        userProperty.key LIKE 'firebase_exp_%'
        AND event_name IN ('in_app_purchase', 'ecommerce_purchase')
        AND (_TABLE_SUFFIX BETWEEN 'YYYYMMDD' AND 'YYYMMDD')
      GROUP BY 1, 2, 3
    )
  GROUP BY 1, 2
  ORDER BY 1, 2;

בחירת ערכים של ניסוי ספציפי

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

  SELECT
    'EXPERIMENT_NAME' AS experimentName,
    CASE userProperty.value.string_value
      WHEN '0' THEN 'Baseline'
      WHEN '1' THEN 'VARIANT_1_NAME'
      WHEN '2' THEN 'VARIANT_2_NAME'
      END AS experimentVariant,
    event_name AS eventName,
    COUNT(*) AS count
  FROM
    `analytics_ANALYTICS_PROPERTY.events_*`,
    UNNEST(user_properties) AS userProperty
  WHERE
    (_TABLE_SUFFIX BETWEEN 'YYYMMDD' AND 'YYYMMDD')
    AND userProperty.key = 'firebase_exp_EXPERIMENT_NUMBER'
  GROUP BY
    experimentVariant, eventName