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

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

גודל המדגם

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

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

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

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

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

  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 מציין הבדל בעל מובהקות סטטיסטית בין הווריאנטים, כלומר סביר להניח שהוא לא התרחש במקרה.
  • ערך-p גבוה מ-0.05 מציין שלהבדל בין הווריאנטים אין מובהקות סטטיסטית.

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

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

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

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

נתונים מתועדים

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

נתוני ההסקה

  • רווח בר-סמך של 95% (הפרש בין ממוצעים) מציג מרווח שמכיל את הערך 'האמיתי' של המדד במעקב עם רמת סמך של 95%. לדוגמה, אם התוצאות של הניסוי מניבות טווח CI של 95% להכנסה הכוללת המשוערת בין 20 ל-40 ש"ח, יש סיכוי של 95% שההפרש האמיתי בין הממוצעים הוא בין 20 ל-40 ש"ח. אם טווח ה-CI כולל את הערך 0, לא זוהה הבדל בעל מובהקות סטטיסטית בין הווריאנט לבין ערך הבסיס.

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

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

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

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

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

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

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

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

נתונים שנצפו

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

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

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

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

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

קביעת המנהיג/ה

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

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

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

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

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

משך הניסוי

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

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

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

סכימה של 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 sandbox.

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

  1. פותחים את הכרטיסייה Integrations (שילובים). אפשר לגשת אליה באמצעות > Project settings (הגדרות הפרויקט) במסוף Firebase.
  2. אם אתם כבר משתמשים ב-BigQuery עם שירותי Firebase אחרים, צריך ללחוץ על ניהול. אחרת, לוחצים על קישור.
  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: זהו מזהה הנכס Google Analytics בן 9 הספרות. אפשר למצוא אותו ב-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. בוחרים את הפרויקט ואז בוחרים באפשרות Create SQL query.
  3. מוסיפים את השאילתה. בקישור הצגת שאילתות לדוגמה מפורטות שאילתות לדוגמה שאפשר להריץ.
  4. לוחצים על Run.

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

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

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

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

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

  /*
    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. משפט ה-SQL הבא מסיר את הווריאנטים של הניסוי, את מספר המשתמשים הייחודיים בכל וריאנט ומחשב את הסכום הכולל של ההכנסות מאירועים מסוג in_app_purchase ו-ecommerce_purchase, ואת סטיות התקן של כל הניסויים בטווח הזמן שצוין בתאריכי ההתחלה והסיום של _TABLE_SUFFIX.BigQuery אתם יכולים להשתמש בנתונים שמתקבלים מהשאילתה הזו עם גנרטור של מובהקות סטטיסטית לבדיקות 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. המידע הזה כולל שמות של וריאנטים, פרמטרים של וריאנטים ומטא-נתונים אחרים של הגדרות.