שילוב אנליטיקת נתוני משחק: מודל אירועים, Firebase, BigQuery

שילוב אנליטיקת נתוני משחק: מודל אירועים, Firebase, BigQuery

לעתים קרובות אנו נתקלים במצבים שבהם Firebase Analytics ב-Unity משולב תוך חצי שעה. חודש לאחר ההשקה, מנהל המוצר מגלה שהמרת הרכישה באנדרואיד היא חצי מזו שב-iOS. אירועים מתועדים עם שמות נכונים, אך פרמטרים אובדים חלקית עקב חריגה ממגבלת 25 הפרמטרים המותאמים אישית לכל אירוע. משפך השימור אינו מוגדר: session_start ו-first_open נספרים אוטומטית, אך אירועי התקדמות רמות מעולם לא נשלחו. אנליטיקה היא לא רק "חיבור ה-SDK". זהו מאמץ שיטתי: עיצוב מודל אירועים המותאם לעיצוב המשחק ולמדדים העסקיים. במשך 5 שנים, השלמנו למעלה מ-50 אינטגרציות — מהיפר-קז'ואל ועד פרויקטי AAA. ארכיטקטורת אנליטיקה נכונה חוסכת עד 40% מהזמן בפרשנות נתונים.

למה נתונים אובדים

טקסונומיית אירועים שגויה. מגבלות Firebase: 500 שמות אירועים ייחודיים לכל אפליקציה, שמות עד 40 תווים, פרמטרים עד 25 לכל אירוע, ערכי מחרוזת עד 100 תווים. פרויקטים שמתעדים את level_complete_world_1_level_5_stars_3 כשם אירוע פוגעים במהרה בתקרה ומאבדים גמישות בנתונים היסטוריים. הסכימה הנכונה: level_complete כאירוע, world_id, level_id, stars, time_sec, attempts כפרמטרים. זה מאפשר חיתוך ב-BigQuery ללא שינוי קוד הלקוח.

דגימה ב-GA4. Firebase Analytics (GA4) מחיל דגימה מעל נפח נתונים מסוים בממשק הסטנדרטי. לנתונים מדויקים, שלבו עם BigQuery Export — חינמי ב-Firebase אך דורש הגדרה. ללא BigQuery, משפכים לקהלים של מיליון משתמשים מציגים מספרים משוערים. בניסיוננו, צמצמנו את שגיאת הדגימה ל-1% — עבור לקוח, זה אומר התאמת תחזית ההכנסות ב-15%.

שכפול אירועים ב-Unity. בעת שימוש ב-DontDestroyOnLoad למנהל האנליטיקה, קל להגיע למצב שבו לאחר טעינת סצנה חדשה, המופע הישן אינו נהרס — אירועים נשלחים פעמיים. FirebaseAnalytics.LogEvent() אינו אידמפוטנטי; כפילויות בזרם הגולמי אינן נראות ללא group by ב-BigQuery. אנו פותרים זאת באמצעות Service Locator וסינגלטון מובטח — מספר הכפילויות יורד לאפס.

איך לעצב מודל אירועים

1. זיהוי משפכים מרכזיים: הרשמה, התקדמות רמות, רכישות.
2. מינוי בעל טקסונומיה — מעצב משחק או אנליסט.
3. תיעוד שמות אירועים ופרמטרים לפני כתיבת קוד.
4. הבטחה ששמות אירועים לא יעלו על 40 תווים ומספר הפרמטרים ≤25.
5. בדיקת שליחת אירועים במהלך הפיתוח באמצעות DebugView.

מה כולל השילוב

עיצוב מודל אירועים — במשותף עם מעצב המשחק והאנליסט של הלקוח. קביעה: אילו אירועים נדרשים לניתוח שימור (D1/D7/D30), משפך מונטיזציה, איזון רמות, בדיקות A/B. קיבוע במסמך טקסונומיית אירועים לפני הקידוד.

אינטגרציית SDK: Firebase Analytics כבסיס, ובנוסף אופציונלית Amplitude (טובה יותר לניתוח התנהגותי), GameAnalytics (חינמית, טובה למובייל היפר-קז'ואל), או AppsFlyer/Adjust לייחוס. כל SDK דורש אתחול נפרד עם תשומת לב ל-GDPR ו-ATT.

יישום: אנו כותבים הפשטה של IAnalyticsService מעל SDK ספציפיים — זה מאפשר החלפת ספקים ללא שינוי קוד המשחק. AnalyticsManager — סינגלטון באמצעות ServiceLocator, לא MonoBehaviour — מסיר תלות במחזור חיי הסצנה.

הגדרת BigQuery Export מקונסולת Firebase, יצירת שאילתות אנליטיות בסיסיות לדיווח (שימור, משפך, הכנסות לפי פלחים), אופציונלית לוח מחוונים ב-Looker Studio.

{ "event": "level_complete", "parameters": { "world_id": 3, "level_id": 15, "stars": 2, "time_sec": 120, "attempts": 4 } }