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

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

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

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

יצירת ניסוי

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

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

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

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

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

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

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

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

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

7. בקטע Variants (וריאציות), מקלידים הודעה לשליחה לקבוצת הבסיס בשדה Enter message text (הזנת טקסט ההודעה). כדי לא לשלוח הודעה לקבוצת הבסיס, משאירים את השדה הזה ריק.

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

9. (אופציונלי) מזינים שם לכל וריאנט בניסוי כדי להחליף את השמות וריאנט A, וריאנט B וכו'.

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

11. בוחרים אפשרויות להודעה:

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

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

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

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

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

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

   Swift

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

   Objective-C

   [[FIRMessaging messaging] tokenWithCompletion:^(NSString * _Nullable token, NSError * _Nullable error) {
     if (error != nil) {
       NSLog(@"Error fetching the remote FCM registration token: %@", error);
     } else {
       NSLog(@"Remote FCM registration token: %@", token);
       NSString* message =
         [NSString stringWithFormat:@"FCM registration token: %@", token];
       // display message
       NSLog(@"%@", message);
     }
   }];

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

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

ניהול הניסוי

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

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

התחלת ניסוי

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

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

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

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

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

   • % difference from baseline: A measure of the improvement of a metric for a given variant as compared to the baseline. החישוב מתבצע על ידי השוואה בין טווח הערכים של הווריאציה לבין טווח הערכים של קו הבסיס.
   • ההסתברות לגבור שיעור ההמרה הבסיסי: ההסתברות המשוערת שוריאנט מסוים ישיג תוצאות טובות יותר מקו הבסיס במדד שנבחר.
   • observed_metric לכל משתמש: על סמך תוצאות הניסוי, זהו הטווח החזוי שערך המדד ייכלל בו לאורך זמן.
   • סה"כ observed_metric: הערך המצטבר שנצפה עבור קו הבסיס או הווריאציה. הערך הזה משמש למדידת הביצועים של כל וריאנט בניסוי, ולחישוב המדדים שיפור, טווח ערכים, ההסתברות לגבור שיעור ההמרה הבסיסי והסיכוי להיות הווריאציה הטובה ביותר. בהתאם למדד שנמדד, יכול להיות שהתווית של העמודה הזו תהיה 'משך הזמן לכל משתמש', 'הכנסה לכל משתמש', 'שיעור שימור' או 'שיעור המרה'.

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

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

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

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

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

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

הרחבת ניסוי

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

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

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

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

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

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

‫A/B Testing מדדים

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

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

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

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

מדדי יעדים

מדדים נוספים

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

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

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

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

3. אם אתם צריכים להגדיר ייצוא:

   1. קוראים את המאמר מידע על קישור Firebase אל BigQuery ואז לוחצים על הבא.

   2. בקטע Configure integration (הגדרת השילוב), מפעילים את האפשרות Google Analytics.

   3. בוחרים אזור וקובעים את הגדרות הייצוא.

   4. לוחצים על קישור אל 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. במסוף Google Cloud, עוברים אל BigQuery.
2. בוחרים את הפרויקט ואז בוחרים באפשרות יצירת שאילתת SQL.
3. מוסיפים את השאילתה. דוגמאות לשאילתות שאפשר להריץ זמינות במאמר דוגמאות לשאילתות.
4. לוחצים על Run.

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

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

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

1. במסוף Firebase, עוברים אל DevOps & Engagement (פיתוח אפליקציות ואינטראקציה) >‏ A/B Testing (בדיקות A/B).
2. בוחרים את הניסוי A/B Testing שרוצים לשלוח לו שאילתה כדי לפתוח את סקירת הניסוי.
3. בתפריט 'אפשרויות', מתחת לשילוב של 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