‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

יצירת ניסויים בהעברת הודעות עם בדיקות A/B

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

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

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

יצירת ניסוי

ניסוי שמשתמש ב-Notifications composer מאפשר לכם להעריך כמה וריאנטים של הודעת התראה אחת.

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

אם לא הפעלתם את Google Analytics כשיצרתם את הפרויקט, אתם יכולים להפעיל אותו בכרטיסייה Settings > Integrations במסוף Firebase.
במסוף Firebase, עוברים אל DevOps & Engagement (DevOps ומעורבות) > A/B Testing (בדיקת A/B).
לוחצים על Create experiment, ואז בוחרים באפשרות Notifications כשמופיעה בקשה לבחור את השירות שרוצים לבדוק.
מזינים שם ותיאור (אופציונלי) לניסוי ולוחצים על הבא.
ממלאים את השדות בקטע טירגוט. קודם בוחרים את האפליקציה שבה רוצים להפעיל את הניסוי. אתם יכולים גם לטרגט קבוצת משנה של משתמשים שישתתפו בניסוי, על ידי בחירת אפשרויות שכוללות את הפרטים הבאים:
- גרסה: גרסה אחת או יותר של האפליקציה
- קהל משתמשים: קהלים של Analytics שמשמשים לטירגוט משתמשים שעשויים להיכלל בניסוי
- מאפיין משתמש: מאפיין משתמש אחד או יותר ב-Analytics לבחירת משתמשים שעשויים להיכלל בניסוי
- מדינה/אזור: מדינה אחת או יותר או אזור אחד או יותר לבחירת משתמשים שעשויים להיכלל בניסוי
- שפת המכשיר: שפה אחת או יותר והגדרות מקומיות שמשמשות לבחירת משתמשים שעשויים להיכלל בניסוי.
- פתיחה ראשונה: טירגוט משתמשים על סמך הפעם הראשונה שהם פתחו את האפליקציה
- אינטראקציה אחרונה עם האפליקציה: טירגוט משתמשים על סמך הפעם האחרונה שהם ביצעו אינטראקציה עם האפליקציה.
הערה: בניסויים שמטרגטים קהלי משתמשים ב-Analytics, יכול להיות שיעברו 24 עד 48 שעות עד שהנתונים יצטברו. מידע נוסף על האפשרות הזו ועל אפשרויות טירגוט אחרות זמין במאמר טירגוט משתמשים.
מגדירים את אחוז משתמשי היעד: בוחרים את אחוז המשתמשים באפליקציה שתואמים לקריטריונים שהוגדרו בקטע משתמשי היעד, שאותם רוצים לחלק באופן שווה בין קבוצת הבסיס לבין וריאנט אחד או יותר בניסוי. אפשר להגדיר כל אחוז בין 0.01% ל-100%. האחוזים מוקצים מחדש באופן אקראי למשתמשים בכל ניסוי, כולל ניסויים משוכפלים.
בקטע Variants, בשדה Enter message text, מקלידים את ההודעה שרוצים לשלוח לקבוצת הבסיס. כדי לא לשלוח הודעה לקבוצת הבסיס, משאירים את השדה הזה ריק.
(אופציונלי) כדי להוסיף יותר מגרסה אחת לניסוי, לוחצים על Add Variant. כברירת מחדל, בניסויים יש קבוצת בקרה אחת וקבוצת ניסוי אחת.
(אופציונלי) מזינים שם לכל וריאנט בניסוי כדי להחליף את השמות וריאנט א', וריאנט ב' וכו'.
מגדירים מדד יעד לניסוי, שבו משתמשים כשמעריכים את הווריאציות של הניסוי, וגם מדדים נוספים שרוצים מהרשימה הנפתחת. המדדים האלה כוללים יעדים מובנים (התעניינות, רכישות, הכנסות, שימור וכו'), אירועי המרה ב-Analytics ואירועים אחרים ב-Analytics.
בוחרים אפשרויות להודעה:
- תאריך מסירה: בוחרים באפשרות שליחה עכשיו כדי להפעיל את הניסוי מיד אחרי השמירה, או באפשרות מתוזמן כדי לציין מועד להפעלת הניסוי בעתיד.
- אפשרויות מתקדמות: כדי לבחור אפשרויות מתקדמות לכל ההתראות שכלולות בניסוי, מרחיבים את הקטע Advanced options ומשנים את אחת מהאפשרויות שמופיעות ברשימה.
לוחצים על בדיקה כדי לשמור את הניסוי.

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

אימות הניסוי במכשיר בדיקה

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

כדי לקבל את טוקן הרישום של FCM:

Swift

Messaging.messaging().token { token, error in
  if let error = error {
    print("Error fetching remote FCM registration token: \(error)")
  } else if let token = token {
    print("Remote instance ID token: \(token)")
  }
}

Objective-C

[[FIRMessaging messaging] tokenWithCompletion:^(NSString * _Nullable token, NSError * _Nullable error) {
  if (error != nil) {
    NSLog(@"Error fetching the remote FCM registration token: %@", error);
  } else {
    NSLog(@"Remote FCM registration token: %@", token);
    NSString* message =
      [NSString stringWithFormat:@"FCM registration token: %@", token];
    // display message
    NSLog(@"%@", message);
  }
}];

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

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, עוברים אל DevOps & Engagement (DevOps ומעורבות) > A/B Testing (בדיקת A/B).
לוחצים על טיוטה, מעבירים את העכבר מעל הניסוי, לוחצים על תפריט ההקשר () ואז על ניהול מכשירי בדיקה.
מזינים את הטוקן של FCM למכשיר בדיקה ובוחרים את וריאנט הניסוי שרוצים לשלוח למכשיר הבדיקה הזה.
מפעילים את האפליקציה ומוודאים שהווריאנט שנבחר מתקבל במכשיר הבדיקה.

ניהול הניסוי

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

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

התחלת ניסוי

במסוף Firebase, עוברים אל DevOps & Engagement (DevOps ומעורבות) > A/B Testing (בדיקת A/B).
לוחצים על טיוטה ואז על שם הניסוי.
כדי לוודא שיש באפליקציה משתמשים שייכללו בניסוי, מרחיבים את פרטי הטיוטה ובודקים אם מופיע מספר שגדול מ-0% בקטע טירגוט והפצה (לדוגמה, 1% מהמשתמשים שעומדים בקריטריונים).
כדי לשנות את הניסוי, לוחצים על עריכה.
כדי להתחיל את הניסוי, לוחצים על התחלת הניסוי. אפשר להפעיל עד 24 ניסויים בכל פרויקט בו-זמנית.

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

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

במסוף Firebase, עוברים אל DevOps & Engagement (DevOps ומעורבות) > A/B Testing (בדיקת A/B).
לוחצים על פועל, ואז לוחצים על שם הניסוי או מחפשים אותו. בדף הזה אפשר לראות נתונים סטטיסטיים שונים שנצפו ונבנו לפי מודל לגבי הניסוי שפועל, כולל:
- ההפרש באחוזים מערך הבסיס: מדד לשיפור של מדד מסוים בווריאנט נתון בהשוואה לערך הבסיס. הערך מחושב על ידי השוואה בין טווח הערכים של הווריאציה לבין טווח הערכים של קו הבסיס.
- ההסתברות לגבור על שיעור ההמרה הבסיסי: ההסתברות המשוערת שגרסה מסוימת תגבור על שיעור ההמרה הבסיסי של המדד שנבחר.
- observed_metric לכל משתמש: על סמך תוצאות הניסוי, זהו הטווח החזוי שערך המדד יגיע אליו לאורך זמן.
- ‫Total observed_metric: הערך המצטבר שנצפה עבור קו הבסיס או הווריאנט. הערך משמש למדידת הביצועים של כל וריאנט בניסוי, ולחישוב השיפור, טווח הערכים, ההסתברות לגבור על שיעור ההמרה הבסיסי וההסתברות להיות הווריאנט הטוב ביותר. בהתאם למדד שנמדד, העמודה הזו יכולה להיות מסומנת בתווית "משך זמן לכל משתמש", "הכנסה לכל משתמש", "שיעור שימור" או "שיעור המרה".
אחרי שהניסוי פועל במשך זמן מה (לפחות 7 ימים עבור FCM ו-In-App Messaging או 14 ימים עבור Remote Config), הנתונים בדף הזה מציינים איזו וריאציה, אם בכלל, היא ה "מובילה". חלק מהמדדים מלווים בתרשים עמודות שמציג את הנתונים בפורמט חזותי.

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

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

במסוף Firebase, עוברים אל DevOps & Engagement (DevOps ומעורבות) > A/B Testing (בדיקת A/B).
לוחצים על Completed או על Running, לוחצים על הניסוי שרוצים להשיק לכל המשתמשים, לוחצים על תפריט ההקשר () ואז על Roll out variant.
כדי להשיק את הניסוי לכל המשתמשים, מבצעים אחת מהפעולות הבאות:
- בניסוי שמשתמש בניסוח מסרים (Notifications Composer), משתמשים בתיבת הדו-שיח השקת ההודעה כדי לשלוח את ההודעה לשאר המשתמשים המטורגטים שלא היו חלק מהניסוי.
- בניסוי של Remote Config, בוחרים וריאנט כדי לקבוע אילו ערכי פרמטרים של Remote Config יתעדכנו. הקריטריונים לטירגוט שהוגדרו בזמן יצירת הניסוי יתווספו כתנאי חדש בתבנית, כדי שהפעלת הווריאנט תשפיע רק על המשתמשים שטורגטו בניסוי. אחרי שלוחצים על Review in Remote Config (בדיקה בהגדרת תצורה מרחוק) כדי לבדוק את השינויים, לוחצים על Publish changes (פרסום השינויים) כדי להשלים את ההשקה.
- בניסוי של In-App Messaging, משתמשים בתיבת הדו-שיח כדי לקבוע איזו גרסה צריך להשיק כקמפיין In-App Messaging נפרד. אחרי שתבחרו את הקמפיין, תועברו למסך היצירה של FIAM כדי לבצע שינויים (אם צריך) לפני הפרסום.

הרחבת ניסוי

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

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

שכפול או הפסקה של ניסוי

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

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

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

קריטריון טירגוט	מפעילים	ערכים	הערה
גרסה	מכיל, לא מכיל, תואם בדיוק, מכיל ביטוי רגולרי (regex)	מזינים ערך לגרסה אחת או יותר של האפליקציה שרוצים לכלול בניסוי.	כשמשתמשים באופרטורים contains,‏ does not contain או matches exactly, אפשר לספק רשימה של ערכים מופרדים בפסיקים. כשמשתמשים באופרטור מכיל ביטוי רגולרי, אפשר ליצור ביטויים רגולריים בפורמט RE2. הביטוי הרגולרי יכול להתאים לכל המחרוזת של גרסת היעד או לחלק ממנה. אפשר גם להשתמש בעוגנים ^ ו-$ כדי להתאים את ההתחלה, הסוף או כל מחרוזת היעד.
קהל או קהלים של משתמשים	כולל את כל, כולל לפחות אחד מתוך, לא כולל את כל, לא כולל לפחות אחד מתוך	בוחרים קהל אחד או יותר ב-Analytics כדי לטרגט משתמשים שעשויים להיכלל בניסוי.	בחלק מהניסויים שמטרגטים קהלים מסוג Google Analytics, יכול להיות שיעברו כמה ימים עד שיצטברו נתונים, כי הם כפופים לזמן אחזור של עיבוד נתונים של Analytics. סביר להניח שתיתקלו בעיכוב הזה עם משתמשים חדשים, שבדרך כלל מתווספים לקהלים שעומדים בדרישות תוך 24 עד 48 שעות אחרי היצירה, או עם קהלים שנוצרו לאחרונה.
מאפיין משתמש	לטקסט: מכיל, לא מכיל, תואם בדיוק, מכיל ביטוי רגולרי (regex) למספרים: <, ≤, =, ≥, >	מאפיין משתמש של Analytics משמש לבחירת משתמשים שעשויים להיכלל בניסוי, עם מגוון אפשרויות לבחירת ערכים של מאפייני משתמשים. בצד הלקוח, אפשר להגדיר רק ערכי מחרוזת למאפייני משתמש. בתנאים שמשתמשים באופרטורים מספריים, שירות Remote Config ממיר את הערך של מאפיין המשתמש התואם למספר שלם או למספר ממשי.	כשמשתמשים באופרטור מכיל ביטוי רגולרי, אפשר ליצור ביטויים רגולריים בפורמט RE2. הביטוי הרגולרי יכול להתאים לכל המחרוזת של גרסת היעד או לחלק ממנה. אפשר גם להשתמש בעוגנים ^ ו-$ כדי להתאים את ההתחלה, הסוף או כל מחרוזת היעד.
ארץ/אזור	לא רלוונטי	מדינה אחת או יותר, או אזור אחד או יותר, שמשמשים לבחירת משתמשים שעשויים להיכלל בניסוי.
שפות	לא רלוונטי	שפה אחת או יותר ולוקאלים שמשמשים לבחירת משתמשים שעשויים להיכלל בניסוי.
פתיחה ראשונה	יותר מ- פחות מ- בין	טירגוט משתמשים לפי הפעם הראשונה שהם פתחו את האפליקציה, בימים.
האינטראקציה האחרונה עם האפליקציה	יותר מ- פחות מ- בין	טירגוט משתמשים על סמך הפעם האחרונה שבה הם קיימו אינטראקציה עם האפליקציה, במספר ימים.

‫A/B Testing מדדים

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

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

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

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

מדדי יעדים

מדד	תיאור
משתמשים שהאפליקציה שלהם לא קרסה	אחוז המשתמשים שלא נתקלו באפליקציה בשגיאות שזוהו על ידי ה-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.

כדי להתחיל, צריך לבצע את הפעולות הבאות, כפי שמתואר במדריך הזה:

הפעלת הייצוא של BigQuery ל-Google Analytics במסוף Firebase
גישה לנתונים של A/B Testing באמצעות BigQuery
שאילתות לדוגמה

צריך להפעיל את הייצוא של BigQuery עבור Google Analytics במסוף Firebase

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

קודם כל, ודאו שאתם מייצאים את נתוני Analytics אל BigQuery:

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

אם בכרטיס כתוב Link, צריך להגדיר את הייצוא (המשיכו לשלב הבא).
אם אתם צריכים להגדיר ייצוא:
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.

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

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

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

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

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

במסוף Firebase, עוברים אל DevOps & Engagement (DevOps ומעורבות) > A/B Testing (בדיקת A/B).
בוחרים את הניסוי ב-A/B Testing שרוצים לשלוח לגביו שאילתה כדי לפתוח את סקירת הניסוי.
בתפריט האפשרויות, בקטע שילוב עם BigQuery, לוחצים על שאילתה על נתוני הניסוי. הפרויקט ייפתח ב-BigQuery במסוף Google Cloud, ותוצג שאילתה בסיסית שבה אפשר להשתמש כדי לשלוח שאילתות לגבי נתוני הניסוי.

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

  /*
    This query is auto-generated by Firebase A/B Testing for your
    experiment "Winter welcome experiment".
    It demonstrates how you can get event counts for all Analytics
    events logged by each variant of this experiment's population.
  */
  SELECT
    'Winter welcome experiment' AS experimentName,
    CASE userProperty.value.string_value
      WHEN '0' THEN 'Baseline'
      WHEN '1' THEN 'Welcome message (1)'
      WHEN '2' THEN 'Welcome message (2)'
      END AS experimentVariant,
    event_name AS eventName,
    COUNT(*) AS count
  FROM
    `analytics_000000000.events_*`,
    UNNEST(user_properties) AS userProperty
  WHERE
    (_TABLE_SUFFIX BETWEEN '20260202' AND '20260502')
    AND userProperty.key = 'firebase_exp_25'
  GROUP BY
    experimentVariant, eventName

בקטע דוגמאות לשאילתות תוכלו למצוא דוגמאות נוספות לשאילתות.

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

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

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

אתם יכולים להשתמש בנתוני התוצאות של הניסוי כדי לאמת באופן עצמאי את התוצאות של Firebase A/B Testing. BigQueryהצהרת ה-SQL הבאה מחלצת את וריאציות הניסוי, את מספר המשתמשים הייחודיים בכל וריאציה, את סך ההכנסות מאירועי in_app_purchase ו-ecommerce_purchase ואת סטיות התקן של כל הניסויים בטווח הזמן שצוין כתאריכי ההתחלה והסיום של _TABLE_SUFFIX. אתם יכולים להשתמש בנתונים שמתקבלים מהשאילתה הזו עם מחולל מובהקות סטטיסטית לבדיקות t חד-צדדיות, כדי לוודא שהתוצאות ש-Firebase מספקת תואמות לניתוח שלכם.

במאמר פירוש תוצאות הבדיקה מוסבר איך A/B Testing מחשב את ההסקה.

  /*
    This query returns all experiment variants, number of unique users,
    the average USD spent per user, and the standard deviation for all
    experiments within the date range specified for _TABLE_SUFFIX.
  */
  SELECT
    experimentNumber,
    experimentVariant,
    COUNT(*) AS unique_users,
    AVG(usd_value) AS usd_value_per_user,
    STDDEV(usd_value) AS std_dev
  FROM
    (
      SELECT
        userProperty.key AS experimentNumber,
        userProperty.value.string_value AS experimentVariant,
        user_pseudo_id,
        SUM(
          CASE
            WHEN event_name IN ('in_app_purchase', 'ecommerce_purchase')
              THEN event_value_in_usd
            ELSE 0
            END) AS usd_value
      FROM `PROJECT_NAME.analytics_ANALYTICS_ID.events_*`
      CROSS JOIN UNNEST(user_properties) AS userProperty
      WHERE
        userProperty.key LIKE 'firebase_exp_%'
        AND event_name IN ('in_app_purchase', 'ecommerce_purchase')
        AND (_TABLE_SUFFIX BETWEEN 'YYYYMMDD' AND 'YYYMMDD')
      GROUP BY 1, 2, 3
    )
  GROUP BY 1, 2
  ORDER BY 1, 2;

בחירת ערכים של ניסוי ספציפי

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

  SELECT
    'EXPERIMENT_NAME' AS experimentName,
    CASE userProperty.value.string_value
      WHEN '0' THEN 'Baseline'
      WHEN '1' THEN 'VARIANT_1_NAME'
      WHEN '2' THEN 'VARIANT_2_NAME'
      END AS experimentVariant,
    event_name AS eventName,
    COUNT(*) AS count
  FROM
    `analytics_ANALYTICS_PROPERTY.events_*`,
    UNNEST(user_properties) AS userProperty
  WHERE
    (_TABLE_SUFFIX BETWEEN 'YYYMMDD' AND 'YYYMMDD')
    AND userProperty.key = 'firebase_exp_EXPERIMENT_NUMBER'
  GROUP BY
    experimentVariant, eventName