דף זה תורגם על ידי Cloud Translation API.

יצירת ניסויים בהעברת הודעות עם בדיקות A/B

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

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

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

יצירת ניסוי

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

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

אם לא הפעלתם את Google Analytics כשיצרתם את הפרויקט, תוכלו להפעיל אותו בכרטיסייה Integrations (שילובים). כדי לגשת אליה, לוחצים על > Project settings (הגדרות הפרויקט) במסוף Firebase.
בקטע Engage (התקשרות) בסרגל הניווט של Firebase Console, לוחצים על A/B Testing.
לוחצים על יצירת ניסוי ואז על התראות כשמוצגת בקשה לבחירת השירות שרוצים לבדוק.
מזינים שם ותיאור אופציונלי לניסוי ולוחצים על הבא.
ממלאים את השדות בקטע טירגוט, וקודם בוחרים את האפליקציה שבה רוצים להשתמש בניסוי. אפשר גם לטרגט קבוצת משנה של המשתמשים כדי להשתתף בניסוי, על ידי בחירת אפשרויות שכוללות את הדברים הבאים:
- גרסה: גרסה אחת או יותר של האפליקציה
- קהל משתמשים: קהלים שמשמשים לטירגוט משתמשיםAnalytics שעשויים להיכלל בניסוי
- מאפיין משתמש: מאפיין משתמש אחד או יותר לAnalyticsבחירת משתמשים שאולי ייכללו בניסוי
- מדינה או אזור: מדינה אחת או יותר או אזור אחד או יותר לבחירת משתמשים שאולי ייכללו בניסוי
- שפת המכשיר: שפה אחת או יותר ולוקאלים שמשמשים לבחירת משתמשים שאולי ייכללו בניסוי
- פתיחה ראשונה: טירגוט משתמשים על סמך הפעם הראשונה שבה הם פתחו את האפליקציה
- התעניינות אחרונה באפליקציה: טירגוט משתמשים על סמך הפעם האחרונה שבה הם הביעו התעניינות באפליקציה שלכם
הערה: יכול להיות שיחלפו 24-48 שעות עד שהמערכת תאסוף נתונים על ניסויים שמטרגטים קהלים של משתמשי Analytics. מידע נוסף על האפשרות הזו ועל אפשרויות טירגוט אחרות זמין במאמר בנושא טירגוט משתמשים.
מגדירים את אחוז המשתמשים המטורגטים: בוחרים את אחוז בסיס המשתמשים באפליקציה שתואם לקריטריונים שהוגדרו בקטע משתמשים מטורגטים, שרוצים לחלק באופן שווה בין קו הבסיס לבין וריאציה אחת או יותר בניסוי. אפשר להזין כל אחוז בין 0.01% ל-100%. האחוזים מוקצים מחדש למשתמשים באופן אקראי לכל ניסוי, כולל ניסויים משוכפלים.
בקטע וריאציות, כותבים את ההודעה שרוצים לשלוח לקבוצת הבסיס בשדה הזנת טקסט ההודעה. כדי לא לשלוח הודעה לקבוצת הבסיס, משאירים את השדה הזה ריק.
(אופציונלי) כדי להוסיף יותר מווריאציה אחת לניסוי, לוחצים על הוספת וריאציה. כברירת מחדל, בניסויים יש קבוצת בסיס אחת וגרסה אחת.
(אופציונלי) מזינים שם לכל וריאציה בניסוי כדי להחליף את השמות וריאציה א', וריאציה ב' וכו'.
מגדירים מדד יעד לניסוי כדי להשתמש בו בהערכת הווריאציות של הניסוי, וגם מדדים נוספים שרוצים מתוך הרשימה הנפתחת. המדדים האלה כוללים יעדים מובנים (התעניינות, רכישות, הכנסות, שימור וכו'), Analytics אירועי המרה וAnalyticsאירועים אחרים.
בוחרים אפשרויות להודעה:
- תאריך השליחה: בוחרים באפשרות שליחה עכשיו כדי להפעיל את הניסוי מיד אחרי השמירה, או באפשרות מתוזמן כדי לציין מועד עתידי להפעלת הניסוי.
- אפשרויות מתקדמות: כדי לבחור אפשרויות מתקדמות לכל ההתראות שנכללות בניסוי, מרחיבים את האפשרויות המתקדמות ומשנים את האפשרויות הרצויות מתוך רשימת האפשרויות.
לוחצים על בדיקה כדי לשמור את הניסוי.

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

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

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

כך מקבלים את FCM טוקן הרישום:

Swift

Messaging.messaging().token { token, error in
  if let error = error {
    print("Error fetching FCM registration token: \(error)")
  } else if let token = token {
    print("FCM registration token: \(token)")
    self.fcmRegTokenMessage.text  = "Remote FCM registration token: \(token)"
  }
}

Objective-C

[[FIRMessaging messaging] tokenWithCompletion:^(NSString *token, NSError *error) {
  if (error != nil) {
    NSLog(@"Error getting FCM registration token: %@", error);
  } else {
    NSLog(@"FCM registration token: %@", token);
    self.fcmRegTokenMessage.text = token;
  }
}];

Java

FirebaseMessaging.getInstance().getToken()
    .addOnCompleteListener(new OnCompleteListener<String>() {
        @Override
        public void onComplete(@NonNull Task<String> task) {
          if (!task.isSuccessful()) {
            Log.w(TAG, "Fetching FCM registration token failed", task.getException());
            return;
          }

          // Get new FCM registration token
          String token = task.getResult();

          // Log and toast
          String msg = getString(R.string.msg_token_fmt, token);
          Log.d(TAG, msg);
          Toast.makeText(MainActivity.this, msg, Toast.LENGTH_SHORT).show();
        }
    });

Kotlin

FirebaseMessaging.getInstance().token.addOnCompleteListener(OnCompleteListener { task ->
    if (!task.isSuccessful) {
        Log.w(TAG, "Fetching FCM registration token failed", task.exception)
        return@OnCompleteListener
    }

    // Get new FCM registration token
    val token = task.result

    // Log and toast
    val msg = getString(R.string.msg_token_fmt, token)
    Log.d(TAG, msg)
    Toast.makeText(baseContext, msg, Toast.LENGTH_SHORT).show()
})

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.Messaging.FirebaseMessaging.DefaultInstance.GetTokenAsync().ContinueWith(
  task => {
    if (!(task.IsCanceled || task.IsFaulted) && task.IsCompleted) {
      UnityEngine.Debug.Log(System.String.Format("FCM registration token {0}", task.Result));
    }
  });

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

ניהול הניסוי

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

ייצוא נתונים ל-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.

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

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

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

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

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

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

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

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

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

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

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

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

במסוף Firebase, פותחים את A/B Testing ובוחרים את ניסוי A/B Testing שרוצים לשלוח לו שאילתה כדי לפתוח את הסקירה הכללית של הניסוי.
בתפריט 'אפשרויות', מתחת לאפשרות שילוב של 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