כשמשתמשים ב-Firebase Remote Config כדי לפרוס הגדרות לאפליקציה עם בסיס משתמשים פעיל, חשוב לוודא שההגדרות נכונות. אפשר להשתמש בניסויים מסוג A/B Testing כדי לקבוע את הפרטים הבאים בצורה הטובה ביותר:
- הדרך הטובה ביותר להטמיע תכונה כדי לשפר את חוויית המשתמש לעתים קרובות, מפתחי אפליקציות מגלים שהמשתמשים שלהם לא אוהבים תכונה חדשה או חוויית משתמש מעודכנת רק אחרי שהדירוג של האפליקציה בחנות האפליקציות יורד. בדיקות A/B יכולות לעזור לכם למדוד אם המשתמשים אוהבים גרסאות חדשות של תכונות, או שהם מעדיפים את האפליקציה כפי שהיא. בנוסף, שמירה של רוב המשתמשים בקבוצת בסיס מבטיחה שרוב בסיס המשתמשים יוכלו להמשיך להשתמש באפליקציה בלי לראות שינויים בהתנהגות או במראה שלה עד לסיום הניסוי.
- הדרך הטובה ביותר לבצע אופטימיזציה של חוויית המשתמש בהתאם ליעד עסקי. לפעמים אתם מבצעים שינויים במוצר כדי למקסם מדד כמו הכנסה או שימור. כשמשתמשים בבדיקת A/B, מגדירים את היעד העסקי ו-Firebase מבצעת את הניתוח הסטטיסטי כדי לקבוע אם וריאנט מסוים מניב ביצועים טובים יותר מערך הבסיס של היעד שנבחר.
כדי לבצע בדיקת A/B של וריאנטים של תכונות עם קו בסיס, מבצעים את הפעולות הבאות:
- יוצרים את הניסוי.
- מאמתים את הניסוי במכשיר בדיקה.
- מנהלים את הניסוי.
יצירת ניסוי
ניסוי Remote Config מאפשר להעריך כמה וריאנטים בפרמטר Remote Config אחד או יותר.
נכנסים למסוף Firebase ומוודאים ש-Google Analytics מופעל בפרויקט, כדי שלניסוי תהיה גישה לנתוני Analytics.
אם לא הפעלתם את Google Analytics במהלך יצירת הפרויקט, תוכלו להפעיל אותו בכרטיסייה Integrations (שילובים), שניתן לגשת אליה באמצעות > Project settings במסוף Firebase.
בקטע התעניינות בתפריט הניווט של מסוף Firebase לוחצים על A/B Testing.
לוחצים על Create experiment ובוחרים באפשרות Remote Config כשמתבקשים לבחור את השירות שבו רוצים לערוך את הניסוי.
מזינים שם ותיאור אופציונלי לניסוי, ולוחצים על הבא.
ממלאים את השדות לטירגוט ובוחרים קודם את האפליקציה שבה נעשה שימוש בניסוי. אפשר גם לטרגט קבוצת משנה של המשתמשים להשתתפות בניסוי. לשם כך, לוחצים על וגם ובוחרים אפשרויות מהרשימה הבאה:
- גרסה: גרסה אחת או יותר של האפליקציה
- מספר build: קוד הגרסה של האפליקציה
- שפות: שפה אחת או יותר ולוקאל אחד או יותר שבעזרתם בוחרים את המשתמשים שעשויים להיכלל בניסוי
- מדינה/אזור: מדינה או אזור אחד או יותר לבחירת המשתמשים שצריכים להיכלל בניסוי
- קהל משתמשים: Analytics קהלים שמשמשים לטירגוט משתמשים שעשויים להיכלל בניסוי
- מאפיין משתמש: מאפיין משתמש אחד או יותר מסוג Analytics לבחירת משתמשים שעשויים להיכלל בניסוי
פתיחה ראשונה: טירגוט משתמשים על סמך הפעם הראשונה שהם פתחו את האפליקציה
אפשר לטרגט משתמשים לפי מועד הפתיחה הראשון אחרי שבוחרים אפליקציה ל-Android או ל-iOS. התכונה נתמכת בגרסאות ה-SDK הבאות של Remote Config: Apple platforms SDK v9.0.0 ואילך ו-Android SDK v21.1.1 ואילך (Firebase BoM v30.3.0 ואילך).
בנוסף, צריך להפעיל את Analytics בצד הלקוח במהלך האירוע הפתוח הראשון.
מגדירים את אחוז המשתמשים היעד: מזינים את האחוז מתוך בסיס המשתמשים של האפליקציה שעומד בקריטריונים שהוגדרו בקטע משתמשי היעד, שרוצים לחלק באופן שווה בין הבקרה לבין וריאנט אחד או יותר בניסוי. אפשר להגדיר כל אחוז בין 0.01% ל-100%. המשתמשים מוקצים באופן אקראי לכל ניסוי, כולל ניסויים כפולים.
אפשר גם להגדיר אירוע הפעלה כדי לוודא שבניסוי ייספרו רק הנתונים ממשתמשים שהפעילו בפעם הראשונה אירוע כלשהו מסוג Analytics. חשוב לזכור שכל המשתמשים שתואמים לפרמטרים של הטירגוט יקבלו ערכים ניסיוניים של Remote Config, אבל רק המשתמשים שיפעילו אירוע הפעלה ייכללו בתוצאות הניסוי.
כדי להבטיח שהניסוי יהיה תקין, אתם צריכים לוודא שהאירוע שבחרתם יקרה אחרי שהאפליקציה מפעילה את הערכים של ההגדרות המאוחזרות. בנוסף, אי אפשר להשתמש באירועים הבאים כי הם תמיד מתרחשים לפני שהערכים שאוחזרו מופעלים:
app_install
app_remove
app_update
dynamic_link_first_open
בקטע יעדים של הניסוי, בוחרים את המדד הראשי שרוצים לעקוב אחריו ומוסיפים מהרשימה את המדדים הנוספים שרוצים לעקוב אחריהם. יעדים מובנים (רכישות, הכנסות, שימור משתמשים, משתמשים ללא תאונות וכו'), Analytics אירועי המרה ואירועי Analytics אחרים. כשמסיימים, לוחצים על הבא.
בקטע וריאנטים, בוחרים בסיס להשוואה ולפחות וריאנט אחד לניסוי. משתמשים ברשימה בחירה או יצירה של פרמטר חדש כדי להוסיף פרמטר אחד או יותר לניסוי. אפשר ליצור פרמטר שלא נעשה בו שימוש קודם במסוף Firebase, אבל הוא חייב להתקיים באפליקציה כדי שיהיה לו השפעה. תוכלו לחזור על השלב הזה כדי להוסיף כמה פרמטרים לניסוי.
(אופציונלי) כדי להוסיף עוד וריאנט לניסוי, לוחצים על הוספת וריאנט.
שינוי פרמטר אחד או יותר של וריאנטים ספציפיים. כל הפרמטרים שלא השתנו זהים למשתמשים שלא נכללים בניסוי.
מרחיבים את וריאנט weights כדי להציג או לשנות את המשקל של הווריאנט בניסוי. כברירת מחדל, כל וריאנט מקבל משקל שווה. חשוב לשים לב שחלוקה לא שווה עשויה להאריך את משך הזמן שנדרש לאיסוף הנתונים, ולא ניתן לשנות את החלוקה לאחוזים אחרי שהניסוי מתחיל.
לוחצים על בדיקה כדי לשמור את הניסוי.
מותר ליצור עד 300 ניסויים לכל פרויקט, שיכולים לכלול עד 24 ניסויים פעילים, והשאר טיוטות או ניסויים שהושלמו.
אימות הניסוי במכשיר בדיקה
לכל התקנה של Firebase אפשר לאחזר את אסימון האימות להתקנה שמשויך אליה. אפשר להשתמש באסימון הזה כדי לבדוק וריאנטים ספציפיים של ניסוי במכשיר בדיקה שבו מותקנת האפליקציה שלכם. כדי לאמת את הניסוי במכשיר בדיקה:
- מקבלים את טוקן האימות של ההתקנה באופן הבא:
Swift
do { let result = try await Installations.installations() .authTokenForcingRefresh(true) print("Installation auth token: \(result.authToken)") } catch { print("Error fetching token: \(error)") }
Objective-C
[[FIRInstallations installations] authTokenForcingRefresh:true completion:^(FIRInstallationsAuthTokenResult *result, NSError *error) { if (error != nil) { NSLog(@"Error fetching Installation token %@", error); return; } NSLog(@"Installation auth token: %@", [result authToken]); }];
Java
FirebaseInstallations.getInstance().getToken(/* forceRefresh */true) .addOnCompleteListener(new OnCompleteListener<InstallationTokenResult>() { @Override public void onComplete(@NonNull Task<InstallationTokenResult> task) { if (task.isSuccessful() && task.getResult() != null) { Log.d("Installations", "Installation auth token: " + task.getResult().getToken()); } else { Log.e("Installations", "Unable to get Installation auth token"); } } });
Kotlin+KTX
val forceRefresh = true FirebaseInstallations.getInstance().getToken(forceRefresh) .addOnCompleteListener { task -> if (task.isSuccessful) { Log.d("Installations", "Installation auth token: " + task.result?.token) } else { Log.e("Installations", "Unable to get Installation auth token") } }
C++
firebase::InitResult init_result; auto* installations_object = firebase::installations::Installations::GetInstance( firebase::App::GetInstance(), &init_result); installations_object->GetToken().OnCompletion( [](const firebase::Future<std::string>& future) { if (future.status() == kFutureStatusComplete && future.error() == firebase::installations::kErrorNone) { printf("Installations Auth Token %s\n", future.result()->c_str()); } });
Unity
Firebase.Installations.FirebaseInstallations.DefaultInstance.GetTokenAsync(forceRefresh: true).ContinueWith( task => { if (!(task.IsCanceled || task.IsFaulted) && task.IsCompleted) { UnityEngine.Debug.Log(System.String.Format("Installations token {0}", task.Result)); } });
- בסרגל הניווט של מסוף Firebase, לוחצים על בדיקות A/B.
- לוחצים על טיוטה (ו/או על הפעלה לניסויים בהגדרת תצורה מרחוק), מעבירים את העכבר מעל הניסוי, לוחצים על תפריט ההקשר (more_vert) ואז על ניהול מכשירי הבדיקה.
- מזינים את אסימון האימות של ההתקנה למכשיר הבדיקה ובוחרים את הווריאנט של הניסוי שרוצים לשלוח למכשיר הבדיקה הזה.
- מריצים את האפליקציה ומוודאים שהגרסה שנבחרה מתקבלת במכשיר הבדיקה.
מידע נוסף על התקנות של Firebase זמין במאמר ניהול התקנות של Firebase.
ניהול הניסוי
אחרי שיוצרים ניסוי באמצעות Remote Config, הכלי ליצירת התראות או Firebase In-App Messaging, אפשר לאמת ולהפעיל את הניסוי, לעקוב אחריו בזמן שהוא פועל ולהגדיל את מספר המשתמשים שכלולים בניסוי שפועל.
בסיום הניסוי, תוכלו לשים לב להגדרות שבהן נעשה שימוש בווריאנט הזוכה, ולאחר מכן להשיק את ההגדרות האלה לכל המשתמשים. לחלופין, תוכלו להפעיל ניסוי נוסף.
התחלת ניסוי
- בקטע Engage בתפריט הניווט של מסוף Firebase, לוחצים על A/B Testing.
- לוחצים על טיוטה ואז על שם הניסוי.
- כדי לוודא שיש באפליקציה משתמשים שייכללו בניסוי, מרחיבים את פרטי הטיוטה ובודקים אם מופיע מספר גבוה מ-0% בקטע טירגוט והפצה (לדוגמה, 1% מהמשתמשים שעומדים בקריטריונים).
- כדי לשנות את הניסוי, לוחצים על Edit (עריכה).
- כדי להתחיל את הניסוי, לוחצים על התחלת הניסוי. אפשר להריץ עד 24 ניסויים בכל פרויקט בכל פעם.
מעקב אחרי ניסוי
אחרי שהניסוי פועל במשך זמן מה, אפשר לבדוק את ההתקדמות שלו ולראות איך נראות התוצאות של המשתמשים שהשתתפו בניסוי עד כה.
- בקטע Engage בתפריט הניווט של מסוף Firebase, לוחצים על A/B Testing.
לוחצים על ריצה ואז לוחצים על שם הניסוי או מחפשים אותו. בדף הזה מוצגים נתונים סטטיסטיים שונים לגבי הניסוי הפעיל, כולל נתונים סטטיסטיים מתועדים, כולל:
- % ההבדל בהשוואה לערך הבסיס: מדד לשיפור המדד של וריאציה נתונה בהשוואה לערך הבסיס. הערך מחושב על ידי השוואה בין טווח הערכים של הווריאנט לבין טווח הערכים של הבקרה.
- ההסתברות לגבור על שיעור ההמרה הבסיסי: ההסתברות המשוערת שגרסת המשנה מסוימת תגבר על שיעור ההמרה הבסיסי של המדד שנבחר.
- observed_metric לכל משתמש: על סמך תוצאות הניסוי, זהו הטווח הצפוי שבו הערך של המדד ייכלל לאורך זמן.
- סה"כ observed_metric: הערך המצטבר שנצפה של הבסיס או הווריאנט. הערך הזה משמש למדידת הביצועים של כל וריאנט של הניסוי, והוא משמש לחישוב השיפור, טווח הערכים, ההסתברות לגבור על ערך הבסיס וההסתברות להיות הווריאנט הטוב ביותר. בהתאם למדד שנמדד, העמודה הזו עשויה להיקרא 'משך זמן לכל משתמש', 'הכנסה לכל משתמש', 'שיעור שימור' או 'שיעור המרה'.
אחרי שהניסוי יפעל במשך זמן מה (לפחות 7 ימים ל-FCM ול-In-App Messaging או 14 ימים ל-Remote Config), הנתונים בדף הזה יציינו איזו וריאציה, אם בכלל, היא 'המובילה'. חלק מהמדידות מלוות בתרשים עמודות שמציג את הנתונים בפורמט חזותי.
השקה של ניסוי לכל המשתמשים
אחרי שהניסוי יפעל מספיק זמן כדי שתוכלו לזהות את הווריאנט 'המוביל' או הווריאנט המנצח ביחס למדד היעד, תוכלו להשיק את הניסוי לכל המשתמשים. כך תהיה לך אפשרות לבחור וריאנט ולפרסם אותו לכל המשתמשים מאותו רגע ואילך. גם אם לא הייתה הגדרה מנצחת בניסוי, עדיין תוכלו להשיק וריאנט לכל המשתמשים.
- בקטע Engage בתפריט הניווט של מסוף Firebase, לוחצים על A/B Testing.
- לוחצים על הושלם או על בפעילות, לוחצים על הניסוי שרוצים להשיק לכל המשתמשים, לוחצים על תפריט ההקשר ( ) השקת הווריאנט.
כדי להשיק את הניסוי לכל המשתמשים, מבצעים אחת מהפעולות הבאות:
- בניסוי שבו נעשה שימוש בכלי ליצירת התראות, משתמשים בתיבת הדו-שיח הודעה להשקה כדי לשלוח את ההודעה לשאר המשתמשים המטורגטים שלא היו חלק מהניסוי.
- לניסוי Remote Config, צריך לבחור וריאנט כדי לקבוע אילו ערכי פרמטרים של Remote Config לעדכן. קריטריונים לטירגוט שהוגדרו בזמן יצירת הניסוי מתווספים כתנאי חדש בתבנית, כדי להבטיח שההשקה תשפיע רק על משתמשים שמוגדרים כטירגוט בניסוי. אחרי שלוחצים על בדיקה ב-Remote Config כדי לבדוק את השינויים, לוחצים על פרסום השינויים כדי להשלים את ההשקה.
- בניסוי מסוג In-App Messaging, משתמשים בתיבת הדו-שיח כדי לקבוע איזה וריאנט צריך להשיק כקמפיין In-App Messaging נפרד. לאחר הבחירה, תועברו למסך הכתיבה של FIAM כדי לבצע שינויים (אם יש צורך) לפני הפרסום.
הרחבת ניסוי
אם הניסוי לא מניב מספיק משתמשים כדי ש-A/B Testing יוכל להכריז על מנהיג, תוכלו להגדיל את התפלגות הניסוי כדי להגיע לאחוז גדול יותר מבסיס המשתמשים של האפליקציה.
- בקטע Engage בתפריט הניווט של מסוף Firebase, לוחצים על A/B Testing.
- בוחרים את הניסוי שפועל שרוצים לערוך.
- בדף סקירה כללית של הניסוי, לוחצים על תפריט הסיטואציה ( ) ואז על עריכת הניסוי שפועל.
- בתיבת הדו-שיח טירגוט מוצגת אפשרות להגדיל את אחוז המשתמשים שנכללים בניסוי שפועל. בוחרים מספר גבוה יותר מהאחוז הנוכחי ולוחצים על פרסום. הניסוי יוצג לאחוז המשתמשים שציינתם.
שכפול או הפסקה של ניסוי
- בקטע Engage בתפריט הניווט של מסוף Firebase, לוחצים על A/B Testing.
- לוחצים על הושלם או על פעיל, מעבירים את הסמן מעל הניסוי, לוחצים על תפריט ההקשר ( ) ואז לוחצים על העתקת הניסוי או על הפסקת הניסוי.
טירגוט משתמשים
תוכלו לטרגט את המשתמשים שייכללו בניסוי לפי הקריטריונים הבאים לטירגוט משתמשים.
קריטריון טירגוט | מפעילים | ערכים | הערה | |
---|---|---|---|---|
גרסה | מכיל,
לא מכיל, תואם במדויק, מכיל ביטוי רגולרי (regex) |
מזינים ערך לגרסה אחת או יותר של האפליקציה שרוצים לכלול בניסוי. |
כשמשתמשים באחד מהאופרטורים contains, does not contain או matches exactly, אפשר לספק רשימה של ערכים מופרדים בפסיקים. כשמשתמשים באופרטור contains regex, אפשר ליצור ביטויים רגולריים בפורמט RE2. הביטוי הרגולרי יכול להתאים לכל המחרוזת של גרסת היעד או לחלק ממנה. אפשר גם להשתמש בעוגנים ^ ו-$ כדי להתאים להתחלה, לסוף או לכל המחרוזת של היעד. |
|
קהלי משתמשים | כולל את כולם,
כולל לפחות אחד מהם, לא כולל את כולם, לא כולל לפחות אחד מהם |
בוחרים קהל Analytics אחד או יותר כדי לטרגט משתמשים שעשויים להיכלל בניסוי. |
יכול להיות שיחלפו כמה ימים עד שיצטברו נתונים בניסויים מסוימים שמטרגטים קהלים של Google Analytics, כי הם כפופים לזמן האחזור של עיבוד הנתונים ב-Analytics.
הסבירות הגבוהה ביותר היא שהעיכוב הזה יתרחש אצל משתמשים חדשים, שבדרך כלל מצורפים לקהלים שעומדים בדרישות 24 עד 48 שעות אחרי היצירה, או אצל קהלים שנוצרו לאחרונה.
לגבי Remote Config, המשמעות היא שגם אם משתמש עומד באופן טכני בדרישות להכללה בקהל, אם Analytics עדיין לא הוסיף את המשתמש לקהל כשהפעולה fetchAndActivate() מבוצעת, המשתמש לא ייכלל בניסוי. |
|
מאפיין משתמש | לטקסט:
מכיל, לא מכיל, תואם בדיוק, מכיל ביטוי רגולרי (regex) למספרים: <, ≤, =, ≥, > |
מאפיין המשתמש Analytics משמש לבחירת משתמשים שייכללו
בניסוי, עם מגוון אפשרויות לבחירת ערכים של
מאפיין משתמש.
בצד הלקוח, אפשר להגדיר רק ערכים של מחרוזות למאפייני משתמש. בתנאים שמשתמשים באופרטורים מספריים, השירות Remote Config ממיר את הערך של מאפיין המשתמש התואם למספר שלם או למספר עשרוני. |
כשמשתמשים באופרטור contains regex, אפשר ליצור ביטויים רגולריים בפורמט RE2. הביטוי הרגולרי יכול להתאים לכל מחרוזת הגרסה של היעד או לחלק ממנה. אפשר גם להשתמש בעוגנים ^ ו-$ כדי להתאים את ההתחלה, הסוף או שלמותה של מחרוזת היעד. | |
ארץ/אזור | לא רלוונטי | מדינה אחת או אזור אחד או יותר שמשמשים לבחירת משתמשים שעשויים להיכלל בניסוי. | ||
שפות | לא רלוונטי | שפה אחת או יותר ולוקאל אחד או יותר שבעזרתם בוחרים משתמשים שעשויים להיכלל בניסוי. | ||
פתיחה ראשונה |
לפני אחרי |
טירגוט למשתמשים לפי הפעם הראשונה שהם פותחים את האפליקציה:
|
אפשר לטרגט משתמשים לפי הפתיחה הראשונה אחרי שבוחרים אפליקציה ל-Android או ל-iOS. התכונה נתמכת כרגע בגרסאות ה-SDK הבאות של Remote Config: Apple platforms SDK v9.0.0 ואילך ו-Android SDK v21.1.1 ואילך (Firebase BoM v30.3.0 ואילך). בנוסף, Analytics חייב להיות מופעל אצל הלקוח במהלך אירוע הפתיחה הראשון. |
A/B Testing מדדים
כשיוצרים את הניסוי, בוחרים מדד ראשי, או מדד מטרה שמשמש לקביעת הווריאנט המנצח. מומלץ גם לעקוב אחרי מדדים אחרים כדי להבין טוב יותר את הביצועים של כל וריאנט בניסוי, ולעקוב אחרי מגמות חשובות שעשויות להיות שונות בכל וריאנט, כמו שימור משתמשים, יציבות האפליקציה והכנסות מרכישות מתוך האפליקציה. אפשר לעקוב אחרי עד חמישה מדדים שאינם מדדי יעד בניסוי.
לדוגמה, נניח שאתם משתמשים ב-Remote Config כדי להשיק באפליקציה שני תהליכי משחק שונים, ואתם רוצים לבצע אופטימיזציה להגדלת מספר הרכישות מתוך האפליקציה ולהגדלת ההכנסות מפרסום, אבל אתם רוצים גם לעקוב אחרי היציבות ושימור המשתמשים בכל וריאנט. במקרה כזה כדאי לבחור באפשרות אומדן הכנסה כוללת בתור מדד היעד, כי הוא כולל הכנסות מרכישות מתוך האפליקציה והכנסות מפרסום, ולאחר מכן, כדי לעקוב אחר מדדים אחרים, אתם יכולים להוסיף את הפרטים הבאים:
- כדי לעקוב אחרי שימור המשתמשים היומי והשבועי, מוסיפים את המדדים שימור (2-3 ימים) ושימור (4-7 ימים).
- כדי להשוות בין יציבות שני תהליכי המשחק, מוסיפים את המדד משתמשים ללא קריסות.
- כדי לראות תצוגות מפורטות יותר של כל סוג הכנסה, מוסיפים את האפשרויות הכנסות מרכישות והכנסות משוערות מפרסום.
בטבלאות הבאות מוסבר איך מחושבים מדדי היעדים ומדדים אחרים.
מדדי יעדים
מדד | תיאור |
---|---|
משתמשים שהאפליקציה שלהם לא קרסה | אחוז המשתמשים שלא נתקלו באפליקציה בשגיאות שזוהו על ידי Firebase Crashlytics SDK במהלך הניסוי. |
ההכנסה המשוערת מפרסום | רווחים משוערים ממודעות. |
סה"כ הכנסות משוערות | הערך הכולל של ההכנסות מרכישות וההכנסות המשוערות מפרסום. |
הכנסות מרכישות | הערך הכולל של כל האירועים מסוג purchase ו-in_app_purchase .
|
שימור (יום אחד) | מספר המשתמשים שחוזרים לאפליקציה שלכם מדי יום. |
שימור (2-3 ימים) | מספר המשתמשים שחוזרים לאפליקציה תוך 2-3 ימים. |
שימור (4 עד 7 ימים) | מספר המשתמשים שחוזרים לאפליקציה שלכם תוך 4 עד 7 ימים. |
שימור משתמשים (8 עד 14 ימים) | מספר המשתמשים שחוזרים לאפליקציה תוך 8 עד 14 ימים. |
שימור (יותר מ-15 ימים) | מספר המשתמשים שחוזרים לאפליקציה 15 ימים או יותר אחרי שהם השתמשו בה בפעם האחרונה. |
first_open | אירוע Analytics שמופעל כשמשתמש פותח אפליקציה בפעם הראשונה אחרי ההתקנה או ההתקנה מחדש. משמש כחלק ממשפך המרות. |
מדדים נוספים
מדד | תיאור |
---|---|
notification_dismiss | אירוע Analytics שמופעל כשהתראה שנשלחה על ידי מחבר ההתראות נסגרת (ב-Android בלבד). |
notification_receive | אירוע Analytics שמופעל כשהודעה שנשלחה מהמלחין להתראות מתקבלת בזמן שהאפליקציה פועלת ברקע (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.
כדי להתחיל, מבצעים את הפעולות הבאות כפי שמתואר במדריך הזה:
- הפעלת ייצוא של BigQuery ל-Google Analytics במסוף Firebase
- גישה לנתונים של A/B Testing באמצעות BigQuery
- שאילתות לדוגמה
הפעלת ייצוא של BigQuery ל-Google Analytics במסוף Firebase
בתוכנית Spark תוכלו להשתמש ב-Sandbox BigQuery כדי לגשת ל-BigQuery ללא תשלום, בכפוף למגבלות של Sandbox. למידע נוסף, ראו תמחור ו-BigQuery sandbox.
קודם כול, צריך לוודא שאתם מייצאים את נתוני Analytics אל BigQuery:
- פותחים את הכרטיסייה Integrations (שילובים). אפשר לגשת אליה באמצעות > Project settings (הגדרות הפרויקט) במסוף Firebase.
- אם אתם כבר משתמשים ב-BigQuery עם שירותי Firebase אחרים, צריך ללחוץ על ניהול. אחרת, לוחצים על קישור.
- קוראים את המאמר מידע על קישור 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 בפברואר 2024 עד 2 במאי 2024, עליכם לציין את הערך_TABLE_SUFFIX between '20240202' AND '20240502'
. לדוגמה, ראו בחירת ערכים של ניסוי ספציפי. - שמות אירועים: בדרך כלל הם תואמים למדדי היעדים שהגדרתם בניסוי. לדוגמה,
in_app_purchase
אירועים,ad_impression
אוuser_retention
אירועים.
אחרי שאוספים את המידע הנדרש ליצירת השאילתה:
- פותחים את BigQuery במסוף Google Cloud.
- בוחרים את הפרויקט ואז בוחרים באפשרות Create SQL query.
- מוסיפים את השאילתה. לדוגמה, ראו שאילתות לדוגמה.
- לוחצים על Run.
שליחת שאילתות על נתוני הניסוי באמצעות השאילתה שנוצרת באופן אוטומטי במסוף Firebase
אם אתם משתמשים בתוכנית Blaze, בדף סקירה כללית של הניסוי מוצגת שאילתה לדוגמה שמציגה את שם הניסוי, הווריאנטים, שמות האירועים ומספר האירועים בניסוי שמוצג.
כדי לקבל ולהריץ את השאילתה שנוצרה באופן אוטומטי:
- במסוף Firebase, פותחים את A/B Testing ובוחרים את הניסוי ב-A/B Testing שרוצים לשלוח עליו שאילתה כדי לפתוח את הסקירה הכללית של הניסוי.
- בתפריט האפשרויות, בקטע 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