יצירת ניסויים של הגדרת תצורה מרחוק ב-Firebase עם בדיקות A/B

הערה: התכונה הזו נתמכת באפליקציות ל-Android, ל-iOS ולאפליקציות אינטרנט.

כשמשתמשים ב-Firebase Remote Config כדי לפרוס הגדרות לאפליקציה עם בסיס משתמשים פעיל, חשוב לוודא שהכול נעשה בצורה נכונה. אתם יכולים להשתמש בניסויים ב-A/B Testing כדי לקבוע את הדברים הבאים:

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

הערה: עדכונים בזמן אמת נתמכים בניסויים ב-A/B Testing. כדי להשתמש בתכונה הזו, צריך לוודא שבאפליקציה מותקנות הגרסאות הנדרשות של ה-SDK (גרסה 34.13.0 ומעלה של Firebase SDK ל-Android, גרסה 12.13.0 ומעלה של Firebase SDK לפלטפורמות של Apple וגרסה 12.15.0 ומעלה של Firebase JavaScript SDK).

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

1. יוצרים את הניסוי.
2. ניהול הניסוי.

חשוב: ודאו שיש לכם את גרסת ה-SDK המינימלית ל-A/B Testing: Firebase SDK ל-Android גרסה 17.1.1 ואילך, Firebase SDK לפלטפורמות Apple גרסה 4.5.0 ו-Firebase JavaScript SDK גרסה 12.8.0.

יצירת ניסוי

ניסוי ב-Remote Config מאפשר לכם לבדוק כמה וריאציות של פרמטר אחד או יותר של Remote Config.

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

   אם לא הפעלתם את Google Analytics כשיצרתם את הפרויקט, אתם יכולים להפעיל אותו בכרטיסייה Settings > Integrations במסוף Firebase.

2. במסוף Firebase, עוברים אל DevOps ומעורבות > A/B Testing

3. לוחצים על Create experiment, ואז בוחרים באפשרות Remote Config כשמופיעה בקשה לבחור את השירות שרוצים לבדוק.

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

5. (אופציונלי) כדי להוסיף יותר מגרסה אחת לניסוי, לוחצים על הוספת גרסה.

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

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

8. מגדירים את הקריטריונים לטירגוט של הניסוי באמצעות התנאים של Remote Config:

   • שימוש חוזר בתנאי קיים: אם תנאי קיים בתבנית Remote Config כבר תואם לקהל היעד, בוחרים אותו מהרשימה.

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

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

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

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

     • גרסה: גרסה אחת או יותר של האפליקציה
     • מספר Build: מספר ה-Build (אפל) או קוד הגרסה (Android) של האפליקציה
     • פלטפורמה: פלטפורמה אחת או יותר (iOS,‏ Android או אינטרנט) לטירגוט
     • מערכת הפעלה: טירגוט משתמשים של אפליקציית אינטרנט על סמך מערכת ההפעלה והגרסה שלה
     • דפדפן: טירגוט משתמשים של אפליקציית אינטרנט על סמך הדפדפן וגרסת הדפדפן שלהם
     • קטגוריית מכשיר: טירגוט משתמשים באפליקציית אינטרנט לפי סוג המכשיר שלהם – נייד או לא נייד
     • שפות: שפה אחת או יותר והגדרות אזוריות שמשמשות לבחירת המשתמשים שעשויים להיכלל בניסוי.
     • מדינה או אזור: מדינה או אזור אחד או יותר לבחירת המשתמשים שצריכים להיכלל בניסוי
     • קהל המשתמשים: Analytics קהלים שמשמשים לטירגוט משתמשים שעשויים להיכלל בניסוי
     • מאפיין משתמש: מאפיין משתמש אחד או יותר ב-Analytics לבחירת משתמשים שעשויים להיכלל בניסוי
     • משתמש באחוז אקראי: טירגוט של אחוז אקראי של משתמשים בטווח אחוזונים מוגדר
     • פלח מיובא: טירגוט משתמשים ששייכים לפלחים מיובאים בהתאמה אישית שהועלו לפרויקט
     • תאריך/שעה: טירגוט משתמשים לפי חלון זמן ותאריך ספציפיים
     • פתיחה ראשונה: טירגוט משתמשים על סמך הפעם הראשונה שהם פתחו את האפליקציה
     • מזהה התקנה: טירגוט מכשירי בדיקה ספציפיים או מופעי לקוח ספציפיים באמצעות מזהי ההתקנה שלהם ב-Firebase‏ (FID)
     • המשתמש קיים: טירגוט לכל המשתמשים בכל האפליקציות בפרויקט
     • אות בהתאמה אישית: טירגוט משתמשים על סמך אותות של מפתח/ערך בהתאמה אישית בצד הלקוח, שמועברים בזמן הריצה
   הערה: בגלל זמן האחזור של עיבוד הנתונים ב-Google Analytics, יכול להיות שיידרש יותר זמן כדי לצבור נתונים בניסויים שמטרגטים קהלי משתמשים ב-Analytics. מידע נוסף על האפשרות הזו ועל אפשרויות טירגוט אחרות זמין במאמר טירגוט משתמשים.

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

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

    הערה: אירועי הפעלה לא נתמכים בהטמעות של A/B Testing באתר.

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

    • app_install
    • app_remove
    • app_update

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

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

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

הערה: כשהניסוי פועל, אפשר לעקוב אחרי אחוז השליפה של וריאציות הבדיקה לעומת ערך ברירת המחדל בדף DevOps & Engagement > Remote Config > Parameters במסוף Firebase.

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

ניהול הניסוי

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

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

עריכת ניסוי

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

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

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

1. בקטע DevOps & Engagement בתפריט הניווט של מסוף Firebase, לוחצים על Remote Config.
2. לוחצים על הכרטיסייה בדיקות A/B.

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

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

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

טיפ: אתם יכולים למיין לפי עמודה ולסנן את הניסויים של בדיקות ה-A/B לפי שם וסטטוס הניסוי.

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

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

1. בקטע DevOps & Engagement בתפריט הניווט של מסוף Firebase, לוחצים על Remote Config.
2. לוחצים על הכרטיסייה בדיקות A/B.
3. לוחצים על Completed או על Running, לוחצים על הניסוי שרוצים להשיק לכל המשתמשים, לוחצים על תפריט ההקשר () ואז על Roll out variant.
4. כדי להשיק את הניסוי לכל המשתמשים:
   • בניסוי Remote Config, בוחרים וריאנט כדי לקבוע אילו ערכי פרמטרים של Remote Config יתעדכנו. הקריטריונים לטירגוט שהוגדרו בזמן יצירת הניסוי יתווספו כתנאי חדש בתבנית, כדי שהפעלת הווריאנט תשפיע רק על המשתמשים שטורגטו בניסוי. אחרי שלוחצים על Review in Remote Config (בדיקה בהגדרת תצורה מרחוק) כדי לבדוק את השינויים, לוחצים על Publish changes (פרסום השינויים) כדי להשלים את ההשקה.

הרחבת ניסוי

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

1. בקטע DevOps & Engagement בתפריט הניווט של מסוף Firebase, לוחצים על Remote Config.
2. לוחצים על הכרטיסייה בדיקות A/B.
3. בוחרים את הניסוי הפעיל שרוצים לערוך.
4. ב-Experiment overview, לוחצים על תפריט ההקשר () ואז על Edit running experiment.
5. בתיבת הדו-שיח Targeting מוצגת אפשרות להגדיל את אחוז המשתמשים שמשתתפים בניסוי הפעיל. בוחרים מספר שגבוה מהאחוז הנוכחי ולוחצים על פרסום. הניסוי יופץ לאחוז המשתמשים שציינתם.

שכפול ניסוי

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

הפסקת ניסוי

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

זיהוי לקוח באינטרנט והתמדה בניסויים

הערה: הקטע הזה רלוונטי רק לאפליקציות אינטרנט.

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

מערכת Firebase A/B Testing משתמשת ב-FID כדי להקצות משתמשים לווריאנטים של ניסויים, ומערכת Google Analytics משתמשת בו לצבירת אירועים כדי למדוד ולנתח את התנהגות המשתמשים בכל וריאנט.

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

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

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

במסוף Firebase יש תמיכה בסוגי הכללים הבאים. תכונות מקבילות זמינות ב-API בארכיטקטורת REST של Remote Config, כפי שמפורט בהפניה לביטויים מותנים.

סוג הכלל	מפעילים	ערכים	הערה
אפליקציה	==	בוחרים מזהה אפליקציה מרשימת מזהי האפליקציות שמשויכות לפרויקט ב-Firebase.	כשמוסיפים אפליקציה ל-Firebase, מזינים מזהה חבילה או שם חבילה של Android שמגדירים מאפיין שמוצג בתור מזהה אפליקציה בכללי Remote Config. כך משתמשים במאפיין הזה: בפלטפורמות של אפל: משתמשים ב-CFBundleIdentifier של האפליקציה. מזהה החבילה נמצא בכרטיסייה General (כללי) של יעד האפליקציה הראשי ב-Xcode. ב-Android: משתמשים ב-applicationId של האפליקציה. אפשר למצוא את applicationId בקובץ build.gradle(.kts) ברמת האפליקציה.
גרסת אפליקציה	לערכי מחרוזת: התאמה מדויקת, מכיל, לא מכיל, מכיל ביטוי רגולרי לערכים מספריים: <, <=, =, !=, >, >=	מציינים את הגרסאות של האפליקציה שרוצים לטרגט. לפני שמשתמשים בכלל הזה, צריך להשתמש בכלל מזהה אפליקציה כדי לבחור אפליקציה ל-Android או ל-Apple שמשויכת לפרויקט Firebase.	בפלטפורמות של אפל: משתמשים ב-CFBundleShortVersionString של האפליקציה. הערה: ודאו שבאפליקציה שלכם ל-Apple מותקנת גרסה 6.24.0 ומעלה של Firebase Apple platforms SDK, כי CFBundleShortVersionString לא נשלח בגרסאות קודמות (ראו הערות המוצר). ב-Android: משתמשים ב-versionName של האפליקציה. הערה: אופרטורים להשוואה מספרית (<, <=, =, !=, >, >=) תומכים רק בגרסאות סמנטיות מספריות (כמו 1.2.3). הם לא תומכים בסיומות או במקפים של טרום-השקה (כמו -beta או -rc). במחרוזות של גרסאות עם סיומות או מקפים לא מספריים (כמו 1.5-beta), צריך להשתמש באופרטורים של מחרוזות (כמו מכיל ביטוי רגולרי, מכיל או תואם בדיוק). השוואות של מחרוזות בכלל הזה הן תלויות אותיות רישיות. כשמשתמשים באופרטור תואם בדיוק, מכיל, לא מכיל או מכיל ביטוי רגולרי, אפשר לבחור כמה ערכים. כשמשתמשים באופרטור מכיל ביטוי רגולרי, אפשר ליצור ביטויים רגולריים בפורמט RE2. הביטוי הרגולרי יכול להתאים לכל מחרוזת גרסת היעד או לחלק ממנה. אפשר גם להשתמש בעוגנים ^ ו-$ כדי להתאים את ההתחלה, הסוף או כל מחרוזת היעד.
מספר Build	לערכי מחרוזת: התאמה מדויקת, מכיל, לא מכיל, ביטוי רגולרי לערכים מספריים: =, ≠, >, ≥, <, ≤	מציינים את גרסאות ה-build של האפליקציה שרוצים לטרגט. לפני שמשתמשים בכלל הזה, צריך להשתמש בכלל מזהה אפליקציה כדי לבחור אפליקציה ל-Apple או ל-Android שמשויכת לפרויקט Firebase.	האופרטור הזה זמין רק לאפליקציות ל-Apple ול-Android. הוא תואם ל-CFBundleVersion של האפליקציה ב-Apple ול-versionCode ב-Android. השוואות של מחרוזות בכלל הזה הן תלויות אותיות רישיות. כשמשתמשים באופרטורים תואם בדיוק, מכיל, לא מכיל או מכיל ביטוי רגולרי, אפשר לבחור כמה ערכים. כשמשתמשים באופרטור מכיל ביטוי רגולרי, אפשר ליצור ביטויים רגולריים בפורמט RE2. הביטוי הרגולרי יכול להתאים לכל המחרוזת של גרסת היעד או לחלק ממנה. אפשר גם להשתמש בעוגנים ^ ו-$ כדי להתאים את ההתחלה, הסוף או כל מחרוזת היעד.
פלטפורמה	==	iOS Android אינטרנט
מערכת הפעלה	==	מציינים את מערכות ההפעלה שרוצים לטרגט. לפני שמשתמשים בכלל הזה, צריך להשתמש בכלל מזהה אפליקציה כדי לבחור אפליקציית אינטרנט שמשויכת לפרויקט Firebase.	הכלל הזה מקבל את הערך true במופע נתון של אפליקציית אינטרנט אם מערכת ההפעלה והגרסה שלה תואמות לערך יעד ברשימה שצוינה.
דפדפן	==	מציינים את הדפדפנים שרוצים לטרגט. לפני שמשתמשים בכלל הזה, צריך להשתמש בכלל מזהה אפליקציה כדי לבחור אפליקציית אינטרנט שמשויכת לפרויקט Firebase.	הכלל הזה מקבל את הערך true במופע נתון של אפליקציית אינטרנט אם הדפדפן והגרסה שלו תואמים לערך יעד ברשימה שצוינה.
קטגוריית מכשיר	הוא, הוא לא	נייד	הכלל הזה בודק אם המכשיר שניגש לאפליקציית האינטרנט הוא נייד או לא נייד (מחשב או קונסולה). סוג הכלל הזה זמין רק לאפליקציות אינטרנט.
שפות	נמצא ב-	בוחרים שפה אחת או יותר.	הכלל הזה מקבל את הערך true במופע נתון של אפליקציה אם המופע הזה מותקן במכשיר שמשתמש באחת מהשפות שברשימה.
ארץ/אזור	נמצא ב-	בוחרים אזור אחד או יותר או מדינה אחת או יותר.	הכלל הזה מקבל את הערך true במופע נתון של אפליקציה אם המופע נמצא באחד מהאזורים או באחת מהמדינות שברשימה. קוד המדינה של המכשיר נקבע לפי כתובת ה-IP של המכשיר בבקשה, או לפי קוד המדינה שנקבע על ידי Firebase Analytics (אם נתוני Analytics משותפים עם Firebase).
קהל או קהלים של משתמשים	כולל לפחות אחד מהבאים	בוחרים קהל אחד או יותר מתוך רשימה של Google Analytics קהלים שהגדרתם לפרויקט.	כדי להשתמש בכלל הזה, צריך להגדיר כלל של מזהה אפליקציה כדי לבחור אפליקציה שמשויכת לפרויקט ב-Firebase. הערה: מכיוון שקהלים רבים ב-Analytics מוגדרים לפי אירועים או מאפייני משתמשים, שיכולים להתבסס על הפעולות של משתמשי האפליקציה, יכול להיות שיחלוף זמן מה עד שהכלל משתמש בקהל ייכנס לתוקף במופע נתון של האפליקציה. כלומר, גם אם משתמש עומד בתנאים של קהל מסוים, אם Analytics עדיין לא הוסיף את המשתמש לקהל כש-fetchAndActivate() מופעל, המשתמש לא יעמוד בתנאי.
מאפיין משתמש	לערכי מחרוזת: contains, does not contain, exactly matches, contains regular expression לערכים מספריים: =, ≠, >, ≥, <, ≤ הערה: בצד הלקוח, אפשר להגדיר רק ערכי מחרוזת למאפייני משתמשים. בתנאים שמשתמשים באופרטורים מספריים, Remote Config ממיר את הערך של מאפיין המשתמש התואם למספר שלם או למספר עם נקודה צפה (float).	בוחרים מתוך רשימה של מאפייני משתמשים זמינים ב-Google Analytics.	כדי ללמוד איך להשתמש במאפייני משתמשים כדי להתאים אישית את האפליקציה לפלחים ספציפיים מאוד של בסיס המשתמשים, קראו את המאמר Remote Config ומאפייני משתמשים. מידע נוסף על מאפייני משתמשים זמין במדריכים הבאים: הגדרה של מאפייני משתמשים ב-Apple הגדרה של מאפייני משתמשים ב-Android כשמשתמשים באופרטור התאמה מדויקת, מכיל, לא מכיל או מכיל ביטוי רגולרי, אפשר לבחור כמה ערכים. כשמשתמשים באופרטור מכיל ביטוי רגולרי, אפשר ליצור ביטויים רגולריים בפורמט RE2. הביטוי הרגולרי יכול להתאים לכל המחרוזת של גרסת היעד או לחלק ממנה. אפשר גם להשתמש בעוגנים ^ ו-$ כדי להתאים את ההתחלה, הסוף או כל מחרוזת היעד. הערה: מאפייני משתמשים שנאספים באופן אוטומטי לא זמינים כשיוצרים תנאים ב-Remote Config.
משתמש באחוז אקראי	סליידר (במסוף Firebase). ב-API בארכיטקטורת REST משתמשים באופרטורים <=,‏ > ו-between.	0-100	אפשר להשתמש בשדה הזה כדי להחיל שינוי על מדגם אקראי של מופעי אפליקציה (עם גודלי מדגם קטנים עד 0 .0001%), באמצעות ווידג'ט של פס הזזה כדי לפלח משתמשים (מופעי אפליקציה) שסודרו באופן אקראי לקבוצות. כל מופע של אפליקציה ממופה באופן קבוע למספר שלם או שבר אקראי, בהתאם לseed שמוגדר בפרויקט. ערכי בסיס יכולים להכיל בין תו אחד ל-32 תווים, כולל ערכים אלפאנומריים, נקודות, מקפים ו/או קווים תחתונים. הכלל ישתמש במפתח ברירת המחדל (שמוצג בתור Edit seed במסוף Firebase), אלא אם תשנו את ערך הבסיס. כדי להחזיר כלל לשימוש במפתח ברירת המחדל, צריך לנקות את השדה Seed. כדי לטרגט באופן עקבי את אותם מופעי אפליקציה בטווחי אחוזים נתונים, צריך להשתמש באותו ערך בסיס בכל התנאים. אפשר גם לבחור קבוצה חדשה של מופעי אפליקציה שמוקצים באופן אקראי לטווח אחוזים נתון, על ידי ציון ערך seed חדש. לדוגמה, כדי ליצור שני תנאים קשורים שכל אחד מהם חל על 5% ממשתמשי האפליקציה ללא חפיפה, אפשר להגדיר תנאי אחד שיתאים לאחוזים שבין 0% ל-5%, ולהגדיר תנאי אחר שיתאים לטווח שבין 5% ל-10%. כדי לאפשר למשתמשים מסוימים להופיע באופן אקראי בשתי הקבוצות, צריך להשתמש בערכי בסיס שונים לכללים בכל תנאי.
פלח מיובא	נמצא ב-	בוחרים פלח מיובא אחד או יותר.	כדי להשתמש בכלל הזה, צריך להגדיר פלחים מיובאים בהתאמה אישית.
תאריך/שעה	לפני, אחרי	תאריך ושעה ספציפיים, לפי אזור הזמן של המכשיר או לפי אזור זמן ספציפי, כמו "(GMT+11) שעון סידני".	השוואה בין השעה הנוכחית לבין שעת האחזור של המכשיר.
פתיחה ראשונה	לפני, אחרי	טירגוט משתמשים על סמך הפעם הראשונה שהם פותחים את האפליקציה: בוחרים באפשרות משתמשים חדשים כדי לטרגט משתמשים שפתחו את האפליקציה בפעם הראשונה אחרי תאריך ושעה עתידיים מסוימים. בוחרים באפשרות טווח תאריכים כדי לטרגט משתמשים שפתחו את האפליקציה בפעם הראשונה בטווח התאריכים שלפני או אחרי התאריך והשעה שציינתם. כדי לטרגט משתמשים בטווח תאריכים ספציפי, משלבים את התנאים לפני ואחרי.	אפשר לטרגט משתמשים לפי פתיחה ראשונה אחרי שבוחרים אפליקציה ל-Android, ל-iOS או לאינטרנט. נדרשות ערכות ה-SDK הבאות: Firebase SDK ל-Google Analytics ‫Apple platforms SDK בגרסה 9.0.0 ומעלה או Android SDK בגרסה 21.1.1 ומעלה (Firebase BoM בגרסה 30.3.0 ומעלה), ו-JavaScript SDK בגרסה 12.8.0 ומעלה. בנוסף, צריך להפעיל את Analytics באפליקציית הלקוח במהלך אירוע הפתיחה הראשונה.
מזהה ההתקנה	נמצא ב-	מציינים מזהה התקנה אחד או יותר (עד 50) לטירגוט.	הכלל הזה מקבל את הערך true בהתקנה נתונה אם המזהה של ההתקנה הזו נמצא ברשימת הערכים שמופרדים בפסיקים. במאמר אחזור מזהי לקוחות מוסבר איך מקבלים מזהי התקנה.
המשתמש קיים	(ללא אופרטור)	מטרגט את כל המשתמשים בכל האפליקציות בפרויקט הנוכחי.	אפשר להשתמש בכלל התנאי הזה כדי להתאים לכל המשתמשים בפרויקט, בלי קשר לאפליקציה או לפלטפורמה. כשמשתמשים בהתאמה אישית של Remote Config, אפשר להשתמש באופרטור הזה כדי לוודא שכל המשתמשים בפרויקט מקבלים ערכים בהתאמה אישית.
אות בהתאמה אישית	לערכי מחרוזת: מכיל, לא מכיל, התאמה מדויקת, מכיל ביטוי רגולרי לערכים מספריים: =, ≠, >, ≥, <, ≤ לערכי גרסה: =, ≠, >, ≥, <, ≤	השוואות של מחרוזות בכלל הזה הן תלויות אותיות רישיות. כשמשתמשים באופרטורים "תואם בדיוק", "מכיל", "לא מכיל" או "מכיל ביטוי רגולרי", אפשר לבחור כמה ערכים. כשמשתמשים באופרטור "מכיל ביטוי רגולרי", אפשר ליצור ביטויים רגולריים בפורמט RE2. הביטוי הרגולרי יכול להתאים לכל מחרוזת גרסת היעד או לחלק ממנה. אפשר גם להשתמש בתווי העיגון ^ ו-$ כדי להתאים את ההתחלה, הסוף או כל מחרוזת היעד. אלה סוגי הנתונים שנתמכים בסביבות לקוח: ‫iOS: ‏int, ‏double ‫Android: ‏int, ‏ long, ‏ double אינטרנט: מספר מספר שמייצג את מספרי הגרסאות שצריך להתאים (לדוגמה, 2.1.0).	מידע נוסף על תנאים של אותות בהתאמה אישית וביטויים מותנים זמין במאמרים תנאים של אותות בהתאמה אישית ורכיבים שמשמשים ליצירת תנאים.

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

‫A/B Testing מדדים

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

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

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

הערה: אירועי Analytics מופיעים ברשימות המדדים רק אם הם הופעלו על ידי האפליקציה. עם זאת, אפשר להקליד את שם המדד בשדה בחירת מדד היעד וללחוץ על יצירת אירוע כדי להוסיף אותו, והוא ישמש אתכם כשהאפליקציה תפעיל את האירועים האלה בעתיד.

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

מדדי יעדים

מדד	תיאור
משתמשים שהאפליקציה שלהם לא קרסה	אחוז המשתמשים שלא נתקלו באפליקציה בשגיאות שזוהו על ידי ה-SDK של Firebase Crashlytics במהלך הניסוי. הערה: אין תמיכה ב-Firebase Crashlytics באפליקציות אינטרנט.
הכנסות משוערות מפרסום	רווחים משוערים ממודעות.
ההכנסה הכוללת המשוערת	הערך המשולב של הכנסות מרכישות והכנסות משוערות מפרסום.
הכנסות מרכישות	הערך המשולב של כל האירועים מסוג purchase ו-in_app_purchase.
שימור משתמשים (יום אחד)	מספר המשתמשים שחוזרים לאפליקציה שלכם על בסיס יומי.
שימור (יומיים-שלושה)	מספר המשתמשים שחוזרים לאפליקציה תוך יומיים-שלושה.
שימור (4-7 ימים)	מספר המשתמשים שחוזרים לאפליקציה תוך 4 עד 7 ימים.
שימור משתמשים (8-14 ימים)	מספר המשתמשים שחוזרים לאפליקציה תוך 8 עד 14 ימים.
שימור (15 ימים ומעלה)	מספר המשתמשים שחוזרים לאפליקציה 15 ימים או יותר אחרי הפעם האחרונה שהם השתמשו בה.
first_open	אירוע Analytics שמופעל כשמשתמש פותח אפליקציה בפעם הראשונה אחרי שהוא התקין או התקין אותה מחדש. משמש כחלק ממשפך המרות.

מדדים נוספים

מדד	תיאור
notification_dismiss	אירוע Analytics שמופעל כשמשתמש סוגר התראה שנשלחה על ידי ניסוח מסרים (Notifications Composer) (Android בלבד).
notification_receive	אירוע Analytics שמופעל כשמתקבלת התראה שנשלחה על ידי ניסוח מסרים (Notifications Composer) בזמן שהאפליקציה פועלת ברקע (Android בלבד).
os_update	אירוע Analytics שעוקב אחרי מקרים שבהם מערכת ההפעלה של המכשיר מתעדכנת לגרסה חדשה.מידע נוסף זמין במאמר אירועים שנאספים באופן אוטומטי. המדד הזה לא נתמך באפליקציות אינטרנט.
screen_view	אירוע Analytics שעוקב אחרי המסכים שהמשתמשים צפו בהם באפליקציה. מידע נוסף זמין במאמר מעקב אחרי צפיות במסך.
session_start	אירוע Analytics שסופר את סשני המשתמשים באפליקציה. מידע נוסף זמין במאמר אירועים שנאספים באופן אוטומטי.

ייצוא נתונים ל-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, עוברים אל הכרטיסייה הגדרות > שילובים.

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

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

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

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

   2. בקטע Configure integration, מפעילים את Google Analytics.

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

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

   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: מזהה הנכס ב-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.

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

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

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

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

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

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

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

1. במסוף Firebase, עוברים אל DevOps & Engagement (DevOps ומעורבות) > 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 '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