כדי לעזור לכם להפיק את המקסימום מהרלוונטיות והתועלת של תוצאות הבדיקה, בדף הזה מוסבר בפירוט איך Firebase A/B Testing פועל.
גודל הדוגמה
הסקה Firebase A/B Testing לא דורשת זיהוי של גודל מדגם מינימלי לפני שמתחילים ניסוי. באופן כללי, כדאי לבחור את רמת החשיפה הגבוהה ביותר לניסוי שאתם מרגישים בנוח איתה. ככל שגודל המדגם גדול יותר, כך גדל הסיכוי למצוא תוצאה בעלת מובהקות סטטיסטית, במיוחד כשההבדלים בביצועים בין הווריאציות קטנים. כדאי גם להיעזר במחשבון מקוון לגודל המדגם כדי למצוא את גודל המדגם המומלץ על סמך מאפייני הניסוי.
עריכת ניסויים
אתם יכולים לערוך פרמטרים מסוימים של ניסויים פעילים, כולל:
- שם הניסוי
- תיאור
- תנאי טירגוט
- ערכי וריאציות
כדי לערוך ניסוי:
- במסוף Firebase, עוברים אל DevOps & Engagement (DevOps ומעורבות) > A/B Testing (בדיקת A/B).
- פותחים את דף התוצאות של הניסוי שרוצים לשנות.
- בתפריט אפשרויות נוספות , לוחצים על עריכת הניסוי הפעיל.
- מבצעים את השינויים הרצויים ולוחצים על פרסום.
חשוב לזכור ששינוי ההתנהגות של האפליקציה בזמן שהניסוי פועל עלול להשפיע על התוצאות.
לוגיקת הקצאת הווריאנטים של הגדרת התצורה מרחוק
משתמשים שעומדים בכל תנאי הטירגוט של הניסוי (כולל תנאי אחוז החשיפה) מוקצים לווריאנטים של הניסוי בהתאם למשקלי הווריאנטים ולגיבוב (hash) של מזהה הניסוי ומזהה ההתקנה של 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% (הפרש בממוצעים) מציג רווח שמכיל את הערך "האמיתי" של המדד שאחריו עוקבים, ברמת סמך של 95%. לדוגמה, אם הניסוי מניב רווח בר-סמך של 95% לסך ההכנסות המשוער בין 5 $ל-10$, יש סיכוי של 95% שההבדל האמיתי בממוצעים הוא בין 5 $ל-10$. אם טווח רווח הסמך כולל את הערך 0, לא זוהה הבדל בעל מובהקות סטטיסטית בין הווריאנט לבין ערך הבסיס.
ערכי הרווח בר-הסמך מופיעים בפורמט שתואם למדד שאחריו עוקבים. לדוגמה, זמן (ב
HH:MM:SS) לשימור משתמשים, דולר ארה"ב להכנסות מפרסום לכל משתמש ואחוז לשיעור ההמרה.ערך p-value, שמייצג את ההסתברות לראות נתונים קיצוניים כמו התוצאות שהתקבלו בניסוי, בהנחה שאין הבדל אמיתי בין הווריאציה לבין קו הבסיס. ככל שערך ה-p נמוך יותר, כך רמת הסמך גבוהה יותר שהביצועים שנצפו יישארו נכונים אם נחזור על הניסוי. ערך של 0.05 או פחות מצביע על הבדל משמעותי ועל סבירות נמוכה שהתוצאות מקריות. ערכי ה-p מבוססים על מבחן חד-צדדי, שבו הערך של הווריאנט גדול מהערך של קו הבסיס. מערכת Firebase משתמשת במבחן t לשונות לא שווה למשתנים רציפים (ערכים מספריים, כמו הכנסה) ובמבחן z לפרופורציות לנתוני המרות (ערכים בינאריים, כמו שימור משתמשים, משתמשים שלא חוו קריסות, משתמשים שמפעילים אירוע Google Analytics).
תוצאות הניסוי מספקות תובנות חשובות לגבי כל וריאנט של הניסוי, כולל:
- עד כמה כל מדד בניסוי גבוה או נמוך יותר בהשוואה לקו הבסיס, כפי שנמדד ישירות (כלומר, הנתונים שנצפו בפועל)
- הסבירות שההבדל שנצפה בין הווריאנט לבין קו הבסיס יכול היה להתרחש באופן מקרי (ערך p-value)
- טווח שסביר להניח שיכיל את ההבדל "האמיתי" בביצועים בין הווריאנט לבין ערך הבסיס לכל מדד בניסוי – דרך להבין את תרחישי הביצועים "במקרה הטוב ביותר" ו "במקרה הגרוע ביותר"
החלטה של המנהיג
בניסויים שמשתמשים בהסקה שכיחותנית, מערכת Firebase מחליטה שאחד הווריאנטים מוביל אם יש הבדלים עם מובהקות סטטיסטית בין הביצועים של הווריאנט לבין הביצועים של ערך הבסיס במדד היעד. אם כמה וריאנטים עומדים בקריטריונים האלה, נבחר הווריאנט עם ערך ה-p הנמוך ביותר.
מכיוון שקביעת הווריאנט המוביל מבוססת רק על היעד העיקרי, כדאי לשקול את כל הגורמים הרלוונטיים ולבדוק את התוצאות של המדדים המשניים לפני שמחליטים אם כדאי להשיק וריאנט מוביל או לא. כדאי לשקול את היתרון הצפוי של השינוי, את הסיכון (כמו הקצה התחתון של הרווח בר-הסמך לשיפור) ואת ההשפעה על מדדים אחרים מלבד היעד הראשי.
לדוגמה, אם המדד הראשי הוא "משתמשים ללא קריסות", ווריאנט א' מוביל בבירור על פני קו הבסיס, אבל מדדי שימור המשתמשים של וריאנט א' נמוכים יותר משימור המשתמשים של קו הבסיס, כדאי לבדוק את הנושא לעומק לפני שמשיקים את וריאנט א' באופן נרחב יותר.
אתם יכולים להשיק כל וריאנט, לא רק את הווריאנט המוביל, על סמך ההערכה הכוללת של הביצועים במדדים הראשיים והמשניים.
משך הניסוי
ב-Firebase מומלץ להמשיך להריץ ניסוי עד שמתקיימים התנאים הבאים:
- הניסוי צבר מספיק נתונים כדי לספק תוצאה שימושית. הניסויים ונתוני התוצאות מתעדכנים פעם ביום. כדי להעריך את גודל המדגם המומלץ לניסוי, אפשר להיעזר במחשבון גודל מדגם אונליין.
- הניסוי פעל מספיק זמן כדי להבטיח מדגם מייצג של המשתמשים ולמדוד את הביצועים לטווח ארוך יותר. שבועיים הם משך הזמן המינימלי המומלץ להרצה של ניסוי טיפוסי בהגדרת תצורה מרחוק.
נתוני הניסוי מעובדים במשך 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.
כדי להתחיל, צריך לבצע את הפעולות הבאות, כפי שמתואר במדריך הזה:
- הפעלת הייצוא של BigQuery ל-Google Analytics במסוף Firebase
- גישה לנתונים של A/B Testing באמצעות BigQuery
- שאילתות לדוגמה
צריך להפעיל את הייצוא של BigQuery עבור Google Analytics במסוף Firebase
אם אתם מנויים בתוכנית Spark, אתם יכולים להשתמש בארגז החול של BigQuery כדי לגשת ל-BigQuery ללא עלות, בכפוף למגבלות של ארגז החול. מידע נוסף זמין במאמר תמחור וארגז החול של BigQuery.
קודם כל, ודאו שאתם מייצאים את נתוני Analytics אל BigQuery:
במסוף Firebase, עוברים אל הכרטיסייה
הגדרות > שילובים.בכרטיס BigQuery, לוחצים על Manage ומוודאים שהפרויקט מייצא את נתוני Analytics אל BigQuery.
אם בכרטיס כתוב Link, צריך להגדיר את הייצוא (המשיכו לשלב הבא).
אם אתם צריכים להגדיר ייצוא:
קוראים את המידע בקטע מידע על קישור Firebase אל BigQuery ולוחצים על הבא.
בקטע Configure integration, מפעילים את Google Analytics.
בוחרים אזור ובוחרים את הגדרות הייצוא.
לוחצים על קישור אל 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 בפברואר 2026 עד 2 במאי 2026, צריך לציין_TABLE_SUFFIX between '20260202' AND '20260502'. לדוגמה, ראו בחירת ערכים של ניסוי ספציפי. - שמות האירועים: בדרך כלל, הם תואמים למדדי היעדים שהגדרתם בניסוי. לדוגמה, אירועי
in_app_purchase,ad_impressionאוuser_retention.
אחרי שאוספים את המידע שצריך כדי ליצור את השאילתה:
- במסוף Google Cloud, נכנסים לדף BigQuery.
- בוחרים את הפרויקט ולוחצים על יצירת שאילתת SQL.
- מוסיפים את השאילתה. במאמר שאילתות לדוגמה תוכלו למצוא דוגמאות לשאילתות שאפשר להריץ.
- לוחצים על Run.
הרצת שאילתות על נתוני הניסוי באמצעות השאילתה שנוצרה באופן אוטומטי במסוף Firebase
אם אתם משתמשים בתוכנית Blaze, בדף Experiment overview יש שאילתה לדוגמה שמחזירה את שם הניסוי, הווריאציות, שמות האירועים ומספר האירועים בניסוי שאתם צופים בו.
כדי לקבל ולהריץ את השאילתה שנוצרה אוטומטית:
- במסוף Firebase, עוברים אל DevOps & Engagement (DevOps ומעורבות) > A/B Testing (בדיקת A/B).
- בוחרים את הניסוי ב-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 '20260202' AND '20260502')
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 ניסויים פעילים. המגבלות האלה משותפות עם Remote Config השקות. לדוגמה, אם יש לכם שתי השקות פעילות ושלושה ניסויים פעילים, אתם יכולים להוסיף עד 19 השקות או ניסויים נוספים.
אם הגעתם למגבלה של 300 ניסויים, תצטרכו למחוק ניסוי קיים כדי ליצור ניסוי חדש.
אם הגעתם למגבלה של 24 ניסויים והשקות פעילים, תצטרכו להפסיק ניסוי או השקה פעילים לפני שתוכלו להתחיל ניסוי או השקה חדשים.
בניסוי יכולות להיות עד 8 וריאציות (כולל קבוצת הבקרה) ועד 25 פרמטרים לכל וריאציה. הגודל של ניסוי יכול להיות עד 200KiB בערך. המידע הזה כולל שמות של וריאנטים, פרמטרים של וריאנטים ומטא-נתונים אחרים של הגדרות אישיות.