אירועים ב-Firebase Analytics: אוטומטיים, מומלצים ומותאמים

נכתב על ידי דני צ'רניאק, DigiKnowledge. נבדק לאחרונה: 10.11.2026

אילו סוגי אירועים יש ב-Firebase Analytics?

Firebase Analytics, או בשמו הרשמי Google Analytics for Firebase, הוא ה-SDK שדרכו אפליקציה שולחת נתונים לנכס GA4. כל מה שהוא מודד הוא אירוע: פתיחה ראשונה, מעבר מסך, רכישה, שיתוף. התיעוד של Google מחלק את האירועים לסוגים, כשלכל סוג יש תשובה אחרת לשאלה מי מגדיר אותו ומה צריך לכתוב בקוד.

בתיעוד מופיע סוג נוסף, enhanced measurement, אבל האירועים שלו (גלילה, הורדת קובץ, קליק יוצא) שייכים לאתרים ולא לאפליקציות. את ההבדל בין Firebase לבין פלטפורמת ייחוס כמו AppsFlyer לא נפרט כאן, כי הוא מוסבר במדריך AppsFlyer מול Firebase.

מה נאסף אוטומטית בלי שורת קוד?

לפי התיעוד של Google, מרגע שה-SDK מותקן נאספים אירועים בלי קוד נוסף. אלה העיקריים באפליקציה:

שלושה סייגים שכדאי להכיר. הראשון: לפי התיעוד in_app_purchase לא מודד אוטומטית הכנסות מאפליקציה בתשלום או החזרים ומתעלם מרכישות בדיקה ו-sandbox, כך שהסכום ב-GA4 יכול להיות שונה ממה שמופיע ב-Play Console. השני: מי שמתעד את אותה רכישה גם ידנית עלול לקבל כפילות. השלישי: חלק מהאירועים האוטומטיים, למשל app_store_subscription_renew, מסומנים בתיעוד כאירועים שלא מיוצאים ל-BigQuery.

לכל אירוע באפליקציה, גם מותאם, מצורפים בין השאר הפרמטרים app_version, firebase_screen_id ו-firebase_screen_class. את app_exception ואת ניטור הקריסות עצמו פירטנו במדריך ניטור קריסות עם Crashlytics.

מתי משתמשים באירוע מומלץ?

אירוע מומלץ הוא אירוע שאתם שולחים בקוד, אבל בשם ובפרמטרים ש-Google הגדירה. לפי התיעוד, שליחה שלהם עם הפרמטרים שנקבעו להם נותנת את הפירוט המלא בדוחות ומאפשרת ליהנות מיכולות שיתווספו בעתיד. הדוגמה המוחשית ביותר: אירועי המכירות המקוונות, מ-view_item ועד purchase, הם אלה שמזינים את דוח Ecommerce purchases, כך שאירוע בשם אחר שמתאר רכישה לא יגיע לשם.

התיעוד מחלק את הרשימה לשלוש קבוצות: אירועים לכל נכס (login, sign_up, search, share, generate_lead, tutorial_begin, tutorial_complete), אירועי מכירות מקוונות (add_to_cart, begin_checkout, add_payment_info, purchase, refund) ואירועי משחקים (level_start, level_end, level_up, post_score, unlock_achievement). ב-SDK של Android השמות האלה קיימים כקבועים במחלקה FirebaseAnalytics.Event והפרמטרים במחלקה FirebaseAnalytics.Param, כמו בדוגמה מהתיעוד:

firebaseAnalytics.logEvent(FirebaseAnalytics.Event.SELECT_ITEM) {
    param(FirebaseAnalytics.Param.ITEM_ID, id)
    param(FirebaseAnalytics.Param.ITEM_NAME, name)
    param(FirebaseAnalytics.Param.CONTENT_TYPE, "image")
}

ההמלצה של Firebase היא לשלוח את האירועים המומלצים שרלוונטיים לאפליקציה יחד עם הפרמטרים שנקבעו להם. אירוע מומלץ בלי הפרמטרים שלו נותן רק חלק מהתמונה.

מתי יוצרים אירוע מותאם ואיך?

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

firebaseAnalytics.logEvent("share_image") {
    param("image_name", name)
    param("full_text", text)
}

הנקודה שהכי הרבה צוותים מפספסים: פרמטר שנשלח עם אירוע לא מופיע בדוחות מעצמו. לפי התיעוד צריך לרשום אותו תחת Custom Definitions, כמימד מותאם לערך טקסטואלי או כמדד מותאם לערך מספרי. בלי הרישום הזה הנתון נאסף, אבל לא תראו אותו בממשק. את ההיקפים והמכסות של הרישום פירטנו במדריך מימדים ומדדים מותאמים ב-GA4. התיעוד גם ממליץ לא ליצור שלא לצורך מימדים מותאמים בעלי קרדינליות גבוהה, למשל מזהה ייחודי לכל משתמש או חותמת זמן, כי הם עלולים לדחוס נתונים לשורת (other).

מהן מגבלות האיסוף שחייבים להכיר?

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

שלוש הבהרות. מכסת 500 האירועים חלה על app data streams בלבד: לפי התיעוד ב-web data streams אין מגבלה כזאת. התיעוד של Firebase מוסיף שאין מגבלה על נפח האירועים הכולל שהאפליקציה מתעדת. מה שחורג פשוט לא נרשם: Analytics לא מתעד את מאפיין המשתמש ה-26 או שם אירוע שארוך מ-40 תווים. Google Analytics 360 מעלה חלק מהמגבלות, אבל לפי התיעוד לא את מגבלות התווים של אירועים ופרמטרים.

המכסה שכדאי לשים עליה עין היא לא רק 500 האירועים אלא גם 25 הפרמטרים לאירוע, בעיקר באירועי רכישה שמישהו העמיס עליהם כל שדה מה-backend.

אילו כללי שמות שוברים אירוע?

לפי כללי השמות של Google, שם אירוע רגיש לאותיות גדולות וקטנות: Share_Image ו-share_image הם שני אירועים נפרדים ושניהם נספרים במכסה. שם חייב להתחיל באות ולהכיל רק אותיות, ספרות וקו תחתון, בלי רווחים. יש שמות שמורים שאי אפשר להשתמש בהם, רובם שמות של אירועים אוטומטיים. שמות של פרמטרים ושל מאפייני משתמש לא יכולים להתחיל בקו תחתון או באחת מהקידומות firebase_‎, ga_‎ או google_‎ (בפרמטרים שמורה גם הקידומת gtag עם נקודה אחריה). Google מציינת שהרשימות אינן סופיות ומתעדכנות מדי פעם.

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

מה מיוחד ב-screen_view ובפרמטרי ברירת מחדל?

screen_view נשלח אוטומטית בכל מעבר מסך. לפי התיעוד של Firebase ה-SDK מזהה את המחלקה של המסך שבפוקוס, UIViewController ב-iOS או Activity ב-Android. הוא מצמיד לאירועים את firebase_screen_class ומזהה מסך שנוצר אוטומטית. זה עובד טוב כשלכל מסך יש מחלקה משלו ופחות טוב כשכמה מסכים חולקים אותה מחלקה, למשל במשחקים. באפליקציות SwiftUI התיעוד מציין שצריך להגדיר את שמות המסכים ידנית.

אפשר לתעד screen_view ידנית עם שם מסך ומחלקה, גם כשהמעקב האוטומטי פעיל. אפשר גם לכבות את המעקב האוטומטי: ב-iOS במפתח FirebaseAutomaticScreenReportingEnabled בקובץ Info.plist, ב-Android בערך google_analytics_automatic_screen_reporting_enabled בקובץ AndroidManifest.xml.

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

איך בודקים שהאירוע באמת הגיע?

1. מפעילים לוג מפורט במכשיר. ב-Android מריצים את פקודות ה-adb שמופיעות בתיעוד וקוראים את האירועים ב-logcat. ב-iOS מוסיפים ב-Xcode את ארגומנט ההרצה FIRAnalyticsVerboseLoggingEnabled, עם מקף לפניו. זו הבדיקה המיידית ש-Firebase ממליצה עליה. את הפקודות המלאות תמצאו במדריך שבשלב הבא.
2. עוברים ל-DebugView. שם רואים את רצף האירועים של מכשיר בדיקה אחד עם הפרמטרים. את התהליך המלא פירטנו במדריך DebugView.
3. בודקים את שם האירוע והפרמטרים מול המגבלות. 40 תווים לשם, 25 פרמטרים, 100 תווים לערך. אירוע שחורג לא יופיע בכלל.
4. רושמים את הפרמטרים. מימד או מדד מותאם לכל פרמטר שצריך להופיע בדוח.
5. מחכים לדוח Events. לפי התיעוד הוא מתעדכן מדי פעם במהלך היום ולא בזמן אמת, לכן הוא מתאים לאימות אחרי שחרור ולא לבדיקה בזמן פיתוח.

שאלות נפוצות

מה השורה התחתונה?

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

מקורות

Firebase: Log events (Android), Google Analytics Help: Event collection limits, Firebase Help: Automatically collected events, Google Analytics Help: Recommended events, Google Analytics Help: Event naming rules, Firebase: Measure screenviews

דני צ'רניאק
יועץ אנליטיקה דיגיטלית ומייסד DigiKnowledge. מרצה לאנליטיקה דיגיטלית באוניברסיטת תל אביב, באוניברסיטה הפתוחה ובאוניברסיטת אריאל. לעמוד האישי