כשאתם פונים למשתמשים או מתחילים קמפיין שיווקי חדש, אתם רוצים לוודא שאתם עושים את זה נכון. בדיקות A/B יכולות לעזור לכם למצוא את הניסוח והתצוגה האופטימליים על ידי בדיקת וריאציות של הודעות בחלקים נבחרים של בסיס המשתמשים שלכם. בין שהמטרה שלכם היא לשפר את שיעור השימור או את ההמרות על המבצע, בדיקת A/B יכולה לבצע ניתוח סטטיסטי כדי לקבוע אם וריאנט של הודעה מניב ביצועים טובים יותר מהבסיס של היעד שבחרתם.
כדי לבצע בדיקת A/B של וריאנטים של תכונות עם קו בסיס, מבצעים את הפעולות הבאות:
- יוצרים את הניסוי.
- מאמתים את הניסוי במכשיר בדיקה.
- מנהלים את הניסוי.
יצירת ניסוי
ניסוי באמצעות הכלי 'יצירת התראות' מאפשר לבדוק כמה וריאנטים בהודעת התראה אחת.
נכנסים למסוף Firebase ומוודאים ש-Google Analytics מופעל בפרויקט, כדי שלניסוי תהיה גישה לנתוני Analytics.
אם לא הפעלתם את Google Analytics בזמן יצירת הפרויקט, תוכלו להפעיל אותו בכרטיסייה Integrations. אפשר לגשת לכרטיסייה הזו דרך > Project settings במסוף Firebase.
בקטע Engage בסרגל הניווט של מסוף Firebase, לוחצים על A/B Testing.
לוחצים על Create experiments (יצירת ניסוי), ואז בוחרים Notifications כשמוצגת בקשה לשירות שבו רוצים להתנסות.
מזינים שם ותיאור אופציונלי לניסוי, ולוחצים על הבא.
ממלאים את השדות טירגוט, ובוחרים קודם את האפליקציה שבה נעשה שימוש בניסוי. אפשר גם לטרגט קבוצת משנה של המשתמשים כדי שהם ישתתפו בניסוי. לשם כך, בוחרים באפשרויות הבאות:
- גרסה: גרסה אחת או יותר של האפליקציה
- קהל משתמשים: Analytics קהלים שמשמשים לטירגוט משתמשים שעשויים להיכלל בניסוי
- מאפיין משתמש: מאפיין משתמש אחד או יותר מסוג Analytics לבחירת משתמשים שעשויים להיכלל בניסוי
- מדינה/אזור: מדינה אחת או אזור אחד או יותר לבחירת המשתמשים שיכולים להיכלל בניסוי
- שפת המכשיר: שפה או לוקאל אחד או יותר שמשמשים לבחירת המשתמשים שעשויים להיכלל בניסוי
- פתיחה ראשונה: טירגוט משתמשים על סמך הפעם הראשונה שהם פתחו את האפליקציה
- התעניינות אחרונה באפליקציה: טירגוט משתמשים על סמך הפעם האחרונה שהם התעניינו באפליקציה
מגדירים את אחוז המשתמשים לטירגוט:בוחרים את האחוז מתוך בסיס המשתמשים באפליקציה שתואם לקריטריונים שהוגדרו בקטע טירגוט משתמשים שרוצים לחלק באופן שווה בין וריאנט הבסיס לבין וריאנט אחד או יותר בניסוי. אפשר להגדיר כל אחוז בין 0.01% ל-100%. האחוזים מוקצים מחדש באופן אקראי למשתמשים בכל ניסוי, כולל ניסויים כפולים.
בקטע Variants, כותבים הודעה שרוצים לשלוח לקבוצת הבקרה בשדה Enter message text. כדי לא לשלוח הודעה לקבוצת הבקרה, משאירים את השדה הזה ריק.
(אופציונלי) כדי להוסיף עוד וריאציות לניסוי, לוחצים על Add Variant. כברירת מחדל, לכל ניסוי יש קבוצת בסיס אחת ווריאנט אחד.
(אופציונלי) מזינים שם לכל וריאנט בניסוי כדי להחליף את השמות וריאנט א', וריאנט ב' וכו'.
הגדירו לניסוי מדד יעד שישמש להערכה של וריאציות הניסוי, יחד עם המדדים הנוספים הרצויים מהרשימה הנפתחת. המדדים האלה כוללים יעדים מובנים (מעורבות, רכישות, הכנסות, שימור וכו'), אירועי המרה מסוג Analytics ואירועי Analytics אחרים.
בוחרים אפשרויות להודעה:
- תאריך שליחה: בוחרים באפשרות שליחה כדי להפעיל את הניסוי מיד אחרי השמירה, או באפשרות מתוזמן כדי לציין מועד להפעלת הניסוי בעתיד.
- אפשרויות מתקדמות: כדי לבחור אפשרויות מתקדמות לכל ההתראות שכלולות בניסוי, מרחיבים את הקטע אפשרויות מתקדמות ומשנים את אחת מאפשרויות ההודעות שמפורטות.
לוחצים על בדיקה כדי לשמור את הניסוי.
מותר ליצור עד 300 ניסויים לכל פרויקט, שיכולים לכלול עד 24 ניסויים פעילים, והשאר טיוטות או ניסויים שהושלמו.
אימות הניסוי במכשיר בדיקה
לכל התקנה של Firebase אפשר לאחזר את אסימון ההרשמה FCM שמשויך אליה. אפשר להשתמש באסימון הזה כדי לבדוק וריאנטים ספציפיים של ניסוי במכשיר בדיקה שבו מותקנת האפליקציה. כדי לאמת את הניסוי במכשיר לבדיקה:
- מקבלים את טוקן הרישום FCM באופן הבא:
Swift
Messaging.messaging().token { token, error in if let error = error { print("Error fetching FCM registration token: \(error)") } else if let token = token { print("FCM registration token: \(token)") self.fcmRegTokenMessage.text = "Remote FCM registration token: \(token)" } }
Objective-C
[[FIRMessaging messaging] tokenWithCompletion:^(NSString *token, NSError *error) { if (error != nil) { NSLog(@"Error getting FCM registration token: %@", error); } else { NSLog(@"FCM registration token: %@", token); self.fcmRegTokenMessage.text = token; } }];
Java
FirebaseMessaging.getInstance().getToken() .addOnCompleteListener(new OnCompleteListener<String>() { @Override public void onComplete(@NonNull Task<String> task) { if (!task.isSuccessful()) { Log.w(TAG, "Fetching FCM registration token failed", task.getException()); return; } // Get new FCM registration token String token = task.getResult(); // Log and toast String msg = getString(R.string.msg_token_fmt, token); Log.d(TAG, msg); Toast.makeText(MainActivity.this, msg, Toast.LENGTH_SHORT).show(); } });
Kotlin+KTX
FirebaseMessaging.getInstance().token.addOnCompleteListener(OnCompleteListener { task -> if (!task.isSuccessful) { Log.w(TAG, "Fetching FCM registration token failed", task.exception) return@OnCompleteListener } // Get new FCM registration token val token = task.result // Log and toast val msg = getString(R.string.msg_token_fmt, token) Log.d(TAG, msg) Toast.makeText(baseContext, msg, Toast.LENGTH_SHORT).show() })
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.Messaging.FirebaseMessaging.DefaultInstance.GetTokenAsync().ContinueWith( task => { if (!(task.IsCanceled || task.IsFaulted) && task.IsCompleted) { UnityEngine.Debug.Log(System.String.Format("FCM registration token {0}", task.Result)); } });
- בסרגל הניווט של מסוף Firebase, לוחצים על A/B Testing.
- לוחצים על טיוטה, מעבירים את העכבר מעל הניסוי, לוחצים על תפריט ההקשר (more_vert) ואז על ניהול מכשירי הבדיקה.
- מזינים את הטוקן FCM של מכשיר הבדיקה ובוחרים את גרסת הניסוי שרוצים לשלוח למכשיר הבדיקה הזה.
- מפעילים את האפליקציה ומוודאים שהווריאציה שנבחרה מתקבלת במכשיר הבדיקה.
ניהול הניסוי
אחרי שיוצרים ניסוי עם Remote Config, עם הכלי 'התראות' או עם Firebase In-App Messaging, אפשר לאמת את הניסוי ולהתחיל אותו, לעקוב אחרי הניסוי בזמן שהוא פועל ולהגדיל את מספר המשתמשים שנכללים בניסוי הפעיל.
בסיום הניסוי, תוכלו לשים לב להגדרות שבהן נעשה שימוש בווריאנט הזוכה, ולאחר מכן להשיק את ההגדרות האלה לכל המשתמשים. לחלופין, אפשר להריץ ניסוי אחר.
התחלת ניסוי
- בקטע Engage בתפריט הניווט של מסוף Firebase, לוחצים על A/B Testing.
- לוחצים על טיוטה ואז על השם של הניסוי.
- כדי לוודא שיש באפליקציה משתמשים שייכללו בניסוי, מרחיבים את פרטי הטיוטה ובודקים אם מופיע מספר גבוה מ-0% בקטע טירגוט והפצה (לדוגמה, 1% מהמשתמשים שעומדים בקריטריונים).
- כדי לשנות את הניסוי, לוחצים על עריכה.
- כדי להתחיל את הניסוי, לוחצים על התחלת הניסוי. בכל פרויקט אפשר להריץ עד 24 ניסויים בכל פרויקט.
מעקב אחרי ניסוי
אחרי שהניסוי פועל במשך זמן מה, אפשר לבדוק את ההתקדמות שלו ולראות איך נראות התוצאות של המשתמשים שהשתתפו בניסוי עד כה.
- בקטע Engage בתפריט הניווט של מסוף Firebase, לוחצים על A/B Testing.
לוחצים על Running ואז על שם הניסוי או מחפשים אותו. בדף הזה אפשר לראות נתונים סטטיסטיים שונים שנצפו ונתונים סטטיסטיים לפי מודל לגבי הניסוי שפועל, כולל:
- % difference from baseline: מדד לשיפור המדד של וריאנט נתון בהשוואה לערך הבסיס. הערך מחושב על ידי השוואה בין טווח הערכים של הווריאנט לבין טווח הערכים של הבקרה.
- ההסתברות לגבור על שיעור ההמרה הבסיסי: ההסתברות המשוערת שגרסת המשנה מסוימת תגבר על שיעור ההמרה הבסיסי של המדד שנבחר.
- observed_metric לכל משתמש: על סמך תוצאות הניסוי, זהו הטווח החזוי לערך המדד לאורך זמן.
- סה"כ observed_metric: הערך המצטבר שנצפה של הבסיס או הווריאנט. הערך הזה משמש למדידת הביצועים של כל וריאנט של הניסוי, והוא משמש לחישוב השיפור, טווח הערכים, ההסתברות לגבור על ערך הבסיס וההסתברות להיות הווריאנט הטוב ביותר. בהתאם למדד שנמדד, העמודה הזו עשויה להיקרא 'משך זמן לכל משתמש', 'הכנסה לכל משתמש', 'שיעור שימור' או 'שיעור המרה'.
אחרי שהניסוי יפעל במשך זמן מה (לפחות 7 ימים ל-FCM ול-In-App Messaging או 14 ימים ל-Remote Config), הנתונים בדף הזה יציינו איזו וריאציה, אם בכלל, היא 'המובילה'. חלק מהמדידות מלוות בתרשים עמודות שמציג את הנתונים בפורמט חזותי.
השקה של ניסוי לכל המשתמשים
לאחר שניסוי פועל מספיק זמן כדי לזהות את הווריאנט "המוביל", או הווריאנט המנצח ביחס למדד היעד, ניתן לפרסם את הניסוי בקרב 100% מהמשתמשים. כך תהיה לך אפשרות לבחור וריאנט ולפרסם אותו לכל המשתמשים מאותו רגע ואילך. גם אם לא הייתה הגדרה מנצחת בניסוי, עדיין תוכלו להשיק וריאנט לכל המשתמשים.
- בקטע Engage בתפריט הניווט של מסוף Firebase, לוחצים על A/B Testing.
- לוחצים על complete או על running , לוחצים על הניסוי שרוצים לפרסם לכל המשתמשים ולוחצים על תפריט ההקשר ( ) Roll upVariant (השקת וריאנט).
כדי להשיק את הניסוי לכל המשתמשים, מבצעים אחת מהפעולות הבאות:
- בניסוי שבו נעשה שימוש בכלי ליצירת התראות, משתמשים בתיבת הדו-שיח הודעה להשקה כדי לשלוח את ההודעה לשאר המשתמשים המטורגטים שלא היו חלק מהניסוי.
- בניסוי מסוג Remote Config, בוחרים וריאנט כדי לקבוע אילו ערכי פרמטר של Remote Config לעדכן. קריטריוני הטירגוט שמוגדרים כשיוצרים את הניסוי נוספים כתנאי חדש לתבנית, כדי להבטיח שההשקה תשפיע רק על משתמשים שהניסוי מטרגט. אחרי שלוחצים על Review in Remote Config כדי לבדוק את השינויים, לוחצים על Publish changes (פרסום השינויים) כדי להשלים את ההשקה.
- אם מדובר בניסוי In-App Messaging, אפשר להשתמש בתיבת הדו-שיח כדי לקבוע איזה וריאנט צריך להשיק כקמפיין עצמאי של In-App Messaging. אחרי הבחירה, תועברו למסך הכתיבה של FIAM כדי לבצע שינויים (אם יש צורך) לפני הפרסום.
הרחבת הניסוי
אם אתם רואים שהניסוי לא מושך מספיק משתמשים כדי שמערכת A/B Testing תכריז על מנצח, תוכלו להגדיל את ההפצה של הניסוי כדי להגיע לאחוז גדול יותר מתוך בסיס המשתמשים של האפליקציה.
- בקטע Engage בתפריט הניווט של מסוף Firebase, לוחצים על A/B Testing.
- בוחרים את הניסוי שפועל שרוצים לערוך.
- בדף סקירה כללית של הניסוי, לוחצים על תפריט הסיטואציה ( ) ואז על עריכת הניסוי שפועל.
- בתיבת הדו-שיח טירגוט מוצגת אפשרות להגדיל את אחוז המשתמשים שנכללים בניסוי שפועל. בוחרים מספר גבוה יותר מהאחוז הנוכחי ולוחצים על פרסום. הניסוי יוצג לאחוז המשתמשים שציינתם.
שכפול או הפסקה של ניסוי
- בקטע התעניינות בתפריט הניווט של מסוף Firebase לוחצים על A/B Testing.
- לוחצים על הושלם או על פעיל, מעבירים את הסמן מעל הניסוי, לוחצים על תפריט ההקשר ( ) ואז לוחצים על העתקת הניסוי או על הפסקת הניסוי.
טירגוט משתמשים
אתם יכולים לטרגט את המשתמשים שרוצים לכלול בניסוי באמצעות הקריטריונים הבאים לטירגוט משתמשים.
קריטריון טירגוט | מפעילים | ערכים | הערה |
---|---|---|---|
גרסה | מכיל,
לא מכיל, תואם במדויק, מכיל ביטוי רגולרי (regex) |
מזינים ערך לגרסה אחת או יותר של האפליקציה שרוצים לכלול בניסוי. |
כשמשתמשים באחד מהאופרטורים contains, does not contain או matches exactly, אפשר לספק רשימה של ערכים מופרדים בפסיקים. כשמשתמשים באופרטור contains regex, אפשר ליצור ביטויים רגולריים בפורמט RE2. הביטוי הרגולרי יכול להתאים לכל מחרוזת הגרסה של היעד או לחלק ממנה. אפשר גם להשתמש בעוגנים ^ ו-$ כדי להתאים להתחלה, לסוף או לכל המחרוזת של היעד. |
קהלי משתמשים | כולל את כולם,
כולל לפחות אחד מהם, לא כולל את כולם, לא כולל לפחות אחד מהם |
בוחרים קהל Analytics אחד או יותר כדי לטרגט משתמשים שעשויים להיכלל בניסוי. | יכול להיות שיחלפו כמה ימים עד שיצטברו נתונים בניסויים מסוימים שמטרגטים קהלים של Google Analytics, כי הם כפופים לזמן אחזור של עיבוד נתונים של Analytics. הסבירות הגבוהה ביותר היא שהעיכוב הזה יתרחש אצל משתמשים חדשים, שבדרך כלל מצורפים לקהלים שעומדים בדרישות 24 עד 48 שעות אחרי היצירה, או אצל קהלים שנוצרו לאחרונה. |
מאפיין משתמש | לטקסט:
מכיל, לא מכיל, תואם בדיוק, מכיל ביטוי רגולרי למספרים: <, ≤, =, ≥, > |
מאפיין המשתמש Analytics משמש לבחירת משתמשים שעשויים להיכלל בניסוי, עם מגוון אפשרויות לבחירת ערכים של מאפיין המשתמש.
בצד הלקוח, אפשר להגדיר רק ערכים של מחרוזות למאפייני משתמש. בתנאים שמשתמשים באופרטורים מספריים, השירות Remote Config ממיר את הערך של מאפיין המשתמש התואם למספר שלם או למספר עשרוני. |
כשמשתמשים באופרטור contains regex אפשר ליצור ביטויים רגולריים בפורמט RE2. הביטוי הרגולרי יכול להתאים לכל מחרוזת הגרסה של היעד או לחלק ממנה. אפשר גם להשתמש בעוגנים ^ ו-$ כדי להתאים להתחלה, לסוף או לכל המחרוזת של היעד. |
ארץ/אזור | לא רלוונטי | מדינה אחת או אזור אחד או יותר שמשמשים לבחירת משתמשים שעשויים להיכלל בניסוי. | |
שפות | לא רלוונטי | שפה אחת או יותר ולוקאל אחד או יותר שבעזרתם בוחרים משתמשים שעשויים להיכלל בניסוי. | |
פתיחה ראשונה |
יותר מ-
פחות מ- בין |
אפשר לטרגט משתמשים על סמך הפעם הראשונה שהם פתחו את האפליקציה שלך, שצוין מספר ימים. | |
אינטראקציה אחרונה באפליקציה |
יותר מ-
פחות מ- בין |
טירגוט משתמשים על סמך הפעם האחרונה שהם השתמשו באפליקציה, מצוין בימים. |
A/B Testing מדדים
כשיוצרים ניסוי, בוחרים מדד ראשי, או יעד, שמשמש לקביעת הווריאנט המנצח. כדאי גם לעקוב אחרי מדדים אחרים, שיעזרו לכם להבין טוב יותר את הביצועים של כל וריאנט בניסוי ולעקוב אחרי מגמות חשובות שעשויות להיות שונות בכל וריאנט, כמו שימור משתמשים, יציבות האפליקציה והכנסות מרכישות מתוך האפליקציה. אפשר לעקוב אחרי עד חמישה מדדים שאינם מדדי יעד בניסוי.
לדוגמה, נניח שהוספתם רכישות חדשות מתוך האפליקציה ואתם רוצים להשוות בין היעילות של שתי הודעות 'דחיפה' שונות. במקרה כזה, מומלץ להגדיר את הכנסה מרכישות כמדד היעד, כי אתם רוצים שהגרסה הזו תייצג את התזכורת שהניבה את ההכנסה הגבוהה ביותר מרכישות מתוך האפליקציה. בנוסף, אתם רוצים לעקוב אחרי המשתנה שהניב יותר המרות עתידיות ומשתמשים שנשארו, ולכן כדאי להוסיף את המדדים הבאים בקטע מדדים אחרים למעקב:- הכנסה כוללת משוערת כדי לראות את ההבדל בין שתי הגרסאות בהכנסה המשולבת מרכישות מתוך האפליקציה וממודעות
- Retention (1 day), Retention (2-3 days), Retention (4-7 days) כדי לעקוב אחרי שימור המשתמשים היומי או השבועי
בטבלאות הבאות מוסבר איך מחושבים מדדי היעדים ומדדים אחרים.
מדדי יעדים
מדד | תיאור |
---|---|
משתמשים שהאפליקציה שלהם לא קרסה | אחוז המשתמשים שלא נתקלו באפליקציה בשגיאות שזוהו על ידי 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 שרוצים לשלוח עליו שאילתה כדי לפתוח את הסקירה הכללית של הניסוי.
- בתפריט Options, מתחת לקטע BigQuery integration, בוחרים באפשרות Query query 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. ההצהרה 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