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

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

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

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

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

יצירת ניסוי

Remote Config ניסוי מאפשר להעריך כמה וריאנטים של Remote Config פרמטר אחד או יותר.

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

   אם לא הפעלתם את Google Analytics כשנוצר הפרויקט, תוכלו להפעיל אותו בכרטיסייה Integrations (שילובים) בקטע settings Settings (הגדרות) במסוף Firebase.

2. במסוף Firebase, עוברים אל DevOps & Engagement (פיתוח אפליקציות ואינטראקציה) > A/B Testing.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    • app_install
    • app_remove
    • app_update

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

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

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

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

ניהול הניסוי

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

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

עריכת ניסוי

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

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

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

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

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

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

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

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

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

1. בקטע DevOps & Engagement בתפריט הניווט של מסוף Firebase, לוחצים על Remote Config.
2. לוחצים על הכרטיסייה בדיקות A/B.
3. לוחצים על הושלם או על פועל, לוחצים על ניסוי שרוצים להשיק לכל המשתמשים, לוחצים על תפריט ההקשר (more_vert) השקת וריאציה.
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. בקטע סקירה כללית של הניסוי, לוחצים על תפריט ההקשר (more_vert) ואז על עריכת ניסוי פעיל.
5. בתיבת הדו-שיח טירגוט מוצגת אפשרות להגדלת אחוז המשתמשים שמשתתפים בניסוי הפעיל. בוחרים מספר שגדול מהאחוז הנוכחי ולוחצים על פרסום. הניסוי יוצג לאחוז המשתמשים שציינתם.

שכפול ניסוי

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

הפסקת ניסוי

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

זיהוי לקוח אינטרנט והמשכיות של ניסויים

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

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

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

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

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

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

‫A/B Testing מדדים

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

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

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

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

מדדי יעדים

מדדים נוספים

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

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

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

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

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

   2. בקטע Configure integration (הגדרת השילוב), מפעילים את האפשרות Google Analytics.

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

   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 מזהה הנכס: מזהה הנכס בן 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 אירועים.

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

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

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

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

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

1. במסוף Firebase, עוברים אל DevOps & Engagement (פיתוח אפליקציות ואינטראקציה) >‏ 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 '20240202' AND '20240502')
    AND userProperty.key = 'firebase_exp_25'
  GROUP BY
    experimentVariant, eventName

דוגמאות נוספות לשאילתות זמינות במאמר דוגמאות לשאילתות.

דוגמאות לשאילתות

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

חילוץ ערכי סטיית תקן של רכישות וניסויים מכל הניסויים

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