מידע על בדיקות A/B של Firebase

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

גודל המדגם

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

עריכת ניסויים

אפשר לערוך פרמטרים נבחרים של ניסויים פעילים, כולל:

• שם הניסוי
• תיאור
• תנאים לטירגוט
• ערכי וריאנטים

כדי לערוך ניסוי:

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

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

לוגיקה להקצאת וריאנטים בהגדרת תצורה מרחוק

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

Google Analytics קהלים כפופים לזמן אחזור ולא זמינים באופן מיידי כשמשתמש עומד לראשונה בקריטריונים של הקהל:

• כשיוצרים קהל חדש, יכול להיות שיחלפו 24 עד 48 שעות עד שיתחילו להתווסף אליו משתמשים חדשים.
• בדרך כלל, משתמשים חדשים מצטרפים לקהלים שעומדים בדרישות תוך 24 עד 48 שעות אחרי שהם עומדים בדרישות.

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

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

אירועי הפעלה

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

משקלים של וריאנטים

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

פירוש תוצאות הבדיקה

‫Firebase A/B Testing משתמשת בהסקה תדירותית כדי לעזור לכם להבין את הסבירות שתוצאות הניסוי התקבלו רק בגלל מקריות. הסבירות הזו מיוצגת על ידי ערך הסתברות, או ערך-p. ערך-p הוא ההסתברות להבדל בביצועים בגודל הזה או גדול יותר בין שני וריאנטים, שיכול היה להתרחש בגלל סיכוי אקראי אם למעשה אין השפעה, שנמדדת על ידי ערך בין 0 ל-1. ‫A/B Testing משתמש ברמת מובהקות של 0.05, כך ש:

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

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

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

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

לכל מדד מוצגים הנתונים הסטטיסטיים הבאים:

נתונים שנצפו

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

נתוני הסקה

• 95% CI (Difference in means) מציג רווח שמכיל את הערך ה "אמיתי" של המדד שנמצא במעקב, עם רמת סמך של 95%. לדוגמה, אם תוצאות הניסוי מראות שרווחים כוללים משוערים נמצאים בטווח של 5 $עד 10 $עם מרווח סמך של 95%, יש סיכוי של 95% שההבדל האמיתי בין הממוצעים הוא בין 5 $ל-10$. אם טווח מהימנות כולל את 0, לא זוהה הבדל בעל מובהקות סטטיסטית בין הווריאנט לבין ערך הבסיס.

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

• ערך p, שמייצג את ההסתברות לצפייה בנתונים קיצוניים כמו התוצאות שהתקבלו בניסוי, בהנחה שאין הבדל אמיתי בין הווריאציה לבין קבוצת הבסיס. ככל שמובהקות התוצאה (p-value) נמוכה יותר, כך גדל הביטחון שהביצועים שנצפו יישארו כאלה אם נחזור על הניסוי. ערך של 0.05 ומטה מצביע על הבדל משמעותי ועל סבירות נמוכה לכך שהתוצאות מקריות. ערכי ה-p מבוססים על בדיקה חד-זנבית, שבה ערך הווריאציה גדול מערך הבסיס. ‫Firebase משתמש במבחן t עם שונות לא שווה למשתנים רציפים (ערכים מספריים, כמו הכנסה) ובמבחן z של פרופורציות לנתוני המרות (ערכים בינאריים, כמו שימור משתמשים, משתמשים שלא נתקלו בקריסה, משתמשים שמפעילים אירוע Google Analytics).

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

• כמה גבוה או נמוך יותר כל מדד בניסוי בהשוואה לנתוני הבסיס, כפי שנמדד ישירות (כלומר, הנתונים שנצפו בפועל)
• הסבירות שההבדל שנצפה בין הווריאנט לבין קו הבסיס יכול היה להתרחש בגלל סיכוי אקראי (ערך p)
• טווח שסביר שיכלול את ההבדל 'האמיתי' בביצועים בין הווריאנט לבין ערך הבסיס של כל מדד בניסוי – דרך להבין את תרחישי הביצועים של 'המקרה הטוב ביותר' ו'המקרה הגרוע ביותר'

פירוש תוצאות של ניסויים שמבוססים על Google Optimize

Firebase A/B Testing תוצאות של ניסויים שהתחילו לפני 23 באוקטובר 2023 התבססו על Google Optimize. ‫Google Optimize השתמש בהסקת מסקנות בייסיאנית כדי ליצור נתונים סטטיסטיים בעלי תובנות מנתוני הניסוי.

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

לכל מדד מוצגים הנתונים הסטטיסטיים הבאים:

נתונים שנצפו

• הערך הכולל (סכום המדד לכל המשתמשים בווריאציה)
• ערך ממוצע (הערך הממוצע של המדד עבור משתמשים בווריאציה)
• הפרש באחוזים מהערך הבסיסי

נתונים לפי מודל

• ההסתברות לגבור על ערך הבסיס: מה הסיכוי שהמדד גבוה יותר בווריאציה הזו בהשוואה לערך הבסיס
• ההבדל באחוזים לעומת ערך הבסיס: מבוסס על האומדנים החציוניים של המדד עבור הווריאנט וערך הבסיס
• טווח המדד: הטווחים שבהם סביר להניח שהערך של המדד יימצא, ברמת ודאות של 50% ו-95%

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

1. כמה גבוה או נמוך יותר כל מדד בניסוי בהשוואה לנתוני הבסיס, כפי שנמדד ישירות (כלומר, הנתונים שנצפו בפועל)
2. הסיכוי המשוער שכל מדד בניסוי יהיה גבוה יותר מהמדד הבסיסי או מהמדד הכולל הטוב ביותר, על סמך הסקה בייסיאנית (ההסתברות להיות טוב יותר או הכי טוב, בהתאמה)
3. הטווחים הסבירים לכל מדד בניסוי על סמך הסקה בייסיאנית – תרחישי 'המקרה הטוב ביותר' ו'המקרה הגרוע ביותר' (מרווחי מהימנות)

קביעת הבכיר בארגון

בניסויים שבהם נעשה שימוש בהסקת מסקנות תדירותית, מערכת Firebase מחליטה שאחד הווריאנטים מוביל אם יש הבדלים עם מובהקות סטטיסטית בין הביצועים של הווריאנט לבין הביצועים של ערך הבסיס במדד היעד. אם כמה וריאנטים עומדים בקריטריונים האלה, נבחר הווריאנט עם ערך ה-p הנמוך ביותר.

בניסויים שנעשה בהם שימוש ב-Google Optimize, מערכת Firebase קבעה שאחד הווריאנטים הוא "המוביל הברור" אם היה סיכוי של יותר מ-95% שהוא יהיה טוב יותר מווריאנט הבסיס במדד העיקרי. אם כמה וריאנטים עמדו בקריטריונים של 'מוביל ברור', רק הווריאנט עם הביצועים הכי טובים קיבל את התווית 'מוביל ברור'.

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

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

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

משך הניסוי

מומלץ להמשיך להריץ ניסוי ב-Firebase עד שמתקיימים התנאים הבאים:

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

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

סכימה של 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, לוחצים על ניהול. אחרת, לוחצים על קישור.
3. בודקים את המידע במאמר מידע על קישור Firebase אל BigQuery ואז לוחצים על הבא.
4. בקטע Configure integration (הגדרת שילוב), מעבירים את המתג Google Analytics למצב מופעל.

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

   הערה: מידע נוסף על Google Analytics בהגדרות של Firebase זמין במאמר איסוף נתונים.

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 אירועים.

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

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

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

טיפ: השלבים האלה מתארים שימוש במסוף Google Cloud, אבל אפשר גם להשתמש ב-CLI או בספריות לקוח כדי לשלוח שאילתות ל-BigQuery. מידע נוסף זמין במאמרי העזרה בנושא BigQuery.

הפעלת שאילתות על נתוני ניסוי באמצעות שאילתה שנוצרה אוטומטית במסוף 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

מגבלות

מספר הניסויים ב-A/B Testing מוגבל ל-300 ניסויים בסך הכול, 24 ניסויים פעילים ו-24 ניסויים בטיוטה. המגבלות האלה משותפות עם Remote Config השקות. לדוגמה, אם יש לכם שני תהליכי השקה פעילים ושלושה ניסויים פעילים, תוכלו להפעיל עד 19 תהליכי השקה או ניסויים נוספים.

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

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

בניסוי יכולות להיות עד 8 וריאציות (כולל וריאציית הבסיס) ועד 25 פרמטרים לכל וריאציה. הגודל של ניסוי יכול להיות עד 200KB בערך. המידע הזה כולל שמות של וריאנטים, פרמטרים של וריאנטים ומטא-נתונים אחרים של הגדרות.