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

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

גודל הדגימה

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

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

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

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

כך עורכים ניסוי:

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

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

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

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

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

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

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

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

אירועי הפעלה

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

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

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

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

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

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

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

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

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

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

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

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

נתוני הנחות

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

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

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

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

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

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