הגדרת אירועי אנליטיקה למשחקי מובייל: רמות, רכישות, שימור

הגדרת אירועי אנליטיקה למשחק מובייל: רמות, רכישות, שימור

אנליטיקה למשחק מובייל ללא טקסונומיית אירועים מתוכננת כראוי הופכת לערמת מספרים חסרי תועלת. תמונה טיפוסית: Firebase או Amplitude מציגות 300 אירועים, אבל לענות על 'למה שיעור השימור ל-7 ימים ירד מ-18% ל-11%' זה בלתי אפשרי — או שהנתונים הנדרשים לא נאספו או שנאספו עם שגיאות בפרמטרים. נתקלנו בזה עשרות פעמים ואנחנו יודעים איך למנוע את זה. טקסונומיית אירועים מעוצבת היטב היא הבסיס למדידה מדויקת של שימור, המרה ו-LTV. חיסכון באנליטיקה עולה 40% מתקציב פרסום מבוזבז — עשרות אלפי דולרים בקנה מידה גדול. ביקורת האנליטיקה שלנו חוסכת ללקוחות בדרך כלל 30,000–50,000 דולר בשנה בהוצאות פרסום שגויות.

ארכיטקטורת אירועי משחק

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

אירועי סשן — session_start, session_end עם session_duration_seconds. ב-session_end, רשום את סיבת הסיום: רקע, קריסה, voluntary_quit. זה מבדיל בין נטישה אמיתית לבעיות טכניות.

אירועי התקדמות הם קריטיים לניתוח שימור. סט הפרמטרים המינימלי עבור level_start / level_complete / level_fail:

// Android Kotlin + Firebase Analytics
val bundle = Bundle().apply {
    putString("level_id", "world2_level07")
    putInt("level_number", 23) // глобальный порядковый номер
    putInt("attempt_number", attemptCount) // попытка на этот уровень
    putString("difficulty", "hard")
    putInt("player_score_before", currentScore)
    putInt("coins_before", coinBalance)
    putLong("time_in_level_ms", elapsed)
}
Firebase.analytics.logEvent("level_complete", bundle)

// Android Kotlin + Firebase Analytics val bundle = Bundle().apply { putString("level_id", "world2_level07") putInt("level_number", 23) // глобальный порядковый номер putInt("attempt_number", attemptCount) // попытка на этот уровень putString("difficulty", "hard") putInt("player_score_before", currentScore) putInt("coins_before", coinBalance) putLong("time_in_level_ms", elapsed) } Firebase.analytics.logEvent("level_complete", bundle) הוא השדה שנשכח לרוב. בלעדיו, לא ניתן למדוד את נקודת התסכול: כמה ניסיונות שחקן עושה לפני שהוא פורש. טקסונומיה נכונה יעילה פי 3 מזיהוי אד-הוק באיתור צווארי בקבוק בשימור.

למה השימור יורד ללא אירועים מתאימים

נניח ששחקן משלים רמה בניסיון העשירי. אם לא אוספים attempt_number, רואים רק את המספר הכולל של השלמות. עם שדה זה, ניתן לבנות התפלגות של ניסיונות ולהבין באיזו רמה שחקנים מאבדים עניין. הניסיון מראה שאחרי 3–4 כישלונות, השימור יורד ב-15–20% — תובנה לאיזון קושי. לפי תיעוד Firebase, זיהוי משתמש נכון דרך attempt_number משפר את דיוק ניתוח השימור ב-25%. בנוסף, 70% מבעיות האנליטיקה במשחקים נגרמות מפרמטרים חסרים — לא מיישום פגום.

אירועי מונטיזציה — תמיד דרך setUserId() עם הפרמטרים הנדרשים על ידי FB/Google לייחוס ROAS:

// iOS Swift
Analytics.logEvent(AnalyticsEventPurchase, parameters: [
    AnalyticsParameterCurrency: "USD",
    AnalyticsParameterValue: 1.99,
    AnalyticsParameterItemID: "coin_pack_medium",
    AnalyticsParameterItemName: "500 Coins",
    AnalyticsParameterItemCategory: "currency",
    AnalyticsParameterTransactionID: receipt.transactionIdentifier,
    "attempt_number_at_purchase": attemptCount, // кастомный параметр
    "level_id_at_purchase": currentLevelId
])

purchase ו-// iOS Swift Analytics.logEvent(AnalyticsEventPurchase, parameters: [ AnalyticsParameterCurrency: "USD", AnalyticsParameterValue: 1.99, AnalyticsParameterItemID: "coin_pack_medium", AnalyticsParameterItemName: "500 Coins", AnalyticsParameterItemCategory: "currency", AnalyticsParameterTransactionID: receipt.transactionIdentifier, "attempt_number_at_purchase": attemptCount, // кастомный параметр "level_id_at_purchase": currentLevelId ]) — חושפים באיזו נקודת כאב בהתקדמות ההמרה לרכישה מתרחשת. זו תובנה ישירה לעיצוב מונטיזציה.

אירועי שימור: מה באמת צריך

שימור D1/D7/D30 מחושב אוטומטית ב-Firebase, Amplitude, GameAnalytics — בתנאי שהמשתמש מזוהה כראוי. הטעות העיקרית: שימוש ב-level_id_at_purchase במקום attempt_number_at_purchase לאחר אימות. לאחר התחברות, קרא:

Firebase.analytics.setUserId(userId) // Firebase amplitude.setUserId(userId) // Amplitude 

בלי זה, משתמש אחד נספר מספר פעמים — השימור מוערך בחסר, המרות משוכפלות. השוואה: פרויקטים עם זיהוי נכון מראים שימור גבוה ב-30% (מנתוני המקרים שלנו).

לניתוח שימור, חשוב גם אירוע installationId עם פרמטר userId. אל תסתמך רק על Session Start מערכתי — אפליקציה ברקע לא יוצרת סשן, אבל המשתמש אולי 'חזר' מבלי לפתוח את המשחק בסשן פעיל.

כלי אימות

פשוט להוסיף Firebase.analytics.setUserId(userId) // Firebase amplitude.setUserId(userId) // Amplitude לא מספיק — יש לוודא שאירועים מגיעים עם פרמטרים נכונים:

DebugView ב-Firebase הוא כלי QA חובה. רשום את המכשיר דרך daily_login וכל האירועים יופיעו בזמן אמת עם פרמטרים.

איך להבטיח איכות נתונים לפני השקה?

אנחנו מבטיחים שכל אירוע מאומת דרך DebugView במכשיר אמיתי. בנוסף, אנו מגדירים ניטור חריגות: אם מספר אירועי days_since_install מזנק בחדות, זה מאותת על בעיה. גישה זו מקצרת את זמן הדיבוג בחצי בהשוואה לבדיקת לוגים ידנית. עם ניסיון של 6+ שנים ויותר מ-50 פרויקטים שנבדקו, אנו מבטיחים שהאנליטיקה שלך ברמה ארגונית.

טעויות נפוצות ויקרות

logEvent כמחרוזת במקום מספר שלם. נראה מינורי עד שמנסים לבנות משפך 'מספר ניסיונות ממוצע לרמה' — האגרגציה נשברת.

רישום אירועים על thread רקע ללא בדיקה. adb shell setprop debug.firebase.analytics.app YOUR_PACKAGE_NAME ב-iOS ניתן לקריאה מכל thread, אבל באנדרואיד חלק מה-SDKs דורשים את ה-main thread — תמיד בדוק את התיעוד לגרסה הספציפית שלך.

אירועים מוגזמים. 300 אירועים בפרויקט זה כמעט תמיד בעיה. Google Analytics 4 מגביל ל-500 שמות אירועים ייחודיים לפרויקט Firebase. משחקים עם מעקב אגרסיבי מגיעים למגבלה זו.

מה כלול בעבודה

1. עיצוב טקסונומיית אירועים ספציפית לז'אנר המשחק ולמכניקות
2. יישום מעקב ב-Unity / iOS native (Swift) / Android native (Kotlin)
3. הגדרת מאפייני משתמש וזיהוי משתמש לאחר אימות
4. QA של כל אירוע דרך DebugView / Event Inspector
5. מסירת תיעוד עם כל האירועים והפרמטרים המתוארים

לוחות זמנים

עיצוב טקסונומיה ויישום למשחק עם 20–40 אירועים: 3–6 ימים תלוי במספר מכניקות המשחק. העלות מחושבת באופן אישי. אנו מספקים הערכת פרויקט — צור קשר לייעוץ. הזמן ביקורת על האנליטיקה הנוכחית שלך כדי להימנע מהפסדים נסתרים.